· 7 min read ·

Ring 0 and the Attack Surface You Accepted When You Installed That Game

Source: lobsters

The anti-cheat arms race has been running for roughly as long as online multiplayer has existed. This deep dive by s4dbrd covers the mechanics well enough to use as a foundation, but the more interesting story is what kernel-level access means for the security of a system beyond the game itself.

What Ring 0 Actually Means

Modern x86 processors implement four privilege levels, called rings, ranging from ring 0 to ring 3. The operating system kernel runs at ring 0, where code has unrestricted access to hardware, can execute privileged instructions like LGDT and LIDT, and can read and write any physical memory address. User-space applications, including the games themselves, run at ring 3, where memory access is mediated by the kernel and hardware access goes through system calls.

When an anti-cheat runs as a kernel driver, it operates at ring 0 alongside the OS kernel. It can read any process’s memory directly, intercept system calls before they complete, register callbacks that fire on every process creation or image load, and enumerate or modify kernel data structures that no user-space process can touch. This is why kernel anti-cheats can detect things that user-space protection cannot: a cheat running in ring 3 cannot hide from something watching from ring 0.

The tradeoff is that a kernel driver is trusted code. A bug in it is a privilege escalation, full stop.

How the Driver Gets Loaded

Windows requires that kernel drivers be digitally signed before the OS will load them. On 64-bit Windows Vista and later, Driver Signature Enforcement (DSE) is enforced by default: unsigned drivers simply will not load. Anti-cheat vendors get their drivers signed either through Microsoft’s WHQL (Windows Hardware Quality Labs) program or with a cross-signing certificate from an approved CA.

The driver is packaged as a .sys file. When it installs, it registers a service with the Service Control Manager (SCM), specifying when to start (SERVICE_BOOT_START, SERVICE_SYSTEM_START, etc.). Riot’s Vanguard, notably, sets its driver to start at boot, meaning it is loaded into kernel space before the user logs in and before any games are running. This is intentional: it prevents cheats from pre-loading before the anti-cheat can observe them.

Once loaded, the driver’s DriverEntry function runs in kernel context. This is where it sets up its dispatch routines, registers callbacks, and creates device objects that user-space processes can communicate with.

What Anti-Cheats Actually Do at Ring 0

The core mechanisms fall into a few categories.

Kernel callbacks are the primary tool. Windows exposes several callback registration APIs to kernel drivers:

// Called whenever a process is created or exits
PsSetCreateProcessNotifyRoutineEx(MyProcessCallback, FALSE);

// Called whenever an image (EXE, DLL, driver) is loaded into memory
PsSetLoadImageNotifyRoutine(MyImageLoadCallback);

// Intercept handle operations -- e.g. prevent processes from opening
// the game process with PROCESS_VM_READ
ObRegisterCallbacks(&callbackReg, &registrationHandle);

The ObRegisterCallbacks mechanism is particularly useful. When any process tries to open a handle to the game process, the anti-cheat gets notified and can strip away access rights like PROCESS_VM_READ or PROCESS_VM_WRITE before the handle is returned. A cheat running in user space that tries to read game memory via ReadProcessMemory will get a handle with those rights removed, and the call will fail.

Memory scanning from the kernel is more reliable than from user space because the kernel can bypass the page table tricks and API hooks that user-mode cheats use to conceal themselves. Anti-cheat drivers can call MmCopyMemory with the MM_COPY_MEMORY_VIRTUAL or MM_COPY_MEMORY_PHYSICAL flag to read arbitrary memory, or iterate the working set of a process to examine mapped regions.

Integrity checking covers both game file hashes on disk and in-memory code segments. The kernel driver can compare what’s loaded in the game’s process against what the original PE file contains, detecting patches that cheats inject at runtime.

Driver enumeration checks for unauthorized kernel drivers. The anti-cheat can walk the PsLoadedModuleList kernel structure or use the ZwQuerySystemInformation with SystemModuleInformation to list all loaded drivers and compare them against a known-good list.

The IOCTL Bridge Between User and Kernel Space

The game client and the kernel driver communicate through the Windows I/O subsystem using IOCTLs (I/O Control Codes). The driver creates a named device object during initialization:

RtlInitUnicodeString(&deviceName, L"\\Device\\AntiCheatDrv");
RtlInitUnicodeString(&symbolicLink, L"\\DosDevices\\AntiCheatDrv");

IoCreateDevice(DriverObject, 0, &deviceName,
               FILE_DEVICE_UNKNOWN, 0, FALSE, &DeviceObject);
IoCreateSymbolicLink(&symbolicLink, &deviceName);

The game client opens this device and sends requests:

