How kernel anti-cheats work

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.

All of this is beyond horrific.

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.

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.

It's a whole lot of effort to go through just so corporations can get gamers playing with strangers instead of friends, while taking the whole thing way too seriously. You need anticheat when you want competitive rankings and esports leagues, but is any of that actually any better than just playing casual games with people you know and trust to play fair?

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.

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.

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.

> 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.

I think I'll just stick to simple games on iOS/iPadOS or just use my Nintendo Switch. These anti-cheat systems are far too invasive for my liking. I also worry about those things being hacked! The last time i built a gaming pc was 20 years ago, and i was playing Doom, FEAR, and Half Life Two.. Then i did some simple gaming on macOS

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.

It’s crazy to me how hard people work to effectively ruin a game for themselves… Imagine putting in this much effort to play Minecraft survival but on creative mode. It just doesn’t sound fun

Kernel anti-cheats are a fascinating example of security trade-offs.

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.

>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.

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”

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

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.

Remember when sony got a huge pushback for putting rootkits on CDs?

Now industry propaganda has gamers installing them voluntarily.

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.

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

Never forget the risks of trusting game companies with this sort of access to your machine.

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.

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.

This got me wondering how easy it'd be to automate discovery of BYOVD vulns with LLMs (both offensively and defensively)

Uh, isn’t the IDT one of these things that PatchGuard explicitly checks? Mind you, anticheats keep PatchGuard corralled these days because they want their own KiPageFault hooks assuming HVCI is not in place.

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)

It's AI-assisted content, but has good reference links.

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'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.

I wonder if there are other problems.

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.

Hear me out:

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.

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.

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”

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

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.

Remember when sony got a huge pushback for putting rootkits on CDs?

Now industry propaganda has gamers installing them voluntarily.

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

In addition:

All of this is beyond horrific.

Even in a more benign case, people often get 'gremlins', weird failures and BSOD due to some kernel apis being intercepted and overridden incorrectly.

Every sane approach to security relies on keeping the bad guys out, not mitigating the damage they can do once they're in.

Unfortunately (or fortunately depending on what side of the fence you live), boot chain security is not taken as seriously in the PC ecosystem as it is on phones. As as a result, even if you relying on os features, you cannot trust them. This is doubly the case in situations where the user owns the kernel (eg Linux) or hypervisor. Attestation would work, but the number of users that you could probably successfully attest are on on a trustworthy setup is fairly small, so it's not really a realistic option. And that is why they must reach for other options. Keep in mind that even if it's not foolproof, if it reduces the number of cheaters by a statistically significant amount, it's worthwhile.

I really thought this might change over time given strong desire for useful attestation by major actors like banks and media companies, but apparently they cannot exert the same level of influence on the PC industry as they have on the mobile industry.

Every sane approach to security relies on checking you are doing permitted actions on the server, not locking down the client.

Are you saying that the solution here is to sell computers so locked down that no user can install anything other than verified software?

> Every sane approach to security relies on keeping the bad guys out, not mitigating the damage they can do once they're in.

That’s not true at all in the field of cybersecurity in general, and I have doubts that it’s true in the subset of the field that has to do with anticheat.

You want to eliminate the freedom of running the software you desire for everyone to hopefully mitigate cheating?

>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.

If you got RCE in the game itself, it's effectively game over for any data you have on the computer.

https://xkcd.com/1200/

>All of this is beyond horrific.

Hot take: It's also totally unnecessary. The entire arms race is stupid.

Proper anti-cheat needs to be 0% invasive to be effective; server-side analysis plus client-side with no special privileges.

The problem is laziness, lack of creativity and greed. Most publishers want to push games out the door as fast as possible, so they treat anti-cheat as a low-budget afterthought. That usually means reaching for generic solutions that are relatively easy to implement because they try to be as turn-key as possible.

This reductionist "Oh no! We have to lock down their access to video output and raw input! Therefore, no VMs or Linux for anyone!" is idiotic. Especially when it flies in the face of Valve's prevailing trend towards Linux as a proper gaming platform.

There's so many local-only, privacy-preserving anti-cheat approaches that can be done with both software and dirt cheap hardware peripherals. Of course, if anyone ever figures that out, publishers will probably twist it towards invasive harvesting of data.

I'd love to be playing Marathon right now, but Bungie just wholesale doesn't support Linux nor VMs. Cool. That's $40 they won't get from me, multiply by about 5-10x for my friends. Add in the negative reviews that are preventing the game's Steam rating from reaching Overwhelmingly Positive and the damage to sales is significant.

yes. this is why there's one box for work, & another for play.

Yes it can be? This is a very strange statement to me. Many genuinely like testing themselves against other people, improving over time, and seeing how they stack up. Competition is a pretty basic human thing, e.g. sports, chess, card games, and therefore video games. And competing with the world is a far grander challenge than those you explicitly know.

Not everyone enjoys that, and that’s fine, but acting like it’s somehow unnatural or pointless feels way off.

> 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.

This is roughly what Valve does for CS2. But, as far as I understand, it's not very effective and unfortunately still results in higher cheating rates than e.g. Valorant.

It exists, it's called FACEIT (for CS, specifically). Anyone who seriously cares about the game at a high level is pretty much exclusively playing there.

Community moderation simply doesn't work at scale for anticheat - in level of effort required, root cause detection, and accuracy/reliability.

I support this idea. Personally, I do not really care about cheating in video games. If some is cheating in a video game, I can just turn it off, go outside, and take deep breath of fresh air and touch some grass.

I rather play with cheaters here and there than install some kernel level malware on machine just to make sure EA, Activision, et al can keep raking in money hand over fist.

Or better yet, I can just play on console where there is no cheating that I have ever seen.

You mean PlaySafe ID?

thats basically playsafe id

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.

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.

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.

> Another option that is becoming super popular is bios patching

I wouldn’t call BIOS patching “super popular”. That sounds like an admission that anti-cheat is working because running cheats now requires a lot of effort. Now that cheats are becoming more involved to run, it’s becoming less common to cheat.

When cheats were as simple as downloading a program and you were off to cheating, the barrier to entry was a lot lower. It didn’t require reboots or jumping through hoops. Anyone could do it and didn’t even have to invest much time into it.

Now that cheats are no longer an easy thing to do, a lot of would-be cheaters are getting turned off of the idea before they get far enough to cheat in a real game.

> 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.

Didn’t the first half of your post just argue that these measures can be defeated and therefore you can’t rely on them?

I'm playing WoW and I've heard lots of compains about Blizzard banning innocent players. Just recently there was a wave of complains that they banned players who spent a lot of time farming one dungeon (like 10+ hours per day).

I, myself, got two accounts banned and I was innocent. I managed to make it through support and got them unbanned but I'm fairly certain that many players didn't, because they seem to employ AI in their support.

So I'm a bit skeptical about that kind of behavioural bans. You risk banning a lot of dedicated players who happened to play differently from the majority and that tend to bring bad reputation. For example I no longer purchase yearly subscription, because I'm afraid of sudden ban and losing lots of unspent subscription time.

Everything you described increases the cost of attack (creating a cheat), and as a result, not everyone can afford it, which means anti-cheats work. They don't have to be a panacea. Gameplay analysis will only help against blatant cheaters, but will miss players with simple ESP.

It's almost the same as saying "you don't need a password on your phone" or something like that.

>It's quite literally impossible to cheat anymore (in a way that disturbs normal players for more than a few games)

AKA the way that is easiest to detect, and the easiest way to claim that the game doesn't have cheaters. Behavioral analysis doesn't work with closet cheaters, and they corrupt the community and damage the game in much subtler ways. There's nothing worse than to know that the player you've competed with all this time had a slight advantage from the start.

Don't forget that ActiBlizz are also pretty much the only ones regularly taking legal action against pay2cheat developers, see Bossland/EngineOwning.

Taking a probabilistic approach to ban people… so if enough people start cheating it's fine?

Kernel AC is currently the best way to protect against cheats by far, the game with the strongest protection is Valorant and it works very well. OW2 is lightyears behind Valorant.

Not sure what your point is. Most of your post is inaccurate, DMA cheats represent the minority of cheats because they're very expensive and you need a second computer.

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’s crazy to me how hard people work to effectively ruin a game for themselves… Imagine putting in this much effort to play Minecraft survival but on creative mode. It just doesn’t sound fun

Hear me out:

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's AI-assisted content, but has good reference links.

You want to eliminate the freedom of running the software you desire for everyone to hopefully mitigate cheating?

If you got RCE in the game itself, it's effectively game over for any data you have on the computer.

https://xkcd.com/1200/

> Every sane approach to security relies on keeping the bad guys out, not mitigating the damage they can do once they're in.

That’s not true at all in the field of cybersecurity in general, and I have doubts that it’s true in the subset of the field that has to do with anticheat.

> Cheaters are by definition anomalies

So are very good players, very bad players, players with weird hardware issues, players who just got one in a million lucky…

When you have enough randomly distributed variables, by the law of big numbers some of them will be anomalous by pure chance. You can't just look at any statistical anomaly and declare it must mean something without investigating further.

In science, looking at a huge number of variables and trying to find one or two statistically significant variables so you can publish a paper is called p hacking. This is why there are so many dubious and often even contradictory "health condition linked to X" articles.

I've been advocating for a statistical honeypot model for a while now. This is a much more robust anti cheat measure than even streaming/LAN gaming provides. If someone figures out a way to obtain access to information they shouldn't have on a regular basis, they will be eventually be found with these techniques. It doesn't matter the exact mechanism of cheating. This even catches the "undetectable" screen scraping mouse robot AI wizard stuff. Any amount of signal integrated over enough time can provide damning evidence.

> With that goal in mind, we released a patch as soon as we understood the method these cheats were using. This patch created a honeypot: a section of data inside the game client that would never be read during normal gameplay, but that could be read by these exploits. Each of the accounts banned today read from this "secret" area in the client, giving us extremely high confidence that every ban was well-deserved.

https://www.dota2.com/newsentry/3677788723152833273

This is said very often, but doesn't seem to be working out in practice.

Valve has spent a lot of time and money on machine learning models which analyze demo files (all inputs). Yet Counter-Strike is still infested with cheaters. I guess we can speculate that it's just a faulty implementation, but clearly the problem isn't just "throw a ML model at the problem".

Honeypots are used pretty often, sure. They're not enough, though useful.

Behavioral analysis is way harder in practice than it sounds, because most closet cheaters do not give enough signal to stand out, and the clusters are moving pretty fast. The way people play the game always changes. It's not the problem of metric selection as it might appear to an engineer, you need to watch the community dynamics. Currently only humans are able to do that.

In CS2, a huge portion of cheaters can be identified just by the single stat 'time-to-damage'. Cheaters will often be 100ms faster to react than even the fastest pros. Not all cheaters use their advantage in this way, but simply always make perfect choices because they have more information than their opponents.

I disagree with the premise that it doesn't matter as long as users can't tell. Say you're running a Counterstrike tournament with a 10k purse... Integrity matters there. And a smart cheater is running 'stealth' in that situation. Think a basic radar or a verrrrrry light aimbot, etc.

The problem is that traditional cheats (aimbot, wallhack, etc.) give users such a huge edge that they are multiple standard deviations from the norm on key metrics. I agree with you on that and there are anticheats that look for that exact thing.

I've also seen anticheats where flagged users have a session reviewed. EG you review a session with "cheats enabled" and try to determine whether you think the user is cheating. This works decently well in a game like CS where you can be reasonably confident over a larger sample size whether a user is playing corners correctly, etc.

The issue with probing for game world entities is that at some point, you have to resolve it in the client. EG "this is a fake player, store it in memory next to the other player entities but don't render this one on screen." This exact thing has happened in multiple games, and has worked as a temporary solution. End of the day, it ends up being a cat and mouse game. Cheat developers detect this and use the same resolution logic as the game client does. Memory addresses change, etc. and the users are blocked from using it for a few hours or a few days, but the developer patches and boom, off to the races.

These days game hacks are a huge business. Cheats often are offered as a subscription and can rank from anywhere from 10-hundreds of dollars a month. It's big money and some of the larger hack manufacturers are full blown companies which can have tens of thousands of customers. It's a huge business.

I think you're realistically left with two options. Require in-person LAN matches with hardware provided by the tournament which is tamper-resistant. Or run on a system so locked down that cheats don't exist.

Both have their own problems... In-person eliminates most of that risk but it's always possible to exploit. Running on a system which is super locked down (say, the most recent playstation) probably works, until someone has a 0day tucked away that they hoard specifically for their advantage. An unlikely scenario but with the money involved in some esports... Anything is possible.

https://www.documentcloud.org/documents/24698335-la22cv00051...

It’s not about costs, it’s about tradeoffs. In an online shooter game (for example) there is latency, and both clients are going to have slightly different viewpoints of the world when they take an action.

No amount of netcode can solve the fact that if I see you on my screen and you didn’t see me, it’s going to feel unfair.

