I have to admit that I am blown away by the commenters in here in favor of kernel level anti-cheat systems. They are incredibly invasive and flat out lazy and any company that adopts them loses me...
I have to admit that I am blown away by the commenters in here in favor of kernel level anti-cheat systems. They are incredibly invasive and flat out lazy and any company that adopts them loses me as a customer. I suspect that the big reason they push this is that server-side cheat detection requires that their servers do the work instead of the client PCs (reminds me of all the JS front-end heavy web apps). Hardware based cheats are becoming more prominent and these companies are going to be SOL because the punted on securing their side of the client/server paradigm.
We have different values. I do not believe that the kernel-level access significantly changes the level of risk presented to my personal data. The risk is already significant by installing their...
blown away by the commenters
We have different values.
They are incredibly invasive
I do not believe that the kernel-level access significantly changes the level of risk presented to my personal data. The risk is already significant by installing their user-mode game client.
they push this is that server-side cheat detection requires that their servers do the work instead of the client PCs
Valve continues to attempt this way of solving the problem, and continue to be behind their competitors.
Hardware based cheats are becoming more prominent
Hence why Riot is relying more on hardware level features to make the game client more impentrable.
This is a loss of agency on computers, absolutely. Would I prefer that game consoles had better M+K support built in, so that I could just game on that, and not be concerned about installing additional software on my computer, yes. But that isn't happening, so c'est la vie. I'd prefer to enjoy my games.
Oh yes it does. A piece of software that runs in kernel mode has the highest privileges any software on your system can have. This means if it wants to it can literally extract anything from other...
I do not believe that the kernel-level access significantly changes the level of risk presented to my personal data. The risk is already significant by installing their user-mode game client.
Oh yes it does. A piece of software that runs in kernel mode has the highest privileges any software on your system can have. This means if it wants to it can literally extract anything from other programs memory it wants to, intercept and record any communication with any device, (in theory) hide any piece of software in your system in a way that cannot even be detected by the operating system, or even modify you operating system in any way it pleases. Ever heard of rootkits?
Any software based sandboxing simply becomes impossible when you're dealing with kernel mode software. A normal piece of software could for example never look into your active browser sessions. A software running in kernel mode can easily extract anything from your browser's memory - for example any data of any website you visit (even if the communication is encrypted) including stuff like session cookies that allow for easy account takeover if forwarded to someone else. Or have your passsord manager unlocked? Congratulations - your anticheat can now read your password.
So any malicious piece of code introduced into a software with kernel level access voluntarily (e.g. for data collection), forced (e.g. by a state actor), or without the knowledge of the software's author (e.g. supply chain attack à la xzutils) is much bigger problem than it would be in usermode.
And that's only the perspective of malicious-by-design code. There's also the accidental perspective:
Even your operating system doesn't run most stuff in kernel mode. Because every little bug in a kernel level piece of code allows for easy takeover of your entire os. Suddenly running stuff for a f'ing game in kernel mode greatly increases your attack surface. And given recent incidents of some script kiddies abusing little bugs in kernel mode anti cheat we've seen recently, I don't have great confidence in the quality of those systems. The level of security auditing and public scrutiny is nowhere near that of your usual os kernel, and the focus of gaming companies is simply to get as much control over your system as possible to ensure you're doing nothing to interfere with their game. Security is not something they focus on during the development of such engines, only preventing you from doing things that could lead to them making less money from their game at all cost.
On another note:
One of the simplest solutions to escape cheaters ruining the fun for casual gamers would be to host private servers for your friends or some otherwise restricted group. I really miss games that easily allowed for that. Unfortunately game companies don't do that anymore to keep control and extort axditonal money via subscription/cosmetics/microtransactions. :(
I'm sure kernel mode antocheat systems have their place in a competitive e-sports setting, but for casual gamers it's just overkill.
Also the way I've seen compliance rules set up in many places a lot of people could lose their job due to negligence if they were to log into some work related account on a computer with kernel mode anticheat installed. I don't think most people actively realize that.
You vastly overestimate the security posture of user mode software on machines. As mentioned elsewhere, it is true that password managers decrypt into encrypted memory. It is also true that all...
You vastly overestimate the security posture of user mode software on machines.
As mentioned elsewhere, it is true that password managers decrypt into encrypted memory. It is also true that all password managers (except KeePass, if you configure an option) take the keyboard input in user mode. Hey presto, keylogged.
Cookies are stored in AppData on Windows. Why do you think Steam and Discord account stealers do not require administration access to hijack accounts?
I don't believe Chrome decrypts everything into protected memory, so I'd be very surprised if you needed kernel-level elevation to steal memory from it.
So, no, I don't think your examples are particularly meaningful to me.
And where do you store the memory encryption key for that encrypted memory? I highly doubt that most password managers manage that key via a TPM or use some kind of secure enclave such as Intel...
As mentioned elsewhere, it is true that password managers decrypt into encrypted memory
And where do you store the memory encryption key for that encrypted memory? I highly doubt that most password managers manage that key via a TPM or use some kind of secure enclave such as Intel SGX (which is deprecated anyway).
As for keyloggers - yes, there are better solutions than how windows handles it. Wayland is for example much better at isolating keystrokes so that only the current window can access them.
Cookies are stored in AppData on Windows.
Sure, accessing AppData can be done without running in kernel space, but there are file permissions under windows that are managed via access control lists. So some degree of isolation is still possible in user space, which doesn't hold true for kernel space software. Furthermore Browsers under Windows usually use the Windows Data Protection API to encrypt the cookies they store on disk with the current user's credidentials. It is however true, that a process running as the same user could access those files with the default settings unchanged.
I don't believe Chrome decrypts everything into protected memory, so I'd be very surprised if you needed kernel-level elevation to steal memory from it.
There's a difference between accessing files (as in stuff on your harddrive) created by a different process, and accessing an active processes memory (as in RAM content). It would be highly questionable if one userspace application could read/write from a different userspace application's address space without some kind of exploit. A kernel space application can easily do that. There's not just application data but also other stuff (e.g. various encryption keys) in memory that is never written to any file. The only way to protect your memory against passive introspection with complete read access to a machines physical RAM would be some kind of secure enclave that is implemented in hardware, encrypts the relevant memory regions, handles the encryption keys internally, and only runs authenticated code/commands.
Also one huge point that you're disregarding is the case of significantly increased attack surface. Each bug in a kernel module comes with an increased risk of enabling RCE in kernel space allowing for a complete remote takeover of your machine by a third party without a malicious software author. And as the focus of Anticheat developers is a lot different than that of OS developers, so negligence with regards to security is much more likely to occur. And its not like there've been no instances of kernel space anticheat solutions being buggy in the recent past.
And finally a kernel module rolled out across billions of devices due to every casual player having it makes it a VERY attractive target for malicious actors. It's just unnecessary risk imo.
This gets to the crux of what I’d prefer. Actual proper isolation and sandboxing. Macs have made a similar great effort here, and it’s why Riot are fine having a significantly less intrusive...
As for keyloggers - yes, there are better solutions than how windows handles it. Wayland is for example much better at isolating keystrokes so that only the current window can access them.
This gets to the crux of what I’d prefer. Actual proper isolation and sandboxing. Macs have made a similar great effort here, and it’s why Riot are fine having a significantly less intrusive solution on that platform.
It would be highly questionable if one userspace application could read/write from a different userspace application's address space without some kind of exploit
My friend, I just downloaded System Informer (portable), opened it with no admin access, and told it to dumps the strings from my Firefox process. I can clear as day see the browsing history of various pages I had open.
Like, I can only speak for myself. But the concerns you speak of, they’re not sufficiently worse than the existing sorry state of user mode.
But your comment about Wayland is the future I’d desire. Better isolation, no kernel-level access for anyone.
Valorant does not work on macOS in any way, shape or form. As for LoL, this is their justification for not porting Vanguard to macOS yet: ...which seems an awful lot like the situation of EAC on...
This gets to the crux of what I’d prefer. Actual proper isolation and sandboxing. Macs have made a similar great effort here, and it’s why Riot are fine having a significantly less intrusive solution on that platform.
Valorant does not work on macOS in any way, shape or form.
As for LoL, this is their justification for not porting Vanguard to macOS yet:
There isn't yet as much tooling on OSX for script development, although the "need" is growing. For now, Mac won't have Vanguard, but we've still got a few bullets in the chamber for when cheaters inevitably try to exploit this.
...which seems an awful lot like the situation of EAC on Linux.
As we were getting at in the “botting” section, some cheaters have begun to pivot to macOS VMs, in an effort to free themselves from the Vanguard requirement. This move was about as unexpected as syrup on pancakes, so we’re pleased to announce that Vanguard’s companion product, Embedded Vanguard (mVG) is coming soon to a Mac build near you. The unique security of the macOS environment allows us to be a little less stringent on defending its kernel, so as the name implies, this won’t require any extra installs—the security is “embedded” right into the game client. Further still, we’re actually already using mVG to great effect on VALORANT console and on Wild Rift.
Once it ships at the end of this year, we hope it will be the final blow to bots and to the two public scripting suite developers that are now grappling with the realization they wasted three months on porting cheats to OSX. Don’t worry too much though, Swift looks great on a resume.
You are partially correct. I still stand by my claim that virtual address spaces of different user space processes cannot be directly accessed by another user level process (without requesting...
My friend, I just downloaded System Informer (portable), opened it with no admin access, and told it to dumps the strings from my Firefox process. I can clear as day see the browsing history of various pages I had open.
You are partially correct. I still stand by my claim that virtual address spaces of different user space processes cannot be directly accessed by another user level process (without requesting help from the OS). However, Windows does provide a ReadProcessMemory and WriteProcessMemory debug API. With this API another process can access the memory of a different process of the same privilege level AND the same user, as long as security features such as PPL are not enabled for the process at hand. Arguably it would be nicer to have strict process isolation enabled by default and have the user explicitly confirm usage of the abovementioned API for a given process.
The important difference between using the API and directly accessing the memory as a kernel space application is, that the API has well-defined behaviour controlled by the operating system and can be subject to a number of security restrictions (although some aspects of the default security model of windows may need to be rethought), whereas an application in kernel space can circumvent any OS imposed restriction whatsoever.
Maybe the question why game companies want to use kernel level access in the first place is a good question to ask. They want to be able to scan the memory and monitor the behaviour of arbitrary applications. Why would they need kernel level access in the first place if this were possible in an unrestricted manmer for userspace applications?
But your comment about Wayland is the future I’d desire.
Note that my comment regarding Wayland may be a bit misleading. Wayland does consider any application untrusted, and thus isolates them against each other on the level it is operating at. Wayland is however just a communication protocol for UIs and does not consider the lower OS levels. The default security model of linux systems is user-based. So any process with the same UID is in principle considered trusted. There are additional isolation mechanisms (namespaces, cgroups, ACLs), but those may need to be explicitly configured to model a more restrictive security model all the way down to the lowest level.
Better isolation, no kernel-level access for anyone.
Yes, I agree, better isolation is absolutely desirable, and kernel access is something that should not be used lightly.
But personally I do also believe in user agency in so far that a system administrator should be able to make an informed decision to have something run at an arbitrarily high privilege level, but it should never happen implicitly, unnecessarily, or by default. The reason I say this is that I've seen the other extreme way to often as well: Companies using security as an excuse to enforce policies that create a monopoly for them in some area by hindering competition or directly extorting money. Things like 'you have to use my store to install any software at all, and by the way if you sell something via an application installed via my store you have to give me 30% even if the sold thing is completely unrelated to the software and the user may as well subscribe to your service or buy your product via your website without any additional fees at all.'
I guess what I'm saying is don't give kernel level access to software if not absolutely necesaary, but don't make the operating system vendor enforce that policy - just make the admin jump through reasonably many hurdles before arriving there.
I did think a little bit more about this point, and it's a fair criticism. I don't actually think most people are segmenting their systems in this way, but if they chose to do so, it is a shame...
API another process can access the memory of a different process of the same privilege level AND the same user
I did think a little bit more about this point, and it's a fair criticism. I don't actually think most people are segmenting their systems in this way, but if they chose to do so, it is a shame that kernel-level software provides a loophole for vendors to inspect all accounts.
(Of course, you could take this segmenting a million miles further: seperate Windows installs, both BitLockered? Hell, if you're using multiple installs, you can use Linux if you want, with FDE to stop data sniffing there. Or just Qubes, lol, although no competent anti-cheat will let you play video games using Qubes).
Maybe the question why game companies want to use kernel level access in the first place is a good question to ask. They want to be able to scan the memory and monitor the behaviour of arbitrary applications. Why would they need kernel level access in the first place if this were possible in an unrestricted manmer for userspace applications?
Because as we've discussed, user-mode can't read kernel-level memory (or even any sort of privileged memory), so cheat vendors will go there. Cheaters obviously don't worry about installing arbitrary kernel-level software.
My point is: for me, as a user of a single user machine, on a non-isolated operating system, all of my software runs in user mode. The scope for data stealing is outrageously high already, and so the kernel-level aspect doesn't particularly change my security posture.
I guess what I'm saying is don't give kernel level access to software if not absolutely necesaary, but don't make the operating system vendor enforce that policy - just make the admin jump through reasonably many hurdles before arriving there.
This is where it becomes tricky.
On the one hand, completely agree with you. I do worry about a future where users lack control over their computing technology. I totally agree with this user that adding kernel-level technology to co-op, or singleplayer titles, is a gross overstep of responsibility (as well as titles like GTA:Online, where they haven't even attempted to solve the inherent problem of trusting peer-to-peer networking being impossible - making it a server-based title should've been the first move). I basicially agree with everything he said, to be honest.
On the other hand, if you want a future where kernel-level anti-cheats aren't required, the game has to be able to attest that the environment is secure, which obviously takes way those user freedoms.
I read that as less “how close to the bare metal is the cheat or anti-cheat running” and more “I built a robot with a video camera and mechanical arms, how can anticheat ever detect this” Visually...
Hardware based cheats are becoming more prominent
Hence why Riot is relying more on hardware level features to make the game client more impentrable.
I read that as less “how close to the bare metal is the cheat or anti-cheat running” and more “I built a robot with a video camera and mechanical arms, how can anticheat ever detect this”
Visually processing and identifying elements on the screen faster than a human is getting easier and easier these days, with response times of a few milliseconds (compared to human reaction time which is somewhere around 200 milliseconds, maybe a bit higher or lower depending on the person and circumstances)
It’s not so far into the future that cheaters will be able to simply run their setup through a KVM switch (for example) that reads the screen output and augments the person’s keyboard and mouse movements from entirely off board hardware that never needs to directly connect to the computer (and therefore won’t be detected by even the most comprehensive anti-cheat software)
Don't worry, this kind of cheating is rare so it can be ignored for now. And when it inevitably grows due to other avenues for cheating being closed off, they can force their hand by requiring a...
Don't worry, this kind of cheating is rare so it can be ignored for now. And when it inevitably grows due to other avenues for cheating being closed off, they can force their hand by requiring a camera focused on your face and another focused on your hands to play. AI can then track and analyze your hand and eye movements to see if it matches your input, thereby ensuring competitive integrity! Yay!
I used to think that it's the server's job to perform anti cheat, but some cheats are done by simply presenting existing information in a different way: Games need to show player's casted shadows...
I used to think that it's the server's job to perform anti cheat, but some cheats are done by simply presenting existing information in a different way:
Games need to show player's casted shadows and sounds, so the server needs to send players' location and foodsteps before they're actually visible. Cheats make those fact more visible. Valorant simply make the player do not cast shadow, but the visibility algorithm is quite expensive especially when you need to run it for every edge of player models to every other player, instead of just you to the other players locally.
Cheats can help the player remember more information, like when was this ultimate used last (that your client was told), where was this player seen last, whether they entered a hotspot (perhaps to place vision wards)
Cheats can help the player with game knowledge, like if an objective marker is placed on a 2D map the cheat software can lookup spawn locations and reveal that the objective is in the 2nd floor/basement of the house saving time searching the area.
Modding can make something appear differently. Like character models that appear bigger than their hitboxes in bright colors.
Botting is another concern for some games
See OSRS's RuneLite as an example of how a game that supposedly do everything server-side can have "helper" software, although it is legitimatize in that game due to how dated the official client is. RuneScape 3 have Alt1 which is also allowed and operate purely by OCR.
Anyway I think the problem with kernel anti cheats are:
Some of them is always on when the game is not active (eg. Valorant's). User mode game client (incl. traditional anti cheat) normally completely exit when the user asked it to.
Some games do not cleanly uninstall the anti cheats and remove any driver trust. In an upcoming change this also needs to be disclosed on the Steam store, but I doubt they'd be declared correctly.
It runs at higher privilege than the game itself. Many modern games shouldn't require UAC prompts to run or install. (The last few games I played I clicked "no" in the UAC install prompts and they run just fine. Usually they're just to ensure you have latest MSVC installed, etc.)
Instead of making it another security layer, it instead get used by lazy developers to fix their flaws. It might even be cheaper than actually fixing it (eg. it might be cheaper to run P2P games and let the host cheat with anticheat bypass, than actually operating a global fleet of trusted dedicated servers and hire people to handle abuse reports). I believe boycott is the only way to increase this cost.
Coop games are increasingly adding anti cheats, and sometimes even single player mode also require one as it runs the exact same binary as the multiplayer mode. I think cheating and modding in single player games and private coop lobbies should be allowed. Previously you could run games with VAC/Punkbuster turned off without the ability to join multiplayer sessions that requires anticheat tickets. Now I don't think any modern games with anticheats allow that at all, as they believe that it make crackers able to develop cheats unhindered on the moddable version.
I wonder about the longevity of these games. Online games might have servers that shutdown, but peer to peer games and single player games can last forever. Adding highly coupled operating system integrations may make the game unplayable after some iterations of Windows. Unlike Denuvo, anticheats usually aren't removed.
It simply isn’t possible for the server to detect all or even most cheating, especially for something like valorant or CS. The client needs quite a lot of trust, simply for latency’s sake. If you...
It simply isn’t possible for the server to detect all or even most cheating, especially for something like valorant or CS. The client needs quite a lot of trust, simply for latency’s sake.
If you read the article, they actually describe an example where they detect hardware based hacks.
I don't think we're going to get far in here, no-one cares. The battle for our computers is lost, apparently. The corporations have won. Our data is theirs, and they're just laughing about it...
I don't think we're going to get far in here, no-one cares. The battle for our computers is lost, apparently. The corporations have won. Our data is theirs, and they're just laughing about it because too many people just don't care. Or worse, actively promote this utter shite.
If folks want to be beholden to a corporation, they should go buy Play Box Series 6 or whatever.
I'm going to put this post on ignore now, before I say something ban worthy.
I'm worried both about the games companies that will gradually erode my ability to play games on my chosen OS "Linux OS" (whatever the fuck that is), by spitefully disabling their games just...
I'm worried both about the games companies that will gradually erode my ability to play games on my chosen OS "Linux OS" (whatever the fuck that is), by spitefully disabling their games just because, and for the users who shill for them as if some game is worthwhile giving up control of your computer over.
I hope I'm wrong but these stinking attitudes are pushing us back down the hill of gaming compatibility again, after having taken so long to climb up it.
The primary purpose of the computer would be to turn on. Providing kernel level access enables situations like CloudStrike's bug on the windows kernel leaving entire industries stranded.
The primary purpose of the computer would be to turn on.
Providing kernel level access enables situations like CloudStrike's bug on the windows kernel leaving entire industries stranded.
Tradeoffs. To me, an invasive anti-cheat would easily be more desirable than a continuous stream of cheaters who turn the game unplayable. That said, I'm glad I'm not interested in such games so I...
Tradeoffs. To me, an invasive anti-cheat would easily be more desirable than a continuous stream of cheaters who turn the game unplayable. That said, I'm glad I'm not interested in such games so I don't need to pick one, as those are both admittedly bad choices.
The only thing I really use my computer for is games. If it can't play the games I want it to play, I might as well not have it. I also like playing competitive games where playing with a cheater...
The only thing I really use my computer for is games. If it can't play the games I want it to play, I might as well not have it. I also like playing competitive games where playing with a cheater completely ruins the fun of the game.
It's a pretty good tradeoff in my case, and does make a lot of sense.
It’s really a night and day difference between valorant and CS2 in terms of the overall player experience. You have people begging for Valve to add a kernel level anticheat in CS, and third party...
It’s really a night and day difference between valorant and CS2 in terms of the overall player experience. You have people begging for Valve to add a kernel level anticheat in CS, and third party kernel level anti cheat’s like faceit are popular.
Denuvo has also quietly been winning “the war against piracy”.
I see this as a good thing for PC gaming’s future - two of the major downsides compared to consoles have had serious change, and that should make publishers much happier to do a multi-release on PC.
You mean that waste of compute cycles eating at modern hardware performance? I don't think the normalization of code which acts as good faith spyware with an access level which recently caused a...
Denuvo has also quietly been winning “the war against piracy”.
You mean that waste of compute cycles eating at modern hardware performance?
I see this as a good thing for PC gaming’s future
I don't think the normalization of code which acts as good faith spyware with an access level which recently caused a global airport outage is at all reasonable for video game anti-cheat.
There are lots of reasons, I'll broadly cover two of them. First, the Linux kernel does not have a stable binary interface for kernel modules. Each module needs to be compiled for the exact kernel...
There are lots of reasons, I'll broadly cover two of them.
First, the Linux kernel does not have a stable binary interface for kernel modules. Each module needs to be compiled for the exact kernel version in use. For a number of technical and ideological reasons, this means any anti-cheat vendor would likely take the old Nvidia approach of shipping a "shim" module that can be built for each user's system and provide that binary interface for the proprietary module. This creates a lot of surface area for breakage, as anyone who has ever had to deal with Nvidia's proprietary Linux driver can attest.
Second, it's virtually impossible to truly secure the Linux kernel itself in a consumer setting, without imposing harsh device-level restrictions that would render Linux on that device no more consumer friendly than Windows and macOS. This is because anyone can build the Linux kernel from source and modify it to work however they want, including fundamentally neutering any anti-cheat modules that may need to be loaded. The only way around this is to only allow end users to play on approved devices with secureboot that only loads kernel images digitally signed by the vendor.
Friendly reminder that anticheat is not security, it's a TPM. It's job is specifically to prevent a user from controlling their own computer to make a 'trustworthy client', by means of obscurity....
Second, it's virtually impossible to truly secure the Linux kernel itself in a consumer setting
Friendly reminder that anticheat is not security, it's a TPM. It's job is specifically to prevent a user from controlling their own computer to make a 'trustworthy client', by means of obscurity.
If it were security, it would fail miserably, because it breaks two major security tenets:
After experiencing the lengths to which some companies will go to make their apps not run on unapproved Android builds for absolutely no reason, I find the way these solutions for preventing a...
After experiencing the lengths to which some companies will go to make their apps not run on unapproved Android builds for absolutely no reason, I find the way these solutions for preventing a user from controlling their own device are explicitly marketed using the word "security" pretty gross and misleading. I paid a lot of money for my devices, and I explicitly choose not to own consoles. I don't cheat and I don't want to turn my PC into a console for the convenience of others. Once this sort of thing is normalized you can bet it ends up being abused.
There are a lot of reasons why a real time networked video game client needs to know information about the game state that the player themself should not. Particularly a game as fast paced as your...
NEVER trust the client
There are a lot of reasons why a real time networked video game client needs to know information about the game state that the player themself should not. Particularly a game as fast paced as your typical multiplayer shooter.
On top of that, aimbots in particular do not rely on secret knowledge. Unless the cheater is rage hacking, there's not much you can do server-side to differentiate mouse inputs made by a well written cheat or a sufficiently skilled player.
All of that is true, which is why I said that anticheats make no sense from a security paradigm. Because, as I said, anticheat is not security, it's a TPM. It's not trying to enforce security...
All of that is true, which is why I said that anticheats make no sense from a security paradigm. Because, as I said, anticheat is not security, it's a TPM. It's not trying to enforce security goals, it's trying to be a TPM. Which is why using the term "security" to describe an anticheat is a bad idea - because anticheat is not security.
Riot’s focus for anti-cheat is on Windows right now, and there are no plans for Linux support with Valorant or League of Legends. While the Steam Deck supports some anti-cheats, developers like Riot are increasingly shying away from Linux. “You can freely manipulate the kernel, and there’s no user mode calls to attest that it’s even genuine,” says Koskinas. “You could make a Linux distribution that’s purpose-built for cheating and we’d be smoked.”
Yup basically as-is there's no ground to stand on, so to speak. My first thought was it should be possible, but on second thought I'm not so sure. Let's say Valve gets some sort of trust framework...
Yup basically as-is there's no ground to stand on, so to speak.
My first thought was it should be possible, but on second thought I'm not so sure. Let's say Valve gets some sort of trust framework merged into the Linux where the kernel, modules, and system libraries are signed by someone, the kernel only runs signed modules, and there are user space tools for inspecting the system validity. The anti-cheat in this case would be a closed source kernel module that only runs on signed kernels.
What I'm realizing is that it's going to be difficult to prevent a malicious kernel from appearing as a good kernel to the anti-cheat. You can't trust any system binaries or syscalls and even if you bring your own statically linked tooling I'm not sure what you can do to be confident you're looking at a good kernel?
Actually, you've twigged on the exact reason why Vanguard depends on Secure Boot & the requisite TPM chip and tries to load as early as possible - because it can't always trust the Windows kernel....
Actually, you've twigged on the exact reason why Vanguard depends on Secure Boot & the requisite TPM chip and tries to load as early as possible - because it can't always trust the Windows kernel.
Technically, there is no reason why Linux couldn't offer something where it carries forward a "chain of trust" of signed kernels and modules, started at boot. And from what I understand, part of this already exists - certain distros like RHEL already allow for a signed and trusted environment.
That said, I'm not familiar enough with Secure Boot support in Linux to know how trustworthy a setup this for the purposes of anti-cheat, and I'm also willing to bet that properly working Secure Boot setups in Linux are the exception rather than the rule. It's likely not feasible for the vast majority of hobbyist Linux setups out there - but could be possible for a known quantity like the Steam Deck.
A lot of distros support secure booting now. Provided the BIOS allows you to enroll a key. That was always the primary fear from the OSS crowd against secure boot... That OEMs would (per...
A lot of distros support secure booting now. Provided the BIOS allows you to enroll a key. That was always the primary fear from the OSS crowd against secure boot... That OEMs would (per Microsoft's demands requests) only enroll their signing key and then permalock it.
Apple has been using a form of Secure Boot on macOS for years now. It extends a chain of trust from EFI, through the bootloader, the kernel, all loaded modules, and even certain critical system...
Apple has been using a form of Secure Boot on macOS for years now. It extends a chain of trust from EFI, through the bootloader, the kernel, all loaded modules, and even certain critical system files. Nevertheless, you can turn this protection off by rebooting into Recovery mode. If you do so, certain applications that depend on a trusted environment like FaceTime and Messages won't work - which, to be clear, is a good thing from a security standpoint.
What if they remove the shutoff valve? They had the perfect opportunity during the switchover to Apple Silicon, but they didn't. And that's because, realistically, they can't. How else could you do driver development?
Won't this allow vendors to create locked down devices like the iPhone? Sure...but that's not a technological problem, that's a social problem. Just like you can't solve social problems with technology, you can't solve them by trying to stonewall a technology either.
Yes. That's why we should pass laws that allow end users to unlock their bootloaders. You can make a lock, but if you sell that lock, you must sell a key to go with it. The real problem is...
Sure...but that's not a technological problem, that's a social problem.
Yes. That's why we should pass laws that allow end users to unlock their bootloaders. You can make a lock, but if you sell that lock, you must sell a key to go with it.
The real problem is unchecked corporate power that lets 1 or 2 companies dictate the course of all computing.
The problem is that most PC vendors and especially motherboard vendors allow customers to enroll their own SecureBoot keys. This isn't a problem for RHEL customers, in fact they may even rely on...
The problem is that most PC vendors and especially motherboard vendors allow customers to enroll their own SecureBoot keys. This isn't a problem for RHEL customers, in fact they may even rely on this feature to enroll IBM's key. The chain of trust is about ensuring the owner of the hardware knows with certainty that it is only running the software they've vetted and that a malicious third party hasn't quietly replaced or modified the kernel image.
The threat model for cheating in video games is very different. The end user, the actual owner of the hardware and the software that runs on it, cannot be trusted. In order to truly maintain the chain of trust in that environment, you need a degree of control over their hardware that will not fly in the Linux community or even the PC gaming community as a whole. Including GPLv3 code on the device could become problematic. It would be TiVo all over again.
It's my understanding that although you can enroll your own keys, said environment won't be able to respond properly to any sort of attestation that only finds a specific set of whitelisted keys...
It's my understanding that although you can enroll your own keys, said environment won't be able to respond properly to any sort of attestation that only finds a specific set of whitelisted keys agreeable. That's...rather the point of using PKI, no?
IMO it's about more than just the steamdeck, they really seem to care about linux support. I'm just going to guess that a bunch of the people at Valve are Linux users as well. If they weren't then...
IMO it's about more than just the steamdeck, they really seem to care about linux support. I'm just going to guess that a bunch of the people at Valve are Linux users as well. If they weren't then I don't think they would have gone this far with proton, linux on the steamdeck, and hardware hackability/repairability.
Adding proprietary hardware and software to the steamdeck to make games function on it that wouldn't function on other Linux machines in such a blatant way... I think that might be the opposite of Valve's direction and motivations as a company. I might be totally off base on this one though.
There is also a bit of a split in the steamdeck userbase. There are non Linux users to which the deck is their only Linux device. Then there are regular Linux users. The attitude of regular Linux users towards companies who break Linux support with anticheat is a big old FU. As someone who falls in the latter category I would really STRONGLY prefer that the steamdeck stay a device that continues to help Linux support as a whole.
Valve basically controls the entire PC market, with (IIRC) 70% of PC games going through Steam, and Valve getting a 30% cut of that. At that scale, Valve's biggest threats are the platforms it...
If they weren't then I don't think they would have gone this far with proton, linux on the steamdeck, and hardware hackability/repairability.
Valve basically controls the entire PC market, with (IIRC) 70% of PC games going through Steam, and Valve getting a 30% cut of that. At that scale, Valve's biggest threats are the platforms it relies on. Back in the Windows 8 days, Microsoft tried to push a Windows Store app that sold games, and Valve realized that if Microsoft could gate features behind the Windows Store then Valve would just be screwed.
So they started work on supporting Mac/Linux. If Microsoft ever ramps up the Windows Store thing, then Valve will ramp up their Linux thing. Linux is Valve's acropolis.
Oh they are. The thing is they have to tread carefully because people (correctly) backlash whenever they push a little too quickly because otherwise it means the end of general-purpose computing....
If Microsoft ever ramps up the Windows Store thing
Oh they are. The thing is they have to tread carefully because people (correctly) backlash whenever they push a little too quickly because otherwise it means the end of general-purpose computing.
Remember when UWP was the future, the only way to install UWP was via Microsoft Store and Win32 was going to be deprecated.
At that point, they would essentially be killing Linux support for their games and replacing it exclusively with Deck support. Forcing the use of specific hardware seems antithetical to the whole...
At that point, they would essentially be killing Linux support for their games and replacing it exclusively with Deck support.
Forcing the use of specific hardware seems antithetical to the whole appeal of Linux to end-users, and would make the platform ultimately more restrictive than Windows.
True. I don’t personally think it’s impossible, but it does seem implausible. That’s quite a lot of work for a small Valve team for what amounts to, in the end, a small niche of games (which to be...
True. I don’t personally think it’s impossible, but it does seem implausible. That’s quite a lot of work for a small Valve team for what amounts to, in the end, a small niche of games (which to be frank don’t play all that well on a steam deck form factor).
It also needs buyin from developers. They could do all that and Riot could turn around and say “yeah, but 0.0001% of our player base would use a steam deck, so we appreciate the work but we’ll get to it in q4 2030”
I still know plenty of people who have quit or refuse to play Riot games because of Vanguard. Though that may be mostly because they just needed an excuse to quit and jumped on one that they could...
I still know plenty of people who have quit or refuse to play Riot games because of Vanguard. Though that may be mostly because they just needed an excuse to quit and jumped on one that they could use without being yelled at.
Can’t make an omelette without breaking a few eggs. No solution is going to be perfect, but for the people who are in the target demographic for valorant, it seems to be the best so far. No doubt...
Can’t make an omelette without breaking a few eggs. No solution is going to be perfect, but for the people who are in the target demographic for valorant, it seems to be the best so far.
No doubt drives out some more casual players, and maybe some of those would become hardcore, but you optimize for your player base in the end.
What I got out what obliviater said is that they meant that players already on the fence about Riot (there has been no shortage of controversies about things like allegations and lawsuits claiming...
What I got out what obliviater said is that they meant that players already on the fence about Riot (there has been no shortage of controversies about things like allegations and lawsuits claiming a toxic workplace culture, including gender discrimination and sexual harassment) and saw this as a final drop in the bucket to move away from Riot games.
Which I think is fair, you already have your doubts about the company and then they also introduce a far reaching kernel level piece of software.
Not mention that with vanguard there is a history of it overreaching and blocking benign things. Not only when someone is playing a game but outside of that as well.
Is that so? It truly doesn't feel that way, but I'm not knowledgeable enough (anymore). I stopped pirating games by the time Steam became useful, but aren't most games still readily available...
Denuvo has also quietly been winning “the war against piracy”.
Is that so? It truly doesn't feel that way, but I'm not knowledgeable enough (anymore). I stopped pirating games by the time Steam became useful, but aren't most games still readily available through torrents? I feel like Steam has done more than Denuvo.
I guess it depends on what you mean by "winning the war on piracy." There's the war against pirates themselves, which I don't think is truly a winnable conflict, and there's the war to be the...
I guess it depends on what you mean by "winning the war on piracy." There's the war against pirates themselves, which I don't think is truly a winnable conflict, and there's the war to be the most-used anti-piracy program, which Denuvo is clearly winning.
I'm with you though that Valve has figured out the best way to tackle games piracy, but they haven't done it in the way that I believe most people who consider such things think. Cost and accessibility, the two considerations that even GabeN pointed to in his famous quote on the topic, are big factors, but it goes beyond that. I think what's made Steam such an effective platform to combat piracy is the wishlist and Steam sales.
With very few exceptions, I will never pay full price for a game. This isn't really a principled choice; it's not like I think games are systemically overpriced, considering I spent roughly the same dollar amount to buy Final Fantasy 3/6 in 1994 as I could to buy Final Fantasy XVI in 2024, not accounting for inflation. I recognize that in some ways games are dramatically underpriced, at least when you consider historical context and the value you get for each dollar spent.
No, the reason I never pay full price is the same reason Steam is such an effective anti-piracy platform: Valve has managed through some really clever decisions to turn games purchasing itself into a value-add. By giving us the wishlist feature and notifying us when wishlisted games go on sale, then offering regular effectively store-wide sales events, Valve has turned the process of paying for games into a sort of game in its own right.
I've joked for years that if you look at the played versus unplayed games in my Steam library, it becomes clear that my hobby isn't playing games really, it's buying games so I can sit atop my hoard of unplayed titles like some kind of digital dragon. That may be a humorous way to conceptualize it, but the underlying idea is very much on the nose.
The fact of piracy is that access to games themselves is trivial. I can spend maybe ten minutes to find a healthy torrent of a title I'm interested in, and have it downloaded and ready to play in about the same amount of time it would take to purchase a legitimate license from Steam, download it and get it installed. Sure, there may be some complications owing to the game being cracked rather than legitimate, but that's kind of immaterial. Those complications are part of what makes piracy fun for those who take it on as a hobby, because oddly, being clever and finding workarounds for anti-piracy measures is part of the appeal of getting your games that way. That's not something I enjoy very much, but much to my surprise, curating my wishlist, being patient enough to wait for a discount I'm satisfied with, and surveying my library have turned out to be things things I do enjoy.
I don't think I'm alone in this. Just look at the number of people who get themselves worked up over clearing their backlogs. Hell, we have the backlog bingo thing going right now, and that simply wouldn't exist if Steam hadn't made the act of purchasing a game license itself attractive. No amount of hardware- or software-level DRM is ever going to hold a candle to the way Steam has incentivized paying for legitimate copies of games.
Nope. Denuvo games are pretty much uncracked until Denuvo is removed, which will happen eventually since the license is reportedly not cheap. There a handful of crackers that have broken past...
Nope. Denuvo games are pretty much uncracked until Denuvo is removed, which will happen eventually since the license is reportedly not cheap.
There a handful of crackers that have broken past Denuvo in the past, but one group got nabbed by law enforcement, the other is erratic and they all take months to do it.
For now, the pirates have been turned into patientgamers (or they just buy it secretly).
That's the one! Pretty sure they were one of the firsts and only one to crack Denuvo for the longest time. And no, I think it was a feud between crackers. Edit: Yeah, wikipedia actually lists...
That's the one! Pretty sure they were one of the firsts and only one to crack Denuvo for the longest time. And no, I think it was a feud between crackers.
Edit: Yeah, wikipedia actually lists that. Empress lashed out against Fitgirl and the entire arrest story. It's coming back to me.
Piracy is a classic example of "your opponents goals and your own goals don't actually have to oppose". Crackers want to eventually crack a game, although ideally sooner rather than later....
Piracy is a classic example of "your opponents goals and your own goals don't actually have to oppose".
Crackers want to eventually crack a game, although ideally sooner rather than later. Publishers want to keep the game uncracked for the 3-month window after launch, although ideally longer than that.
If Denuvo prevents a game from being cracked for e.g. 6 months, then publishers have achieved their goal. If crackers crack the game after 7 months, they've achieved their goal. So both sides can "win" the same war.
Steam has done more than Denuvo, because publishers' actions aren't necessarily rational (e.g. publisher CEOs might find it useful to scapegoat piracy, and wasting money on anti-piracy measures can be an effective method of convincing stockholders they actually believe that piracy is a problem), and providing good service often conflicts with other publisher goals (e.g. EGS might provide worse service but it potentially avoids losing 30% of revenue to Valve, which looks amazing to stockholders in the long term).
Denuvo is winning against piracy? When did this happen? Last time I checked, most recent big title games are still getting cracked. Metaphor: ReFantazio is a good example. Steam is just delivering...
Denuvo is winning against piracy?
When did this happen?
Last time I checked, most recent big title games are still getting cracked.
Metaphor: ReFantazio is a good example.
Steam is just delivering good service, and people that used to pirate games now just buy them.
I used to pirate games an awful lot. (Heck, I still do sometimes)
But now I buy games on steam without even playing them, purely because I used to play them a long time ago. Steam has made it so easy to have your games in 1 single place which is easy to manage, with frequent sales etc.
Metaphor is unique. Denuvo wasn't actually cracked, people just found a way to get around it using binaries from the demo version of the game. /r/CrackWatch maintains a list of Denuvo-protected...
Metaphor is unique. Denuvo wasn't actually cracked, people just found a way to get around it using binaries from the demo version of the game.
Interesting, thank you for letting me know. The thing is, I still would not say Denuvo is winning against piracy. Denuvo is expensive and only a handful of publishers are able to keep up the...
Interesting, thank you for letting me know.
The thing is, I still would not say Denuvo is winning against piracy.
Denuvo is expensive and only a handful of publishers are able to keep up the Denuvo license before the licence costs outweigh the profit, and the game gets pirated after the license is gone.
the other 99% of games still get pirated.. and those websites are updated with new cracked games on a daily basis. (Albeit not AAA games that released a week ago)
Sure, Denuvo is the market leader in this, but I would say the few publishers that are willing to pay for it are not representative of the gaming industry, and the crack status of these few games are certainly not representative of what is going on in the piracy world.
I think you're misunderstanding the fight against piracy. The goal is not to make sure a game can't ever be pirated under any circumstances, any solution that protects a game for a few months is...
I think you're misunderstanding the fight against piracy. The goal is not to make sure a game can't ever be pirated under any circumstances, any solution that protects a game for a few months is widely considered a success, as that is when piracy is shown to have the biggest impact on sales.
We don't really know how much Denuvo costs. All we really know is that these days it is sold as a subscription rather than per-game, so publishers now usually choose to remove it after a while. I think that is a good thing. Once the DRM has served its purpose, all it does is get in the way of the consumer.
I agree with you that what you explained is indeed the goal for companies is to protect the first few months, however I would say that cracking/pirating a game in the first few months is not the...
I agree with you that what you explained is indeed the goal for companies is to protect the first few months, however I would say that cracking/pirating a game in the first few months is not the goal for pirates.
Once a game gets their Denuvo removed and it gets cracked/pirated afterwards, pirates would chalk that up as a win. Usually because in these times people are not in a hurry to play games as people usually have a huge backlog.
All in all, I still do not think Denuvo is going to prevent/defeat piracy, but I do think that it defends the sales that companies are looking for as you mentioned.
I mean, no wonder a rootkit can cheaters. I don't play competitive games so I don't really care and don't have a solution, but it still baffles that so many people willingly install Vangaurd. Even...
I mean, no wonder a rootkit can cheaters. I don't play competitive games so I don't really care and don't have a solution, but it still baffles that so many people willingly install Vangaurd. Even if it will only run during the game later on, it's still a rootkit.
Since it has kernel access, it can pretty much do anything right? I mean, they are scanning memory by design. Maybe Windows kernel level protection is better tha I know, but in my mind they could...
Since it has kernel access, it can pretty much do anything right? I mean, they are scanning memory by design. Maybe Windows kernel level protection is better tha I know, but in my mind they could just read your memory. It's not that I don't trust the makers of Vangaurd, but that a thing you install for game that is always on with kernel level access is such an obvious security nightmare to me.
Again, I might be missing something here, so please correct me if I'm wrong.
But which part of this hypothetical anything actually scares you? For instance, is it the idea that they could keylog you? Steal your documents? Ransomware you? Steal your passwords? The...
Since it has kernel access, it can pretty much do anything right?
But which part of this hypothetical anything actually scares you?
For instance, is it the idea that they could keylog you? Steal your documents? Ransomware you? Steal your passwords?
The hypotheticals that most people worry about are possible without kernel-level access, or even admin-level access. Everything I listed, and far more, is possible without ever going to the kernel-level.
From Riot,
However, if your beef is only about data privacy at Riot, running the game client or running Vanguard makes not one bit of difference. Data can still be retrieved from user-mode, and we're all engineers for the same studio with the same goals, none of which are collecting your personal information. If Riot hasn't earned your trust, do not run our software.
This is waaaay underselling the level of access a rootkit grants. Rootkits can avoid normal detection and get access to things like PW's out of a password manager. And the fact that most users are...
This is waaaay underselling the level of access a rootkit grants. Rootkits can avoid normal detection and get access to things like PW's out of a password manager.
And the fact that most users are ignorant of some of the nastier stuff you could do with kernal access (for example disable fans and run everything at max until it breaks, installing itself on your hardware's firmware, etc) doesn't meant they aren't right to be concerned.
No one cared how crowdstrike worked until it blew up, and I think eventually one of these anticheats is going to be used for a very large attack.
The "upside" is that it's going to be such a complex attack with so much potential value that no 0 day is going to wind up in the hands of some script kiddy so it's not like a compromise is likely to be used for something as "mundane" as melting a bunch of player's PC's.
Edit -
Yeah no. Riot can already copy a stupid amount of data from your machine with the access given, but at the same time something at the kernel level has FAR more access.
True. Technically true, but in all practical purposes, not really relevant. 1Password, KeePassXC, and KeePass (by default) all launch in user mode, and ask for your password in user mode. Boom,...
Rootkits can avoid normal detection
True.
access to things like PW's out of a password manager
Technically true, but in all practical purposes, not really relevant.
1Password, KeePassXC, and KeePass (by default) all launch in user mode, and ask for your password in user mode. Boom, password keylogged. It doesn't matter if they decrypt to secure memory if the password for the keyfile has already been lost.
The list of caveats about where your password can be leaked in memory when using KeePass is scary. KeePassXC appears to be better for in-memory protection... but again, keyloggers. Like, I just validated it right now by creating my own keylogger using Python (pip install keylogger...), and running it in user mode.
No one cared how crowdstrike worked until it blew up
I mean, that was a stability problem, not a security problem. Vanguard's stability posturing is quite decent from what I understand (it should, in theory, not be vulnerable to the Crowdstrike problem).
but at the same time something at the kernel level has FAR more access.
This is hilarious - it's an argument that boils down to "nobody needs Linux, because nobody needs security, because everyone's security is already swiss cheese!". Uuuhhhhhhhhhhhhhhhhhh You have a...
This is hilarious - it's an argument that boils down to "nobody needs Linux, because nobody needs security, because everyone's security is already swiss cheese!".
Uuuhhhhhhhhhhhhhhhhhh
You have a very valid point, but, ew.
Half the reason security is swiss cheese is because legacy systems basically require that, and the other half is people not giving a shit when building new systems, because "security is already swiss cheese".
With a decent sandboxing system, access to the password manager would be the first thing to severely restrict. And then your argument would no longer be relevant. So my beef with your argument is that it's self-perpetuating.
Oh, I'm not suggesting that we shouldn't improve the security posture of modern operating systems. Hell, half of doing so would help resolve many cheating issues by itself! It's why Vanguard on...
Oh, I'm not suggesting that we shouldn't improve the security posture of modern operating systems. Hell, half of doing so would help resolve many cheating issues by itself! It's why Vanguard on macOS is significantly less intrusive than on Windows.
But why does it take kernel-level anti-cheat to have that discussion? It seems a needless distinction to the reality that modern operating systems are leaky faucets.
No, It was a dangerous practice suddenly affecting over a million machines problem. Everyone’s willing to take the risk because the moment the risk is actually understood it’s a massive problem...
I mean, that was a stability problem, not a security problem.
No, It was a dangerous practice suddenly affecting over a million machines problem. Everyone’s willing to take the risk because the moment the risk is actually understood it’s a massive problem and way too late.
But again, what does that really mean for people?
For people, at the bare minimum being forced to throw away their machine.
As I’ve already said elsewhere though I think a target like vanguard won’t be hit by some small entity as a 0 day on that will be FAR too valuable to waste on crypto locking a machine. It’s likely the sort of thing that’s sitting in a couple of state sponsored entries folders if it exists.
I expect that the era from around the 00-whenever shit really hits the fan to be seen in history as the largest series of security breaches ever. The vast amount of outright ignorant practices going on have already bit various governments in known ways, and I expect eventually something really nasty will happen.
Would I bet it’s vanguard that’s the one that tips it all over, no, but it’s crazy that one company has the ability to brick every machine its software is on
But vulnerabilities are also present in user-mode, and are frankly, just as scary. At an Apex Legends event, professional players were forced to play with cheats, live on air (and no, this had...
But vulnerabilities are also present in user-mode, and are frankly, just as scary.
Frankly, kernel-level anti-cheats are the least of my worries when talking about highly networked multiplayer games, where the teams just do not understand the severity of what is possible.
And in how many of these cases did every affected computer need to be thrown out? Because that’s the whole problem with a kernel level attack. You can’t just reinstall your OS as the nuclear...
And in how many of these cases did every affected computer need to be thrown out?
Because that’s the whole problem with a kernel level attack. You can’t just reinstall your OS as the nuclear option.
Edit- to be more accurate you can’t just replace the drive and say “oh well lost all that data”.
This is something that I've seen you repeat ad nauseum here and it's honestly on par with the if-you've-got-nothing-to-hide logical fallacy. If your, seemingly entire, stance is based on logical...
But which part of this hypothetical anything actually scares you?
For instance, is it the idea that they could keylog you? Steal your documents? Ransomware you? Steal your passwords?
This is something that I've seen you repeat ad nauseum here and it's honestly on par with the if-you've-got-nothing-to-hide logical fallacy. If your, seemingly entire, stance is based on logical fallacy you need to reassess your stance.
"All these things can happen without kernel access so you should just let kernel access happen." isn't the gotcha you seem to think it is. I can surveil you without entering your home, so you should just let me put cameras up inside it anyway.
(I’d like to preface this by saying that I really wish I could reply without bumping this thread relentlessly.) I dispute that. I say the action of installing the software is already the camera,...
(I’d like to preface this by saying that I really wish I could reply without bumping this thread relentlessly.)
I can surveil you without entering your home, so you should just let me put cameras up inside it anyway.
I dispute that. I say the action of installing the software is already the camera, and all the kernel-level driver is doing is bolting it down and installing an infrared sensor. Sure, the infrared sensor can see more, and bolting it down makes it harder to remove, but the problem is the fucking camera.
To be clear, my hypothetical perfect future is one where applications are properly sandboxed. Where kernel-level access is impossible, and you use modern techniques like eBPF for monitoring purposes. Ideally with some user agency built in, but you’re never going to be perfect here. Cheats to a large extent become far less useful here. Do it properly like PS5/Xbox, and you’re even removing the ability for hardware peeking.
That, or we give up on the idea of running competitive multiplayer titles on PCs, and consoles properly support mouse and keyboard. The input device is my problem, not the hardware. Screw Linux? Screw Windows too.
In my ideal world you don’t need to install the fucking camera. But right now? I don’t give a damn how powerful the camera is.
You're misusing that fallacy in a way that comes off very crass. Riot is not a government, it does not have a monopoly on violence, and if you don't trust Riot from a privacy perspective, I would...
This is something that I've seen you repeat ad nauseum here and it's honestly on par with the if-you've-got-nothing-to-hide logical fallacy.
You're misusing that fallacy in a way that comes off very crass. Riot is not a government, it does not have a monopoly on violence, and if you don't trust Riot from a privacy perspective, I would find it incoherent to merely stump for removal of their kernel anti-cheat instead of not playing their game.
So what they're saying here is LOL, your data, we could take that any time we want. Idiots.
However, if your beef is only about data privacy at Riot, running the game client or running Vanguard makes not one bit of difference. Data can still be retrieved from user-mode, and we're all engineers for the same studio with the same goals, none of which are collecting your personal information. If Riot hasn't earned your trust, do not run our software.
So what they're saying here is LOL, your data, we could take that any time we want. Idiots.
Yes. That’s the case for any program you run on your computer (Windows/Linux, Mac has quite decent restrictions). if you don’t trust the maker of the software, don’t run it.
Yes. That’s the case for any program you run on your computer (Windows/Linux, Mac has quite decent restrictions). if you don’t trust the maker of the software, don’t run it.
I think in order to qualify as a rootkit, it has to be designed with malicious intent. Otherwise your graphics driver would be one too. The bigger concern is that an unknown bug in Vanguard could...
I think in order to qualify as a rootkit, it has to be designed with malicious intent. Otherwise your graphics driver would be one too.
The bigger concern is that an unknown bug in Vanguard could be leveraged by an attacker to gain kernel-level access to your computer. So it boils down to how much you trust Riot to write safe code.
Nope. Not missing anything. If Riot wanted to do malicious things, they could do whatever they wanted. At the same time, they could already do a world of damage just from you running the...
Nope. Not missing anything. If Riot wanted to do malicious things, they could do whatever they wanted. At the same time, they could already do a world of damage just from you running the executable for the game. For many people, the leap from the latter to the former is not all that high.
In the end, if you think Riot may do something shady, you shouldn’t run any of their games, kernel level anticheat or not.
Will it? That seems a pretty narrow needle to thread. Either you trust Riot to not be a malicious actor, or you don’t, and in the latter you shouldn’t run anything from them. Maybe it will drive...
Will it? That seems a pretty narrow needle to thread. Either you trust Riot to not be a malicious actor, or you don’t, and in the latter you shouldn’t run anything from them.
Maybe it will drive away a lot of potential customers, but Riot seems to be doing fine on that aspect.
The issue is simple. If riot the company gets compromised and suddenly league/val/whatever starts injecting malicious code, the solution to that problem is an order of magnitude easier to handle...
The issue is simple. If riot the company gets compromised and suddenly league/val/whatever starts injecting malicious code, the solution to that problem is an order of magnitude easier to handle if they don't have kernel level access.
Sure. That’s part of the needle. It’s up to a particular individual’s appetite for risk vs their enjoyment from the game. That being said, if Riot was compromised, the juiciest target would be...
Sure. That’s part of the needle. It’s up to a particular individual’s appetite for risk vs their enjoyment from the game. That being said, if Riot was compromised, the juiciest target would be from the usual targets like credential theft, which is on the table kernel or not.
I believe you're either wrong or naive about what the juiciest target would be to suddenly have kernel level access to every single computer a riot game was played on. That's not some rogue group...
I believe you're either wrong or naive about what the juiciest target would be to suddenly have kernel level access to every single computer a riot game was played on.
That's not some rogue group trying to get rich quick from russia or whatever. That's state actor level target.
You will also have to trust that their anti cheat is never going to break and never will fail. It’s not just about what they could willingly do, but also what could happen in case of failure, that...
You will also have to trust that their anti cheat is never going to break and never will fail. It’s not just about what they could willingly do, but also what could happen in case of failure, that level of control could literally mean break your entire system, already happened with them and already happened with other services with the same level of access
Epic breaks basic functionality in Fortnite every other patch. Do people really have faith in game companies to not accidentally bork your machine in irreversible ways?
Epic breaks basic functionality in Fortnite every other patch.
Do people really have faith in game companies to not accidentally bork your machine in irreversible ways?
I have to admit that I am blown away by the commenters in here in favor of kernel level anti-cheat systems. They are incredibly invasive and flat out lazy and any company that adopts them loses me as a customer. I suspect that the big reason they push this is that server-side cheat detection requires that their servers do the work instead of the client PCs (reminds me of all the JS front-end heavy web apps). Hardware based cheats are becoming more prominent and these companies are going to be SOL because the punted on securing their side of the client/server paradigm.
We have different values.
I do not believe that the kernel-level access significantly changes the level of risk presented to my personal data. The risk is already significant by installing their user-mode game client.
Valve continues to attempt this way of solving the problem, and continue to be behind their competitors.
Hence why Riot is relying more on hardware level features to make the game client more impentrable.
This is a loss of agency on computers, absolutely. Would I prefer that game consoles had better M+K support built in, so that I could just game on that, and not be concerned about installing additional software on my computer, yes. But that isn't happening, so c'est la vie. I'd prefer to enjoy my games.
Oh yes it does. A piece of software that runs in kernel mode has the highest privileges any software on your system can have. This means if it wants to it can literally extract anything from other programs memory it wants to, intercept and record any communication with any device, (in theory) hide any piece of software in your system in a way that cannot even be detected by the operating system, or even modify you operating system in any way it pleases. Ever heard of rootkits?
Any software based sandboxing simply becomes impossible when you're dealing with kernel mode software. A normal piece of software could for example never look into your active browser sessions. A software running in kernel mode can easily extract anything from your browser's memory - for example any data of any website you visit (even if the communication is encrypted) including stuff like session cookies that allow for easy account takeover if forwarded to someone else. Or have your passsord manager unlocked? Congratulations - your anticheat can now read your password.
So any malicious piece of code introduced into a software with kernel level access voluntarily (e.g. for data collection), forced (e.g. by a state actor), or without the knowledge of the software's author (e.g. supply chain attack à la xzutils) is much bigger problem than it would be in usermode.
And that's only the perspective of malicious-by-design code. There's also the accidental perspective:
Even your operating system doesn't run most stuff in kernel mode. Because every little bug in a kernel level piece of code allows for easy takeover of your entire os. Suddenly running stuff for a f'ing game in kernel mode greatly increases your attack surface. And given recent incidents of some script kiddies abusing little bugs in kernel mode anti cheat we've seen recently, I don't have great confidence in the quality of those systems. The level of security auditing and public scrutiny is nowhere near that of your usual os kernel, and the focus of gaming companies is simply to get as much control over your system as possible to ensure you're doing nothing to interfere with their game. Security is not something they focus on during the development of such engines, only preventing you from doing things that could lead to them making less money from their game at all cost.
On another note:
One of the simplest solutions to escape cheaters ruining the fun for casual gamers would be to host private servers for your friends or some otherwise restricted group. I really miss games that easily allowed for that. Unfortunately game companies don't do that anymore to keep control and extort axditonal money via subscription/cosmetics/microtransactions. :(
I'm sure kernel mode antocheat systems have their place in a competitive e-sports setting, but for casual gamers it's just overkill.
Also the way I've seen compliance rules set up in many places a lot of people could lose their job due to negligence if they were to log into some work related account on a computer with kernel mode anticheat installed. I don't think most people actively realize that.
You vastly overestimate the security posture of user mode software on machines.
As mentioned elsewhere, it is true that password managers decrypt into encrypted memory. It is also true that all password managers (except KeePass, if you configure an option) take the keyboard input in user mode. Hey presto, keylogged.
Cookies are stored in AppData on Windows. Why do you think Steam and Discord account stealers do not require administration access to hijack accounts?
I don't believe Chrome decrypts everything into protected memory, so I'd be very surprised if you needed kernel-level elevation to steal memory from it.
So, no, I don't think your examples are particularly meaningful to me.
And where do you store the memory encryption key for that encrypted memory? I highly doubt that most password managers manage that key via a TPM or use some kind of secure enclave such as Intel SGX (which is deprecated anyway).
As for keyloggers - yes, there are better solutions than how windows handles it. Wayland is for example much better at isolating keystrokes so that only the current window can access them.
Sure, accessing AppData can be done without running in kernel space, but there are file permissions under windows that are managed via access control lists. So some degree of isolation is still possible in user space, which doesn't hold true for kernel space software. Furthermore Browsers under Windows usually use the Windows Data Protection API to encrypt the cookies they store on disk with the current user's credidentials. It is however true, that a process running as the same user could access those files with the default settings unchanged.
There's a difference between accessing files (as in stuff on your harddrive) created by a different process, and accessing an active processes memory (as in RAM content). It would be highly questionable if one userspace application could read/write from a different userspace application's address space without some kind of exploit. A kernel space application can easily do that. There's not just application data but also other stuff (e.g. various encryption keys) in memory that is never written to any file. The only way to protect your memory against passive introspection with complete read access to a machines physical RAM would be some kind of secure enclave that is implemented in hardware, encrypts the relevant memory regions, handles the encryption keys internally, and only runs authenticated code/commands.
Also one huge point that you're disregarding is the case of significantly increased attack surface. Each bug in a kernel module comes with an increased risk of enabling RCE in kernel space allowing for a complete remote takeover of your machine by a third party without a malicious software author. And as the focus of Anticheat developers is a lot different than that of OS developers, so negligence with regards to security is much more likely to occur. And its not like there've been no instances of kernel space anticheat solutions being buggy in the recent past.
And finally a kernel module rolled out across billions of devices due to every casual player having it makes it a VERY attractive target for malicious actors. It's just unnecessary risk imo.
This gets to the crux of what I’d prefer. Actual proper isolation and sandboxing. Macs have made a similar great effort here, and it’s why Riot are fine having a significantly less intrusive solution on that platform.
My friend, I just downloaded System Informer (portable), opened it with no admin access, and told it to dumps the strings from my Firefox process. I can clear as day see the browsing history of various pages I had open.
Like, I can only speak for myself. But the concerns you speak of, they’re not sufficiently worse than the existing sorry state of user mode.
But your comment about Wayland is the future I’d desire. Better isolation, no kernel-level access for anyone.
Valorant does not work on macOS in any way, shape or form.
As for LoL, this is their justification for not porting Vanguard to macOS yet:
...which seems an awful lot like the situation of EAC on Linux.
I'm actually referring to a later blog post by Riot here (you are referring to the first blog post),
You are partially correct. I still stand by my claim that virtual address spaces of different user space processes cannot be directly accessed by another user level process (without requesting help from the OS). However, Windows does provide a
ReadProcessMemoryandWriteProcessMemorydebug API. With this API another process can access the memory of a different process of the same privilege level AND the same user, as long as security features such as PPL are not enabled for the process at hand. Arguably it would be nicer to have strict process isolation enabled by default and have the user explicitly confirm usage of the abovementioned API for a given process.The important difference between using the API and directly accessing the memory as a kernel space application is, that the API has well-defined behaviour controlled by the operating system and can be subject to a number of security restrictions (although some aspects of the default security model of windows may need to be rethought), whereas an application in kernel space can circumvent any OS imposed restriction whatsoever.
Maybe the question why game companies want to use kernel level access in the first place is a good question to ask. They want to be able to scan the memory and monitor the behaviour of arbitrary applications. Why would they need kernel level access in the first place if this were possible in an unrestricted manmer for userspace applications?
Note that my comment regarding Wayland may be a bit misleading. Wayland does consider any application untrusted, and thus isolates them against each other on the level it is operating at. Wayland is however just a communication protocol for UIs and does not consider the lower OS levels. The default security model of linux systems is user-based. So any process with the same UID is in principle considered trusted. There are additional isolation mechanisms (namespaces, cgroups, ACLs), but those may need to be explicitly configured to model a more restrictive security model all the way down to the lowest level.
Yes, I agree, better isolation is absolutely desirable, and kernel access is something that should not be used lightly.
But personally I do also believe in user agency in so far that a system administrator should be able to make an informed decision to have something run at an arbitrarily high privilege level, but it should never happen implicitly, unnecessarily, or by default. The reason I say this is that I've seen the other extreme way to often as well: Companies using security as an excuse to enforce policies that create a monopoly for them in some area by hindering competition or directly extorting money. Things like 'you have to use my store to install any software at all, and by the way if you sell something via an application installed via my store you have to give me 30% even if the sold thing is completely unrelated to the software and the user may as well subscribe to your service or buy your product via your website without any additional fees at all.'
I guess what I'm saying is don't give kernel level access to software if not absolutely necesaary, but don't make the operating system vendor enforce that policy - just make the admin jump through reasonably many hurdles before arriving there.
I did think a little bit more about this point, and it's a fair criticism. I don't actually think most people are segmenting their systems in this way, but if they chose to do so, it is a shame that kernel-level software provides a loophole for vendors to inspect all accounts.
(Of course, you could take this segmenting a million miles further: seperate Windows installs, both BitLockered? Hell, if you're using multiple installs, you can use Linux if you want, with FDE to stop data sniffing there. Or just Qubes, lol, although no competent anti-cheat will let you play video games using Qubes).
Because as we've discussed, user-mode can't read kernel-level memory (or even any sort of privileged memory), so cheat vendors will go there. Cheaters obviously don't worry about installing arbitrary kernel-level software.
My point is: for me, as a user of a single user machine, on a non-isolated operating system, all of my software runs in user mode. The scope for data stealing is outrageously high already, and so the kernel-level aspect doesn't particularly change my security posture.
This is where it becomes tricky.
On the one hand, completely agree with you. I do worry about a future where users lack control over their computing technology. I totally agree with this user that adding kernel-level technology to co-op, or singleplayer titles, is a gross overstep of responsibility (as well as titles like GTA:Online, where they haven't even attempted to solve the inherent problem of trusting peer-to-peer networking being impossible - making it a server-based title should've been the first move). I basicially agree with everything he said, to be honest.
On the other hand, if you want a future where kernel-level anti-cheats aren't required, the game has to be able to attest that the environment is secure, which obviously takes way those user freedoms.
I read that as less “how close to the bare metal is the cheat or anti-cheat running” and more “I built a robot with a video camera and mechanical arms, how can anticheat ever detect this”
Visually processing and identifying elements on the screen faster than a human is getting easier and easier these days, with response times of a few milliseconds (compared to human reaction time which is somewhere around 200 milliseconds, maybe a bit higher or lower depending on the person and circumstances)
It’s not so far into the future that cheaters will be able to simply run their setup through a KVM switch (for example) that reads the screen output and augments the person’s keyboard and mouse movements from entirely off board hardware that never needs to directly connect to the computer (and therefore won’t be detected by even the most comprehensive anti-cheat software)
Don't worry, this kind of cheating is rare so it can be ignored for now. And when it inevitably grows due to other avenues for cheating being closed off, they can force their hand by requiring a camera focused on your face and another focused on your hands to play. AI can then track and analyze your hand and eye movements to see if it matches your input, thereby ensuring competitive integrity! Yay!
I used to think that it's the server's job to perform anti cheat, but some cheats are done by simply presenting existing information in a different way:
See OSRS's RuneLite as an example of how a game that supposedly do everything server-side can have "helper" software, although it is legitimatize in that game due to how dated the official client is. RuneScape 3 have Alt1 which is also allowed and operate purely by OCR.
Anyway I think the problem with kernel anti cheats are:
It simply isn’t possible for the server to detect all or even most cheating, especially for something like valorant or CS. The client needs quite a lot of trust, simply for latency’s sake.
If you read the article, they actually describe an example where they detect hardware based hacks.
I don't think we're going to get far in here, no-one cares. The battle for our computers is lost, apparently. The corporations have won. Our data is theirs, and they're just laughing about it because too many people just don't care. Or worse, actively promote this utter shite.
If folks want to be beholden to a corporation, they should go buy Play Box Series 6 or whatever.
I'm going to put this post on ignore now, before I say something ban worthy.
Meet the reboot-to-play game: https://better.game/#/faq
I'm worried both about the games companies that will gradually erode my ability to play games on my chosen OS "Linux OS" (whatever the fuck that is), by spitefully disabling their games just because, and for the users who shill for them as if some game is worthwhile giving up control of your computer over.
I hope I'm wrong but these stinking attitudes are pushing us back down the hill of gaming compatibility again, after having taken so long to climb up it.
It doesn’t seem “just because”. Their reasoning makes a lot of sense?
It does not. Would you like to explain why giving up control of the most vital part of your computer just for a game "makes a lot of sense"?
For a lot of people, playing games is the primary purpose of their computer.
The primary purpose of the computer would be to turn on.
Providing kernel level access enables situations like CloudStrike's bug on the windows kernel leaving entire industries stranded.
Tradeoffs. To me, an invasive anti-cheat would easily be more desirable than a continuous stream of cheaters who turn the game unplayable. That said, I'm glad I'm not interested in such games so I don't need to pick one, as those are both admittedly bad choices.
The only thing I really use my computer for is games. If it can't play the games I want it to play, I might as well not have it. I also like playing competitive games where playing with a cheater completely ruins the fun of the game.
It's a pretty good tradeoff in my case, and does make a lot of sense.
It’s really a night and day difference between valorant and CS2 in terms of the overall player experience. You have people begging for Valve to add a kernel level anticheat in CS, and third party kernel level anti cheat’s like faceit are popular.
Denuvo has also quietly been winning “the war against piracy”.
I see this as a good thing for PC gaming’s future - two of the major downsides compared to consoles have had serious change, and that should make publishers much happier to do a multi-release on PC.
You mean that waste of compute cycles eating at modern hardware performance?
I don't think the normalization of code which acts as good faith spyware with an access level which recently caused a global airport outage is at all reasonable for video game anti-cheat.
Valve will never add kernel-level anti-cheat to CS2 because it's virtually impossible to make that work on Linux
Why is it impossible?
There are lots of reasons, I'll broadly cover two of them.
First, the Linux kernel does not have a stable binary interface for kernel modules. Each module needs to be compiled for the exact kernel version in use. For a number of technical and ideological reasons, this means any anti-cheat vendor would likely take the old Nvidia approach of shipping a "shim" module that can be built for each user's system and provide that binary interface for the proprietary module. This creates a lot of surface area for breakage, as anyone who has ever had to deal with Nvidia's proprietary Linux driver can attest.
Second, it's virtually impossible to truly secure the Linux kernel itself in a consumer setting, without imposing harsh device-level restrictions that would render Linux on that device no more consumer friendly than Windows and macOS. This is because anyone can build the Linux kernel from source and modify it to work however they want, including fundamentally neutering any anti-cheat modules that may need to be loaded. The only way around this is to only allow end users to play on approved devices with secureboot that only loads kernel images digitally signed by the vendor.
Friendly reminder that anticheat is not security, it's a TPM. It's job is specifically to prevent a user from controlling their own computer to make a 'trustworthy client', by means of obscurity.
If it were security, it would fail miserably, because it breaks two major security tenets:
But again, anticheat systems are TPMs.
After experiencing the lengths to which some companies will go to make their apps not run on unapproved Android builds for absolutely no reason, I find the way these solutions for preventing a user from controlling their own device are explicitly marketed using the word "security" pretty gross and misleading. I paid a lot of money for my devices, and I explicitly choose not to own consoles. I don't cheat and I don't want to turn my PC into a console for the convenience of others. Once this sort of thing is normalized you can bet it ends up being abused.
There are a lot of reasons why a real time networked video game client needs to know information about the game state that the player themself should not. Particularly a game as fast paced as your typical multiplayer shooter.
On top of that, aimbots in particular do not rely on secret knowledge. Unless the cheater is rage hacking, there's not much you can do server-side to differentiate mouse inputs made by a well written cheat or a sufficiently skilled player.
All of that is true, which is why I said that anticheats make no sense from a security paradigm. Because, as I said, anticheat is not security, it's a TPM. It's not trying to enforce security goals, it's trying to be a TPM. Which is why using the term "security" to describe an anticheat is a bad idea - because anticheat is not security.
It was mentioned in the articles
Yup basically as-is there's no ground to stand on, so to speak.
My first thought was it should be possible, but on second thought I'm not so sure. Let's say Valve gets some sort of trust framework merged into the Linux where the kernel, modules, and system libraries are signed by someone, the kernel only runs signed modules, and there are user space tools for inspecting the system validity. The anti-cheat in this case would be a closed source kernel module that only runs on signed kernels.
What I'm realizing is that it's going to be difficult to prevent a malicious kernel from appearing as a good kernel to the anti-cheat. You can't trust any system binaries or syscalls and even if you bring your own statically linked tooling I'm not sure what you can do to be confident you're looking at a good kernel?
Actually, you've twigged on the exact reason why Vanguard depends on Secure Boot & the requisite TPM chip and tries to load as early as possible - because it can't always trust the Windows kernel.
Technically, there is no reason why Linux couldn't offer something where it carries forward a "chain of trust" of signed kernels and modules, started at boot. And from what I understand, part of this already exists - certain distros like RHEL already allow for a signed and trusted environment.
That said, I'm not familiar enough with Secure Boot support in Linux to know how trustworthy a setup this for the purposes of anti-cheat, and I'm also willing to bet that properly working Secure Boot setups in Linux are the exception rather than the rule. It's likely not feasible for the vast majority of hobbyist Linux setups out there - but could be possible for a known quantity like the Steam Deck.
A lot of distros support secure booting now. Provided the BIOS allows you to enroll a key. That was always the primary fear from the OSS crowd against secure boot... That OEMs would (per Microsoft's
demandsrequests) only enroll their signing key and then permalock it.And we see it with the iPhone.
Apple has been using a form of Secure Boot on macOS for years now. It extends a chain of trust from EFI, through the bootloader, the kernel, all loaded modules, and even certain critical system files. Nevertheless, you can turn this protection off by rebooting into Recovery mode. If you do so, certain applications that depend on a trusted environment like FaceTime and Messages won't work - which, to be clear, is a good thing from a security standpoint.
What if they remove the shutoff valve? They had the perfect opportunity during the switchover to Apple Silicon, but they didn't. And that's because, realistically, they can't. How else could you do driver development?
Won't this allow vendors to create locked down devices like the iPhone? Sure...but that's not a technological problem, that's a social problem. Just like you can't solve social problems with technology, you can't solve them by trying to stonewall a technology either.
Yes. That's why we should pass laws that allow end users to unlock their bootloaders. You can make a lock, but if you sell that lock, you must sell a key to go with it.
The real problem is unchecked corporate power that lets 1 or 2 companies dictate the course of all computing.
The problem is that most PC vendors and especially motherboard vendors allow customers to enroll their own SecureBoot keys. This isn't a problem for RHEL customers, in fact they may even rely on this feature to enroll IBM's key. The chain of trust is about ensuring the owner of the hardware knows with certainty that it is only running the software they've vetted and that a malicious third party hasn't quietly replaced or modified the kernel image.
The threat model for cheating in video games is very different. The end user, the actual owner of the hardware and the software that runs on it, cannot be trusted. In order to truly maintain the chain of trust in that environment, you need a degree of control over their hardware that will not fly in the Linux community or even the PC gaming community as a whole. Including GPLv3 code on the device could become problematic. It would be TiVo all over again.
It's my understanding that although you can enroll your own keys, said environment won't be able to respond properly to any sort of attestation that only finds a specific set of whitelisted keys agreeable. That's...rather the point of using PKI, no?
This problem is solved by having hardware and software beneath the kernel. On phones there is ARM TrustZone.
Valve could add the necessary hardware and software for attestation to the Steam Deck. There’s no reason it can’t be done.
IMO it's about more than just the steamdeck, they really seem to care about linux support. I'm just going to guess that a bunch of the people at Valve are Linux users as well. If they weren't then I don't think they would have gone this far with proton, linux on the steamdeck, and hardware hackability/repairability.
Adding proprietary hardware and software to the steamdeck to make games function on it that wouldn't function on other Linux machines in such a blatant way... I think that might be the opposite of Valve's direction and motivations as a company. I might be totally off base on this one though.
There is also a bit of a split in the steamdeck userbase. There are non Linux users to which the deck is their only Linux device. Then there are regular Linux users. The attitude of regular Linux users towards companies who break Linux support with anticheat is a big old FU. As someone who falls in the latter category I would really STRONGLY prefer that the steamdeck stay a device that continues to help Linux support as a whole.
Valve basically controls the entire PC market, with (IIRC) 70% of PC games going through Steam, and Valve getting a 30% cut of that. At that scale, Valve's biggest threats are the platforms it relies on. Back in the Windows 8 days, Microsoft tried to push a Windows Store app that sold games, and Valve realized that if Microsoft could gate features behind the Windows Store then Valve would just be screwed.
So they started work on supporting Mac/Linux. If Microsoft ever ramps up the Windows Store thing, then Valve will ramp up their Linux thing. Linux is Valve's acropolis.
That and the old commoditize your complement strategy.
Oh they are. The thing is they have to tread carefully because people (correctly) backlash whenever they push a little too quickly because otherwise it means the end of general-purpose computing.
Remember when UWP was the future, the only way to install UWP was via Microsoft Store and Win32 was going to be deprecated.
At that point, they would essentially be killing Linux support for their games and replacing it exclusively with Deck support.
Forcing the use of specific hardware seems antithetical to the whole appeal of Linux to end-users, and would make the platform ultimately more restrictive than Windows.
True. I don’t personally think it’s impossible, but it does seem implausible. That’s quite a lot of work for a small Valve team for what amounts to, in the end, a small niche of games (which to be frank don’t play all that well on a steam deck form factor).
It also needs buyin from developers. They could do all that and Riot could turn around and say “yeah, but 0.0001% of our player base would use a steam deck, so we appreciate the work but we’ll get to it in q4 2030”
I still know plenty of people who have quit or refuse to play Riot games because of Vanguard. Though that may be mostly because they just needed an excuse to quit and jumped on one that they could use without being yelled at.
Can’t make an omelette without breaking a few eggs. No solution is going to be perfect, but for the people who are in the target demographic for valorant, it seems to be the best so far.
No doubt drives out some more casual players, and maybe some of those would become hardcore, but you optimize for your player base in the end.
What I got out what obliviater said is that they meant that players already on the fence about Riot (there has been no shortage of controversies about things like allegations and lawsuits claiming a toxic workplace culture, including gender discrimination and sexual harassment) and saw this as a final drop in the bucket to move away from Riot games.
Which I think is fair, you already have your doubts about the company and then they also introduce a far reaching kernel level piece of software.
Not mention that with vanguard there is a history of it overreaching and blocking benign things. Not only when someone is playing a game but outside of that as well.
Is that so? It truly doesn't feel that way, but I'm not knowledgeable enough (anymore). I stopped pirating games by the time Steam became useful, but aren't most games still readily available through torrents? I feel like Steam has done more than Denuvo.
I guess it depends on what you mean by "winning the war on piracy." There's the war against pirates themselves, which I don't think is truly a winnable conflict, and there's the war to be the most-used anti-piracy program, which Denuvo is clearly winning.
I'm with you though that Valve has figured out the best way to tackle games piracy, but they haven't done it in the way that I believe most people who consider such things think. Cost and accessibility, the two considerations that even GabeN pointed to in his famous quote on the topic, are big factors, but it goes beyond that. I think what's made Steam such an effective platform to combat piracy is the wishlist and Steam sales.
With very few exceptions, I will never pay full price for a game. This isn't really a principled choice; it's not like I think games are systemically overpriced, considering I spent roughly the same dollar amount to buy Final Fantasy 3/6 in 1994 as I could to buy Final Fantasy XVI in 2024, not accounting for inflation. I recognize that in some ways games are dramatically underpriced, at least when you consider historical context and the value you get for each dollar spent.
No, the reason I never pay full price is the same reason Steam is such an effective anti-piracy platform: Valve has managed through some really clever decisions to turn games purchasing itself into a value-add. By giving us the wishlist feature and notifying us when wishlisted games go on sale, then offering regular effectively store-wide sales events, Valve has turned the process of paying for games into a sort of game in its own right.
I've joked for years that if you look at the played versus unplayed games in my Steam library, it becomes clear that my hobby isn't playing games really, it's buying games so I can sit atop my hoard of unplayed titles like some kind of digital dragon. That may be a humorous way to conceptualize it, but the underlying idea is very much on the nose.
The fact of piracy is that access to games themselves is trivial. I can spend maybe ten minutes to find a healthy torrent of a title I'm interested in, and have it downloaded and ready to play in about the same amount of time it would take to purchase a legitimate license from Steam, download it and get it installed. Sure, there may be some complications owing to the game being cracked rather than legitimate, but that's kind of immaterial. Those complications are part of what makes piracy fun for those who take it on as a hobby, because oddly, being clever and finding workarounds for anti-piracy measures is part of the appeal of getting your games that way. That's not something I enjoy very much, but much to my surprise, curating my wishlist, being patient enough to wait for a discount I'm satisfied with, and surveying my library have turned out to be things things I do enjoy.
I don't think I'm alone in this. Just look at the number of people who get themselves worked up over clearing their backlogs. Hell, we have the backlog bingo thing going right now, and that simply wouldn't exist if Steam hadn't made the act of purchasing a game license itself attractive. No amount of hardware- or software-level DRM is ever going to hold a candle to the way Steam has incentivized paying for legitimate copies of games.
Nope. Denuvo games are pretty much uncracked until Denuvo is removed, which will happen eventually since the license is reportedly not cheap.
There a handful of crackers that have broken past Denuvo in the past, but one group got nabbed by law enforcement, the other is erratic and they all take months to do it.
For now, the pirates have been turned into patientgamers (or they just buy it secretly).
Didn't one of those crackers have an epic meltdown? I vaguely remember something along those lines.
Well Empress has been quite the character for a while now. Maybe you're thinking of their statements made when releasing Hogwarts Legacy?
That's the one! Pretty sure they were one of the firsts and only one to crack Denuvo for the longest time. And no, I think it was a feud between crackers.
Edit: Yeah, wikipedia actually lists that. Empress lashed out against Fitgirl and the entire arrest story. It's coming back to me.
Piracy is a classic example of "your opponents goals and your own goals don't actually have to oppose".
Crackers want to eventually crack a game, although ideally sooner rather than later. Publishers want to keep the game uncracked for the 3-month window after launch, although ideally longer than that.
If Denuvo prevents a game from being cracked for e.g. 6 months, then publishers have achieved their goal. If crackers crack the game after 7 months, they've achieved their goal. So both sides can "win" the same war.
Steam has done more than Denuvo, because publishers' actions aren't necessarily rational (e.g. publisher CEOs might find it useful to scapegoat piracy, and wasting money on anti-piracy measures can be an effective method of convincing stockholders they actually believe that piracy is a problem), and providing good service often conflicts with other publisher goals (e.g. EGS might provide worse service but it potentially avoids losing 30% of revenue to Valve, which looks amazing to stockholders in the long term).
Denuvo is winning against piracy?
When did this happen?
Last time I checked, most recent big title games are still getting cracked.
Metaphor: ReFantazio is a good example.
Steam is just delivering good service, and people that used to pirate games now just buy them.
I used to pirate games an awful lot. (Heck, I still do sometimes)
But now I buy games on steam without even playing them, purely because I used to play them a long time ago. Steam has made it so easy to have your games in 1 single place which is easy to manage, with frequent sales etc.
Metaphor is unique. Denuvo wasn't actually cracked, people just found a way to get around it using binaries from the demo version of the game.
/r/CrackWatch maintains a list of Denuvo-protected games and their crack status. There are a lot of high profile AAA games on that list that are still uncracked years after release.
Interesting, thank you for letting me know.
The thing is, I still would not say Denuvo is winning against piracy.
Denuvo is expensive and only a handful of publishers are able to keep up the Denuvo license before the licence costs outweigh the profit, and the game gets pirated after the license is gone.
the other 99% of games still get pirated.. and those websites are updated with new cracked games on a daily basis. (Albeit not AAA games that released a week ago)
Sure, Denuvo is the market leader in this, but I would say the few publishers that are willing to pay for it are not representative of the gaming industry, and the crack status of these few games are certainly not representative of what is going on in the piracy world.
I think you're misunderstanding the fight against piracy. The goal is not to make sure a game can't ever be pirated under any circumstances, any solution that protects a game for a few months is widely considered a success, as that is when piracy is shown to have the biggest impact on sales.
We don't really know how much Denuvo costs. All we really know is that these days it is sold as a subscription rather than per-game, so publishers now usually choose to remove it after a while. I think that is a good thing. Once the DRM has served its purpose, all it does is get in the way of the consumer.
I agree with you that what you explained is indeed the goal for companies is to protect the first few months, however I would say that cracking/pirating a game in the first few months is not the goal for pirates.
Once a game gets their Denuvo removed and it gets cracked/pirated afterwards, pirates would chalk that up as a win. Usually because in these times people are not in a hurry to play games as people usually have a huge backlog.
All in all, I still do not think Denuvo is going to prevent/defeat piracy, but I do think that it defends the sales that companies are looking for as you mentioned.
Metaphor was a special case, since the demo didn’t have Denuvo, that allowed crackers to get a foothold.
I mean, no wonder a rootkit can cheaters. I don't play competitive games so I don't really care and don't have a solution, but it still baffles that so many people willingly install Vangaurd. Even if it will only run during the game later on, it's still a rootkit.
Some people really enjoy playing competitive FPS games. Different tradeoffs for different people.
Can I ask what specifically, you believe Vanguard has the capability do, that worries you, beyond just the word "rootkit"?
Since it has kernel access, it can pretty much do anything right? I mean, they are scanning memory by design. Maybe Windows kernel level protection is better tha I know, but in my mind they could just read your memory. It's not that I don't trust the makers of Vangaurd, but that a thing you install for game that is always on with kernel level access is such an obvious security nightmare to me.
Again, I might be missing something here, so please correct me if I'm wrong.
But which part of this hypothetical anything actually scares you?
For instance, is it the idea that they could keylog you? Steal your documents? Ransomware you? Steal your passwords?
The hypotheticals that most people worry about are possible without kernel-level access, or even admin-level access. Everything I listed, and far more, is possible without ever going to the kernel-level.
From Riot,
This is waaaay underselling the level of access a rootkit grants. Rootkits can avoid normal detection and get access to things like PW's out of a password manager.
And the fact that most users are ignorant of some of the nastier stuff you could do with kernal access (for example disable fans and run everything at max until it breaks, installing itself on your hardware's firmware, etc) doesn't meant they aren't right to be concerned.
No one cared how crowdstrike worked until it blew up, and I think eventually one of these anticheats is going to be used for a very large attack.
The "upside" is that it's going to be such a complex attack with so much potential value that no 0 day is going to wind up in the hands of some script kiddy so it's not like a compromise is likely to be used for something as "mundane" as melting a bunch of player's PC's.
Edit -
Yeah no. Riot can already copy a stupid amount of data from your machine with the access given, but at the same time something at the kernel level has FAR more access.
True.
Technically true, but in all practical purposes, not really relevant.
1Password, KeePassXC, and KeePass (by default) all launch in user mode, and ask for your password in user mode. Boom, password keylogged. It doesn't matter if they decrypt to secure memory if the password for the keyfile has already been lost.
The list of caveats about where your password can be leaked in memory when using KeePass is scary. KeePassXC appears to be better for in-memory protection... but again, keyloggers. Like, I just validated it right now by creating my own keylogger using Python (
pip install keylogger...), and running it in user mode.I mean, that was a stability problem, not a security problem. Vanguard's stability posturing is quite decent from what I understand (it should, in theory, not be vulnerable to the Crowdstrike problem).
But again, what does that really mean for people?
This is hilarious - it's an argument that boils down to "nobody needs Linux, because nobody needs security, because everyone's security is already swiss cheese!".
Uuuhhhhhhhhhhhhhhhhhh
You have a very valid point, but, ew.
Half the reason security is swiss cheese is because legacy systems basically require that, and the other half is people not giving a shit when building new systems, because "security is already swiss cheese".
With a decent sandboxing system, access to the password manager would be the first thing to severely restrict. And then your argument would no longer be relevant. So my beef with your argument is that it's self-perpetuating.
Oh, I'm not suggesting that we shouldn't improve the security posture of modern operating systems. Hell, half of doing so would help resolve many cheating issues by itself! It's why Vanguard on macOS is significantly less intrusive than on Windows.
But why does it take kernel-level anti-cheat to have that discussion? It seems a needless distinction to the reality that modern operating systems are leaky faucets.
No, It was a dangerous practice suddenly affecting over a million machines problem. Everyone’s willing to take the risk because the moment the risk is actually understood it’s a massive problem and way too late.
For people, at the bare minimum being forced to throw away their machine.
As I’ve already said elsewhere though I think a target like vanguard won’t be hit by some small entity as a 0 day on that will be FAR too valuable to waste on crypto locking a machine. It’s likely the sort of thing that’s sitting in a couple of state sponsored entries folders if it exists.
I expect that the era from around the 00-whenever shit really hits the fan to be seen in history as the largest series of security breaches ever. The vast amount of outright ignorant practices going on have already bit various governments in known ways, and I expect eventually something really nasty will happen.
Would I bet it’s vanguard that’s the one that tips it all over, no, but it’s crazy that one company has the ability to brick every machine its software is on
Like I said above, I don't worry about Riot doing that, but an attacker that found a vulnerability in Vangaurd.
But vulnerabilities are also present in user-mode, and are frankly, just as scary.
At an Apex Legends event, professional players were forced to play with cheats, live on air (and no, this had nothing to do with their anti-cheat solution). A worm began propogating itself through MW2, despite Activision knowing about the bug for years.
Frankly, kernel-level anti-cheats are the least of my worries when talking about highly networked multiplayer games, where the teams just do not understand the severity of what is possible.
And in how many of these cases did every affected computer need to be thrown out?
Because that’s the whole problem with a kernel level attack. You can’t just reinstall your OS as the nuclear option.
Edit- to be more accurate you can’t just replace the drive and say “oh well lost all that data”.
Hm, that's a really good point. I guess you are right: at least Riot is aware of the security risk and they seem to handle it well.
This is something that I've seen you repeat ad nauseum here and it's honestly on par with the if-you've-got-nothing-to-hide logical fallacy. If your, seemingly entire, stance is based on logical fallacy you need to reassess your stance.
"All these things can happen without kernel access so you should just let kernel access happen." isn't the gotcha you seem to think it is. I can surveil you without entering your home, so you should just let me put cameras up inside it anyway.
(I’d like to preface this by saying that I really wish I could reply without bumping this thread relentlessly.)
I dispute that. I say the action of installing the software is already the camera, and all the kernel-level driver is doing is bolting it down and installing an infrared sensor. Sure, the infrared sensor can see more, and bolting it down makes it harder to remove, but the problem is the fucking camera.
To be clear, my hypothetical perfect future is one where applications are properly sandboxed. Where kernel-level access is impossible, and you use modern techniques like eBPF for monitoring purposes. Ideally with some user agency built in, but you’re never going to be perfect here. Cheats to a large extent become far less useful here. Do it properly like PS5/Xbox, and you’re even removing the ability for hardware peeking.
That, or we give up on the idea of running competitive multiplayer titles on PCs, and consoles properly support mouse and keyboard. The input device is my problem, not the hardware. Screw Linux? Screw Windows too.
In my ideal world you don’t need to install the fucking camera. But right now? I don’t give a damn how powerful the camera is.
You're misusing that fallacy in a way that comes off very crass. Riot is not a government, it does not have a monopoly on violence, and if you don't trust Riot from a privacy perspective, I would find it incoherent to merely stump for removal of their kernel anti-cheat instead of not playing their game.
So what they're saying here is LOL, your data, we could take that any time we want. Idiots.
Yes. That’s the case for any program you run on your computer (Windows/Linux, Mac has quite decent restrictions). if you don’t trust the maker of the software, don’t run it.
I think in order to qualify as a rootkit, it has to be designed with malicious intent. Otherwise your graphics driver would be one too.
The bigger concern is that an unknown bug in Vanguard could be leveraged by an attacker to gain kernel-level access to your computer. So it boils down to how much you trust Riot to write safe code.
Well, I trust no-one to write perfect code. Nearly all well-known programs have had bugs and vulnerabilities, so that is indeed my worry.
Nope. Not missing anything. If Riot wanted to do malicious things, they could do whatever they wanted. At the same time, they could already do a world of damage just from you running the executable for the game. For many people, the leap from the latter to the former is not all that high.
In the end, if you think Riot may do something shady, you shouldn’t run any of their games, kernel level anticheat or not.
At what cost?
I would never trust a company like Riot where farting at your employees is normal behavior to have a rootkit on my PC.
Would you trust such a company to run an executable on your computer? Those face farters could be keylogging you from the moment you start the client.
Not really, no. Luckily their games are quite bad anyway.
So the existence of the kernel level anticheat doesn’t actually make any difference.
Not for me, no. But for many others it will.
Will it? That seems a pretty narrow needle to thread. Either you trust Riot to not be a malicious actor, or you don’t, and in the latter you shouldn’t run anything from them.
Maybe it will drive away a lot of potential customers, but Riot seems to be doing fine on that aspect.
The issue is simple. If riot the company gets compromised and suddenly league/val/whatever starts injecting malicious code, the solution to that problem is an order of magnitude easier to handle if they don't have kernel level access.
Sure. That’s part of the needle. It’s up to a particular individual’s appetite for risk vs their enjoyment from the game. That being said, if Riot was compromised, the juiciest target would be from the usual targets like credential theft, which is on the table kernel or not.
I believe you're either wrong or naive about what the juiciest target would be to suddenly have kernel level access to every single computer a riot game was played on.
That's not some rogue group trying to get rich quick from russia or whatever. That's state actor level target.
You will also have to trust that their anti cheat is never going to break and never will fail. It’s not just about what they could willingly do, but also what could happen in case of failure, that level of control could literally mean break your entire system, already happened with them and already happened with other services with the same level of access
Epic breaks basic functionality in Fortnite every other patch.
Do people really have faith in game companies to not accidentally bork your machine in irreversible ways?
I don't really understand what you're after with this interrogation style commentary.