BYOVD and Kernel Driver Traces Explained: Why Bans Still Land

Table of contents

1. What BYOVD actually means

2. The 2018 to 2023 era of kernel cheat loaders

3. The two tables Windows keeps without telling anyone

4. Manual mapping and what it cannot erase

5. How BattlEye, EAC, and Vanguard scan for traces

6. Why an HWID spoofer does not fix this

7. What BYOVD looks like in 2026

What BYOVD actually means

BYOVD is short for Bring Your Own Vulnerable Driver. It is the attack technique that powered nearly every kernel-mode cheat sold between roughly 2018 and 2023, and the residue it leaves behind is the reason most of those cheats now show up on ban waves months after the player stopped using them.

The setup is straightforward. Microsoft requires kernel drivers on modern Windows to be signed by a recognized certificate authority. A cheat developer cannot get their own driver signed; the moment they tried, Microsoft would revoke the certificate. But a legitimate company, say MSI or Gigabyte or an old motherboard utility vendor, already shipped a signed driver. And that signed driver has a bug. Specifically, it accepts a command from user mode that lets the caller read or write arbitrary kernel memory.

The cheat does not need to be signed. The vulnerable driver is signed. The cheat loads the vulnerable driver through the normal Windows driver loader, then uses the bug to execute its own unsigned code in kernel mode. Signature requirement satisfied. Kernel access acquired. From the operating system's point of view, the only thing that loaded was a legitimate signed driver that the publisher had every right to ship.

This is the loophole. And it stayed open long enough to become the default architecture for kernel cheats across the FPS market.

The 2018 to 2023 era of kernel cheat loaders

During those five years, almost every working private cheat for Valorant, Tarkov, PUBG, Apex, and the Battlefield series followed the same architecture. A user-mode launcher dropped a vulnerable driver onto disk. The launcher called the Service Control Manager to start the driver. The driver loaded into kernel memory like any signed driver would. The launcher then sent an IOCTL command that triggered the bug. From that point, the launcher had kernel write access through a legitimate, signed channel.

// BYOVD ATTACK CHAIN, USER MODE TO KERNEL CODE EXECUTION

STEP 01

Drop signed driver

Cheat launcher writes RTCore64.sys or similar to disk. Signature intact.

›

STEP 02

Load via SCM

Service Control Manager loads the driver. Signature check passes.

›

STEP 03

Trigger IOCTL bug

Launcher sends crafted command. Driver writes attacker-controlled bytes.

›

STEP 04

Map cheat code

Unsigned cheat module copied into kernel memory. Executes ring-0.

›

STEP 05

Unload, leave trace

Driver unloaded. PiDDBCache and MmUnloadedDrivers retain record.

Steps 1 to 4 leave no signature evidence. Step 5 leaves evidence that survives reboot.

The cheat developer's instinct, once the cheat finished its session, was to unload the vulnerable driver and delete the file. From a forensic standpoint that looks clean. The driver is gone. The file is gone. A directory listing shows nothing. Process Explorer shows nothing. The Service Control Manager has no record of the service. Most people, including most cheat buyers, assumed that was the end of it.

It was not. Windows kept two records of what had happened, and the cheat developer did not control either one of them.

The two tables Windows keeps without telling anyone

The kernel maintains a structure called the PiDDBCacheTable. The name expands to "Plug and Play Installation Database, Cache Table." Its purpose is bureaucratic. When a driver loads, Windows records its timestamp and a checksum so that future loads of the same driver version can be processed faster. The table is not security infrastructure. It was added for performance reasons. Microsoft did not document it publicly until researchers started reverse-engineering it around 2019.

The second structure is called MmUnloadedDrivers. It is a circular buffer that records the last 50 drivers that have been unloaded from the system. Each entry contains the driver name, the load address, the unload time, and the start address of the driver's image. When a 51st driver unloads, the oldest entry is overwritten. Until then, every entry sits there in kernel memory, accessible to anything with kernel read access, including anti-cheat drivers.

// PiDDBCacheTable INSPECTION, KERNEL MEMORY VIEW

// Entry layout: TimeDateStamp | NameHash | DriverName | LoadCount

