Ring 0 or Nothing: The Architecture of Kernel Anti-Cheat and the Arms Race It Started

The x86 architecture divides processor privilege into rings. Ring 0 is the kernel: unrestricted access to CPU instructions, hardware I/O, page tables, interrupt handlers. Ring 3 is where applications run, virtualized and isolated by the CPU’s paging hardware, unable to read another process’s memory without an explicit kernel-mediated call. The gap between those two rings is structural and consequential; it shapes every design decision in modern anti-cheat software.

For most of PC gaming’s history, anti-cheat operated entirely in Ring 3. It scanned process memory, checked for known cheat signatures, and monitored API calls. Any cheat operating at Ring 0 was invisible to it; a kernel driver can intercept and fabricate results for userland scanners, hide memory regions from the VAD (Virtual Address Descriptor) tree queries that userland tools rely on, or patch the anti-cheat’s own code at the source. The solution, from the perspective of anti-cheat developers, was to match the threat model by operating at the same privilege level.

The Three Major Implementations

EasyAntiCheat, acquired by Epic Games in 2018, ships EasyAntiCheat.sys and loads it at game launch. The driver walks the game process’s Virtual Address Descriptor tree looking for executable private memory: pages marked PAGE_EXECUTE_* that were allocated as MEM_PRIVATE rather than mapped from a file are a strong indicator of injected shellcode. It registers callbacks via ObRegisterCallbacks to intercept any handle opened to the game process with PROCESS_VM_READ access, stripping that access before external memory readers can act on it. The driver unloads when the game exits, which keeps the attack surface window bounded to active gameplay.

BattlEye, developed by BattlEye Innovations in Germany, combines a userland service (BEService.exe) with a kernel driver and takes a continuous scanning posture rather than snapshot-based checks. It registers PsSetCreateProcessNotifyRoutine and PsSetLoadImageNotifyRoutine callbacks to intercept every process start and module load system-wide, not just within the game process, comparing kernel-space modules against an expected set of signed drivers. BattlEye also maintains a frequently updated server-side list of known cheat tools identified by process name, window title, and driver signature.

Riot Vanguard goes further than either of these. Its driver, vgk.sys, is a boot-start driver: it loads at OS startup, before any user session begins, and persists until shutdown regardless of whether Valorant or League of Legends is running. It requires Secure Boot, TPM 2.0, and Windows Hypervisor Protected Code Integrity (HVCI). HVCI runs a Type-1 hypervisor below the normal OS and enforces that no kernel code executes unless it was validated before boot, preventing runtime kernel memory patching. Vanguard places its integrity checks in Virtual Trust Level 1, the HVCI-protected secure world that Ring 0 code in the normal OS cannot reach. When Riot extended Vanguard to League of Legends in April 2024, making it mandatory for all players, the backlash was significant in regions where older hardware could not meet the TPM and Secure Boot requirements.

The BYOVD Problem

The same kernel attack surface that anti-cheat is protecting has been systematically weaponized by cheat developers through a technique called BYOVD, Bring Your Own Vulnerable Driver. An attacker identifies a legitimate, Microsoft-signed driver with an unsafe IOCTL interface, one that exposes arbitrary kernel memory read and write operations through its device object. RTCore64.sys from MSI Afterburner (CVE-2019-16098) and Dell’s dbutil_2_3.sys (CVE-2021-21551) are two well-documented examples; both were weaponized in the wild by both cheat developers and unrelated threat actors including the LAPSUS$ group.

The exploit chain: load the vulnerable but legitimately signed driver, use its IOCTL to patch the kernel variable controlling Driver Signature Enforcement, then load an unsigned cheat driver without ever creating a registered DRIVER_OBJECT. A driver manually mapped into non-paged pool memory without a formal DRIVER_OBJECT is invisible to the I/O manager’s enumeration APIs, transparent to any anti-cheat system that checks the loaded driver list. Microsoft maintains a Vulnerable Driver Blocklist enforced when HVCI is active, and anti-cheat vendors maintain their own per-driver blocklists, but both are necessarily reactive rather than preventive.

The deeper issue: BYOVD does not exploit a flaw in anti-cheat design. It exploits the Windows kernel driver ecosystem itself, where thousands of signed drivers with legacy IOCTL interfaces have never been audited for memory safety. Every driver signed and shipped by a hardware vendor is a potential future BYOVD weapon, and the supply chain of signed drivers is enormous.

