Ring 0 or Nothing: How Kernel Anti-Cheat Became Both Defense and Attack Vector

The arms race at the heart of online game cheating has a clear directionality: when cheats moved into the kernel, anti-cheat had to follow. That decision was technically justified, and the consequences have been predictably messy.

This deep-dive from s4dbrd covers the mechanics well. What it doesn’t dwell on is the security consequence of putting hundreds of millions of machines under a kernel driver written under commercial pressure, or what happens when those drivers become attack infrastructure themselves.

Why Cheats Forced the Move to Ring 0

The x86 privilege model defines four rings numbered 0 through 3. The OS kernel runs at Ring 0 and can execute any instruction, access any physical memory, and interact directly with hardware. User applications run at Ring 3 and must request kernel services via system calls, which the kernel can audit or deny.

A Ring 3 anti-cheat has a structural problem: a cheat operating at Ring 0 can lie to it without consequence. Kernel-mode code can intercept the system calls the anti-cheat uses to enumerate processes, modify the kernel data structures those calls read from, or directly overwrite the anti-cheat process’s memory. There is no defensive technique available to a Ring 3 process against an adversary at Ring 0.

Moving to Ring 0 levels the playing field. Kernel drivers can register callbacks that fire synchronously on specific system events. PsSetCreateProcessNotifyRoutine fires when any process is created or destroyed, before user-mode code can interfere. PsSetLoadImageNotifyRoutine fires when any executable image is mapped into memory. ObRegisterCallbacks intercepts handle operations on process and thread objects, allowing an anti-cheat to deny certain types of access before they occur.

Beyond callbacks, a kernel driver can walk PsActiveProcessList (the kernel’s internal doubly-linked list of EPROCESS structures for every running process), scan Virtual Address Descriptor (VAD) trees for suspicious executable memory regions, and cross-reference the PEB module list against actually-mapped executable pages to find manually-mapped code that bypassed the standard loader.

That last technique deserves elaboration. A legitimate DLL appears in the PEB’s LDR_DATA_TABLE_ENTRY list, has a corresponding kernel module object, and shows up in EnumProcessModules. A cheat that manually maps itself into the game process’s memory appears as an executable VAD region without any module record. Anti-cheat enumerates all executable memory and flags anything that lacks a corresponding module entry. This is why modern cheat loaders invest heavily in faking module entries, spoofing PEB structures, or using obfuscation that makes their code regions appear as data.

The BYOVD Irony

The problem with putting powerful code at Ring 0 is that the code becomes a high-value target.

Bring Your Own Vulnerable Driver (BYOVD) is an attack technique where an adversary deploys a legitimately signed but exploitable kernel driver onto a target system and uses its vulnerabilities to gain Ring 0 access. Windows Driver Signature Enforcement (DSE) prevents loading unsigned drivers under normal conditions, but a driver already signed by Microsoft or a trusted vendor bypasses that check entirely.

The canonical example is mhyprot2.sys, the anti-cheat driver for Genshin Impact. The driver was WHQL-signed by Microsoft and exposed an IOCTL interface that allowed any user-mode process to terminate arbitrary processes and read or write arbitrary kernel memory. Trend Micro documented in August 2022 that ransomware operators were dropping mhyprot2.sys onto victim machines specifically to kill endpoint detection and response (EDR) software before deploying their payload. The game’s legitimate, trusted anti-cheat driver had become a ransomware delivery mechanism.

This is not an isolated case. MSI Afterburner’s rtcore64.sys (CVE-2019-16098) exposed physical memory read/write and MSR access via IOCTL, and was used by cheat developers to read game memory from kernel space and remove anti-cheat callbacks. Dell’s dbutil_2_3.sys (CVE-2021-21551) allowed arbitrary kernel memory access. GIGABYTE’s gdrv.sys (CVE-2018-19320) provided similar capabilities. The community-maintained LoLDrivers database now catalogs over 300 such drivers, providing a searchable reference for both security researchers and, unavoidably, attackers.

Microsoft maintains a Vulnerable Driver Blocklist, enforced by HVCI (Hypervisor-Protected Code Integrity, labeled “Memory Integrity” in Windows Security settings). The blocklist has historically been slow to update, and new vulnerable drivers continue to appear faster than entries are added.