[0x14] 5F4A21B7 9B2C4E81 ntfs.sys load=4[0x15] 6A1F88C3 3D8A77F2 tcpip.sys load=4[0x16] 5C2E11A4 77B9C201 nvlddmkm.sys load=3[0x17] 5C0B8804 E1A4D7BC RTCore64.sys load=1 ← flagged[0x18] 61A7C2D5 4F8E9911 vgk.sys load=1[0x19] 5D3F4421 88E72A03 amdgpio.sys load=2[0x1A] 5B7E9D12 C4A11B22 capcom.sys load=1 ← blocklisted[0x1B] 62091EB0 91C3D584 storport.sys load=4

// MmUnloadedDrivers, last 4 entries

[U0] RTCore64.sys unload @ 2026-04-12 22:14:33[U1] nvlddmkm.sys unload @ 2026-04-13 08:01:07[U2] gdrv.sys unload @ 2026-04-15 19:42:18[U3] storport.sys unload @ 2026-04-16 03:29:55

The PiDDBCache entry persists across the driver's full lifecycle. The MmUnloadedDrivers ring retains it for the next 50 unload events.

What anti-cheats discovered, somewhere around 2019 to 2020, was that these tables function as forensic evidence. The cheat may have unloaded its vulnerable driver hours or days before the game even started, but the record of having loaded it was still sitting in kernel memory. The hash matched RTCore64.sys. The timestamp matched the cheat session. The name matched a driver Microsoft had publicly blocklisted. None of that information was supposed to be evidence; the kernel kept it for unrelated reasons. But once the anti-cheats started reading those tables, the evidence was right there.

This is the part most cheat buyers never understood. Unloading the driver did not delete it from the operating system's memory of itself. The forensic trail was already written. The only question was when the anti-cheat would get around to reading it.

Manual mapping and what it cannot erase

Manual mapping is the cheat developer's response to all of this. The technique skips the Windows driver loader entirely. Instead of asking the operating system to load a driver, the cheat exploits its kernel write access from BYOVD, then copies the cheat module directly into a region of kernel memory and starts executing it there. From the loader's perspective, nothing loaded. There is no entry in the driver list. There is no entry in the loaded modules list. The SCM has no record. PsLoadedModuleList has no record.

What manual mapping does not erase is the BYOVD itself. The vulnerable driver still had to load through the normal channel to give the cheat its initial kernel write. That step still goes into PiDDBCacheTable. That step still goes into MmUnloadedDrivers when the BYOVD is later unloaded. The manually-mapped cheat module is invisible, yes, but the evidence that a known-bad signed driver was loaded on this machine sits there exactly as before.

Cheat developers responded with table wipes. Patch the PiDDBCacheTable entry. Patch the MmUnloadedDrivers entry. Write zeroes over the bytes. The kernel will not notice; it does not validate the integrity of its own internal caches. For a while this worked. Anti-cheats then started cross-referencing the tables against other records of driver activity, like the kernel's debug data structures, registry traces from the SCM, and the Plug and Play installation log files on disk. Any one of those out of sync with the others became its own signal.

The arms race ran for about three years. By 2023, every shippable kernel cheat had table-wipe logic. By 2024, every major anti-cheat had at least four cross-checks for table consistency. The cheat had to either wipe all of them in perfect sync, which is fragile, or accept that the trace would be readable on the next scan.

How BattlEye, EAC, and Vanguard scan for traces

The three major kernel anti-cheats each implemented BYOVD detection, but they did not do it in identical ways. Knowing which checks each one runs is the difference between understanding why a cheat banned on one game and not another.

BattlEye runs the deepest scan on the cheap end. It reads PiDDBCacheTable, MmUnloadedDrivers, the KdpData kernel debugging structures, and cross-references all three against driver hash signatures it ships with the anti-cheat update. PUBG's BattlEye build additionally streams these tables to server-side telemetry, which means the evidence is collected even when the cheat happens to wipe locally. Tarkov's BattlEye integration runs the same scans plus a periodic re-scan triggered by player report volume.

EAC is roughly equivalent on table reads but heavier on signature matching. It maintains a much larger internal blocklist than BattlEye does and applies it both at scan time and at driver-load time, so a vulnerable driver loaded while EAC is running gets refused at load instead of detected after unload. The trade-off is that EAC catches fewer historical traces than BattlEye, because some of its enforcement happens before the trace is even written.

