Usermode vs Kernel vs Hybrid Anti-Cheat: How Modern Detection Actually Works

Imagine one cheat: a DMA-based ESP that reads player positions out of the game process from a second PC over PCIe, then draws overlays through an HDMI capture-and-inject box. The cheat runs no code on the target machine. Now watch what three different anti-cheats see when the game boots and this cheat is already running.

That thought experiment is the fastest way to understand the split between ring 3, ring 0, and boot-time anti-cheat architectures. The privilege ring an anti-cheat lives in is not a marketing tier. It is the strict upper bound on what memory it can read, what handles it can revoke, and what point in the boot chain it gets to observe.

At KyTech we build cheats for all three tiers, so we spend our days on both sides of this fence. Below is how the layers actually work.

The Ring Model, Applied to Games

Windows on x86-64 uses two CPU privilege rings in practice. Ring 3 is usermode, where the game, the launcher, Chrome, and Discord run. Ring 0 is kernel-mode, where ntoskrnl.exe, HAL, and every loaded driver execute with full access to physical memory, MSRs, page tables, and IRQL manipulation.

A ring 3 process cannot read another process's private virtual memory without going through a syscall the kernel arbitrates. It cannot enumerate kernel drivers, inspect physical memory, or see what is mapped into system address space. Every read filters through the kernel, and it can be lied to by anything above it in privilege.

A ring 0 driver can do all of the above. It can also be shot in the face by PatchGuard if it touches the wrong structure, blocked by HVCI if its pages are RWX, and refused a load by Driver Signature Enforcement without a valid signature and EV cert attestation.

The Reference Cheat

To keep the comparison honest, we describe how each anti-cheat sees this setup:

• A DMA card (Screamer, Squirrel, or a Xilinx-based board) in a second host PC.
• A hardware KMBox translating overlay-detected offsets into synthetic HID mouse packets.
• No cheat driver, process, or DLL on the gaming machine. From a software perspective, it is clean.

Worst-case scenario, increasingly common at the top of the competitive ladder, and the reason the industry has been climbing the ring ladder for a decade. The offensive side of the same story is in how kernel cheats bypass usermode AC.

Tier 1: Ring 3 Usermode Anti-Cheat (VAC in CS2)

Valve Anti-Cheat is the archetype of a pure usermode design. VAC runs inside the game process. It has whatever privileges the game has, which on a modern Windows install is a standard integrity token with no admin rights. It cannot install a driver. It cannot open a handle to \Device\PhysicalMemory. It cannot register a kernel callback.

What it can do:

• Walk its own loaded module list via PEB.Ldr.InLoadOrderModuleList.
• Hash sections of its own image and compare to a known-good digest.
• Enumerate handles it owns and inspect them.
• Read its own virtual memory freely; read other processes only if PROCESS_VM_READ is granted, which normally requires equal or higher integrity.
• Watch for IAT hooks by comparing resolved import addresses to GetProcAddress results.

Here is the syscall a usermode cheat would use to read game memory, and by extension what usermode AC can and cannot intercept:

// Ring 3 read from another process. Requires an open handle to the game
// process with PROCESS_VM_READ. Everything filters through NtReadVirtualMemory.
HANDLE hGame = OpenProcess(PROCESS_VM_READ, FALSE, gamePid);
if (!hGame) return GetLastError();

BYTE buffer[8];
SIZE_T bytesRead = 0;
BOOL ok = ReadProcessMemory(
    hGame,
    (LPCVOID)0x00007FF7ABCD0000,
    buffer,
    sizeof(buffer),
    &bytesRead);
CloseHandle(hGame);

VAC inside CS2 sees the reverse from its own perspective. A cheat DLL loaded into CS2 appears in the loader lists VAC walks. A foreign process opening a handle to CS2 is invisible to ring 3 code, because handle tables live in kernel space.

