>TPM-based measured boot, combined with UEFI Secure Boot, can generate a cryptographically signed attestation ... This is not a complete solution (a sufficiently sophisticated attacker can potentially manipulate attestation)
I was not aware that attackers could potentially manipulate attestation! How could that be done? That would seemingly defeat the point of remote attestation.
While I’m not really a gamer, I do think the conundrum of online games cheating is an interesting technical problem because I honestly can’t think of a “good” solution. The general simplistic answer from those who never had to design such a game or a system of “do everything on the server” is laughably bad.
I could have sworn online gambling people fixed this years ago with just wifi. I thought I remembered reading a comment on here about the online gambling for kids no cheating people not talking to the online gambling for adults no cheating people.
Yes, a literal privilege escalation as a service "anticheat" driver.
Trusting these companies is insane.
Every video game you install is untrusted proprietary software that assumes you are a potential cheater and criminal. They are pretty much guaranteed to act adversarially to you. Video games should be sandboxed and virtualized to the fullest possible extent so that they can access nothing on the real system and ideally not even be able to touch each other. We really don't need kernel level anticheat complaining about virtualization.
I still don't understand why people don't cheat in FPSes by looking at the video stream and having a USB mouse that emits the right mouse movements. (The simplest thing is to just click when someone's head is under your crosshair, in games with hitscan weapons.)
I would love to see a modern competitive game with optional anticheat that, when enabled, allows you to queue for a separate matchmaking pool that is exclusive to other anticheat users. For players in the no-anticheat pool, there could be "community moderation" that anti-anticheat players advocate for.
It'd be really interesting to see what would happen - for instance, what fraction of players would pick each pool during the first few weeks after launch, and then how many of them would switch after? What about players who joined a few months or a year after launch?
Unfortunately, pretty much the only company that could make this work is Valve, because they're the only one who actually cares for players and is big enough that they could gather meaningful data. And I don't think that even Valve will see enough value in this to dedicate the substantial resources it'd take to try to implement.
> pretty much the only company that could make this work is Valve
at least when focusing on counter-strike (CSGO/CS2), they've tried tons of ways to segregate the player base in terms of trustworthy vs not.
from "anti-cheat" vs not, verifying users using phones, paying vs not, you name it.
none of their initiatives managed to ward off the bad actors from the "secured" version. does not give me the confidence that they could make a system work effectively, but something that can work cross-platform, perhaps.
This trust system reminds me of social verification of records in Trackmania. Since physics is deterministic, suspicious replay input is the source of truth which is both easy to fabricate (e.g. via TAS tools) and verify (available in replay file).
> Modern kernel anti-cheat systems are, without exaggeration, among the most sophisticated pieces of software running on consumer Windows machines. They operate at the highest privilege level available to software, they intercept kernel callbacks that were designed for legitimate security products, they scan memory structures that most programmers never touch in their entire careers, and they do all of this transparently while a game is running.
Okay, chill. I'm willing to believe that anti-cheat software is "sophisticated", but intercepting system calls doesn't make it so. There is plenty of software that operates at elevated privilege and runs transparently while other software is running, while intentionally being unsophisticated. It's called a kernel subsystem.
There is a solution to cheating, but it's not clear how hard it would be to implement.
Cheaters are by definition anomalies, they operate with information regular players do not have. And when they use aimbots they have skills other players don't have.
If you log every single action a player takes server-side and apply machine learning methods it should be possible to identify these anomalies. Anomaly detection is a subfield of machine learning.
It will ultimately prove to be the solution, because only the most clever of cheaters will be able to blend in while still looking like great players. And only the most competently made aimbots will be able to appear like great player skills. In either of those cases the cheating isn't a problem because the victims themselves will never be sure.
There is also another method that the server can employ: Players can be actively probed with game world entities designed for them to react to only if they have cheats. Every such event would add probability weight onto the cheaters. Ultimately, the game world isn't delivered to the client in full so if done well the cheats will not be able to filter. For example: as a potential cheater enters entity broadcast range of a fake entity camping in an invisible corner that only appears to them, their reaction to it is evaluated (mouse movements, strategy shift, etc). Then when it disappears another evaluation can take place (cheats would likely offer mitigations for this part). Over time, cheaters will stand out from the noise, most will likely out themselves very quickly.
I feel like this whole problem is just made up. Back in the day, when I played lots of Counter Strike, we had community servers. If a cheater joined, some admin was already online and kicked them right away. I'm sure we hit some people that were not actually cheaters, but they would just go to another server. And since there was no rank, no league, no rewards (like skins, drops, etc.), there was no external reward for cheating. It annoys me that cheating in competitive video games seems like a bigger problem than it has been in the past for no good reason.
Well its because we don't use community servers anymore. Lobbies are created in real time, particularly where SBMM is involved.
It's a bigger problem because in a lobby of 100 people, 1 person cheating ruins it for 99 players. Whereas in a 20 person lobby you can just boot that one person and it only ruins the game for 19 others.
The real “competitive” game is not players playing against other players, but hackers playing against anti-cheat.
“Billiards is not as good a game as Physics”
i've said it before, but is anti-cheat mechanisms needed on consoles? If not, (presumambly due to their locked down nature), what's the problem with having a locked down mode (trusted secure boot path that doesn't allow other programs to run, ala "the xbox mode" that microsoft has started to implement), that is similar to a console.
This seems much more doable today than in the past as machines boot in moments. Switching from secure "xbox mode" to free form PC mode, would be barely a bump.
Now, I see one major difference, heterogenous vs homogenous hardware (and the associated drivers that come with that). In the xbox world, one is dealing with a very specific hardware platform and a single set of drivers. In the PC world (even in a trusted secure boot path), one is dealing with lots of different hardware and drivers that can all have their exploits. If users are more easily able to modify their PCs and set of drivers one, I'd imagine serious cheaters would gravitate to combinations they know they can exploit to break the secure/trusted boot boundary.
Kernel level anti cheat is really the maximum effort of locking down a client from doing something suspicious. But today we still see cheaters in those games running these system. Which proofs that a game server just cannot trust a random client out there. I know it's about costs, what to compute on client and what to compute in server side. But as long as a game trusts computation and 'inputs' of clients we will see those cheating issues.
Mucking about in the kernel basically bypasses the entire security and stability model of the OS. And this is not theoretical, people have been rooted through buggy anticheats software, where the game sent malicious calls to the kernel, and hijacked to anti cheat to gain root access.
Even in a more benign case, people often get 'gremlins', weird failures and BSOD due to some kernel apis being intercepted and overridden incorrectly.
The solution here is to establish root of trust from boot, and use the OSes sandboxing features (like Job Objects on NT and other stuff). Providing a secure execution environment is the OS developers' job.
Every sane approach to security relies on keeping the bad guys out, not mitigating the damage they can do once they're in.
There is hardware that you can simply plug into your PC, which can read and write arbitrary kernel memory. I have a feeling that kernel level anticheat isn't stopping someone who really wants to cheat.
I'll simplify for everyone: They don't. Although I do appreciate the author delving into this beyond surface level analysis.
Modern cheats use hypervisors or just compromise hyper-v and because hyper-v protects itself so it automatically protects your cheat.
Another option that is becoming super popular is bios patching, most motherboards will never support boot guard and direct bios flashing will always be an option since the chipset fuse only protects against flashing from the chipset.
DMA is probably the most popular by far with fusers. However, the cost of good ones has been increasing due to vanguard fighting the common methods which is bleeding into other anticheats (some EAC versions and ricochet).
These are not assumptions, every time anticheats go up a level so do the cheats. In the end the weakest link will be exploited and it doesn't matter how sophisticated your anticheat is.
What does make cheat developers afraid is AI, primarily in overwatch. It's quite literally impossible to cheat anymore (in a way that disturbs normal players for more than a few games) and they only have a usermode anticheat! They heavily rely on spoofing detection and gameplay analysis including community reports. Instead of detecting cheats, they detect cheaters themselves and then clamp down on them by capturing as much information about their system as possible (all from usermode!!!).
Of course you could argue that you could just take advantage that they have to go through usermode to capture all this information and just sit in the kernel, but hardware attestation is making this increasily more difficult.
The future is usermode anticheats and gameplay analysis, drop kernel mode anticheats.
No secure boot doesn't work if you patch SMM in bios, you run before TPM attestation happens.
there are already systems that just use the video feed of the game and provide external inputs for popular games (see [1] for a goofy demo). this goes beyond the pc where the game is being run.
kernel-level anti-cheats came at the wrong standpoint imho, and since there are still cheats in games that support it (e.g. EA FC 25, some CoD Warzone stories, etc.), not quite worth the compromise.
The amount of people in this thread who very clearly don't play competitive video games, let alone at a remotely high level, is astounding. The comment "it's your god given right to cheat in multiplayer games" might legitimately be one of the most insane takes I've ever read.
Kernel anticheat does work. It takes 5 seconds to look at Valve's record of both VAC (client based, signature analysis) and VACNet (machine learning) to know the cheating problem with those technologies is far more prevalent than platforms that use kernel level anticheat (e.g. FACEIT, vanguard). Of course, KLAC is not infallible - this is known. Yes, cheats do (and will continue to) exist. However, it greatly raises the bar to entry. Kernel cheats that are undetected by FACEIT or vanguard are expensive, and often recurring subscriptions (some even going down to intervals as low as per day or week). Cheat developers will 99% of the time not release these publicly because it would be picked up and detected instantly where they could be making serious money selling privately.
As mentioned in the article, with DMA devices you're looking at a minimum of a couple hundred dollars just for hardware, not including the cheat itself.
These are video games. No one is forcing you to play them. If you are morally opposed to KLAC, simply don't play the game. If you don't want KLAC, prepare to have your experience consistently and repeatedly ruined.
How about this: Instead of third-party companies installing their custom code to fuck with my operating system,
How about just having the OS offer an API that a game can request to reboot the OS into "console mode": A single-user, single-application mode that just runs that game only.
Similar to how consoles work.
That mode could be reserved for competitive ranked multiplayer only.
It is, of course, only a matter of time - just like kernel-level copy protection and Sony's XCP - before something like Vanguard in particular is exploited and abused by malware.
Himata is correct, too. After DMA-based stuff, it'll be CPU debugging mode exploits like DCI-OOB, some of which can be made detectable in kernel mode; or, stealthier hypervisors.
A lot of the techniques that both sides use would be much harder on macOS. Of course, Hackintoshes have always existed and where there’s a will, there’s a way. But it makes me wonder how this would evolve if Apple eventually gets its act together and makes a real push into gaming.
Kernel anti-cheats are weaponized by hackers. It is all over HN.
Play games which are beyond that: dota2, cs2 for instance.
On linux, there is a new syscall which allows a process to mmap into itself the pages of another process (I guess ~same effective UID and GID). That is more than enough to give hell to cheats...
But any of that can work only with a permanent and hard working "security" team. If some game devs do not want to do that, they should keep their game offline.
43 comments
[ 2.9 ms ] story [ 54.3 ms ] threadI was not aware that attackers could potentially manipulate attestation! How could that be done? That would seemingly defeat the point of remote attestation.
https://www.vice.com/en/article/fs-labs-flight-simulator-pas...
Company decides to "catch pirates" as though it was police. Ships a browser stealer to consumers and exfiltrates data via unencrypted channels.
https://old.reddit.com/r/Asmongold/comments/1cibw9r/valorant...
https://www.unknowncheats.me/forum/anti-cheat-bypass/634974-...
Covertly screenshots your screen and sends the image to their servers.
https://www.theregister.com/2016/09/23/capcom_street_fighter...
https://twitter.com/TheWack0lian/status/779397840762245124
https://fuzzysecurity.com/tutorials/28.html
https://github.com/FuzzySecurity/Capcom-Rootkit
Yes, a literal privilege escalation as a service "anticheat" driver.
Trusting these companies is insane.
Every video game you install is untrusted proprietary software that assumes you are a potential cheater and criminal. They are pretty much guaranteed to act adversarially to you. Video games should be sandboxed and virtualized to the fullest possible extent so that they can access nothing on the real system and ideally not even be able to touch each other. We really don't need kernel level anticheat complaining about virtualization.
It'd be really interesting to see what would happen - for instance, what fraction of players would pick each pool during the first few weeks after launch, and then how many of them would switch after? What about players who joined a few months or a year after launch?
Unfortunately, pretty much the only company that could make this work is Valve, because they're the only one who actually cares for players and is big enough that they could gather meaningful data. And I don't think that even Valve will see enough value in this to dedicate the substantial resources it'd take to try to implement.
If you want a more serious competitive scene you have FACEIT, which AC is covered in the article.
Trust Factor, despite not being an Anti-Cheat, is arguably one of the best defenses against cheaters (and ultimately toxic players).
at least when focusing on counter-strike (CSGO/CS2), they've tried tons of ways to segregate the player base in terms of trustworthy vs not.
from "anti-cheat" vs not, verifying users using phones, paying vs not, you name it.
none of their initiatives managed to ward off the bad actors from the "secured" version. does not give me the confidence that they could make a system work effectively, but something that can work cross-platform, perhaps.
Great video on Trackmania cheating investigation: https://youtu.be/yDUdGvgmKIw
Okay, chill. I'm willing to believe that anti-cheat software is "sophisticated", but intercepting system calls doesn't make it so. There is plenty of software that operates at elevated privilege and runs transparently while other software is running, while intentionally being unsophisticated. It's called a kernel subsystem.
Cheaters are by definition anomalies, they operate with information regular players do not have. And when they use aimbots they have skills other players don't have.
If you log every single action a player takes server-side and apply machine learning methods it should be possible to identify these anomalies. Anomaly detection is a subfield of machine learning.
It will ultimately prove to be the solution, because only the most clever of cheaters will be able to blend in while still looking like great players. And only the most competently made aimbots will be able to appear like great player skills. In either of those cases the cheating isn't a problem because the victims themselves will never be sure.
There is also another method that the server can employ: Players can be actively probed with game world entities designed for them to react to only if they have cheats. Every such event would add probability weight onto the cheaters. Ultimately, the game world isn't delivered to the client in full so if done well the cheats will not be able to filter. For example: as a potential cheater enters entity broadcast range of a fake entity camping in an invisible corner that only appears to them, their reaction to it is evaluated (mouse movements, strategy shift, etc). Then when it disappears another evaluation can take place (cheats would likely offer mitigations for this part). Over time, cheaters will stand out from the noise, most will likely out themselves very quickly.
It's a bigger problem because in a lobby of 100 people, 1 person cheating ruins it for 99 players. Whereas in a 20 person lobby you can just boot that one person and it only ruins the game for 19 others.
(https://mag.uchicago.edu/billiards)
This seems much more doable today than in the past as machines boot in moments. Switching from secure "xbox mode" to free form PC mode, would be barely a bump.
Now, I see one major difference, heterogenous vs homogenous hardware (and the associated drivers that come with that). In the xbox world, one is dealing with a very specific hardware platform and a single set of drivers. In the PC world (even in a trusted secure boot path), one is dealing with lots of different hardware and drivers that can all have their exploits. If users are more easily able to modify their PCs and set of drivers one, I'd imagine serious cheaters would gravitate to combinations they know they can exploit to break the secure/trusted boot boundary.
I wonder if there are other problems.
Mucking about in the kernel basically bypasses the entire security and stability model of the OS. And this is not theoretical, people have been rooted through buggy anticheats software, where the game sent malicious calls to the kernel, and hijacked to anti cheat to gain root access.
Even in a more benign case, people often get 'gremlins', weird failures and BSOD due to some kernel apis being intercepted and overridden incorrectly.
The solution here is to establish root of trust from boot, and use the OSes sandboxing features (like Job Objects on NT and other stuff). Providing a secure execution environment is the OS developers' job.
Every sane approach to security relies on keeping the bad guys out, not mitigating the damage they can do once they're in.
See https://github.com/ufrisk/pcileech
Modern cheats use hypervisors or just compromise hyper-v and because hyper-v protects itself so it automatically protects your cheat.
Another option that is becoming super popular is bios patching, most motherboards will never support boot guard and direct bios flashing will always be an option since the chipset fuse only protects against flashing from the chipset.
DMA is probably the most popular by far with fusers. However, the cost of good ones has been increasing due to vanguard fighting the common methods which is bleeding into other anticheats (some EAC versions and ricochet).
These are not assumptions, every time anticheats go up a level so do the cheats. In the end the weakest link will be exploited and it doesn't matter how sophisticated your anticheat is.
What does make cheat developers afraid is AI, primarily in overwatch. It's quite literally impossible to cheat anymore (in a way that disturbs normal players for more than a few games) and they only have a usermode anticheat! They heavily rely on spoofing detection and gameplay analysis including community reports. Instead of detecting cheats, they detect cheaters themselves and then clamp down on them by capturing as much information about their system as possible (all from usermode!!!).
Of course you could argue that you could just take advantage that they have to go through usermode to capture all this information and just sit in the kernel, but hardware attestation is making this increasily more difficult.
The future is usermode anticheats and gameplay analysis, drop kernel mode anticheats.
No secure boot doesn't work if you patch SMM in bios, you run before TPM attestation happens.
there are already systems that just use the video feed of the game and provide external inputs for popular games (see [1] for a goofy demo). this goes beyond the pc where the game is being run.
kernel-level anti-cheats came at the wrong standpoint imho, and since there are still cheats in games that support it (e.g. EA FC 25, some CoD Warzone stories, etc.), not quite worth the compromise.
[1] https://www.youtube.com/watch?v=T4rrcw_oRVs
Kernel anticheat does work. It takes 5 seconds to look at Valve's record of both VAC (client based, signature analysis) and VACNet (machine learning) to know the cheating problem with those technologies is far more prevalent than platforms that use kernel level anticheat (e.g. FACEIT, vanguard). Of course, KLAC is not infallible - this is known. Yes, cheats do (and will continue to) exist. However, it greatly raises the bar to entry. Kernel cheats that are undetected by FACEIT or vanguard are expensive, and often recurring subscriptions (some even going down to intervals as low as per day or week). Cheat developers will 99% of the time not release these publicly because it would be picked up and detected instantly where they could be making serious money selling privately. As mentioned in the article, with DMA devices you're looking at a minimum of a couple hundred dollars just for hardware, not including the cheat itself.
These are video games. No one is forcing you to play them. If you are morally opposed to KLAC, simply don't play the game. If you don't want KLAC, prepare to have your experience consistently and repeatedly ruined.
How about this: Instead of third-party companies installing their custom code to fuck with my operating system,
How about just having the OS offer an API that a game can request to reboot the OS into "console mode": A single-user, single-application mode that just runs that game only.
Similar to how consoles work.
That mode could be reserved for competitive ranked multiplayer only.
Now industry propaganda has gamers installing them voluntarily.
Himata is correct, too. After DMA-based stuff, it'll be CPU debugging mode exploits like DCI-OOB, some of which can be made detectable in kernel mode; or, stealthier hypervisors.
Play games which are beyond that: dota2, cs2 for instance.
On linux, there is a new syscall which allows a process to mmap into itself the pages of another process (I guess ~same effective UID and GID). That is more than enough to give hell to cheats...
But any of that can work only with a permanent and hard working "security" team. If some game devs do not want to do that, they should keep their game offline.