Plus, if I was a motivated cheater, I'd just use a camera, a separate computer, and automate the input devices.

They're getting some actual reward from having a big win/loss ratio. I don't know if that's monetary or just the feeling of being the best but I'd expect the latter group to realise this is all nonsense before spending money on hardware.

But they scan memory structures most programmers never touch in their entire careers!

Preventing cheating is hopeless.

Anyway, this isn’t the Olympics, a professional sport, or Chess. It’s more like pickup league. Preserving competitive purity should be a non-goal. Rather, aim for fun matches. Matchmaking usually tries to find similar skill level opponents anyway, so let cheaters cheat their way out of the wider population and they’ll stop being a problem.

Or, let players watch their killcams and tag their deaths. Camper, aimbot, etc etc. Then (for players that have a good sample size of matches) cluster players to use the same tactics together.

Treating games like serious business has sucked all the fun out of it.

I think from a purely technical viewpoint, cheaters will always have the advantage since they control the machine the game and anti-cheat is running on. Anti-cheat just has to keep the barrier high enough so regular players don't think the game is infested with cheaters.

The only solution that seems to work well that I've seen is having very active and good server admins who watch the gameplay and permaban cheaters. Requires a lot of man hours and good UI and info for them to look at, as well as (ideally) the ability to see replays.

That solution only works on servers hosted by players - I've never seen huge game companies that run their own servers (like GTA) have dedicated server admins. I guess they think they can just code cheaters out of their games, but they never can.

The solution is purely cultural. We should collectively think people who cheat online are losers.

(Not being sarcastic.)

Most people ignore that "do everything on the server" kills any game that needs fast interactions or decent local prediction, latency goes through the roof and you might as well play chess by email. There isn't a clean answer.

Kernel anti-cheat isn't an elegant solution either. It's another landmine, security holes, false positives, broken dev tools, and custody battles with Windows updates while pushing more logic server-side still means weeks of netcode tuning and a cascade of race conditions every time player ping spikes, so the idea that this folds to "better code disipline" is fantasy.

Do what Netflix did and run servers at ISPs (or at their providers or Cloudflare points).

It's kind of weird that we still don't have distributed computing infrastructure. Maybe that will be another thing where agents can run near the data their crunching on generic compute nodes.

I think it's somewhere between halting and turing - given infinite resources it's likely solvable, but lacking that it's just narrowing bounds

The only good long term solution is ML on replays + moderately up to date client side (non kernel) AC (just good enough to deter cheaters).

Mac OS with remote attestation has proven strong enough for anticheat on Mac OS without needing kernel anticheat.

Manually managing one cheater in a 20 person server is obviously very different than managing games between multiple millions of concurrent players

They do. Cheats that read rendered pixels are nothing new.

The problem with these bots is that they are indiscriminate which makes them vulnerable to active detection methods. They can also introduce an amount of latency that begins to defeat the purpose for sufficiently skilled players. 100ms is an eternity when you are playing with shotguns in close quarters.

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.

This has already happened.

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

This was mentioned in the article.

Kernel anti-cheats are a fascinating example of security trade-offs.

remember when Sony put a rootkit an an audio cd to prevent people from ripping the cd?

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.

I wonder if there are other problems.

Not sure if they are considered anti-cheats, but there are some measures to detect usage of input devices like XIM that allow keyboard and mouse inputs which allow for superior aim over controllers.

Well it's definitely not game developer written kernel anti-cheat on consoles.

Never forget the risks of trusting game companies with this sort of access to your machine.

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.

The privacy points in general are valid, but what irritates me is using this rationale against kernel mode anti cheats specifically.

You do not need kernel access to make spyware that takes screenshots. You do not need a privileged service to read the user’s browser history.

You can do all of this, completely unprivileged on Windows. People always seem to conflate kernel access with privacy which is completely false. It would in fact be much harder to do any of these things from kernel mode.

Game compagny have to have those kernel anti cheat because MS never implemented proper isolation in the first place, if Windows was secured like an apple phone or a console there wouldn't be a need for it.

Anti cheat don't run on modern console, game dev knoes that the latest firmware on a console is secure enough so that the console can't be tempered.

And if we embraced instead of feared remote attestation and secure enclaves, the days of game companies having this level of access would come to an end.

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

See this for example:

https://tee.fail/

Defeating remote attestation will be a key capability in the future. We should be able to fully own our computers without others being able to discriminate against us for it.

The comms between the motherboard and the TPM chip isn't secured, so an attacker can just do a MITM attack and substitute in the correct values.

This got me wondering how easy it'd be to automate discovery of BYOVD vulns with LLMs (both offensively and defensively)

Probably not too hard with the LLM side itself assuming latest models and good tooling.

The harder thing probably is getting a dataset for “all x64/ARM64 Windows drivers that aren’t already considered vulnerable”.

Also it depends what’s considered a vulnerability here.

The "just wifi" is about getting your true geolocation so regulated gaming platforms can operate legally. Ironically, I bet whatever API they use can be intercepted by a kernel level process.

They also have VM checks. I "accidentally" logged into MGM from a virtual machine. They put my account on hold and requested I write a "liability statement" stating I would delete all "location altering software" and not use it again. (Really!)

That would be interesting if they did.

looking at cards is a way easier problem than rendering a 3d world with other players bouncing around. I imagine you could just send the card player basially a screenshot of what you want them to see and give them no other data to work with and that would mostly solve cheating.

But gambling can be way more complicated than just looking at cards so maybe there's a lot more to it.

Every sane approach to security relies on checking you are doing permitted actions on the server, not locking down the client.

Are you saying that the solution here is to sell computers so locked down that no user can install anything other than verified software?

yes. this is why there's one box for work, & another for play.

It exists, it's called FACEIT (for CS, specifically). Anyone who seriously cares about the game at a high level is pretty much exclusively playing there.

Community moderation simply doesn't work at scale for anticheat - in level of effort required, root cause detection, and accuracy/reliability.

I rather play with cheaters here and there than install some kernel level malware on machine just to make sure EA, Activision, et al can keep raking in money hand over fist.

Or better yet, I can just play on console where there is no cheating that I have ever seen.

Which isn't practical for multiplayer action games, so we end up here.

I think it's fortunate that I own at least one of the computing devices I paid for.

I'm still not seeing how that would solve it. These are all multiplayer games. You could intercept the network traffic before it reaches the machine and then use a separate device to give you audio or visual cues. In StarCraft, reading the network traffic with a pi and hearing "spawning 5 mutalisk" is gonna completely change the game.

That’s what I want as a gamer. I want a PC that works as a console. Whether I want that for other use cases or this machine doesn’t matter. I’m happy to sandbox _everything else_, boot into a specific OS to game etc.

The thing about gaming is that it’s not acceptable to leave 5% performance on the table whereas for other uses it usually is.

That’s not really incompatible with this? That’s just how secure boot works. You can re-enlist keys for a different root of trust, or disable it and accept the trade-off there.

The idea is that it would require a verified hypervisor, and verified operating system for the game, but you could still at the same time be running an unverified operating system with unverified software. The trusted and untrusted software has to be properly sandboxed from one another. The computer does not need to be locked down so you can't run other hypervisors, it just would require that the anticheat can't prove that it's running on a trusted one when it isn't.

The security of PCs is still poor. Even if you had every available security feature right now it's not enough for the game to be safe. We still need to wait for PCs to catch up with the state of the art, then we have to wait 5+ years for devices to make it into the wild to have a big enough market share to make targeting them to be commercially viable.

No. I'm saying we should all drink the blood of babies to stay eternally youthful. You didn't read between the lines deeply enough.

>All of this is beyond horrific.

Hot take: It's also totally unnecessary. The entire arms race is stupid.

Proper anti-cheat needs to be 0% invasive to be effective; server-side analysis plus client-side with no special privileges.

I don't understand why do you think that having the option to have secure boot and a good, trustworthy sandbox for processes implies you cant run Linux on a VM or Linux beside Windows etc.

People always freak out when I mention secure boot, and the funniest response usually are the ones who threaten to abandon Windows for macOS (which has had secure boot for more than a decade by default)

I'm not super technically knowledgeable about secure boot, but as far as I understand, you need to have a kernel signed by a trusted CA, which sucks if you want to compile your own, but is a hurdle generally managed by your distro, if you're willing to use their kernel.

But if all else fails you can always disable secure boot.

Not everyone enjoys that, and that’s fine, but acting like it’s somehow unnatural or pointless feels way off.

I know gamers are drawn to it, that's why the game corps like it so much. But is this actually good? So very often with these hyper competitive games played between strangers competing for global ranking, the whole thing turns very toxic, with gamers often seeming to not even enjoy the moment to moment process, often raging at their incompetent team mates or raging at their opponents for supposedly cheating, or whathaveyou. All the while, not developing relationships as they could be if they were playing something with friends. Elevated cortisol levels, when they could be chilling out. Obviously it's profitable, but is it good?

This is roughly what Valve does for CS2. But, as far as I understand, it's not very effective and unfortunately still results in higher cheating rates than e.g. Valorant.

> This is roughly what Valve does for CS2.

Do you have a source for this?

Maybe this has changed since CS:GO, but in that game you could get VAC banned just for booting the game with cheats running, even if you only demonstrated them in a local game against bots.

Huh. When you say that "it's not very effective" do you mean the segmentation between the pools, or the actual anticheat isn't very good? (I'm assuming the latter - I've heard that VAC is pretty bad as far as anticheat goes)

This was mentioned in the article.

This has already happened.

remember when Sony put a rootkit an an audio cd to prevent people from ripping the cd?

Not sure if they are considered anti-cheats, but there are some measures to detect usage of input devices like XIM that allow keyboard and mouse inputs which allow for superior aim over controllers.

Well it's definitely not game developer written kernel anti-cheat on consoles.

The "just wifi" is about getting your true geolocation so regulated gaming platforms can operate legally. Ironically, I bet whatever API they use can be intercepted by a kernel level process.

Probably not too hard with the LLM side itself assuming latest models and good tooling.

The harder thing probably is getting a dataset for “all x64/ARM64 Windows drivers that aren’t already considered vulnerable”.

Also it depends what’s considered a vulnerability here.

That would be interesting if they did.

But gambling can be way more complicated than just looking at cards so maybe there's a lot more to it.

You mean PlaySafe ID?

thats basically playsafe id

Taking a probabilistic approach to ban people… so if enough people start cheating it's fine?

That’s not really incompatible with this? That’s just how secure boot works. You can re-enlist keys for a different root of trust, or disable it and accept the trade-off there.

The privacy points in general are valid, but what irritates me is using this rationale against kernel mode anti cheats specifically.

You do not need kernel access to make spyware that takes screenshots. You do not need a privileged service to read the user’s browser history.

Kernel access is related to privacy though, and its the most well documented abuse of such things. Kernel level access can help obfuscate the fact that it'a happening. However, it is also useful for significantly worse, and given track records, must be assumed to be true. The problem is kernel level AC hasnt even solved the problem, so the entire thing is risky, uneccesary and unfit for purpose making an entierly unneccesary risk to force onto unsuspecting users. The average user does not understand the risks and is not made aware of them either.

There are far better ways to detect cheating, such as calculating statistics on performance and behaviour and simply binning players with those of similar competency. This way, if cheating gives god-like behaviour, you play with other godlike folks. No banning required. Detecting the thing cheating allows is much easier than detecting ways in which people gain that thing, it creates a single point of detection that is hard to avoid and can be done entierly server side, with multiple teirs how mucb server side calculation a given player consumes. Milling around in bronze levels? Why check? If you aren't performing so well that yoh can leave low ranks, perhaps we need cheats as a handicap, unless co sistently performing well out of distribution, at which point you catch smurfing as well.

point is focusing on detecting the thing people care about rather than one of the myriad of ways people may gain that unfair edge, is going to be easier and more robust while asking for less ergregious things of users.

There is no need for irritation. I condemn all sorts of anticheating software. As far as I'm concerned, if the player wants to cheat he's just exercising his god given rights as the owner of the machine. The computer is ours, we can damn well edit any of its memory if we really want to. Attempts to stop it from happening are unacceptable affronts to our freedom as users.

Simply put, the game companies want to own our machines and tell us what we can or can't do. That's offensive. The machine is ours and we make the rules.

I single out kernel level anticheats because they are trying to defeat the very mitigations we're putting in place to deal with the exact problems you mentioned. Can't isolate games inside a fancy VFIO setup if you have kernel anticheat taking issue with your hypervisor.

Anti cheat don't run on modern console, game dev knoes that the latest firmware on a console is secure enough so that the console can't be tempered.

Consoles and phones are "secure" because you don't own them. They aren't yours. They belong to the corporations. They're just generously allowing you to use the devices. And only in the ways they prescribe.

This is the exact sort of nonsense situation I want to prevent. We should own the computers, and the corporations should be forced to simply suck it up and deal with it. Cheating? It doesn't matter. Literal non-issue compared to the loss of our power and freedom.