HANDLE device = CreateFile(L"\\\\.\\AntiCheatDrv",
    GENERIC_READ | GENERIC_WRITE, 0, NULL,
    OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

DeviceIoControl(device, IOCTL_SUBMIT_HEARTBEAT,
    &request, sizeof(request),
    &response, sizeof(response),
    &bytesReturned, NULL);

The kernel driver’s dispatch routine handles these IRP (I/O Request Packet) messages. The heartbeat pattern is common: the game sends periodic requests to the driver, and if the driver stops responding or the connection breaks, the game can assume the anti-cheat was tampered with and terminate.

The BYOVD Attack Surface

This is where the architecture becomes a security problem that extends well beyond gaming.

Bring Your Own Vulnerable Driver (BYOVD) is an attack technique where malware loads a legitimate but vulnerable signed driver to gain kernel-level code execution. Because DSE only checks whether a driver is signed by a trusted certificate, not whether the driver contains exploitable bugs, any signed driver with a kernel memory write primitive becomes a key to ring 0.

Genshin Impact’s anti-cheat driver, mhyprot2.sys, became a particularly well-documented example. The driver exposed IOCTLs that allowed any unprivileged process to read and write arbitrary kernel memory. In 2022, researchers documented how the BlackByte ransomware gang incorporated the driver into their attack chain: install mhyprot2.sys, use it to write kernel memory, disable EDR (Endpoint Detection and Response) software by patching kernel callbacks, then deploy the ransomware payload. This worked even on machines where Genshin Impact was never installed, because the attacker bundled the driver directly.

The problem is structural. An anti-cheat driver that provides read/write primitives to kernel memory in order to do its job creates those same primitives for anyone who loads the driver. WHQL signing does not audit driver logic, only that the binary hasn’t been tampered with since signing. MiHoYo revoked the certificate and issued an updated driver, but the original signed binary remained functional until Microsoft added it to the vulnerable driver blocklist that Windows 11 and updated Windows 10 systems enforce.

How Cheaters Bypass Kernel Anti-Cheats

The offensive side of this dynamic is equally technical.

Manual mapping bypasses driver enumeration entirely. Instead of loading a driver through the SCM (which would register it in PsLoadedModuleList), the attacker manually allocates kernel memory, copies their driver image into it, and executes it without ever appearing in the list of loaded modules. The technique requires an existing kernel write primitive, which is often obtained through a BYOVD attack first.

DMA attacks operate below the software layer entirely. A PCIe DMA (Direct Memory Access) device connected to a machine can read and write system RAM directly without going through the CPU. An attacker with physical or virtual machine access can attach a PCIe FPGA board that reads game memory and displays it on a separate screen. Because no code runs on the target CPU, kernel callbacks and memory scanning see nothing unusual. Modern anti-cheats attempt to counter this by checking for unexpected PCIe devices and using the IOMMU (Intel VT-d or AMD-Vi) to restrict which DMA addresses each device can access, but IOMMU support requires correct BIOS configuration and is not universally enforced.

Hypervisor-based cheats run below the OS by installing a thin Type-1 hypervisor that then boots Windows as a guest. From inside the hypervisor, the cheat code has full access to the guest’s memory via Extended Page Tables (EPT) and can intercept VM exits to observe or modify game state. The anti-cheat driver inside the Windows guest cannot see code running at VMX root mode. Detecting this requires the anti-cheat to verify it is not itself running as a guest, typically by checking timing side-channels around specific privileged instructions or using hypervisor detection heuristics.

What This Means in Practice

Kernel anti-cheat drivers are not simply game protection software. They are third-party kernel code running at the highest privilege level on a user’s machine, often at boot time, and they expand the attack surface of that machine in proportion to their capability. The same access that lets them detect cheats lets vulnerabilities in them or their communication interfaces compromise the entire system.

The security argument for these drivers is that the alternative, user-space anti-cheat, is simply ineffective against serious cheating, which is true. Games with substantial prize pools or competitive ecosystems have enough financial incentive for cheaters to justify sophisticated tooling. A user-space anti-cheat can be bypassed by a sufficiently motivated attacker in an afternoon; a kernel anti-cheat raises that bar significantly.

The argument against is that users are being asked to accept a permanent, always-on kernel module from a game studio, not a security company with a track record of kernel development. The security of a Windows system now depends, in part, on the competence and patch cadence of Riot Games, Epic Games, Battlestate Games, and whichever studio ships the next title with its own driver. When those drivers have bugs, as mhyprot2.sys demonstrated, the consequences extend far beyond a single game.

The arms race has driven anti-cheat technology into kernel space. The security implications of that decision land on every player who installs the game.

Was this interesting?