DMA and the Hardware Layer

Kernel-mode access is not the terminal point in the arms race. Direct Memory Access cheats operate below the software stack entirely. Using a PCIe DMA card, typically an FPGA-based device sitting in a PCIe slot on the target machine, an attacker on a second computer reads the target machine’s physical RAM directly over the PCIe bus. No process on the target machine opens a handle, writes to memory, or touches any monitored API. The read happens at the hardware layer, below every kernel callback and scanner. PCILeech, an open-source framework by Ulf Frisk, demonstrates the technique comprehensively and has become the reference implementation for DMA-based attacks in both security research and the cheat development community.

Intel VT-d and AMD-Vi, collectively the IOMMU (Input/Output Memory Management Unit), can restrict which DMA operations a PCIe device is permitted to perform. HVCI enforcement activates IOMMU protection, meaning a DMA card cannot read arbitrary physical memory under HVCI; it can only access addresses the OS has explicitly mapped to that device. This is a concrete technical justification for Vanguard’s HVCI requirement that goes beyond driver integrity: without IOMMU enforcement, kernel-level integrity checking can be circumvented entirely at the hardware layer. Whether the IOMMU implementations in current consumer chipsets are robust against all known bypass techniques, including firmware-level attacks and PCIe ACS configuration weaknesses, remains an active area in security research.

The CrowdStrike Parallel

On July 19, 2024, CrowdStrike pushed a content update to its Falcon sensor kernel driver (csagent.sys). The update contained a logic error in the parsing of a threat detection configuration file, causing a null pointer dereference in kernel mode. The result was approximately 8.5 million Windows machines simultaneously blue-screening, taking down hospitals, airlines, financial systems, and emergency services for hours.

CrowdStrike is endpoint security software, not game anti-cheat, but the architectural model is structurally identical: a Ring 0 driver that loads at boot, monitors system-wide activity through kernel callbacks, and receives frequent automatic content updates. The failure mode it demonstrated is precisely the failure mode that kernel anti-cheat exposes. A bad update to vgk.sys or BattlEye.sys pushed during peak gaming hours could produce the same cascading BSOD event across millions of consumer machines in minutes. Unlike enterprise EDR software, game anti-cheat drivers have no staged rollout requirement, no deployment health monitoring infrastructure, and no organizational incident response chain with financial accountability downstream.

Following the incident, Microsoft convened a Windows Endpoint Security Ecosystem Summit in September 2024 and opened discussion about restricting kernel access for security vendors, potentially moving them toward userland Protected Processes with limited kernel APIs. Anti-cheat vendors face the same structural pressure and have the same structural incentive to resist: their threat model genuinely requires Ring 0 access to be effective against BYOVD and DMA adversaries. The argument is technically coherent; the systemic risk it leaves open is also real.

The Progression Has No Final State

The arms race follows a clear logic at each layer. Userland cheats lost to kernel anti-cheat. Kernel-mode cheats lose to HVCI and hypervisor-layer integrity checking. HVCI loses to hypervisor-based cheats running below it in VMX Root mode. Hypervisor-based cheats lose to DMA. DMA loses to IOMMU enforcement. IOMMU enforcement has known weaknesses at the firmware level and in hardware configurations that allow PCIe peer-to-peer DMA. There is no terminal step.

At each layer, the defensive technique imposes costs on the player base: hardware requirements, system stability risk, an expanded attack surface for unrelated threat actors, and a persistent boot-time kernel component on millions of consumer machines that auto-updates on a schedule determined by the vendor. The industry debate has shifted toward whether the security posture created by kernel anti-cheat is proportionate to those costs compared to alternatives: server-side validation, which requires architecturally authoritative server game state; statistical behavioral detection, which Valve uses in VAC alongside human-reviewed demos in the Overwatch system; and hardware-attested execution environments like Intel SGX enclaves, which remain experimental and have their own significant vulnerability history.

The original deep dive by s4dbrd is a solid reference for the implementation mechanics. What it leaves as context is the systemic dimension: the architecture that makes kernel anti-cheat effective against sophisticated ring-0 and DMA adversaries is the same architecture that put 8.5 million machines on the floor in a single bad content update. Those two facts coexist, and the game industry has not found a way to resolve the tension between them.