Ring 0 and the Price of Fair Play: How Kernel Anti-Cheat Drivers Actually Work

Every time you launch Valorant, Call of Duty: Warzone, or PUBG, a kernel-mode driver loads alongside the game. That driver runs at ring 0, the same privilege level as the Windows kernel itself, with unrestricted access to every process, every mapped memory region, and every hardware peripheral on your machine. The industry converged on this approach not because it is elegant, but because every less invasive approach lost the arms race first.

Understanding why requires a short trip into how the x86 privilege model actually works.

The Ring Model and Why It Matters

Modern x86 processors implement four privilege rings, numbered 0 through 3. Windows uses two of them: ring 0 for the kernel and kernel-mode drivers, and ring 3 for all user-space applications, including games and, crucially, the cheats that attach to them. The separation is enforced in hardware. A ring-3 process cannot read another process’s memory directly; it has to ask the kernel through system calls like NtReadVirtualMemory. The kernel can intercept those calls, log them, or refuse them.

For the first decade or so of online gaming, cheat detection lived entirely in ring 3. Tools like Valve Anti-Cheat (VAC) and the early versions of PunkBuster ran as user-space processes that scanned for known cheat signatures, monitored API call patterns, and looked for injected DLLs. This worked well enough when cheats were also confined to ring 3.

The problem is that ring 3 gives cheats and anti-cheats exactly the same visibility into the system. A cheat DLL injected into a game process can hook the same Windows APIs that anti-cheat uses to monitor behavior. Once both sides are operating at the same privilege level, the attacker has the inherent advantage: they choose where to hide, and the defender has to find them.

What Kernel Drivers Can See

A ring-0 driver loaded through the Windows kernel driver model has access to a set of registration APIs that user-space code cannot touch. The key ones are:

• PsSetCreateProcessNotifyRoutine: fires a callback whenever any process on the system is created or terminated
• PsSetLoadImageNotifyRoutine: fires whenever a PE image (EXE or DLL) is mapped into memory, including injected DLLs
• ObRegisterCallbacks: allows the driver to intercept and modify handle operations, including OpenProcess calls that a cheat would use to get a handle to the game
• MmGetSystemRoutineAddress and direct EPROCESS structure traversal: allows walking the kernel’s process list directly, bypassing the user-space process enumeration APIs entirely

This deep dive from s4dbrd covers many of these callback mechanisms in detail. What it sets up well is the fundamental asymmetry: a kernel driver watching for OpenProcess calls to the game process can block any user-space cheat from getting a handle with PROCESS_VM_READ permissions, which is required for external memory reading cheats. The cheat simply cannot read game memory if the anti-cheat driver intercepts and denies the handle before it’s returned.

BattlEye and Easy Anti-Cheat (EAC, now owned by Epic Games) both implement this pattern. Riot’s Vanguard takes it further by loading its driver, vgk.sys, at Windows boot rather than at game launch, which gives it visibility into the entire machine state before any cheating software could have established a foothold.

How Cheat Developers Responded

The natural response to ring-0 anti-cheat is to move cheats to ring 0 as well. Since Windows Vista 64-bit, Microsoft requires all kernel drivers to be cryptographically signed by a trusted certificate authority under the Kernel Mode Code Signing (KMCS) policy. Loading an unsigned driver requires enabling test signing mode, which is easily detected.

This pushed cheat developers toward what is now called the Bring Your Own Vulnerable Driver (BYOVD) attack. The technique is straightforward: ship a legitimate, signed kernel driver that has a known vulnerability, exploit that vulnerability to execute arbitrary code at ring 0, and then do whatever you want from there. The driver itself is signed; the malicious code it executes is not, but by that point you already have kernel privileges and can write directly to kernel memory.

The Capcom incident in 2016 is the canonical example of this going wrong outside the cheating context. Capcom shipped Street Fighter V with a deliberately weak kernel driver, capcom.sys, that exposed an ioctl allowing user-space callers to execute arbitrary shellcode with kernel privileges. The driver was signed and trusted. Security researchers and cheat developers alike recognized immediately that this was a universal privilege escalation primitive available to any process on the system.

Microsoft maintains a Vulnerable Driver Blocklist that is updated through Windows Update, but it is inherently reactive. The blocklist is only effective against known vulnerable drivers; novel BYOVD chains using freshly discovered vulnerabilities in signed drivers are a continuing problem. Threat intelligence reports from groups like ESET and Mandiant have documented multiple nation-state actors using BYOVD as part of their intrusion toolkit, specifically because it is so effective.

DMA Cheats: Escaping Software Entirely

