What Kernel Anti-Cheat Software Sees On A Gaming PC
Every time someone installs Valorant, they’re also installing a kernel-mode driver that loads before Windows finishes booting and keeps running as long as the machine is on, whether or not the game is open. That driver is Riot’s Vanguard. Call of Duty ships Ricochet. Fortnite and dozens of other titles run BattlEye or EasyAntiCheat in the same privileged position. This is now the default architecture for competitive multiplayer games, and it’s worth understanding what “kernel-mode” actually buys the anti-cheat vendor, because the visibility it grants is very different from the antivirus-style scanning most people picture.
Why anti-cheat moved into the kernel
Windows separates code into two privilege levels, commonly called rings. User-mode (ring 3) is where ordinary applications run, including the game itself and, historically, most anti-cheat software. Kernel-mode (ring 0) is where the operating system’s core, along with hardware drivers, runs with essentially unrestricted access to memory and hardware.
A user-mode anti-cheat can only see what the operating system chooses to show it through documented APIs. A cheat running with equal or higher privilege can hide from those APIs, hook the functions the anti-cheat calls, or simply lie to it. This was the standard cat-and-mouse setup for years: user-mode anti-cheat versus user-mode cheat, with the cheat frequently winning because it could manipulate the same layer the anti-cheat was standing on.
Moving anti-cheat into the kernel changes the footing. A kernel driver sits at the same privilege level as the operating system itself, which means a cheat now has to either also run in kernel mode, a much harder and riskier proposition, or find gaps the driver doesn’t cover. That’s the entire rationale. It isn’t about scanning more files, it’s about not being lied to by the layer being scanned.
What the driver can actually observe
Once loaded, a kernel anti-cheat driver has the same class of access as any other kernel component. In practice, publicly documented behavior for drivers like this includes:
Process and module enumeration. The driver can list every running process and every DLL loaded into every process, including ones a user-mode tool might not see if something is hiding them. It can walk the same kernel structures the OS scheduler uses, rather than trusting an API call that a hooked process could intercept.
Memory reads. The driver can read the memory of the game process, and in some implementations the memory of other processes on the machine, looking for known cheat signatures, unexpected code in memory regions that should only contain game code, or memory pages with suspicious permissions such as executable-and-writable regions that legitimate software rarely needs.
Driver and handle inspection. It can enumerate other kernel drivers loaded on the system, checking digital signatures and looking for drivers known to be associated with cheat loaders, debuggers, or virtualization tools used to tamper with a running process. It can also inspect open handles, which reveal what other processes are trying to access the game’s memory or threads.
Hardware and system identifiers. Kernel access exposes low-level hardware IDs such as disk serials, motherboard and BIOS identifiers, and network adapter MAC addresses. This is the same category of signal used for hardware bans, where a cheater’s account ban is paired with an attempt to flag the physical machine, not just the login.
Kernel callback registration. Windows lets kernel drivers register callbacks for events like process creation, thread creation, and image loading. An anti-cheat driver can subscribe to these and get notified the instant a new process starts or a new module loads anywhere on the system, rather than polling and hoping to catch something transient.
None of this requires the driver to “see the screen” or “read files” in the sense people sometimes worry about. It’s closer to a privileged inventory and integrity check of what’s running and how it’s running, evaluated continuously instead of at a single scan point.
What it doesn’t automatically mean
This is where a lot of the public anxiety around kernel anti-cheat outpaces what’s documented. Kernel-mode access is broad, but the driver only does what its code tells it to do, and vendors have been explicit about scope in response to scrutiny. Vanguard’s own disclosures, for instance, describe it as looking at processes and drivers relevant to cheating, not as a general-purpose keylogger or browser-history scraper. That distinction matters for the trust model: the concern isn’t really “can it technically read arbitrary memory,” because at ring 0 almost anything is technically possible, it’s “what does the shipped binary actually do, and can that be independently verified.”
This is also why kernel anti-cheat draws sustained criticism even from security researchers who accept the underlying logic. A driver with this level of access is also a driver with this level of attack surface. If it has a vulnerability, that vulnerability exists at the same privilege as the operating system, which is a much worse place for a bug to live than inside a sandboxed game process. Vendors respond to this with code signing requirements, restricted rollout, and bug bounty programs, but the fundamental tradeoff, more visibility for the anti-cheat in exchange for a bigger blast radius if something goes wrong, doesn’t go away.
Boot-time loading and the always-on question
Several of these drivers, Vanguard being the most discussed example, load at boot time via an early-launch mechanism rather than only when the associated game starts. The stated reason is straightforward from a defense standpoint: cheats that load before the anti-cheat does can potentially hide from it, so the anti-cheat needs to be running before most other software has a chance to. Loading early closes that race condition.
The tradeoff is that the driver is then present on the system even when the person isn’t playing the game, which is the detail that generates the most pushback. Vendors have walked this back or modified it in response to user complaints in various ways over time, including options to disable boot-time loading when not gaming, but the underlying tension, early loading helps catch early-loading cheats, but also means a privileged driver persists outside the context it was installed for, is inherent to the design and not something that gets fully resolved.
The other side: how cheat developers try to stay out of view
None of this makes kernel anti-cheat unbeatable, and no vendor claims it is. The response from cheat developers has largely moved to two places. One is hardware-level cheating, most notably DMA (direct memory access) cheat devices that read a target machine’s memory through a secondary hardware interface such as a PCIe card, bypassing the host’s own kernel entirely because the reading happens from outside the operating system’s control. The other is kernel-mode cheats themselves, which try to match the anti-cheat’s privilege level rather than operate beneath it, turning the fight into driver versus driver.
Anti-cheat vendors respond to both. Against DMA cheats, some systems look for behavioral fingerprints of external reads or unusual PCIe device enumeration rather than trying to inspect the reading hardware directly. Against rival kernel drivers, they lean on Windows’ driver signature enforcement, blocklists of known-bad driver hashes, and Microsoft’s vulnerable driver blocklist, which flags legitimate signed drivers with exploitable bugs that cheats have historically abused to get kernel access without writing their own driver from scratch. It’s the same asymmetric pattern found everywhere else in this space, detection systems, whether they’re watching for cheats, bots, or fraudulent traffic, publish just enough about their methods to be trusted and just little enough to stay ahead of whoever’s trying to map them.
Conclusion
Kernel anti-cheat exists because the layer below where a game runs turned out to be the only layer a game could trust, and that same logic explains most of the privacy debate around it: the access is real and broad by design, the actual behavior is narrower and vendor-defined, and the gap between those two facts is exactly what security researchers keep pressing on. It’s a small, specific example of a much larger pattern this site spends most of its time on, where platforms and the people trying to get around their rules keep pushing the point of detection lower in the stack, and each move down buys real advantage while opening a new and higher-stakes kind of risk.
If you want more of this kind of look under the hood of the systems that watch, verify, and get gamed back, head back to the Hidden Internet homepage for the rest of the series.
Get new guides and videos first — join the Telegram channel.