It's just sad watching people sacrifice it all for video games. We were the owners of the machine but we gave it all up to play games. This is just hilarious, in a sad way.

Trusted computing isn't about security. Its about vendors not trusting you.

one of those secure consoles you talk about, Xbox, is running Windows as OS

See this for example:

https://tee.fail/

Defeating remote attestation will be a key capability in the future. We should be able to fully own our computers without others being able to discriminate against us for it.

Sure, but the exploit presented doesn't really look practical for the everyman. And I'm not sure if it can be patched in HW/SW, and in any case this is just the first step to a fully fake secure boot.

Thank you for that link, that's super interesting! It looks like it's actually an architectural vulnerability in modern fTPMs, and considered out of scope by both Intel and AMD. So that's a reliable way to break attestation on even the most modern systems!

And if we embraced instead of feared remote attestation and secure enclaves, the days of game companies having this level of access would come to an end.

That's arguably even worse. Remote attestation means you get banned from everything if you "tamper" with "your" computer.

Remote attestation is the ultimate surrender. It's not really your machine anymore. You don't have the keys to the machine. Even if you did, nobody would trust attestations made by those keys anyway. They would only trust Google's keys, Apple's keys. You? You need not apply.

The comms between the motherboard and the TPM chip isn't secured, so an attacker can just do a MITM attack and substitute in the correct values.

That doesn't sound accurate. The T in TPM stands for trust, the whole standard is about verifying and establishing trust between entities. The standard is designed with the assumption that anyone can bring in their scope and probe the ports. This is one of several reasons why the standard defines endorsement keys(EK).

That's fair, although aren't most TPMs nowadays fTPMs? No interceptable communication that way.

> Another option that is becoming super popular is bios patching

Now that cheats are no longer an easy thing to do, a lot of would-be cheaters are getting turned off of the idea before they get far enough to cheat in a real game.

Didn’t the first half of your post just argue that these measures can be defeated and therefore you can’t rely on them?

Cheating is so addictive that it doesn't matter if it's more difficult to cheat. I have peronsally interacted with people that just want to spin-bot.

Anticheats, especially kernel-mode ones does not make the problem smaller. All they do is make it more rewarding for capable people.

I think you are right on every point, but I think it's worth noting that WoW is kind of a different beast.

You don't play a "match", you don't play "against" other players most of the time, in this context "botting" and "cheating" overlap because having your character do stuff 24/7 unattended is an evident advantage over the rest of the population, but it's not like you are hindering anyone's progress directly the vast majority of the time doing so.

How often does actual cheating happen in WoW, anywhere it matters? M+? Raiding? PvP?

I agree that it's a problem, having a strong support system for remediating false bans is very important.

>It's quite literally impossible to cheat anymore (in a way that disturbs normal players for more than a few games)

In CS2, the game renders your enemies even though you can't see them (within some close range). The draw calls are theoretically interceptable (either on the software/firmware or other hardware level). Detecting this is essentially impossible because the game trusts that the GPU will render correctly.

Overwatch has made the decision that closest cheaters are not a problem and have actually protected a cheater in contenders, although they were forced to leave the competitive scene. None of it ever became public.

It's almost the same as saying "you don't need a password on your phone" or something like that.

> but will miss players with simple ESP.

False, people that have information they shouldn't have will act in detectable ways, even if they try their hardest not to.

Economics work out, harder to make means that it's more profitable to do so. DMA crackdown has actually lead into innovation which has drove the prices down for "normal" DMA hardware what used to be thousands is now $120, excessive spoofing detection has driven down the cost of bios level spoofing and as a result the creation of bios level DMA backdoors - no additional hardware required.

ESP is a lot more obvious to a machine than one might think, the subtle behavior differences are obvious to a human and even more so for a model. Of course none of that can be proven, but it can increase the scrutiny of such players from player reports.

Kernel AC is currently the best way to protect against cheats by far, the game with the strongest protection is Valorant and it works very well. OW2 is lightyears behind Valorant.

Not sure what your point is. Most of your post is inaccurate, DMA cheats represent the minority of cheats because they're very expensive and you need a second computer.

elitepvpers - it's public. DMA cheats have grown and are the primary way people cheat in games these days it makes around 5m/month [retail] just from one of the providers that I know in the scene this includes selling the hardware, the bypass and the cheats (not under the same umbrella for obvious reasons).

The scene has shifted immensely in the last few years, everyone and their grandmother has DMA now, I mean you can buy these off amazon now. Korean's are a bit stuck since most of them use gaming cafes so they've been slow adopters, but cafe shops have the benefit of using an old version of hyper-v which allows you to just use the method described above. Hyper-V cheats are the most popular for valorant.

I would argue that valorant and overwatch are pretty much on the same level based on what it feels to play. I've seen just as many visible cheaters in valorant as in overwatch. Although I will admit that I am pretty outdated myself since around mid 2025. Valorant allows you to ** around so that might be related, overwatch bans rage hackers way faster than valorant does as well.

So no, my post is pretty accurate.

Don't forget that ActiBlizz are also pretty much the only ones regularly taking legal action against pay2cheat developers, see Bossland/EngineOwning.

I saw engine owning lawsuit verdict as the biggest loss for the companies. They proved that you can continue running a cheat provider service out in the open.

They won way more than they lost, people who left got given a free pass for ratting the remaining people out.

Which isn't practical for multiplayer action games, so we end up here.

I think it's fortunate that I own at least one of the computing devices I paid for.

The thing about gaming is that it’s not acceptable to leave 5% performance on the table whereas for other uses it usually is.

To do real time analysis and interception probably not. But for after the fact analysis, if a player is moving on knowledge he couldn’t have had because it shouldn’t have been rendered yet or something, then you can assume cheating.

Doesn’t matter. There’s no world where a multiplayer action game is worth it, and anyway this is a classic example of trying to solve a social problem with technology.

The reason cheating is a problem at all is that instead of playing with friends, you use online matchmaking to play with equally alienated online strangers. This causes issues well in excess of cheating, including paranoia over cheating.

This. Also the client knows more than its allowed to show the user, like the positions of enemy players. You can make aimbots and wallhacks without needing to tamper with the game state.

Yea, but it'd be real nice if we could trust the software we run on our own devices, no?

Secure boot with software attestation could also be used for good.

You can't do anything with a locked-down computer. It can encrypt all its traffic and you can't see anything.

Just know that it will still get cracked and cheats will exist. I suspect this is Microsoft's next "console" as they have been developing "anti-cheat" for quite some time.

Question for you - why don’t you buy a console? (I agree with you by the way, it’s why I have a ps5)

> it’s not acceptable to leave 5% performance on the table whereas for other uses it usually is.

I think that’s an incredibly rare stance not held by the vast majority of gamers, including competitive ones.

Mid range hardware can run majority of games at high fps. You can easily leave performance on the table.

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. If you have ever wondered how BattlEye actually catches a cheat, or why Vanguard insists on loading before Windows boots, or what it means for a PCIe DMA device to bypass every single one of these protections, this post is for you.

This is not a comprehensive or authoritative reference. It is just me documenting what I found and trying to explain it clearly. Some of it comes from public research and papers I have linked at the bottom, some from reading kernel source and reversing drivers myself. If something is wrong, feel free to reach out. The post assumes some familiarity with Windows internals and low-level programming, but I have tried to explain each concept before using it.

1. Introduction

Why Usermode Protections Are Not Enough

The fundamental problem with usermode-only anti-cheat is the trust model. A usermode process runs at ring 3, subject to the full authority of the kernel. Any protection implemented entirely in usermode can be bypassed by anything running at a higher privilege level, and in Windows that means ring 0 (kernel drivers) or below (hypervisors, firmware). A usermode anti-cheat that calls ReadProcessMemory to check game memory integrity can be defeated by a kernel driver that hooks NtReadVirtualMemory and returns falsified data. A usermode anti-cheat that enumerates loaded modules via EnumProcessModules can be defeated by a driver that patches the PEB module list. The usermode process is completely blind to what happens above it.

Cheat developers understood this years before most anti-cheat engineers were willing to act on it. The kernel was, for a long time, the exclusive domain of cheats. Kernel-mode cheats could directly manipulate game memory without going through any API that a usermode anti-cheat could intercept. They could hide their presence from usermode enumeration APIs trivially. They could intercept and forge the results of any check a usermode anti-cheat might perform.

The response was inevitable: move the anti-cheat into the kernel.

The Arms Race

The escalation has been relentless. Usermode cheats gave way to kernel cheats. Kernel anti-cheats appeared in response. Cheat developers began exploiting legitimate, signed drivers with vulnerabilities to achieve kernel execution without loading an unsigned driver (the BYOVD attack). Anti-cheats responded with blocklists and stricter driver enumeration. Cheat developers moved to hypervisors, running below the kernel and virtualizing the entire OS. Anti-cheats added hypervisor detection. Cheat developers began using PCIe DMA devices to read game memory directly through hardware without ever touching the OS at all. The response to that is still being developed.

Each escalation requires the attacking side to invest more capital and expertise, which has an important effect: it filters out casual cheaters. A $30 kernel cheat subscription is accessible to many people. A custom FPGA DMA setup costs hundreds of dollars and requires significant technical knowledge to configure. The arms race, while frustrating for anti-cheat engineers, does serve the practical goal of making cheating expensive and difficult enough that most cheaters do not bother.

Major Anti-Cheat Systems

Four systems dominate the competitive gaming landscape:

BattlEye is used by PUBG, Rainbow Six Siege, DayZ, Arma, and dozens of other titles. Its kernel component is BEDaisy.sys, and it has been the subject of detailed public reverse engineering work, most notably by the secret.club researchers and the back.engineering blog.

EasyAntiCheat (EAC) is now owned by Epic Games and used in Fortnite, Apex Legends, Rust, and many others. Its architecture is broadly similar to BattlEye in its three-component design but differs significantly in implementation details.

Vanguard is Riot Games’ proprietary anti-cheat used in Valorant and League of Legends. It is notable for loading its kernel component (vgk.sys) at system boot rather than at game launch, and for its aggressive stance on driver allowlisting.

FACEIT AC is used for the FACEIT competitive platform for Counter-Strike. It is a kernel-level system with a well-regarded reputation in the competitive community for effective cheat detection, and has been the subject of academic analysis examining the architectural properties of kernel anti-cheat software more broadly.

The ARES 2024 Paper on Kernel Anti-Cheat Architecture

The 2024 paper “If It Looks Like a Rootkit and Deceives Like a Rootkit” (presented at ARES 2024) analyzed FACEIT AC and Vanguard through the lens of rootkit taxonomy, noting that both systems share technical characteristics with that class of software: kernel-level operation, system-wide callback registration, and broad visibility into OS activity. The authors are careful to distinguish between technical classification and intent, explicitly acknowledging that these systems are legitimate software serving a defensive purpose. The paper’s contribution is primarily taxonomic rather than accusatory.

The underlying observation is simply that effective kernel anti-cheat requires the same OS primitives that malicious kernel software uses, because those primitives are what provide the visibility needed to detect cheats. Any sufficiently capable kernel anti-cheat will look like a rootkit under static behavioral analysis, because capability and intent are orthogonal at the kernel API level. This is a constraint imposed by Windows architecture, not a design choice unique to any particular anti-cheat vendor.

2. Architecture of a Kernel Anti-Cheat

The Three-Component Model

Modern kernel anti-cheats universally follow a three-layer architecture:

Kernel driver: Runs at ring 0. Registers callbacks, intercepts system calls, scans memory, enforces protections. This is the component that actually has the power to do anything meaningful.
Usermode service: Runs as a Windows service, typically with SYSTEM privileges. Communicates with the kernel driver via IOCTLs. Handles network communication with backend servers, manages ban enforcement, collects and transmits telemetry.
Game-injected DLL: Injected into (or loaded by) the game process. Performs usermode-side checks, communicates with the service, and serves as the endpoint for protections applied to the game process specifically.

The separation of concerns here is both architectural and security-motivated. The kernel driver can do things no usermode component can, but it cannot easily make network connections or implement complex application logic. The service can do those things but cannot directly intercept system calls. The in-game DLL has direct access to game state but runs in an untrustworthy ring-3 context.

Communication Channels

IOCTLs (I/O Control Codes) are the primary communication mechanism between usermode and a kernel driver. A usermode process opens a handle to the driver’s device object and calls DeviceIoControl with a control code. The driver handles this in its IRP_MJ_DEVICE_CONTROL dispatch routine. The entire communication is mediated by the kernel, which means a compromised usermode component cannot forge arbitrary kernel operations - it can only make requests that the driver is programmed to service.

Named pipes are used for IPC between the service and the game-injected DLL. A named pipe is faster and simpler than routing everything through the kernel, and it allows the service to push notifications to the game component without polling.

Shared memory sections created with NtCreateSection and mapped into both the service process and the game process via NtMapViewOfSection allow high-bandwidth, low-latency data sharing. Telemetry data (input events, timing data) can be written to a shared ring buffer by the game DLL and read by the service without the overhead of IPC per event.