Boot-Time vs. Launch-Time: Vanguard’s Architectural Bet

Riot Games’ Vanguard anti-cheat for Valorant made an architectural choice that separates it from EasyAntiCheat and BattlEye: vgk.sys is a boot-start driver. It registers with SERVICE_BOOT_START in the registry, loading it during the kernel’s initial driver loading phase, before smss.exe starts and before any user-mode processes exist.

EAC and BattlEye load their drivers at game launch. This leaves a window. A cheat driver that establishes itself before the game starts can intercept anti-cheat initialization, remove registered callbacks before they activate, or patch the anti-cheat driver in memory before it becomes fully active. Boot-time loading closes this window for any cheat that requires a running user session to install itself.

Vanguard also requires Secure Boot and TPM 2.0, and enforces HVCI compatibility for all drivers on the system. Secure Boot means the entire boot chain is cryptographically verified, so cheats cannot establish themselves by modifying the bootloader or early OS components. HVCI enforcement means potential BYOVD tools must clear both the blocklist and the hypervisor’s code integrity checks.

The tradeoff is persistent presence: vgk.sys runs continuously on the machine even when the player has no game open. Riot’s stated position is that the driver is dormant outside game sessions and sends no telemetry when Valorant is not running. That may be accurate, but users have no technical means to verify it. A boot-level kernel driver has the access it needs to read anything on the machine; whether the vendor uses that access as claimed is a matter of trust rather than verification. These concerns were raised at Vanguard’s launch in April 2020, particularly given Riot’s majority ownership by Tencent, and they have not been technically resolved in the years since.

The Hardware Ceiling

Software-based anti-cheat, including boot-time kernel drivers with HVCI enforcement, has an upper bound on what it can detect.

DMA (Direct Memory Access) cheat hardware breaches that ceiling. A cheat board, typically an FPGA or modified PCIe card, installs into the gaming machine. A second computer connects to it and reads the gaming machine’s RAM directly through the PCIe bus, bypassing the CPU entirely. The cheat software runs on the external machine. From the game machine’s perspective, there is no cheat process, no injected code, no suspicious driver, and no anomalous executable memory region. All of the operating system’s monitoring infrastructure sees nothing because the access happens at the hardware layer below the OS.

The defenses against DMA attacks are IOMMU (Input-Output Memory Management Unit) enforcement, which restricts which DMA transactions PCIe devices are permitted to perform, and hardware attestation via TPM, which can prove the system is running unmodified software but cannot prove the underlying hardware is uncompromised. Anti-cheat vendors acknowledge DMA cheats exist; no complete software-based solution is deployed at scale.

The broader principle is that software-based integrity verification can only detect threats visible to the software. An adversary operating below the software layer, through firmware, DMA hardware, or a custom hypervisor, is outside the threat model that kernel anti-cheat was designed to address. The arms race does not stop at Ring 0.

The Tradeoff the Industry Underacknowledges

The escalation to kernel-mode anti-cheat was technically justified. Kernel-level cheats could not be reliably detected from user space, and competitive game integrity matters to the players who care about it. EasyAntiCheat, BattlEye, and Vanguard do prevent a substantial portion of cheat software that would otherwise degrade multiplayer quality.

The costs deserve clearer acknowledgment than the industry typically offers. Every kernel driver expands the operating system’s attack surface. Anti-cheat drivers are developed under commercial and competitive pressure, not under the scrutiny applied to OS kernel code, and they are not subject to mandatory security audits. mhyprot2.sys demonstrated that a widely-deployed, WHQL-signed anti-cheat driver could become active ransomware infrastructure. The Linux gaming ecosystem has had to negotiate compatibility layers specifically with vendors because kernel drivers cannot run natively on Linux; some vendors, Vanguard being the primary example, simply do not support it at all, excluding a platform entirely rather than rearchitecting for compatibility.

The current industry norm treats kernel anti-cheat as a necessary and non-negotiable feature of competitive online games. It may well be necessary. The decision to ship a privileged, difficult-to-audit driver to every player who installs the game, with security properties the player cannot independently verify, is still a design choice with consequences that extend beyond in-game fairness.