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.

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.

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.

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.

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.

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.

I was not aware that attackers could potentially manipulate attestation! How could that be done? That would seemingly defeat the point of remote attestation.

(https://mag.uchicago.edu/billiards)

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.

Now industry propaganda has gamers installing them voluntarily.

See https://github.com/ufrisk/pcileech

They solve a real problem (cheats running at higher privilege levels), but at the same time they introduce a massive trusted component into the OS. You're basically asking users to install something that behaves very much like a rootkit, just with a defensive purpose.

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.

Question being: Why aren't they all blacklisted? Why does Microsoft allow known malware to run?

The article doesn’t go too in depth on the actually interesting things modern anticheats do.

In addition:

- you can’t really expect .text section of game/any modules except maybe your own to be 100% matching one on disk, because overlays will hook stuff like render crap (fun fact for you: Steam will also aggressively hook various WinAPI stuff presumably for VAC, at least on CS2)

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.

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.

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.