Boot-time vs Runtime Driver Loading

The distinction between boot-time and runtime driver loading is more significant than it might appear.

BattlEye and EAC load their kernel drivers when the game is launched. BEDaisy.sys and its EAC equivalent are registered as demand-start drivers and loaded via ZwLoadDriver from the service when the game starts. They are unloaded when the game exits.

Vanguard loads vgk.sys at system boot. The driver is configured as a boot-start driver (SERVICE_BOOT_START in the registry), meaning the Windows kernel loads it before most of the system has initialized. This gives Vanguard a critical advantage: it can observe every driver that loads after it. Any driver that loads after vgk.sys can be inspected before its code runs in a meaningful way. A cheat driver that loads at the normal driver initialization phase is loading into a system that Vanguard already has eyes on.

The practical implication of boot-time loading is also why Vanguard requires a system reboot to enable: the driver must be in place before the rest of the system initializes, which means it cannot be loaded after the fact without a restart.

Driver Signing Requirements

Windows enforces Driver Signature Enforcement (DSE) on 64-bit systems, which requires that kernel drivers be signed with a certificate that chains to a trusted root and that the driver’s code integrity be verified at load time. This is implemented through CiValidateImageHeader and related functions in ci.dll. The kernel also enforces that driver certificates meet certain Extended Key Usage (EKU) requirements.

Anti-cheats handle signing in the obvious way: they pay for extended validation (EV) code signing certificates, go through Microsoft’s WHQL process for some components, or use cross-signing. The certificate requirements have tightened significantly over the years; Microsoft now requires EV certificates for new kernel drivers, and the kernel driver signing portal requires WHQL submission for drivers targeting Windows 10 and later in many cases.

The reason this matters for cheats is that DSE is a significant barrier. Without a signed driver or a way to bypass DSE, a cheat author cannot load arbitrary kernel code. BYOVD attacks (covered in section 7) are the primary mechanism for bypassing this restriction.

BattlEye Component Breakdown

BattlEye’s architecture is well-documented through reverse engineering:

BEDaisy.sys is the kernel driver. It registers callbacks for process creation, thread creation, image loading, and object handle operations. It implements the actual scanning and protection logic.

BEService.exe (or BEService_x64.exe) is the usermode service. It communicates with BEDaisy.sys via a device object that the driver exposes. It handles network communication with BattlEye’s backend servers, receives detection results from the driver, and is responsible for ban enforcement (kicking the player from the game server).

BEClient_x64.dll is injected into the game process. BattlEye does not inject this via CreateRemoteThread in the traditional sense - it is loaded as part of game initialization, with the game’s cooperation. This DLL is responsible for performing usermode-side checks within the game process context: it verifies its own integrity, performs various environment checks, and serves as the target for protections that the kernel driver applies specifically to the game process.

The communication flow goes: BEDaisy.sys detects something suspicious, signals BEService.exe via an IOCTL completion or a shared memory notification, BEService.exe reports to BattlEye’s servers, the server decides on an action (kick/ban), and BEService.exe instructs the game to terminate the connection.

BattlEye’s three-component architecture: BEDaisy.sys at ring 0 communicates upward via IOCTLs to BEService.exe running as a SYSTEM service, which manages BEClient_x64.dll injected in the game process.

Vanguard’s Architecture

vgk.sys is notably more aggressive than the BattlEye driver in its scope. Because it loads at boot, it can intercept the driver load process itself. Vanguard maintains an internal allowlist of drivers that are permitted to co-exist with a protected game. Any driver not on this list, or any driver that fails integrity checks, can result in Vanguard refusing to allow the game to launch. This is an allowlist model rather than a blocklist model, which is architecturally much stronger.

vgauth.exe is the Vanguard service, which handles the communication between vgk.sys and Riot’s backend infrastructure.

3. Kernel Callbacks and Monitoring

This is the foundation of everything a kernel anti-cheat does. The Windows kernel exposes a rich set of callback registration APIs intended for security products, and anti-cheats use every one of them.

ObRegisterCallbacks

ObRegisterCallbacks is perhaps the single most important API for process protection. It allows a driver to register a callback that is invoked whenever a handle to a specified object type is opened or duplicated. For anti-cheat purposes, the object types of interest are PsProcessType and PsThreadType.

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 </pre></td><td><pre>OB_CALLBACK_REGISTRATION callbackReg = {0}; OB_OPERATION_REGISTRATION opReg[2] = {0}; // Altitude string is required - must be unique per driver UNICODE_STRING altitude = RTL_CONSTANT_STRING(L"31001"); // Monitor handle opens to process objects opReg[0].ObjectType = PsProcessType; opReg[0].Operations = OB_OPERATION_HANDLE_CREATE | OB_OPERATION_HANDLE_DUPLICATE; opReg[0].PreOperation = ObPreOperationCallback; opReg[0].PostOperation = ObPostOperationCallback; // Monitor handle opens to thread objects opReg[1].ObjectType = PsThreadType; opReg[1].Operations = OB_OPERATION_HANDLE_CREATE | OB_OPERATION_HANDLE_DUPLICATE; opReg[1].PreOperation = ObPreOperationCallback; opReg[1].PostOperation = NULL; callbackReg.Version = OB_FLT_REGISTRATION_VERSION; callbackReg.OperationRegistrationCount = 2; callbackReg.Altitude = altitude; callbackReg.RegistrationContext = NULL; callbackReg.OperationRegistration = opReg; NTSTATUS status = ObRegisterCallbacks(&callbackReg, &gCallbackHandle); </pre></td></tr></tbody></table>

The pre-operation callback receives a POB_PRE_OPERATION_INFORMATION structure. The critical field is Parameters->CreateHandleInformation.DesiredAccess. The callback can strip access rights from the desired access by modifying Parameters->CreateHandleInformation.DesiredAccess before the handle is created. This is how anti-cheats prevent external processes from opening handles to the game process with PROCESS_VM_READ or PROCESS_VM_WRITE access.

When a cheat calls OpenProcess(PROCESS_VM_READ | PROCESS_VM_WRITE, FALSE, gameProcessId), the anti-cheat’s ObRegisterCallbacks pre-operation callback fires. The callback checks whether the target process is the protected game process. If it is, it strips PROCESS_VM_READ, PROCESS_VM_WRITE, PROCESS_VM_OPERATION, and PROCESS_DUP_HANDLE from the desired access. The cheat receives a handle, but the handle is useless for reading or writing game memory. The cheat’s ReadProcessMemory call will fail with ERROR_ACCESS_DENIED.

The IRQL for ObRegisterCallbacks pre-operation callbacks is PASSIVE_LEVEL, which means the callback can call pageable code and perform blocking operations (within reason).

ObCallbackDemo.sys in action. DebugView shows the driver stripping handle access rights, Target.exe is running with secret data in memory, and Verifier.exe fails to read it with Access Denied.

PsSetCreateProcessNotifyRoutineEx