The most technically sophisticated cheat category currently in active use is Direct Memory Access (DMA) cheating. These attacks use a PCIe DMA device, typically a commodity FPGA board like the Screamer PCIe Squirrel or similar hardware, inserted into the target machine’s motherboard.

DMA is a hardware feature that allows PCIe devices to read and write system memory without involving the CPU. It is fundamental to how GPUs, network cards, and storage controllers work. A DMA cheat device presents itself to the OS as a legitimate PCIe device (often spoofing the device ID of a common NIC or USB controller) while simultaneously offering a second interface, over USB or another PCIe link, to a second machine running the actual cheat software.

From the second machine, the cheat reads the game’s process memory directly over the DMA link. The game machine’s OS never sees a suspicious ReadProcessMemory call, because no such call is made. The kernel anti-cheat driver never fires its handle callbacks, because no handle is opened. The read happens below the kernel’s visibility, at the hardware level.

Countermeasures against DMA cheats are limited and expensive. IOMMU (Input-Output Memory Management Unit) virtualization, when properly configured, can restrict which physical addresses a PCIe device is allowed to access. Windows’ Virtualization Based Security (VBS) and Hypervisor-Protected Code Integrity (HVCI) use the IOMMU to enforce this, but IOMMU protection requires hardware support, correct BIOS configuration, and imposes some overhead. Most gaming systems do not have it enabled, and even when they do, sophisticated DMA boards implement firmware that spoofs device identity at the PCIe transaction layer to look like a trusted device that the IOMMU’s allowlist permits.

The Hypervisor Layer

Another bypass category uses hardware virtualization directly. By running the game inside a Type-1 or Type-2 hypervisor, a cheat can introspect the guest VM’s memory from the host, where no anti-cheat driver has visibility. The anti-cheat driver running inside the guest sees a normal machine; the cheat running in the host sees everything.

Detecting hypervisor presence is an active area of anti-cheat research. Common detection vectors include:

• Timing attacks: certain instructions take measurably longer when executed inside a VM due to VM exits
• CPUID leaf inspection: hypervisors expose a hypervisor-present bit and vendor strings in CPUID leaves 0x40000000 and above
• RDTSC (Read Time-Stamp Counter) consistency checks: a hypervisor intercepting RDTSC will sometimes produce inconsistent timestamps relative to wall-clock time
• Absence of expected hardware: some anti-cheats fingerprint TPM state, specific MSRs, and hardware identifiers that are difficult to spoof convincingly inside a VM

None of these detections are foolproof. A sufficiently customized hypervisor (based on projects like KVM or Xen with guest-visible virtualization artifacts suppressed) can pass most checks. The detection burden on anti-cheat is significant because false positives mean banning legitimate players who happen to be running WSL2, Hyper-V, or VMware for unrelated reasons.

The Security Trade-Off

The architecture that makes kernel anti-cheat effective is also what makes it a legitimate security concern. A ring-0 driver with broad handle interception, memory scanning capabilities, and boot-time initialization has exactly the same system access profile as a rootkit. The difference between Vanguard and a sophisticated piece of malware, from the OS’s perspective, is that one of them has a valid Authenticode signature and the other does not.

This creates real risk. Any exploitable vulnerability in a kernel anti-cheat driver is a kernel privilege escalation for every player who has that driver loaded. Anti-cheat vendors are a target: a zero-day in a widely deployed anti-cheat driver reaches millions of machines simultaneously. EAC and BattlEye combined are present on a large fraction of gaming PCs, making their driver attack surfaces a high-value target.

Activision’s Ricochet anti-cheat, introduced for Warzone in 2021, added a different layer: rather than simply banning detected cheaters, it began serving corrupted data to players its driver flagged as cheating. Detected cheaters would see incorrect player positions, take elevated damage, or find their weapons disabled. This approach, sometimes called hallucination or adversarial anti-cheat, is interesting precisely because it does not require the detection to be perfect. Even a high false-negative rate can degrade the cheating experience enough to reduce the economic incentive for cheat development.

Where This Goes

The kernel arms race has a structural problem: both sides keep escalating the privilege level of their code, and the legitimate players are the ones running third-party ring-0 code with significant system access and a correspondingly significant attack surface. Server-side statistical detection, replay analysis, and machine learning classifiers for behavioral anomalies are less invasive but also less capable against subtle aim assistance that stays within plausible human parameters.

The honest assessment is that no current approach solves the problem. Kernel drivers stop the majority of casual cheaters. They do not stop DMA hardware, properly configured hypervisors, or novel BYOVD chains. The people they stop most effectively are the ones who would have been stopped by less invasive means. The sophisticated cheat ecosystem that damages competitive play at high ranks operates above or below the kernel layer entirely, and the arms race shows no sign of reaching a stable equilibrium.