I miss PUBG, but the fundamental purpose of anti-cheat software is to circumvent and curtail user freedom. I don't really want affordances for that in my OS.
Strongly agreed. Some people want kernel-level anticheat for Linux. I think that's a huge mistake. Ideally, kernel-level anticheat would be done away with altogether. More realistically, I'm just going to avoid any games which use kernel-level anticheat, even if it means missing out.
2) The anti-cheat is the game's entire reason for being. It is the main focus of the development and marketing. People buy Valorant for the anti-cheat; they are willing to accept a kernel driver as a trade off for fairer competition.
Honest question: do you segment your activities on your computer on different users?
No? In which case, what practical spyware risk does a kernel level driver add that user mode software can’t do?
User mode software can spy on your clipboard, surreptitiously take screenshots, and take data out of your system. That spooks me enough that, if I don’t trust a software manufacturer, I don’t install it. Kernel mode makes no practical difference in my security posture.
The way I described it to a friend was to use this analogy:
Imagine you have someone over for game night, and before you play they say "Oh, by the way, I need the keys to the filing cabinet where you keep all your tax returns and whatnot." To which you might respond, "Wait, you need to read my tax returns before we can play this game?" And they say, "Oh, I'm not going to read them, I just need to hold the key while we play."
And you would rightly tell them to piss off and get out of your house, because that makes no sense. If you really wanted to torture the metaphor, you could I guess argue that they need full access to your house just in case you decide to pull some loaded dice out of the filing cabinet or something, but that's not really the important thing to me. The important thing is that, regardless of whether or not I trust the developer of the anti-cheat, the game just isn't that important.
It is the same stance as calling Windows games, developed for Windows, using DirectX, without any consideration of the studios to ever target GNU/Linux, even though they might actually target Android/Linux with other titles, Linux games.
Because somehow Proton is better than standing for actual GNU/Linux games.
So like IBM with OS/2 and Windows, studios keep ignoring Linux, and let Valve do whatever is needed, it is Valve's problem to sort out.
The author cites fear mongering over kernel anticheat, but I don't think anyone reasonable should be ok with their personal computer having kernel anticheat installed.
Genshin's anticheat was used to install ransomware, ESEA's anticheat was used to install bitcoin miners on users machines, EA's anticheat was used to hack clients computers during a tournament, etc.
When not explicitly malicious, anticheat software is at best spyware that's spying on your computer use to identify cheating. People complain a ton about Microsoft recall storing screenshots of your computer locally being a security risk, and yet they're fine with a Chinese owned anticheat program taking screenshots of your computer and uploading them online. And even if the company isn't trying to use that info to spy on you, my understanding is that when you're a chinese company, you have to give full access of that data to the government.
With the ongoing/rising tensions between the US and China, I actually think there's a significant chance that we may see all Chinese owned anticheat programs banned in the US, which would be pretty significant since they own or partially own the majority (as far as I know).
Can't help but consider how, perhaps, this could be a teaching moment for other folks. I know "convenience reigns supreme" but getting perhaps less-tech savvy gamers knowledgeable about what is being given up when you use anti-cheat.
Alas, I'd like to believe we could be in an era of "hey, not a problem, just have a dedicated gaming machine," but that too is difficult.
This is one use case where I think the idea of cloud gaming (e.g. google stadia) could make some sense. Having this as an alternative for linux users would be nice.
It's much harder to cheat if the game isn't running on your computer.
I don't personally see an issue that my computer can't run literal rootkits being shipped with the game. But I concede that not everyone shares my preferences, and if you wish to run this malware you should be able to do so.
Bigger showstopper is probably that video game devs won't put energy into Linux support, unless we're talking about Android. Wine isn't going to translate the anticheat.
Cheats are why I stopped playing FPS's and only occasionally play Rocket League. I can't tell if I'm bad at the game or if everyone else is cheating. Half of the games on this list are FPS's.
I think the more important question isn't how you implement an anti-cheat, it's why some types of games attract cheaters.
When victory in a game isn't about strategy but just about how quickly you can click o character's head, and just by doing it once you win the game, that makes the whole game a clear target for cheating. Everyone cheats as the sniper, nobody cheats as the medic.
I think you could make an FPS that cheaters hate by designing it so that it requires at least 2 players to defeat a player on the opposite team, e.g. by giving everyone weapons of different type and needing two types to defeat an enemy.
I feel like the only other solution to kernel-level anticheat is some kind of measured and verified system image. The whole chain has to be signed and trusted from the TPM through the kernel to userspace. This way if anyone tampers with the system the game will refuse to launch. I think something like this is already possible with systemd or is at least the long term goal IIRC from Lennart's blog.
IME these systems can be quite fragile in practice. All it takes is one pre-signature exploit (like U-boot parsing ext4 and devicetree before verifying signature) and your whole chain becomes useless.
And while the kernel is quite secure against hacks from userspace, the hardware interfaces are generally more trusted. This is not a problem on smartphones or embedded devices where you can obfuscate everything on a small SoC but the whole PC/x86_64 platform is much more flexible and open. I doubt there is a way to get reliable attestation on current desktop systems (many of which are assembled from independent parts) unless you get complete buy-in from all the manufacturers.
Finally, with AI systems recently increasing in power, perhaps soon the nuclear option of camera + CV + keyboard/mouse will become practical.
Then cheaters will be able to just patch the game startup code so it skips the TPM check. If the game executable were encrypted to the TPM somehow, that might work then though.
I thought DMA cheats rendered all of these anticheat efforts useless? It feels like the future of anticheat should probably be focused on how to efficiently send player data to clients only when they would be able to interact with them anyway. Or replay moderation?
One way to do anti-cheat on linux without compromising the sanctity of your host kernel would be to run the game inside a hardware-protected VM.
Anti-cheat does not ordinarily like to run inside a VM, because then the hypervisor can do the cheating, invisibly to the kernel. However, technologies like AMD SEV can (in theory) protect the guest from the host, using memory encryption. (And potentially also protect from DMA-based cheats, too)
What you'd need is some way for the hardware to attest to the guest "yes, you really are running inside SEV".
It's an unpopular opinion, but for better or worse, this is why I think it still makes sense to have a dedicated games machine separate from the main computer.
I'm largely a console gamer, so I don't have to worry about EA's latest malware opening my computer up to the world. I'm also a filthy casual though.
Let me ask you a question. How many vulnerable drivers (yes, those that can be abused by bad actors to gain kernel access) do you think the average gamer has on their Windows install? I’ll start with my own system. This is what I can immediately think of:
• MSI Afterburner - RTCore64.sys driver (yes, even in the latest version) has a vulnerability that allows any usermode process to read and write any kernel memory it wishes
• CPU-Z - cpuz142_x64.sys driver has (again) kernel memory read/write vulnerability and MSR register read/write
If I looked hard enough, I would most likely find more.
Was going to post this on a now-deleted comment about anticheat being a hard problem, so popping it here because it might be relevant:
Anticheat is only hard because people are looking for a technical solution to a social problem. The actual way to get a good game in most things is to only play with people you trust and, if you think someone is cheating, stop trusting them and stop playing with them.
This doesn't scale to massive matchmaking scenarios of course - and so many modern games don't even offer it as an option - so companies would have to give up the automatic ranking of all players and the promise of dopamine that can be weaponised against them, but it works for sports in the real world and it worked for the likes of Quake, UT, etc. so I don't think it's a necessarily bad idea. Social ostracism is an incredibly powerful force.
However, it does mean that the big publishers wouldn't have control over everything a player does. Getting them to agree to that is probably the real hard problem.
My naive take is that technical solutions are possible, but critically they can’t be fully automated. The most effective anti-cheat solution possible probably looks something like a full-time in-house team comprised of seasoned ITSEC, data nerds, a couple of ML people, and a few devs. A team like that could probably pick out and boot cheaters with a very low rate of false positives given adequate data to crunch, and they’d only get better over time as they build a roster of patterns and behaviors to match against.
The problem is that this costs more than game companies are willing to spend, even when they’re raking in cash hand over fist. As long as the problem isn’t so bad that it’s making players quit, it’s cheaper to employ more automated, less effective strategies. The end goal isn’t player happiness, it’s higher profit margins.
I cannot agree. Getting a Quake game up in the early 2000s could take hours worth of sitting in IRC pickup channels, if it happened at all. I don't feel publishers are at fault here. I figure the vast majority of players would pick an instant game with potential cheaters over an hour wait for a 50% chance at a game.
> The actual way to get a good game in most things is to only play with people you trust and, if you think someone is cheating, stop trusting them and stop playing with them.
One of the games mentioned in this article is Rust. Playing with only people you trust defeats the point because it's a game full of betrayal. At best you'll be able to get a group together once and then destroy your relationships more than Monopoly would.
Making sure you can get enough people together for a game is one thing; making sure you can get enough people together for a game that you know aren't cheating is even harder. Most "friends" these days are online-only acquaintances that you simply can't know well enough to know if they're cheating or not. In the heat of the moment while playing a game it's tough to tell if someone's cheating or just good at the game. The toxicity of people being accused of cheating and defending themselves will quickly split apart any acquaintance group.
Thanks. Personally, I simply refuse to install games with anti-cheats, be it on Linux or on Windows. This mostly leaves me with FOSS games and small communities. For instance, Zero-K. Zero-K is curiously fine for large team games - you will usually find players to play with anytime - but if you are looking for PvP you have to be there when the right players are usually online. Being there and available for a game can be a way to contribute to a FOSS project too.
In some cases there are numerous public servers, which can mitigate the "player availability" problem.
Also, for these online FOSS games the servers are community-owned and moderated. Cheaters, trolls, inappropriate chats are monitored by someone who is interested in, and generally quite knowledgeable about, the game.
The cat and mouse game between cheat devs and anti-cheat devs is quite interesting. I saw a nice video [1] a year ago about the state of the art in cheat development, which at that point was having a PCIe device that can issue DMA requests to read the RAM at any time and stream the data to a second PC to analyse. Vanguard did end up banning those people eventually, since it can see what devices you have plugged in. I can't help but wonder if the next level would be some kind of shim on the physical RAM sticks; or maybe custom UEFI firmware.
Ultimately the OS should be providing a service that can verify a program is running in a secure environment and hasn't been tampered with. That's something that's useful for things far beyond games. I kind of hope the cheaters win this war for now, to create the incentive for building a better, proper, standardized, cross-platform solution.
TL;DR: Malware level / kernel invasive anti cheats idea that relies on some opaque anti-user blobs is conceptually incompatible with Linux and open source in general.
Proponents of such junk can get lost with their fake justifications of why kernel level anti-cheat malware should be acceptable. They should instead work on server side anti-cheats.
Is cheating possible because games are written in low level languages which have to have precise tracked positions of elements in memory?
If your garbage collector is grabbing an entire arena of memory and moving it constantly, doesn't that limit a cheat to asking an API to retrieve an object because only the managed memory knows where objects reside at any given moment?
No. When you write code in a high-level language, your data is still in-memory offset at some 'precise tracked position', even if you are not being explicit/conscious about that layout.
Games that use high-level languages are often easier to hack. e.g. Escape from Tarkov is one of the most hacked games because players can hook directly into its C# script VM, writing code as easily as if they had the original source.
TL;DR: the issue of anti-cheat on Linux is that Linux actually gives the user full control of their OS, which precludes all even remotely effective anti-cheat mechanisms by design.
Everyone is thinking about this problem the wrong way. Just use remote attestation.
Who needs opaque binary blob kernel modules or whatever for anti-cheat when you can bootstrap a secure boot and remote attestation setup? It's possible for a game server to verify cryptographically that someone is running stock firmware, stock bootloader, stock TCB userspace, a stock game executable, and that no debugger is attached. You don't need cat and mouse BS with executable obfuscation. You don't need inscrutable spyware. You don't need to prohibit VMs. All you need to do is configure your program not to be debuggable, prohibit network MITM (e.g. with certificate pinning), and then use remote attestation to make sure nobody has tampered with the system to make it ignore your anti debugging configuration.
All of the components involved in this trust chain can be open source. There's no spyware involved. No rootkit. No obfuscation. Everything is transparent and above board.
The only downside (besides implementation complexity) is that the remote attestation scheme is incompatible with running custom builds of the components remotely attested. But so what? Doing so isn't a requirement of open source. You can still run custom builds too -- just not at the same time you play your game.
Kernel level anti-cheat a short term curse with long term damages. For those wondering about the short term, here's a cheat that will never be handled by rootki-anticheat: https://youtu.be/9alJwQG-Wbk (vid description, an aimbot that triggers your human muscles to aim faster than any unaugmented human) That solution was effectively made from a box of scraps. Now imagine in a year when some go getters package and sell it to the mass market.
Long term damages are self explanatory, it's called a-rootkit
Targeting perfect fairness in a multiplayer video game with arbitrary latency between participants is a waste of energy. A much better target is to make it feel like no one is cheating. I don't really care too much if someone is actually better or worse than me at counterstrike. What I mostly care about is wildly implausible gameplay. No one is going to stop the guy who is getting a 5% gain on his ELO by using a 2nd computer, machine vision and a robot to move his mouse ever so slightly faster than he typically can.
However, there are ways to detect when someone is being an absolute madman with the hacks. We're talking head snapping through walls with 100% accuracy and instantaneous displacement across an entire 30 minute match. These people can simply be banned immediately by hardware/steam ID. We can write basic rules to detect stuff like this. There's no "confidence interval" for speed hacking through a map and awping the entire CT team in 3 seconds. You certainly don't need kernel drivers.
64 comments
[ 1.2 ms ] story [ 72.4 ms ] threadSo to sum up. Valorant's anti-cheat, which the author sees something like an ideal solution:
- starts up and loads its kernel driver on boot.
- generates a persistent unique ID based on hardware serial numbers and associates this with my game account.
- stays active the entire time the system is up, whether I play the game or not. But don't worry, it only does some unspecified logging.
- is somehow not a spyware or data protection risk at all...
1) There is a 100k bug-bounty on the anti-cheat: https://hackerone.com/riot?type=team
2) The anti-cheat is the game's entire reason for being. It is the main focus of the development and marketing. People buy Valorant for the anti-cheat; they are willing to accept a kernel driver as a trade off for fairer competition.
No? In which case, what practical spyware risk does a kernel level driver add that user mode software can’t do?
User mode software can spy on your clipboard, surreptitiously take screenshots, and take data out of your system. That spooks me enough that, if I don’t trust a software manufacturer, I don’t install it. Kernel mode makes no practical difference in my security posture.
And you would rightly tell them to piss off and get out of your house, because that makes no sense. If you really wanted to torture the metaphor, you could I guess argue that they need full access to your house just in case you decide to pull some loaded dice out of the filing cabinet or something, but that's not really the important thing to me. The important thing is that, regardless of whether or not I trust the developer of the anti-cheat, the game just isn't that important.
https://www.youtube.com/watch?v=RwzIq04vd0M
It seems to me that kernel-level anti-cheat is little more than a speed bump for determined cheaters.
Because somehow Proton is better than standing for actual GNU/Linux games.
So like IBM with OS/2 and Windows, studios keep ignoring Linux, and let Valve do whatever is needed, it is Valve's problem to sort out.
Is the memory of this kernel module protected from access from another kernel module ?
Genshin's anticheat was used to install ransomware, ESEA's anticheat was used to install bitcoin miners on users machines, EA's anticheat was used to hack clients computers during a tournament, etc.
When not explicitly malicious, anticheat software is at best spyware that's spying on your computer use to identify cheating. People complain a ton about Microsoft recall storing screenshots of your computer locally being a security risk, and yet they're fine with a Chinese owned anticheat program taking screenshots of your computer and uploading them online. And even if the company isn't trying to use that info to spy on you, my understanding is that when you're a chinese company, you have to give full access of that data to the government.
With the ongoing/rising tensions between the US and China, I actually think there's a significant chance that we may see all Chinese owned anticheat programs banned in the US, which would be pretty significant since they own or partially own the majority (as far as I know).
Alas, I'd like to believe we could be in an era of "hey, not a problem, just have a dedicated gaming machine," but that too is difficult.
You can do this on macOS too, by the way. XNU is open-source.
It's much harder to cheat if the game isn't running on your computer.
I think the more important question isn't how you implement an anti-cheat, it's why some types of games attract cheaters.
When victory in a game isn't about strategy but just about how quickly you can click o character's head, and just by doing it once you win the game, that makes the whole game a clear target for cheating. Everyone cheats as the sniper, nobody cheats as the medic.
I think you could make an FPS that cheaters hate by designing it so that it requires at least 2 players to defeat a player on the opposite team, e.g. by giving everyone weapons of different type and needing two types to defeat an enemy.
I wonder if anti-cheating game design is a thing?
And while the kernel is quite secure against hacks from userspace, the hardware interfaces are generally more trusted. This is not a problem on smartphones or embedded devices where you can obfuscate everything on a small SoC but the whole PC/x86_64 platform is much more flexible and open. I doubt there is a way to get reliable attestation on current desktop systems (many of which are assembled from independent parts) unless you get complete buy-in from all the manufacturers.
Finally, with AI systems recently increasing in power, perhaps soon the nuclear option of camera + CV + keyboard/mouse will become practical.
Anti-cheat does not ordinarily like to run inside a VM, because then the hypervisor can do the cheating, invisibly to the kernel. However, technologies like AMD SEV can (in theory) protect the guest from the host, using memory encryption. (And potentially also protect from DMA-based cheats, too)
What you'd need is some way for the hardware to attest to the guest "yes, you really are running inside SEV".
I'm largely a console gamer, so I don't have to worry about EA's latest malware opening my computer up to the world. I'm also a filthy casual though.
---
Let me ask you a question. How many vulnerable drivers (yes, those that can be abused by bad actors to gain kernel access) do you think the average gamer has on their Windows install? I’ll start with my own system. This is what I can immediately think of:
• MSI Afterburner - RTCore64.sys driver (yes, even in the latest version) has a vulnerability that allows any usermode process to read and write any kernel memory it wishes
• CPU-Z - cpuz142_x64.sys driver has (again) kernel memory read/write vulnerability and MSR register read/write
If I looked hard enough, I would most likely find more.
Anticheat is only hard because people are looking for a technical solution to a social problem. The actual way to get a good game in most things is to only play with people you trust and, if you think someone is cheating, stop trusting them and stop playing with them.
This doesn't scale to massive matchmaking scenarios of course - and so many modern games don't even offer it as an option - so companies would have to give up the automatic ranking of all players and the promise of dopamine that can be weaponised against them, but it works for sports in the real world and it worked for the likes of Quake, UT, etc. so I don't think it's a necessarily bad idea. Social ostracism is an incredibly powerful force.
However, it does mean that the big publishers wouldn't have control over everything a player does. Getting them to agree to that is probably the real hard problem.
The problem is that this costs more than game companies are willing to spend, even when they’re raking in cash hand over fist. As long as the problem isn’t so bad that it’s making players quit, it’s cheaper to employ more automated, less effective strategies. The end goal isn’t player happiness, it’s higher profit margins.
One of the games mentioned in this article is Rust. Playing with only people you trust defeats the point because it's a game full of betrayal. At best you'll be able to get a group together once and then destroy your relationships more than Monopoly would.
In some cases there are numerous public servers, which can mitigate the "player availability" problem.
Also, for these online FOSS games the servers are community-owned and moderated. Cheaters, trolls, inappropriate chats are monitored by someone who is interested in, and generally quite knowledgeable about, the game.
Ultimately the OS should be providing a service that can verify a program is running in a secure environment and hasn't been tampered with. That's something that's useful for things far beyond games. I kind of hope the cheaters win this war for now, to create the incentive for building a better, proper, standardized, cross-platform solution.
[1] https://www.youtube.com/watch?v=kzVYgg9nQis
Proponents of such junk can get lost with their fake justifications of why kernel level anti-cheat malware should be acceptable. They should instead work on server side anti-cheats.
If your garbage collector is grabbing an entire arena of memory and moving it constantly, doesn't that limit a cheat to asking an API to retrieve an object because only the managed memory knows where objects reside at any given moment?
Who needs opaque binary blob kernel modules or whatever for anti-cheat when you can bootstrap a secure boot and remote attestation setup? It's possible for a game server to verify cryptographically that someone is running stock firmware, stock bootloader, stock TCB userspace, a stock game executable, and that no debugger is attached. You don't need cat and mouse BS with executable obfuscation. You don't need inscrutable spyware. You don't need to prohibit VMs. All you need to do is configure your program not to be debuggable, prohibit network MITM (e.g. with certificate pinning), and then use remote attestation to make sure nobody has tampered with the system to make it ignore your anti debugging configuration.
All of the components involved in this trust chain can be open source. There's no spyware involved. No rootkit. No obfuscation. Everything is transparent and above board.
The only downside (besides implementation complexity) is that the remote attestation scheme is incompatible with running custom builds of the components remotely attested. But so what? Doing so isn't a requirement of open source. You can still run custom builds too -- just not at the same time you play your game.
Seems like a fair compromise to me
Long term damages are self explanatory, it's called a-rootkit
However, there are ways to detect when someone is being an absolute madman with the hacks. We're talking head snapping through walls with 100% accuracy and instantaneous displacement across an entire 30 minute match. These people can simply be banned immediately by hardware/steam ID. We can write basic rules to detect stuff like this. There's no "confidence interval" for speed hacking through a map and awping the entire CT team in 3 seconds. You certainly don't need kernel drivers.