PsSetCreateProcessNotifyRoutineEx allows a driver to register a callback that fires on every process creation and termination event system-wide. The callback receives a PEPROCESS for the process, the PID, and a PPS_CREATE_NOTIFY_INFO structure containing details about the process being created (image name, command line, parent PID).

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 </pre></td><td><pre>VOID ProcessNotifyCallback( PEPROCESS Process, HANDLE ProcessId, PPS_CREATE_NOTIFY_INFO CreateInfo ) { if (CreateInfo == NULL) { // Process is terminating HandleProcessTermination(Process, ProcessId); return; } // Process is being created if (CreateInfo->ImageFileName != NULL) { // Check if this is a known cheat process if (IsKnownCheatProcess(CreateInfo->ImageFileName)) { // Set an error status to prevent the process from launching CreateInfo->CreationStatus = STATUS_ACCESS_DENIED; } } } PsSetCreateProcessNotifyRoutineEx(ProcessNotifyCallback, FALSE); </pre></td></tr></tbody></table>

Notably, the Ex variant (introduced in Windows Vista SP1) provides the image file name and command line, which the original PsSetCreateProcessNotifyRoutine does not. The callback is called at PASSIVE_LEVEL from a system thread context.

Anti-cheats use this callback to detect cheat tool processes spawning on the system. If a known cheat launcher or injector process is created while the game is running, the anti-cheat can immediately flag this. Some implementations also set CreateInfo->CreationStatus to a failure code to outright prevent the process from launching.

PsSetCreateThreadNotifyRoutine

PsSetCreateThreadNotifyRoutine fires on every thread creation and termination system-wide. Anti-cheats use it specifically to detect thread creation in the protected game process. When a new thread is created in the game process, the callback fires and the anti-cheat can inspect the thread’s start address.

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 </pre></td><td><pre>VOID ThreadNotifyCallback(HANDLE ProcessId, HANDLE ThreadId, BOOLEAN Create) { if (!Create) return; if (IsProtectedProcess(ProcessId)) { PETHREAD Thread; PsLookupThreadByThreadId(ThreadId, &Thread); // Get the thread start address - this is stored in ETHREAD PVOID StartAddress = PsGetThreadWin32StartAddress(Thread); // Check if start address is within a known module if (!IsAddressInKnownModule(StartAddress)) { // Thread started at an address with no backing module - suspicious FlagSuspiciousThread(Thread, StartAddress); } ObDereferenceObject(Thread); } } </pre></td></tr></tbody></table>

The call to PsLookupThreadByThreadId retrieves the ETHREAD pointer for the new thread. PsGetThreadWin32StartAddress returns the Win32 start address as seen by the process, which is distinct from the kernel-internal start address. Once finished with the thread object, ObDereferenceObject releases the reference acquired by PsLookupThreadByThreadId.

A thread created in the game process whose start address does not fall within any loaded module’s address range is a strong indicator of injected code. Legitimate threads start inside module code. An injected thread typically starts in shellcode or manually mapped PE code that has no module backing.

PsSetLoadImageNotifyRoutine

PsSetLoadImageNotifyRoutine fires whenever an image (DLL or EXE) is mapped into any process. It provides the image file name and a PIMAGE_INFO structure containing the base address and size.

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 </pre></td><td><pre>VOID LoadImageCallback( PUNICODE_STRING FullImageName, HANDLE ProcessId, PIMAGE_INFO ImageInfo ) { if (IsProtectedProcess(ProcessId)) { // A DLL was loaded into the protected game process // Verify it's on the allowlist or check its signature if (!IsAllowedModule(FullImageName)) { // Log and potentially act on this ReportSuspiciousModule(FullImageName, ImageInfo->ImageBase); } } } </pre></td></tr></tbody></table>

This is IRQL PASSIVE_LEVEL. The callback fires after the image is mapped but before its entry point executes, which gives the anti-cheat an opportunity to scan the image before any of its code runs.

CmRegisterCallbackEx

CmRegisterCallbackEx registers a callback for registry operations. Anti-cheats use this to monitor for registry modifications that might indicate cheats configuring themselves or attempting to modify anti-cheat settings.

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 </pre></td><td><pre>NTSTATUS RegistryCallback( PVOID CallbackContext, PVOID Argument1, // REG_NOTIFY_CLASS PVOID Argument2 // Operation-specific data ) { REG_NOTIFY_CLASS notifyClass = (REG_NOTIFY_CLASS)(ULONG_PTR)Argument1; if (notifyClass == RegNtPreSetValueKey) { PREG_SET_VALUE_KEY_INFORMATION info = (PREG_SET_VALUE_KEY_INFORMATION)Argument2; // Check if someone is modifying anti-cheat registry keys if (IsProtectedRegistryKey(info->Object)) { return STATUS_ACCESS_DENIED; } } return STATUS_SUCCESS; } </pre></td></tr></tbody></table>

MiniFilter Drivers for Filesystem Monitoring

A minifilter driver sits in the file system filter stack and intercepts IRP requests going to and from file system drivers. Anti-cheats use minifilters to monitor for cheat file drops (writing known cheat executables or DLLs to disk), to detect reads of their own driver files (which might indicate attempts to patch the on-disk driver binary before it is verified), and to enforce file access restrictions.

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 </pre></td><td><pre>FLT_PREOP_CALLBACK_STATUS PreOperationCallback( PFLT_CALLBACK_DATA Data, PCFLT_RELATED_OBJECTS FltObjects, PVOID *CompletionContext ) { if (Data->Iopb->MajorFunction == IRP_MJ_WRITE) { // Check if the target file is a known cheat file name PFLT_FILE_NAME_INFORMATION nameInfo; FltGetFileNameInformation(Data, FLT_FILE_NAME_NORMALIZED, &nameInfo); if (IsKnownCheatFileName(&nameInfo->Name)) { Data->IoStatus.Status = STATUS_ACCESS_DENIED; FltReleaseFileNameInformation(nameInfo); return FLT_PREOP_COMPLETE; } FltReleaseFileNameInformation(nameInfo); } return FLT_PREOP_SUCCESS_NO_CALLBACK; } </pre></td></tr></tbody></table>

FltGetFileNameInformation retrieves the normalized file name for the target of the operation. FltReleaseFileNameInformation must be called to release the reference when done. Minifilter callbacks typically run at APC_LEVEL or PASSIVE_LEVEL, depending on the operation and the file system. This is important because many operations (like allocating paged pool or calling pageable functions) are not safe at DISPATCH_LEVEL or above.

4. Memory Protection and Scanning

The kernel driver can do far more than just register callbacks. It can actively scan the game process’s memory and the system-wide memory pool for artifacts of cheats.

Blocking Handle Access

As covered in the ObRegisterCallbacks section, the primary mechanism for protecting game memory from external reads and writes is stripping PROCESS_VM_READ and PROCESS_VM_WRITE from handles opened to the game process. This is effective against any cheat that uses standard Win32 APIs (ReadProcessMemory, WriteProcessMemory) because these ultimately call NtReadVirtualMemory and NtWriteVirtualMemory, which require appropriate handle access rights.

However, a kernel-mode cheat can bypass this entirely. It can call MmCopyVirtualMemory directly (an unexported but locatable kernel function) or manipulate page table entries directly to access game memory without going through the handle-based access control system. This is why handle protection alone is insufficient and why kernel-level cheats require kernel-level anti-cheat responses.

Periodic Memory Integrity Hashing

Anti-cheats periodically hash the code sections (.text sections) of the game executable and its core DLLs. A baseline hash is computed at game start, and periodic re-hashes are compared against the baseline. If the hash changes, someone has written to game code, which is a strong indicator of code patching (commonly used to enable no-recoil, speed, or aimbot functionality by patching game logic).

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 </pre></td><td><pre>// Pseudocode for code section integrity checking BOOLEAN VerifyCodeSectionIntegrity(PEPROCESS Process, PVOID ModuleBase) { // Attach to process context to read its memory KAPC_STATE apcState; KeStackAttachProcess(Process, &apcState); // Parse PE headers to find .text section PIMAGE_NT_HEADERS ntHeaders = RtlImageNtHeader(ModuleBase); PIMAGE_SECTION_HEADER section = IMAGE_FIRST_SECTION(ntHeaders); for (USHORT i = 0; i < ntHeaders->FileHeader.NumberOfSections; i++, section++) { if (memcmp(section->Name, ".text", 5) == 0) { PVOID sectionBase = (PVOID)((ULONG_PTR)ModuleBase + section->VirtualAddress); ULONG sectionSize = section->Misc.VirtualSize; // Compute hash of current code section contents UCHAR currentHash[32]; ComputeSHA256(sectionBase, sectionSize, currentHash); // Compare against stored baseline hash if (memcmp(currentHash, gBaselineHash, 32) != 0) { KeUnstackDetachProcess(&apcState); return FALSE; // Code modification detected } } } KeUnstackDetachProcess(&apcState); return TRUE; } </pre></td></tr></tbody></table>

The KeStackAttachProcess / KeUnstackDetachProcess pattern is used to temporarily attach the calling thread to the target process’s address space, allowing the driver to read memory that is mapped into the game process without going through handle-based access controls. RtlImageNtHeader parses the PE headers from the in-memory image base.

Heuristic Scanning: Detecting Manually Mapped Code

The most interesting memory scanning is the heuristic detection of manually mapped code. When a legitimate DLL loads, it appears in the process’s PEB module list, in the InLoadOrderModuleList, and has a corresponding VAD_NODE entry with a MemoryAreaType that indicates the mapping came from a file. Manual mapping bypasses the normal loader, so the mapped code appears in memory as an anonymous private mapping or as a file-backed mapping with suspicious characteristics.

The key heuristic is: find all executable memory regions in the process, then cross-reference each one against the list of loaded modules. Executable memory that does not correspond to any loaded module is suspicious.

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 </pre></td><td><pre>// Walk the VAD tree to find executable anonymous mappings VOID ScanForManuallyMappedCode(PEPROCESS Process) { KAPC_STATE apcState; KeStackAttachProcess(Process, &apcState); PVOID baseAddress = NULL; MEMORY_BASIC_INFORMATION mbi; while (NT_SUCCESS(ZwQueryVirtualMemory( ZwCurrentProcess(), baseAddress, MemoryBasicInformation, &mbi, sizeof(mbi), NULL))) { if (mbi.State == MEM_COMMIT && (mbi.Protect & PAGE_EXECUTE_READ || mbi.Protect & PAGE_EXECUTE_READWRITE || mbi.Protect & PAGE_EXECUTE_WRITECOPY) && mbi.Type == MEM_PRIVATE) // Private, not file-backed { // Executable private memory - not associated with any file mapping // This is a strong indicator of manually mapped or shellcode ReportSuspiciousRegion(mbi.BaseAddress, mbi.RegionSize, "Executable private memory without file backing"); } baseAddress = (PVOID)((ULONG_PTR)mbi.BaseAddress + mbi.RegionSize); if ((ULONG_PTR)baseAddress >= 0x7FFFFFFFFFFF) break; // User space limit } KeUnstackDetachProcess(&apcState); } </pre></td></tr></tbody></table>

ZwQueryVirtualMemory iterates through committed memory regions, returning a MEMORY_BASIC_INFORMATION structure for each. The Type field distinguishes private allocations (MEM_PRIVATE) from file-backed mappings (MEM_IMAGE, MEM_MAPPED). BattlEye’s scanning approach, as documented by the secret.club and back.engineering analyses, involves scanning all memory regions of the protected process and specifically flagging executable regions without file backing. It also scans external processes’ memory pages looking for execution bit anomalies, specifically targeting cases where page protection flags have been changed programmatically to make otherwise non-executable memory executable (a common technique when shellcode is staged).

VAD Tree Walking

The VAD (Virtual Address Descriptor) tree is a kernel-internal structure that the memory manager uses to track all memory regions allocated in a process. Each VAD_NODE (which is actually a MMVAD structure in kernel terms) contains information about the region: its base address and size, its protection, whether it is file-backed (and if so, which file), and various flags.

Anti-cheats walk the VAD tree directly rather than relying on ZwQueryVirtualMemory, because the VAD tree cannot be trivially hidden from kernel mode in the same way that module lists can be manipulated. Walking the VAD:

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 </pre></td><td><pre>// Simplified VAD walker - actual offsets are version-specific VOID WalkVAD(PEPROCESS Process) { // VadRoot is at a version-specific offset in EPROCESS // On Windows 11 23H2, this is at EPROCESS+0x7D8 (https://www.vergiliusproject.com/kernels/x64/windows-11/23h2/_EPROCESS) PMM_AVL_TABLE vadRoot = (PMM_AVL_TABLE)((ULONG_PTR)Process + EPROCESS_VAD_ROOT_OFFSET); WalkAVLTree(vadRoot->BalancedRoot.RightChild); } VOID WalkAVLTree(PMMADDRESS_NODE node) { if (node == NULL) return; PMMVAD vad = (PMMVAD)node; // Check the VAD flags for suspicious characteristics // u.VadFlags.PrivateMemory = 1 and executable protection = suspicious if (vad->u.VadFlags.PrivateMemory && IsExecutableProtection(vad->u.VadFlags.Protection)) { // Check for file-backed backing if (vad->Subsection == NULL) { ReportSuspiciousVAD(vad); } } WalkAVLTree(node->LeftChild); WalkAVLTree(node->RightChild); } </pre></td></tr></tbody></table>

We can observe this detection in practice using WinDbg’s !vad command on a process with injected code.

The first entry is a Private EXECUTE_READWRITE region with no backing file, injected by our test tool. Every legitimate module shows as Mapped Exe with a full file path.

The power of VAD walking is that it catches manually mapped code even if the cheat has manipulated the PEB module list or the LDR_DATA_TABLE_ENTRY chain to hide itself. The VAD is a kernel structure that usermode code cannot modify directly.

5. Anti-Injection Detection

CreateRemoteThread Injection

The classic injection technique: call CreateRemoteThread in the target process with LoadLibraryA as the thread start address and the DLL path as the argument. This is trivially detectable via PsSetCreateThreadNotifyRoutine: the new thread’s start address will be LoadLibraryA (or rather its address in kernel32.dll), and the caller process is not the game itself.

A more subtle check is the CLIENT_ID of the creating thread. When CreateRemoteThread is called, the kernel records which process created the thread. The anti-cheat can check whether a thread in the game process was created by an external process, which is a reliable indicator of injection.

APC Injection

QueueUserAPC and the underlying NtQueueApcThread allow queuing an Asynchronous Procedure Call to a thread in any process for which the caller has THREAD_SET_CONTEXT access. When the target thread enters an alertable wait, the APC fires and executes arbitrary code in the target thread’s context.

Detection at the kernel level leverages the KAPC structure. Each thread has a kernel APC queue and a user APC queue. Anti-cheats can inspect the pending APC queue of game process threads to detect suspicious APC targets:

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 </pre></td><td><pre>// Check for suspicious pending APCs on a thread VOID InspectThreadAPCQueue(PETHREAD Thread) { // The user APC queue is at a version-specific offset in ETHREAD // ETHREAD::ApcState::ApcListHead[1] (index 1 = user APC list) PLIST_ENTRY apcList = (PLIST_ENTRY)((ULONG_PTR)Thread + ETHREAD_APC_STATE_OFFSET + KAPC_STATE_USER_APC_LIST_OFFSET); PLIST_ENTRY entry = apcList->Flink; while (entry != apcList) { PKAPC apc = CONTAINING_RECORD(entry, KAPC, ApcListEntry); // Check if the normal routine (user APC function) // points to an address without module backing if (apc->NormalRoutine != NULL && !IsAddressInLoadedModule((PVOID)apc->NormalRoutine)) { ReportSuspiciousAPC(Thread, apc->NormalRoutine); } entry = entry->Flink; } } </pre></td></tr></tbody></table>

NtMapViewOfSection-Based Injection

A sophisticated injection technique maps a shared section object (backed by a file or created with NtCreateSection) into the target process using NtMapViewOfSection. This bypasses CreateRemoteThread-based detection heuristics because no remote thread is created initially. The injected code is then typically triggered via APC or by modifying an existing thread’s context.

Detection is via the VAD: a section mapping that appears in the game process but was created by an external process will have a distinct pattern in the VAD. Specifically, the MMVAD::u.VadFlags.NoChange and related flags, combined with the file object backing the section (or lack thereof), can reveal this technique.

Reflective DLL Injection and Manual Mapping

Reflective DLL injection embeds a reflective loader inside the DLL that, when executed, maps the DLL into memory without using LoadLibrary. The DLL parses its own PE headers, resolves imports, applies relocations, and calls DllMain. The result is a fully functional DLL in memory that never appears in the InLoadOrderModuleList.

Detection: executable memory with a valid PE header (check for the MZ magic bytes and the PE\0\0 signature at the offset specified by e_lfanew) but no corresponding module list entry. This is a reliable indicator.

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 </pre></td><td><pre>// Check for PE headers in executable private memory BOOLEAN HasValidPEHeader(PVOID base, SIZE_T size) { if (size < sizeof(IMAGE_DOS_HEADER)) return FALSE; PIMAGE_DOS_HEADER dosHeader = (PIMAGE_DOS_HEADER)base; if (dosHeader->e_magic != IMAGE_DOS_SIGNATURE) return FALSE; if (dosHeader->e_lfanew >= size - sizeof(IMAGE_NT_HEADERS)) return FALSE; PIMAGE_NT_HEADERS ntHeaders = (PIMAGE_NT_HEADERS) ((ULONG_PTR)base + dosHeader->e_lfanew); if (ntHeaders->Signature != IMAGE_NT_SIGNATURE) return FALSE; return TRUE; } </pre></td></tr></tbody></table>

We can observe this in practice using a simple test tool that allocates an RWX region and writes a minimal PE header into a running process:

Walking the VAD tree with !vad reveals the injected region immediately. The first entry at 0x8A0 is a Private EXECUTE_READWRITE region with no backing file. Compare this to the legitimate Target.exe image at the bottom, which is Mapped Exe EXECUTE_WRITECOPY with a full file path. Dumping the legitimate module’s base with db confirms a complete PE header with the DOS stub:

Dumping the injected region at 0x008A0000 also shows a valid MZ signature, but the rest of the header is mostly zeroes with no DOS stub. This is characteristic of manually mapped code:

Finally, !peb confirms that the injected region does not appear in any of the module lists. The PEB only contains Target.exe, ntdll.dll, kernel32.dll, and KernelBase.dll. The region at 0x008A0000 is completely invisible to any usermode API that enumerates loaded modules:

Stack Walking with RtlWalkFrameChain

When BEDaisy wants to inspect a thread’s call stack, it uses an APC mechanism to capture the stack frames while the thread is in user mode. The APC fires in the game thread’s context and calls RtlWalkFrameChain or RtlCaptureStackBackTrace to capture the return address chain.

The back.engineering analysis of BEDaisy (and the Aki2k/BEDaisy GitHub research) documents this specifically: BEDaisy queues kernel APCs to threads in the protected process. The APC kernel routine runs at APC_LEVEL, captures the thread’s stack, and then analyzes each return address against the list of loaded modules. A return address pointing outside any loaded module is a strong indicator of injected code on the stack, which suggests the thread is currently executing injected code or returned from it.

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 </pre></td><td><pre>// Pseudocode for APC-based stack inspection VOID KernelApcRoutine( PKAPC Apc, PKNORMAL_ROUTINE *NormalRoutine, PVOID *NormalContext, PVOID *SystemArgument1, PVOID *SystemArgument2 ) { // We're now running at APC_LEVEL in the context of the inspected thread PVOID frames[64]; ULONG capturedFrames = RtlWalkFrameChain(frames, 64, 0); for (ULONG i = 0; i < capturedFrames; i++) { if (!IsAddressInKnownModule(frames[i])) { // Stack frame points outside any loaded module ReportSuspiciousStackFrame(frames[i]); } } } </pre></td></tr></tbody></table>

6. Hook Detection

Hooks are the primary mechanism by which usermode cheats intercept and manipulate the game’s interaction with the OS. Detecting them is a core anti-cheat function.

IAT Hook Detection

The Import Address Table (IAT) of a PE file contains the addresses of imported functions. When a process loads, the loader resolves these addresses by looking up each imported function in the exporting DLL and writing the function’s address into the IAT. An IAT hook overwrites one of these entries with a pointer to attacker-controlled code.

Detection is straightforward: for each IAT entry, compare the resolved address against what the on-disk export of the correct DLL says the address should be.

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 </pre></td><td><pre>VOID DetectIATHooks(PVOID moduleBase) { PIMAGE_IMPORT_DESCRIPTOR importDesc = RtlImageDirectoryEntryToData(moduleBase, TRUE, IMAGE_DIRECTORY_ENTRY_IMPORT, NULL); while (importDesc->Name != 0) { PCHAR dllName = (PCHAR)((ULONG_PTR)moduleBase + importDesc->Name); PVOID importedDllBase = GetLoadedModuleBase(dllName); PULONG_PTR iat = (PULONG_PTR)((ULONG_PTR)moduleBase + importDesc->FirstThunk); PIMAGE_THUNK_DATA originalFirstThunk = (PIMAGE_THUNK_DATA)((ULONG_PTR)moduleBase + importDesc->OriginalFirstThunk); while (originalFirstThunk->u1.AddressOfData != 0) { PIMAGE_IMPORT_BY_NAME importByName = (PIMAGE_IMPORT_BY_NAME)((ULONG_PTR)moduleBase + originalFirstThunk->u1.AddressOfData); // Get the expected address from the exporting DLL PVOID expectedAddr = GetExportedFunctionAddress(importedDllBase, importByName->Name); PVOID actualAddr = (PVOID)*iat; if (expectedAddr != actualAddr) { ReportIATHook(dllName, importByName->Name, expectedAddr, actualAddr); } iat++; originalFirstThunk++; } importDesc++; } } </pre></td></tr></tbody></table>

RtlImageDirectoryEntryToData locates the import directory from the PE headers. The TRUE parameter specifies that the image is mapped (as opposed to a raw file on disk), which is correct when working with in-memory modules. The outer loop walks the IMAGE_IMPORT_DESCRIPTOR array, terminating on a zero Name field. The inner loop compares each resolved IAT entry against the expected export address.

Inline Hook Detection

Inline hooks patch the first few bytes of a function with a JMP (opcode 0xE9 for relative near jump, or 0xFF 0x25 for indirect jump through a memory pointer) to redirect execution to attacker code, which typically performs its modifications and then jumps back to the original code (a “trampoline” pattern).

Detection involves reading the first 16-32 bytes of each monitored function and checking for:

0xE9 (JMP rel32)
0xFF 0x25 (JMP [rip+disp32]) - common for 64-bit hooks
0x48 0xB8 ... 0xFF 0xE0 (MOV RAX, imm64; JMP RAX) - an absolute 64-bit jump sequence
0xCC (INT 3) - a software breakpoint, which can also be a hook point

The anti-cheat reads the on-disk PE file and compares the on-disk bytes of function prologues against what is currently in memory. Any discrepancy indicates patching.

To demonstrate inline hook detection, we use a test tool that patches NtReadVirtualMemory in a running process with a MOV RAX; JMP RAX hook:

Before patching, the function prologue shows a clean syscall stub. mov r10, rcx saves the first argument, mov eax, 3Fh loads the syscall number, and syscall transitions to kernel mode:

After the hook is installed, the first 12 bytes are overwritten with mov rax, 0xDEADBEEFCAFEBABE; jmp rax, redirecting execution to an attacker-controlled address. An anti-cheat comparing these bytes against the on-disk copy of ntdll would immediately flag the mismatch:

SSDT Integrity Checking

The System Service Descriptor Table (SSDT) is the kernel’s dispatch table for syscalls. When a usermode process executes a syscall instruction, the kernel uses the syscall number (placed in EAX) to index into the SSDT and invoke the corresponding kernel function. Patching the SSDT redirects syscalls to attacker-controlled code.

SSDT hooking is a classic technique that became significantly harder after the introduction of PatchGuard (Kernel Patch Protection, KPP) in 64-bit Windows. PatchGuard monitors the SSDT (among many other structures) and triggers a CRITICAL_STRUCTURE_CORRUPTION bug check (0x109) if it detects modification. As a result, SSDT hooking is essentially dead in 64-bit Windows. However, anti-cheats still verify SSDT integrity as a defense in depth measure.

IDT and GDT Monitoring

The Interrupt Descriptor Table (IDT) maps interrupt vectors to their handler routines. The Global Descriptor Table (GDT) defines memory segments. Both are processor-level structures that cannot be easily protected by PatchGuard alone on all configurations.

A cheat operating at kernel level can attempt to replace IDT entries to intercept specific interrupts, which can be used for control flow interception or as a covert channel. Anti-cheats verify that IDT entries point to expected kernel locations:

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 </pre></td><td><pre>VOID VerifyIDTIntegrity(void) { IDTR idtr; __sidt(&idtr); // Read IDTR register PIDT_ENTRY64 idt = (PIDT_ENTRY64)idtr.Base; for (int i = 0; i < 256; i++) { ULONG_PTR handler = GetIDTHandlerAddress(&idt[i]); // Verify handler is in ntoskrnl or a known driver address range if (!IsKernelCodeAddress(handler)) { ReportIDTModification(i, handler); } } } </pre></td></tr></tbody></table>

Detecting Direct Syscall Usage by Cheats

A common evasion technique is for cheats to perform syscalls directly (using the syscall instruction with the appropriate syscall number) rather than going through ntdll.dll functions. This bypasses usermode hooks placed in ntdll. Anti-cheats detect this by monitoring threads within the game process for syscall instruction execution from unexpected code locations, and by checking whether ntdll functions that should be called are actually being called with expected frequency and patterns.

7. Driver-Level Protections

Detecting Unsigned and Test-Signed Drivers

On a properly configured Windows system with Secure Boot enabled, all kernel drivers must be signed by a certificate trusted by Microsoft. Test signing mode (enabled with bcdedit /set testsigning on) allows loading self-signed drivers and is a common development and cheat-deployment technique.

Anti-cheats detect test signing mode by reading the Windows boot configuration and by checking the kernel variable that reflects whether DSE is currently enforced. Some anti-cheats refuse to launch if test signing is enabled.

The SeValidateImageHeader and SeValidateImageData functions in the kernel validate driver signatures. Anti-cheats can inspect loaded driver objects and verify that their IMAGE_INFO_EX ImageSignatureType and ImageSignatureLevel fields reflect proper signing.

BYOVD Attacks

Bring Your Own Vulnerable Driver is the dominant technique for loading unsigned kernel code in 2024-2026. The attack works as follows:

The attacker finds a legitimate, signed driver with a vulnerability (typically a dangerous IOCTL handler that allows arbitrary kernel memory reads/writes, or that calls MmMapIoSpace with attacker-controlled parameters).
The attacker loads this legitimate driver (which passes DSE because it has a valid signature).
The attacker exploits the vulnerability in the legitimate driver to achieve arbitrary kernel code execution.
Using that kernel execution, the attacker disables DSE or directly maps their unsigned cheat driver.

Common BYOVD targets have included drivers from MSI, Gigabyte, ASUS, and various hardware vendors. These drivers often have IOCTL handlers that expose direct physical memory read/write capability, which is all an attacker needs.

Anti-Cheat Driver Blocklists

The primary defense against BYOVD is a blocklist of known-vulnerable drivers. The Microsoft Vulnerable Driver Blocklist (maintained in DriverSiPolicy.p7b) is built into Windows and distributed via Windows Update. Anti-cheats maintain their own, more aggressive blocklists.

Vanguard in particular is known for actively comparing the set of loaded drivers against its blocklist and refusing to allow the protected game to launch if a blocklisted driver is present. This is enforced because some BYOVD attacks involve loading the vulnerable driver and immediately using it before unloading it, so checking only at game launch with a pre-scan covers most cases.

PiDDBCache and PiDDBLock

This is one of the more interesting internals that kernel cheat developers and anti-cheat engineers both care deeply about.

PiDDBCacheTable is a kernel-internal AVL tree that caches information about previously loaded drivers. When a driver is loaded, the kernel stores an entry keyed by the driver’s TimeDateStamp (from the PE header) and SizeOfImage. This cache is used to quickly look up whether a driver has been seen before. The structure is a RTL_AVL_TABLE protected by PiDDBLock (an ERESOURCE lock).

Cheat developers who manually map a driver without going through the normal load path try to erase or modify the corresponding PiDDBCacheTable entry to conceal that their driver was ever loaded. Anti-cheats detect this by:

Verifying the consistency of the PiDDBCacheTable - if a driver is in memory (found via pool tag scanning or other means) but has no PiDDBCacheTable entry, the entry was probably scrubbed.
Monitoring the PiDDBLock for unexpected acquisitions from non-kernel threads.
Comparing the timestamp/size combinations of all known loaded drivers against the PiDDBCacheTable entries.

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 </pre></td><td><pre>// Locating PiDDBCacheTable (must locate via signature scan since not exported) // This is version-specific and fragile; anti-cheats maintain multiple signatures BOOLEAN FindPiDDBCacheTable(PVOID *TableAddress) { // Pattern to locate PiDDBCacheTable in ntoskrnl // This is a simplified illustration - real implementations use robust pattern matching PVOID ntoskrnl = GetKernelModuleBase("ntoskrnl.exe"); PUCHAR pattern = "\x48\x8D\x0D"; // LEA RCX, [RIP+...] PVOID match = FindPattern(ntoskrnl, pattern, 3, NTOSKRNL_TEXT_RANGE); if (match) { // Extract the RIP-relative offset INT32 offset = *(INT32*)((ULONG_PTR)match + 3); *TableAddress = (PVOID)((ULONG_PTR)match + 7 + offset); return TRUE; } return FALSE; } </pre></td></tr></tbody></table>

Reversing PiCompareDDBCacheEntries

PiDDBCacheTable is not exported and PiDDBCacheEntry is not in public symbols. To interact with the cache, we need to reverse the entry structure. The compare routine is the best starting point since it directly accesses the fields used for ordering.

The decompiled output reveals the structure layout. The function receives two PiDDBCacheEntry pointers and first compares their DriverName fields (a UNICODE_STRING at offset 0x10) using RtlCompareUnicodeString. If the names are equal and TableContext is non-zero, the entries are considered equal. Otherwise, it falls through to comparing the TimeDateStamp field (a ULONG at offset 0x20). This gives us the recovered structure:

<table><tbody><tr><td><pre>1 2 3 4 5 6 </pre></td><td><pre>struct PiDDBCacheEntry { RTL_BALANCED_LINKS Links; // 0x00 - AVL tree node pointers (0x20 bytes) UNICODE_STRING DriverName; // 0x10 - driver filename (from compare routine offset) ULONG TimeDateStamp; // 0x20 - PE header timestamp (secondary sort key) }; </pre></td></tr></tbody></table>

Walking the AVL Tree

PiDDBCacheTable is an RTL_AVL_TABLE, a self-balancing binary search tree. Each node in the tree starts with an _RTL_BALANCED_LINKS header containing Parent, LeftChild, and RightChild pointers. The actual PiDDBCacheEntry data sits immediately after this header.

To enumerate entries, we start by resolving the table address. PiDDBCacheTable is not exported, so anti-cheats locate it via signature scanning in ntoskrnl.exe. In WinDbg with symbols loaded, we can resolve it directly:

The table contains 151 cached driver entries with a tree depth of 9. The CompareRoutine points to PiCompareDDBCacheEntries, confirming this is the right table. The BalancedRoot is the entry point into the tree. Its RightChild gives us the first real node:

From each node, the entry data starts at offset 0x20 (past the _RTL_BALANCED_LINKS header). Adding our recovered offsets: DriverName at node+0x30, TimeDateStamp at node+0x40. Following the LeftChild and RightChild pointers lets us walk the entire tree:

A cheat developer who manually maps a kernel driver would try to find and remove their entry from this tree to avoid detection. An anti-cheat that detects a driver in memory (via pool tag scanning or other means) but finds no corresponding PiDDBCacheTable entry knows the entry was scrubbed.

MmUnloadedDrivers

MmUnloadedDrivers is a kernel array (also not exported) that maintains a circular buffer of the last 50 unloaded drivers, storing their name, start address, end address, and unload timestamp. This structure allows debugging and forensics of driver activity.

Cheat developers who successfully load and then unload a kernel driver often try to zero out or corrupt their entry in MmUnloadedDrivers to hide traces. Anti-cheats detect this by:

Maintaining their own shadow copy of expected MmUnloadedDrivers entries.
Detecting anomalous zero-filled entries in the middle of the circular buffer (a signature of deliberate erasure).
Cross-referencing MmUnloadedDrivers against other kernel timestamps and logs.

BigPool Allocations

When a kernel allocation exceeds approximately 4KB (more precisely, when it exceeds a threshold managed by the pool allocator), it is managed as a “big pool allocation” tracked in the PoolBigPageTable. Anti-cheats scan this table to find memory allocations that were made by manually mapped drivers. A manually mapped driver typically makes large allocations for its code and data sections; these show up in the big pool table with the allocation address but without a corresponding loaded driver.

The technique is to enumerate all big pool entries, then cross-reference each allocation’s address against the list of loaded driver address ranges. Allocations in no driver’s range that are the right size to be driver code sections are suspicious.

8. Anti-Debug Protections

Anti-cheat code itself is a high-value target for reverse engineering. Reverse engineers analyzing the anti-cheat driver need to use kernel debuggers, which anti-cheats aggressively detect.

NtQueryInformationProcess Checks

At the usermode level (in the game-injected DLL), the anti-cheat uses NtQueryInformationProcess with multiple information classes:

ProcessDebugPort (7): Returns a non-zero value if a debugger is attached via DebugActiveProcess. A kernel driver can spoof this by hooking NtQueryInformationProcess, but the check is done in the kernel driver itself as well.
ProcessDebugObjectHandle (30): Returns a handle to the debug object if one exists.
ProcessDebugFlags (31): The NoDebugInherit flag; checking for its inverse reveals debugger presence.

Kernel Debugger Detection

The kernel driver checks the kernel-exported variables KdDebuggerEnabled and KdDebuggerNotPresent. On a system with WinDbg (or any kernel debugger) attached, KdDebuggerEnabled is TRUE and KdDebuggerNotPresent is FALSE.

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 </pre></td><td><pre>BOOLEAN IsKernelDebuggerPresent(void) { // KD_DEBUGGER_ENABLED is a kernel export if (*KdDebuggerEnabled && !*KdDebuggerNotPresent) { return TRUE; } // Additional check: attempt a debug break and see if it's handled // More sophisticated: check specific kernel structures return FALSE; } </pre></td></tr></tbody></table>

Some anti-cheats go further and directly inspect the KDDEBUGGER_DATA64 structure and the shared kernel data page (KUSER_SHARED_DATA) for debugger-related flags.

Thread Hiding Detection

NtSetInformationThread with ThreadHideFromDebugger (17) sets a flag in the thread’s ETHREAD structure (CrossThreadFlags.HideFromDebugger). Once set, the kernel will not deliver debug events for that thread to any attached debugger. The thread becomes essentially invisible to WinDbg: breakpoints in the thread do not trigger debugger notification, exceptions are not forwarded.

Anti-cheats use this to protect their own threads. However, they also detect if cheats are using it to hide their own injected threads. The detection method is to enumerate all threads in the system via a kernel enumeration (not via usermode APIs that could be hooked) and check the HideFromDebugger bit in CrossThreadFlags for each thread. A hidden thread in the game process that the anti-cheat did not itself hide is a red flag.

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 </pre></td><td><pre>// Check CrossThreadFlags for HideFromDebugger #define PS_CROSS_THREAD_FLAGS_HIDEFROMDEBUGGER 0x4 VOID CheckThreadDebugVisibility(PETHREAD Thread) { // CrossThreadFlags is at a version-specific offset in ETHREAD ULONG crossFlags = *(ULONG*)((ULONG_PTR)Thread + ETHREAD_CROSS_THREAD_FLAGS_OFFSET); if (crossFlags & PS_CROSS_THREAD_FLAGS_HIDEFROMDEBUGGER) { // Thread is hidden from debuggers // If we didn't hide it, flag it if (!IsAntiCheatOwnedThread(Thread)) { ReportHiddenThread(Thread); } } } </pre></td></tr></tbody></table>

To demonstrate this detection, we use a test tool that creates a remote thread in Target.exe and then sets ThreadHideFromDebugger on it:

In WinDbg, we convert the decimal TID to hex, locate the thread in the process, and inspect its CrossThreadFlags. Before setting the flag, the value is 0x5402 with bit 2 (HideFromDebugger) clear:

After calling NtSetInformationThread with ThreadHideFromDebugger, the value changes to 0x5406. Bit 2 is now set, making this thread invisible to any attached debugger:

An anti-cheat enumerating threads in the game process would check this bit on every thread. A hidden thread that the anti-cheat did not create itself is a strong indicator of injected cheat code.

Timing-Based Anti-Debug

Single-step debugging (via the TF flag in EFLAGS) and hardware breakpoints dramatically increase the time between instruction executions. Anti-cheats use RDTSC instruction-based timing to detect this:

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 </pre></td><td><pre>UINT64 before = __rdtsc(); // Execute a fixed number of operations volatile ULONG dummy = 0; for (int i = 0; i < 1000; i++) dummy += i; UINT64 after = __rdtsc(); UINT64 elapsed = after - before; if (elapsed > EXPECTED_MAXIMUM_CYCLES) { // Execution was slowed - likely single-stepping or a breakpoint ReportDebuggerDetected(); } </pre></td></tr></tbody></table>

The threshold EXPECTED_MAXIMUM_CYCLES is calibrated based on known CPU behavior. Single-stepping can add thousands of cycles per instruction (due to debug exception handling), making the timing discrepancy obvious.

Hardware Breakpoint Detection

The x86-64 debug registers (DR0-DR3 for breakpoint addresses, DR6 for status, DR7 for control) are accessible in kernel mode. Reading them allows detection of hardware breakpoints set by a debugger:

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 </pre></td><td><pre>BOOLEAN HasHardwareBreakpoints(void) { ULONG_PTR dr7 = __readdr(7); // Read DR7 (debug control register) // Check Local Enable bits (L0, L1, L2, L3) for each breakpoint // Bits 0, 2, 4, 6 of DR7 are the local enable bits for BP 0-3 if (dr7 & 0x55) { // 0x55 = 01010101b - all four local enable bits return TRUE; } return FALSE; } </pre></td></tr></tbody></table>

Anti-cheats scan all threads’ saved debug register state (accessible via CONTEXT structure obtained with KeGetContextThread or directly from KTHREAD::TrapFrame) for active hardware breakpoints not set by the anti-cheat itself.

Hypervisor-Based Debugger Detection

Type-1 hypervisor-based debuggers (like a custom hypervisor running a Windows VM for isolated debugging) are significantly harder to detect. The primary detection vectors are:

CPUID checks: The hypervisor present bit (bit 31 of ECX when CPUID leaf 1 is executed) indicates a hypervisor is present. The hypervisor vendor can be queried with CPUID leaf 0x40000000. VMware returns “VMwareVMware”, VirtualBox returns “VBoxVBoxVBox”. An unknown vendor string is suspicious.

MSR timing: Executing RDMSR in a VM introduces additional overhead compared to native execution. Anti-cheats time MSR reads and flag anomalies.

CPUID instruction timing: The CPUID instruction itself is a privileged instruction in virtualized environments and must be handled by the hypervisor, introducing measurable latency.

9. DMA Cheats and Detection

DMA cheats represent the current frontier of the anti-cheat arms race, and they are genuinely hard to address with software alone.

What DMA Cheats Are

A PCIe DMA (Direct Memory Access) cheat uses a PCIe-connected device - typically a development FPGA board - that can directly read the host system’s physical memory via the PCIe bus without the CPU being involved. The pcileech framework and its LeechCore library provide the software stack for these devices. The device physically appears on the PCIe bus, acquires access to the host’s physical memory via the PCIe TLP (Transaction Layer Packet) protocol, and reads game process memory by translating virtual addresses to physical addresses (using the page tables, which are also in physical memory and can be read by the device).

The attacking machine (running the cheat software) is physically separate from the victim machine (running the game). All cheat logic runs on the attacker’s machine. The game machine has no processes, no drivers, no memory allocations from the cheat. From a pure software perspective, the game machine is completely clean.

The FPGA sits on the game PC’s PCIe bus and reads physical memory via TLPs without CPU involvement. The cheat software runs entirely on a separate machine, leaving the game PC clean from a software perspective.

PCIe Internals

PCIe communication is structured around TLPs. A memory read TLP from a DMA device contains the physical address to read and the requested byte count. The PCIe root complex services this request by reading the specified physical memory and returning the data in a completion TLP. This is entirely hardware-level and the CPU is not involved in servicing the request.

The device needs to be configured with a valid BAR (Base Address Register) that the BIOS assigns during PCIe enumeration. The device also needs the target system’s IOMMU (if present) to either be disabled or to have the device’s DMA transactions allowed through it.

IOMMU as a Defense

The IOMMU (Intel VT-d, AMD-Vi) is a hardware unit that translates DMA addresses from PCIe devices using a device-specific page table (analogous to the CPU’s page tables for usermode address translation). If the IOMMU is enabled and properly configured, a PCIe device can only access physical memory that the OS has explicitly granted to it via the IOMMU page tables.

With IOMMU enabled, a DMA device that is not associated with any OS driver has no IOMMU mappings and cannot access arbitrary physical memory. This is theoretically a hardware-level defense against DMA attacks.

In practice, the IOMMU defense has significant gaps. Many gaming motherboards ship with IOMMU disabled by default. Even when enabled, the IOMMU configuration is complex and many systems have misconfigured IOMMU policies that leave large physical memory ranges accessible. And critically, DMA firmware that successfully impersonates a legitimate PCIe device (e.g., a USB controller or a network card that the OS has granted IOMMU access to) can potentially access memory through the IOMMU using the legitimate device’s granted permissions.

DMA Firmware Mimicry

Sophisticated DMA cheat firmware is designed to mimic the PCIe device ID, vendor ID, subsystem ID, and BAR0 configuration of a legitimate device. A Xilinx FPGA running customized firmware can present itself to the BIOS and OS as, for example, a USB host controller. The OS loads the legitimate driver for that device (providing IOMMU coverage), and the FPGA firmware uses that coverage to perform DMA reads.

Anti-cheats attempt to detect this by enumerating all PCIe devices and validating that each device’s reported characteristics match expected hardware. But without specific firmware-level attestation, it is very difficult to distinguish legitimate hardware from a properly mimicking FPGA.

Secure Boot and TPM as Partial Mitigations

Epic Games’ requirement for Secure Boot and TPM 2.0 for Fortnite is directly related to the DMA threat. Secure Boot ensures that only signed bootloaders run, which prevents boot-time attacks that could disable IOMMU or install firmware-level cheats. TPM 2.0 enables measured boot (where each boot stage’s hash is recorded in the TPM’s PCR registers), providing an attestation chain that proves the system booted in a known-good state. Remote attestation using the TPM can allow a server to verify that the client system has not been tampered with at the firmware level.

This does not solve the DMA problem directly (a DMA attack device physically attached to the PCIe slot bypasses all of this), but it closes some of the software-assisted DMA attack paths.

10. Behavioral Detection and Telemetry

No static protection scheme is sufficient. Behavioral detection operating on game telemetry is the complementary layer that addresses what kernel protections cannot.

Mouse and Input Analysis

The kernel anti-cheat driver operates at a level where it can intercept raw input before it reaches the game. Drivers for HID (Human Interface Device) input, specifically for mice and keyboards, sit in the input driver stack. By installing a filter driver above mouclass.sys or kbdclass.sys, an anti-cheat can observe all input events with timestamps accurate to the system clock (microsecond resolution).

Aimbot detection targets the statistical properties of mouse movement. Human aiming exhibits specific properties: Fitts’ Law governs approach trajectories, there is characteristic deceleration as the cursor approaches a target, velocity profiles have specific acceleration and deceleration curves, and there is measurement noise. An aimbot performing perfect linear interpolation to a target produces movement that violates these properties. A triggerbot (which fires automatically when the crosshair is on target but does not manipulate mouse movement) is detected via reaction time analysis: human reaction times to a target crossing the crosshair have a minimum physiological floor (approximately 150-200ms) with a characteristic distribution. Reaction times below this floor with high consistency indicate automation.

Machine Learning Detection

The Collins et al. (CheckMATE 2024) paper documents the application of CNNs to triggerbot detection, achieving approximately 99.2% accuracy on labeled datasets. The features fed to the network include mouse position time series, click timing relative to target position, and velocity profiles.

The AntiCheatPT paper (2025) applies transformer architectures to aimbot detection. Using 256-tick windows with 44 data points per tick (including position, velocity, acceleration, view angle rates, and click events), the model achieves 89.17% accuracy in distinguishing legitimate players from aimbot users. The transformer architecture is well-suited to this problem because aimbots often introduce temporal correlations in the input data (smooth tracking, periodic corrections) that attention mechanisms can exploit.

Graph neural networks are used for collusion detection (wallhack and communication-based cheating in team games) by modeling player interaction graphs and detecting anomalous patterns, such as players consistently targeting enemies through walls or demonstrating perfect awareness of enemy positions without line-of-sight.

Left: a legitimate player’s mouse path follows Fitts’ Law with a natural S-curve, overshoot, and micro-corrections. Right: an aimbot produces an idle phase followed by an instant linear snap to the target with no natural deceleration.

Telemetry Pipeline

The flow from raw data to ban decision typically works as follows:

The kernel driver captures input events and timestamps them at the hardware interrupt level.
These events are written to a shared memory ring buffer.
The usermode service reads from the ring buffer, batches events, encrypts them, and transmits to backend servers.
Backend ML inference runs on the event stream and produces anomaly scores.
A manual review queue receives high-confidence flagged sessions.
Ban decisions are pushed back to the game client via the service.

The encryption of telemetry data is critical both for privacy (the data includes all mouse movements) and for anti-tamper (preventing cheats from identifying and falsifying telemetry).

11. Anti-VM and Environment Checks

CPUID-Based VM Detection

The most reliable VM detection is CPUID-based. When CPUID is executed with EAX=1, bit 31 of ECX is set if a hypervisor is present (this is the “Hypervisor Present” bit). With EAX=0x40000000, the hypervisor vendor string is returned in EBX, ECX, EDX:

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 </pre></td><td><pre>BOOLEAN IsRunningInVM(void) { int cpuInfo[4]; __cpuid(cpuInfo, 1); // Check hypervisor present bit (ECX bit 31) if (cpuInfo[2] & (1 << 31)) { // Get hypervisor vendor __cpuid(cpuInfo, 0x40000000); char vendor[13]; memcpy(vendor, &cpuInfo[1], 4); memcpy(vendor + 4, &cpuInfo[2], 4); memcpy(vendor + 8, &cpuInfo[3], 4); vendor[12] = '\0'; // Known VM vendors if (strcmp(vendor, "VMwareVMware") == 0 || strcmp(vendor, "VBoxVBoxVBox") == 0 || strcmp(vendor, "Microsoft Hv") == 0 || // Hyper-V strcmp(vendor, "KVMKVMKVM") == 0) { return TRUE; } return TRUE; // Unknown hypervisor is also suspicious } return FALSE; } </pre></td></tr></tbody></table>

Artifact-Based VM Detection

Each VM platform leaves characteristic artifacts in the registry and device enumeration:

VMware: Registry key HKLM\SOFTWARE\VMware, Inc.\VMware Tools; PCI device \Device\VMwareHGFS; virtual devices appearing in Win32_PnPEntity with “VMware” in the name.
VirtualBox: HKLM\SOFTWARE\Oracle\VirtualBox Guest Additions; VBoxMiniRdDN driver; registry key HKLM\HARDWARE\ACPI\DSDT\VBOX__.
Hyper-V: HKLM\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters; presence of vmbus and storvsc driver objects.

Anti-cheats query these artifacts from kernel mode where they cannot be intercepted by usermode hooking. A system presenting any of these artifacts is likely running in a VM, and the anti-cheat can refuse to operate or flag the session.

Detecting Nested Hypervisors

Cheat developers sometimes use nested hypervisors to create a transparent analysis environment: they run the game in a VM, with the cheat running in the VM’s host. Detection of nested hypervisors relies on timing anomalies: CPUID executed inside a nested VM is handled by two hypervisors in sequence, introducing double the overhead. RDMSR and WRMSR instructions similarly have amplified latency. Statistical analysis of hundreds of timing measurements can reliably distinguish native execution, single-level virtualization, and nested virtualization.

12. Hardware Fingerprinting and Ban Enforcement

Collected Identifiers

Anti-cheats collect multiple hardware identifiers to create a unique fingerprint that survives account banning:

SMBIOS data: Manufacturer, product name, serial numbers, UUID. Accessed via NtQuerySystemInformation(SystemFirmwareTableInformation, ...) or directly via the firmware table.
Disk serial numbers: Physical disk serial numbers via IOCTL IOCTL_STORAGE_QUERY_PROPERTY. These are stable identifiers that survive OS reinstallation.
GPU identifiers: Device instance ID, adapter LUID.
MAC addresses: NIC MAC addresses via NDIS or the registry. These are spoofable at the software level but often not changed by non-technical users.
Boot GUID: The MachineGuid in HKLM\SOFTWARE\Microsoft\Cryptography, or more persistently, the UEFI firmware’s platform UUID accessible via SMBIOS.

The Vanguard analysis from the rhaym-tech GitHub gist documents vgk.sys collecting BIOS information, including the system UUID and various SMBIOS fields, which are combined into a hardware fingerprint for ban enforcement.

HWID Spoofing and Detection

HWID spoofing involves modifying the identifiers that the anti-cheat reads to evade a hardware ban. Spoofing approaches include:

Registry-based spoofing: Patching the registry entries that report disk serial numbers, MAC addresses, and SMBIOS data. This works against anti-cheats that query these through registry paths rather than directly.
Driver-level spoofing: A kernel driver that intercepts IOCTL requests for hardware identifiers and returns spoofed values. This works against anti-cheats that use standard IOCTL paths but fails against anti-cheats that query hardware directly.
Physical spoofing: Programming a different MAC address into NIC firmware, flashing new disk serial numbers (supported by some drives). This is rare and sometimes permanent.

Anti-cheats detect spoofing by cross-referencing multiple identifier sources. If the SMBIOS UUID is FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF (a common spoofed value), that is an immediate flag. If the reported disk model is “Samsung 970 EVO” but the disk serial number format does not match Samsung’s format, that is a spoof indicator. If the UEFI firmware tables report one UUID and the registry reports a different one, the registry value has been tampered with.

13. The Arms Race: Current Trends and Future Directions

The Escalation Hierarchy

The escalation we have seen over the past decade follows a clear pattern:

Usermode cheats were countered by usermode anti-cheat.
Kernel cheats were countered by kernel anti-cheat.
Kernel cheats with BYOVD were countered by driver blocklists and stricter DSE enforcement.
Hypervisor-based cheats were countered by hypervisor detection.
DMA cheats are the current frontier, partially countered by IOMMU, Secure Boot, and TPM attestation.
The next level is firmware-based attacks, where the cheat is embedded in the SSD firmware, GPU firmware, or NIC firmware.

Firmware attacks are particularly concerning because they survive OS reinstallation, are invisible to all kernel-level inspection, and are extremely difficult to detect without physical access to the device for firmware verification. There is no widespread anti-cheat defense against firmware cheats today.

AI-Powered Cheats

The next-generation threat is aimbots powered by computer vision models that run on the GPU or a secondary computer. These systems use a camera or screen capture to analyze the game frame, identify targets, and move the mouse via hardware (a USB HID device, bypassing software input inspection entirely). The mouse movements they produce can be configured to mimic human motion patterns, making statistical detection much harder.

An AI aimbot operating via hardware HID is, from the game machine’s perspective, completely indistinguishable from a human using a mouse. All input comes through legitimate hardware channels. No code runs in the game process. The kernel is entirely clean. The only detection surface is the behavioral profile: the accuracy, reaction times, and movement patterns that the AI produces.

This is why the behavioral ML approaches discussed in section 10 are not optional but increasingly central to effective anti-cheat.

The Privacy Debate

Kernel-level anti-cheat is deeply unpopular among privacy advocates. The criticisms are substantive:

A driver running at ring 0 with boot-time loading has access to everything on the system. While BattlEye, EAC, and Vanguard are not documented to abuse this access for surveillance, the technical capability exists. The ARES 2024 paper’s analysis underscores that the trust model is identical to what we use for security-critical software, which means any vulnerability in these components is a local privilege escalation to ring 0.

The fact that games require installation of boot-time kernel drivers as a condition of play is also a significant attack surface concern. A vulnerability in vgk.sys is a local privilege escalation to ring 0. The anti-cheat software itself becomes an attack target.

Attestation-Based Approaches

The most technically promising direction for anti-cheat is remote attestation. Rather than running a ring-0 driver that actively fights cheats, the system proves to the game server that it is running in a known-good state. TPM-based measured boot, combined with UEFI Secure Boot, can generate a cryptographically signed attestation that specific bootloaders, kernels, and drivers were loaded. The server refuses connections from systems that cannot provide valid attestation.

This is not a complete solution (a sufficiently sophisticated attacker can potentially manipulate attestation), but it significantly raises the bar. Attestation can coexist with traditional scanning to provide defense in depth.

Cloud Gaming as Anti-Cheat

Cloud gaming (GeForce Now, Xbox Cloud Gaming) is architecturally the ultimate anti-cheat for certain game categories. If the game runs in a data center and only video is streamed to the client, there is no game client code to exploit, no game memory to read, and no local environment to manipulate. The cheat attack surface reduces to input manipulation and video analysis, both of which have relatively straightforward detection approaches.

The constraint is latency: cloud gaming is unsuitable for competitive titles where single-digit millisecond reaction times matter. For casual and semi-competitive play, cloud delivery may increasingly be the answer.

14. Conclusion

Modern kernel anti-cheat systems represent a layered defensive architecture that operates across every available level of the Windows privilege model:

Kernel callbacks (ObRegisterCallbacks, PsSetCreateProcessNotifyRoutineEx, PsSetLoadImageNotifyRoutine) provide real-time visibility into system events with the ability to actively block malicious operations.
Memory scanning (VAD walking, big pool enumeration, code section hashing) provides periodic verification that game memory has not been tampered with and that no injected code is present.
Behavioral telemetry (input analysis, statistical profiling, ML inference) catches cheats that are architecturally invisible to kernel scanning.
Hardware fingerprinting enforces ban decisions across account resets.
Anti-debug and anti-VM protections make reverse engineering and development significantly more difficult.

No single technique is sufficient. Kernel callbacks can be bypassed by DMA attacks. Memory scanning can be evaded by hypervisor-based cheats that intercept memory reads. Behavioral detection can be fooled by sufficiently human-mimicking AI. Hardware fingerprinting can be defeated by hardware spoofers. It is the combination of all these layers, continually updated in response to new evasion techniques, that provides meaningful protection.

The trajectory of this arms race points toward hardware attestation and server-side verification as the ultimate foundations of trustworthy game security. Software-only client-side protection will always be asymmetric: defenders must check everything, attackers need only find one gap. Hardware attestation shifts this asymmetry by making it extremely difficult to demonstrate a trustworthy state while operating a modified system.

Until that foundation is universally available and enforced, kernel anti-cheat remains the best practical defense available, with all the associated complexity, privacy implications, and attack surface that entails.

References

Collins, R. et al. “Anti-Cheat: Attacks and the Effectiveness of Client-Side Defences.” CheckMATE 2024 (Workshop co-located with CCS 2024). https://tomchothia.gitlab.io/Papers/AntiCheat2024.pdf
Vella, R. et al. “If It Looks Like a Rootkit and Deceives Like a Rootkit: A Critical Analysis of Kernel-Level Anti-Cheat Systems.” ARES 2024. https://arxiv.org/pdf/2408.00500
Sousa, J. et al. “AntiCheatPT: A Transformer-Based Approach to Cheat Detection in First-Person Shooter Games.” 2025. https://arxiv.org/html/2508.06348v1
secret.club. “Reversing BattlEye’s anti-cheat kernel driver.” 2019. https://secret.club/2019/02/10/battleye-anticheat.html
secret.club. “Easy Anti-Cheat integrity check bypass.” 2020. https://secret.club/2020/04/08/eac_integrity_check_bypass.html
back.engineering. “Reversing BEDaisy.sys.” 2020. https://back.engineering/blog/2020/08/22/
Aki2k. “BEDaisy Reverse Engineering.” GitHub. https://github.com/Aki2k/BEDaisy
archie-osu. “Vanguard Dispatch Table Hooks Analysis.” 2025. https://archie-osu.github.io/2025/04/11/vanguard-research.html
rhaym-tech. “Vanguard vgk.sys Analysis Gist.” GitHub Gist. https://gist.github.com/rhaym-tech/f636b76deeca15528e70304b5ee95980
donnaskiez. “ac: Open Source Kernel Anti-Cheat.” GitHub. https://github.com/donnaskiez/ac