Vanguard does both, plus something neither of the others can: it watches the tables continuously from boot-start. Because vgk.sys loads before Windows finishes booting, it observes the PiDDBCacheTable and MmUnloadedDrivers tables from their initial empty state and records every entry that gets added. Any later attempt to wipe a known-bad entry is detected by comparing the live table against Vanguard's running log. That is the check most cheat developers cannot defeat.

// KERNEL TRACE SCAN COVERAGE BY ANTI-CHEAT

Check BattlEye EAC Vanguard PiDDBCacheTable read ✓ ✓ ✓ MmUnloadedDrivers read ✓ ✓ ✓ KdpData cross-check ✓ partial ✓ Live boot-time observation × × ✓ Load-time blocklist refusal partial ✓ ✓ Server-side trace streaming ✓ partial ✓ Periodic report-triggered rescan ✓ ✓ ✓

Arena Breakout's dual ACE plus TenProtect setup runs scans roughly equivalent to BattlEye's depth, with the addition that two independent scanners run on the same trace data and have to agree before a flag converts to a ban. The architectural detail matters for the cheat market because it means a single false negative on one scanner does not save the build; both have to miss the same trace.

Why an HWID spoofer does not fix this

This is the question that comes up almost every time the topic appears on a cheat forum: "If my hardware ID changes, does the kernel trace history reset?" The answer is no, and the reason is worth understanding clearly.

An HWID spoofer changes what the operating system reports about the hardware. It intercepts queries to the disk serial, the SMBIOS data, the network adapter MAC address, and so on. What it does not change is what the kernel has observed since the last boot. PiDDBCacheTable and MmUnloadedDrivers are session-scoped to the Windows kernel itself; they reset only when Windows reboots. A spoofer running on the same boot session that loaded a vulnerable driver does not clean those tables. It cannot. It is operating at the wrong layer.

The other reason HWID spoofers do not help here is that the trace is not used as a hardware identifier in the first place. The trace is used as evidence of behaviour. The anti-cheat does not say "this PC loaded RTCore64.sys, therefore this hardware ID is banned." It says "this account played while a known-vulnerable driver was loaded, therefore this account is banned." Changing the reported hardware does not change what the account did during that session.

Hardware bans driven by TPM EkPub matching, the kind covered in the TPM attestation article, are a different category. Those do come from hardware identifiers and a spoofer cannot defeat them either, but for a different reason. Behavioural bans from kernel traces are not even trying to fingerprint the hardware. They are reading what happened.

What BYOVD looks like in 2026

The BYOVD era is mostly over. Not entirely; new vulnerable drivers still surface from time to time, and the cheat market still picks them up for a few weeks before they hit the major blocklists. But the architecture as a stable, multi-year approach to kernel cheats is finished. The blocklists are too broad, the table forensics are too thorough, and the anti-cheat development cycle is now fast enough that a new BYOVD has a useful lifespan of weeks, not years.

What replaced it is splitting. The top end moved to hardware: DMA cards over PCIe, capture-card-plus-AI setups detailed in the AI aimbot and hardware fuser article, and KMbox-style input emulators. None of these need a kernel driver on the game PC at all, so none of them write anything into PiDDBCacheTable. The middle moved to external cheats, which read game memory through legitimate APIs from a separate process and accept higher detection risk in exchange for development simplicity. The bottom end moved to outright public cheats with short, disposable account lifespans.

Private internal cheats still exist for less-defended games. PUBG cheats with internal architecture can still avoid BYOVD by using injection techniques that do not require a kernel driver in the first place; the trade-off is reduced functionality, because anything the cheat wants to read or modify has to fit inside what user-mode access allows. For games where the anti-cheat is more aggressive about user-mode introspection, even that approach gets thin fast.

The practical reading for a cheat buyer in 2026 is that if a product is marketed as a "kernel cheat" without further detail about how it loads, the question to ask the vendor is direct: does the loader use a BYOVD chain, and if so which driver. A vendor who cannot answer that question is selling a product whose detection profile they do not understand themselves. A vendor who answers it cleanly, with a clear story about which driver, what blocklist status it has, and how they handle the table cleanup, is at least operating at the level the modern threat model requires. ZhexCheats vets every kernel-mode product in the catalog at exactly that level before it ships, because the cost of getting it wrong now lands on the buyer's hardware and not just the buyer's account.

Ask the right question. Read the answer carefully.