Against our DMA reference cheat, VAC sees nothing. No OpenProcess, no page fault, no thread on the target machine to hash or hook-check. This is why Valve leans on the server-side VACnet stack, first shown by Valve engineer John McDonald at GDC 2018, and on delayed ban waves. VACnet has since expanded into VAC Live, which can flag and disconnect a suspected cheater mid-match rather than only banning days later.

Tier 2: Ring 0 Kernel Anti-Cheat (EAC in Apex Legends)

Easy Anti-Cheat, acquired by Epic Games in October 2018 and shipped as part of Epic Online Services, is the reference implementation of the "kernel driver loaded when the game launches" model. EAC is third-party middleware licensed to more than two hundred titles, including Fortnite, Apex Legends, Rust, Fall Guys, Elden Ring, Dead by Daylight, and, as of April 2026, Rocket League. Product details live at easy.ac. When Apex Legends starts, the EAC launcher spawns as a service and its signed kernel driver EasyAntiCheat_EOS.sys loads via the Service Control Manager, resident until the game exits.

On Linux and Steam Deck, EAC runs entirely in user space through Wine and Proton with no kernel driver. The ring 0 story here is a Windows story specifically. We compare the two big kernel vendors head to head in BattlEye vs Easy Anti-Cheat.

What EAC on Windows has access to that VAC never did:

• The full kernel address space and every PEPROCESS structure via PsLookupProcessByProcessId.
• Every handle open to the game process, including handles opened before the driver loaded, via the kernel handle table.
• The ability to strip or deny access rights before a handle is granted, via ObRegisterCallbacks.
• Notification of every process, thread, and image load system-wide via PsSetCreateProcessNotifyRoutineEx, PsSetCreateThreadNotifyRoutine, and PsSetLoadImageNotifyRoutine.
• The physical memory manager's view of every allocation.

The single most important primitive here is ObRegisterCallbacks. It is how EAC prevents a usermode cheat from ever obtaining a working PROCESS_VM_READ handle to the game. A simplified handler looks like this:

OB_PREOP_CALLBACK_STATUS
PreOpProcessCallback(PVOID Context, POB_PRE_OPERATION_INFORMATION Info)
{
    UNREFERENCED_PARAMETER(Context);

    if (Info->ObjectType != *PsProcessType)
        return OB_PREOP_SUCCESS;

    PEPROCESS target = (PEPROCESS)Info->Object;
    if (target != g_ProtectedGameProcess)
        return OB_PREOP_SUCCESS;

    // Strip everything that lets a caller read, write, or inject.
    ACCESS_MASK strip = PROCESS_VM_READ | PROCESS_VM_WRITE |
                        PROCESS_VM_OPERATION | PROCESS_CREATE_THREAD |
                        PROCESS_DUP_HANDLE | PROCESS_SUSPEND_RESUME;

    if (Info->Operation == OB_OPERATION_HANDLE_CREATE)
        Info->Parameters->CreateHandleInformation.DesiredAccess &= ~strip;
    else
        Info->Parameters->DuplicateHandleInformation.DesiredAccess &= ~strip;

    return OB_PREOP_SUCCESS;
}

Registered with ObRegisterCallbacks(&reg, &g_CookieHandle), this runs before every handle open against a PsProcessType object anywhere in the system. A cheat calling OpenProcess(PROCESS_VM_READ, ...) still receives a handle, but the read bit has been silently scrubbed, and any subsequent ReadProcessMemory returns ERROR_ACCESS_DENIED. This is the mechanism that killed the entire generation of "attach with Cheat Engine and float a value" cheats in EAC-protected titles. For a broader tour of EAC's client and server stack, see Easy Anti-Cheat explained.

When EAC does want to read the game's memory itself from its own driver, it does not use ReadProcessMemory. It attaches to the target process and uses the kernel primitive:

// Ring 0 read of another process. No handle needed. Bypasses every
// ObRegisterCallbacks filter because it never opens a handle.
PEPROCESS gameProc = NULL;
NTSTATUS st = PsLookupProcessByProcessId((HANDLE)gamePid, &gameProc);
if (!NT_SUCCESS(st)) return st;

BYTE buffer[8];
SIZE_T bytesTransferred = 0;
st = MmCopyVirtualMemory(
    gameProc,
    (PVOID)0x00007FF7ABCD0000,   // source VA in game
    IoGetCurrentProcess(),
    &buffer,
    sizeof(buffer),
    KernelMode,
    &bytesTransferred);
ObDereferenceObject(gameProc);

MmCopyVirtualMemory is the workhorse for cross-process reads from a driver, documented alongside the rest of the memory-manager DDIs on learn.microsoft.com. EAC uses it, cheat drivers use it, and it is one of the primitives kernel anti-cheat scans for when it walks the code of other drivers loaded on the system. Epic also shipped ARM64 support for the EAC driver in August 2025 via EOS SDK 1.17.1.3, with Fortnite as the first Windows on ARM title.

Against our DMA reference cheat, EAC sees the same nothing VAC did on the target machine. The DMA card is on a second host. There is no driver to enumerate, no process to callback on. What EAC does have is the server-side statistics pipeline plus its own integrity self-check, which re-hashes the EAC driver's code sections every few seconds so a cheat that patches the driver in place gets noticed within one cycle.

BattlEye, EAC's main competitor, ships a demand-start kernel driver called BEDaisy.sys that follows the same load pattern but is authored by an independent German vendor rather than Epic. BattlEye currently protects PUBG, Rainbow Six Siege, DayZ, Arma 3, Arma Reforger, Escape from Tarkov, and Destiny 2. Its public FAQ at battleye.com covers the kernel-driver framing directly.

Tier 3: Boot-Time Anti-Cheat (Riot Vanguard in Valorant)

Vanguard takes the ring 0 model and moves its load point to system boot. vgk.sys historically loaded via an Early-Launch mechanism as a boot-start driver, before third-party drivers, before user session initialization, and before any adversary could plausibly load their own driver.

Why this matters is subtle. In the EAC model, if a cheat driver loaded five minutes earlier and installed hooks or hid itself from PsLoadedModuleList, EAC arrives after the fact and has to detect anomalies rather than establish trust. Vanguard inverts the order: gets there first, snapshots the kernel state, and any driver arriving later loads through mechanisms Vanguard is already watching.

Since the League of Legends rollout in patch 14.9 (May 2024), Riot has required TPM 2.0 on Windows 11 for League. The two Riot titles are not treated identically. Valorant enforces both TPM 2.0 and UEFI Secure Boot on Windows 11. League requires TPM 2.0 on Windows 11 but does not enforce Secure Boot; Riot cited older-hardware compatibility. Windows 10 systems are exempt from the TPM gate for League entirely.

The most interesting change came on June 24, 2026 with the Vanguard On-Demand release. On eligible systems, vgk.sys no longer loads at boot. It stays dormant until you launch a Riot game and unloads when you close it. Eligibility is a hardware bar: Windows 11 25H2 or later with UEFI Secure Boot, TPM 2.0, IOMMU, VBS, and HVCI all enabled. Riot's Runtime Driver Attestation, co-developed with Microsoft's Xbox OS Security team, verifies at game launch that no cheat drivers ran during the dormant window. Riot said roughly thirty-five percent of Valorant's playerbase met the bar at launch. The full stack is covered in Riot Vanguard explained. On-Demand narrows the always-on window for users who cleared the bar, which is a real concession, but the always-on path still exists for everyone below the hardware line.

The Comparison Table

Note the shared blind spot: none of these tiers can see a DMA card reading memory over PCIe from a second host. That is a hardware-side attack that requires an IOMMU-enforced view of DMA traffic to detect from software, and Windows does not expose it to userspace anti-cheat vendors. Detection of DMA cheating in 2026 lives in server-side behavioral analysis and, at the extreme end, camera-based tournament rules. Riot pushed a May 2026 Vanguard update that enables IOMMU on accounts already flagged for suspected DMA hardware use, the closest anyone has come to a client-side answer.

Ring 0 Constraints You Cannot Wave Away

Every kernel anti-cheat survives the same list of Windows enforcement mechanisms every cheat driver has to survive:

1. DSE (Driver Signature Enforcement) blocks unsigned drivers. Commercial anti-cheats have EV certs and Microsoft attestation. Cheats do not.
2. HVCI runs in VTL1 and enforces W^X on kernel pages. A driver page cannot be simultaneously writable and executable, killing naive shellcode allocation.
3. PatchGuard periodically hashes critical kernel structures. Modifying the SSDT, IDT, or syscall MSR handling bugchecks the machine within minutes.
4. Microsoft signed third-party driver Blocklist blocks known signed-driver-abuse candidates by file hash. Anti-cheats cross-reference the loaded driver list against a private extended blocklist as well. CVE-2015-2291 (Intel Ethernet diagnostic driver) is the canonical historical example of the class.
5. Windows 11 24H2 MmMapIoSpace tightening: MiShowBadMapper now refuses a NonCached alias on WriteBack kernel pages. That killed a class of signed-third-party-driver chains that walked page tables from usermode by mapping physical memory as MMIO.

The kernel anti-cheat and the kernel cheat play inside the same fence. The anti-cheat has a signed cert, a code-signing pipeline, and Microsoft's cooperation. The cheat only needs to work once per detection cycle.

Which Tier Publishers Actually Pick

The tier choice is a business decision, not a technical one. Three questions decide it.

• How valuable is the ranked ladder or the esport? Valorant, Apex, and CS2 all have serious competitive scenes. Tolerance for visible cheating is low, so tolerance for kernel-level intrusion is high.
• How much noise can the user base absorb? Vanguard's always-on model was defensible for a hero shooter tied to Riot's ecosystem; the June 2026 On-Demand pivot suggests even Riot found the political cost non-zero. Fortnite ships EAC in on-demand mode for the same reason.
• What is the install base? VAC on CS2 has to work on every Steam machine on Earth. It cannot be a boot-start driver without breaking Proton and older Windows installs. So it stays in ring 3.

Publishers pick the highest tier they can politically justify. Our pricing page reflects the same asymmetry from the offensive side: kernel-tier cheats for kernel-tier games cost more because the work is harder and the risk is higher.

How KyTech Handles This

KyTech was founded in 2025 by two engineers building cheats for the tier that matters: kernel-protected competitive titles. Our product lineup covers Apex, CS2, Overwatch 2, Black Ops 7, Forza Horizon 6, and Roblox, each targeting a different anti-cheat architecture. We do not sell a "universal loader" because there is no universal loader, and anyone selling one is either lying or shipping a rootkit.

A signed kernel driver at ring 0 can read game memory using the same class of primitive the anti-cheat itself uses, from the same privilege level, without ever calling OpenProcess on the game. That is the architectural posture the KyTech Apex product takes — the ObRegisterCallbacks filter EAC installs is irrelevant on that path because no handle is ever requested for it to strip. See the KyTech Apex product page for the current build.

For CS2 and other VAC-protected titles we run lower in the stack than we need to, on purpose. VAC will not detect a kernel-mode read, and staying in the kernel means the client-side integrity checks VAC runs on the game process return clean because we never modify game memory or inject into the game process.

For Vanguard-protected titles we do not ship. Boot-time anti-cheat with a hardware trust chain is a category where the risk to the customer is high enough that we would rather not sell the product than ship something that gets HWIDs on the block list within a patch cycle. Our HWID spoofer stays in Apex-only beta for the same reason. If you want the offensive side of the ring 0 story we sketched above, we go deeper in how kernel cheats bypass usermode AC. See the full product lineup for current availability.