kdmapper Internals — Saku Grossarth

The BYOVD Attack Pattern

"Bring Your Own Vulnerable Driver" (BYOVD) is a technique where you load a signed driver with known vulnerabilities, exploit those vulnerabilities to gain kernel execution, and use that access to load malicious unsigned code.

Windows requires driver signatures, but signed drivers can have bugs. Anti-cheats often whitelist drivers from major vendors like Intel. This creates a hole: load a vulnerable Intel driver, exploit it, run your code.

How kdmapper Works

1. Loading the Vulnerable Driver

kdmapper loads iqvw64e.sys, Intel's LAN driver. This driver has a vulnerability that allows arbitrary kernel memory writes through its IOCTL interface.

2. The Exploit

The Intel driver exposes an IOCTL that performs memory operations with insufficient validation. kdmapper uses this to:

Allocate kernel memory for the target driver
Write the driver's PE sections into that memory
Patch the IAT and fix relocations
Execute the driver's entry point

3. Manual PE Mapping

Windows' normal driver loader does many things we want to avoid (signing checks, telemetry, etc.). kdmapper does manual PE mapping instead:

Manual mapping steps:
  1. Parse target driver's PE headers
  2. Allocate non-paged pool memory
  3. Copy PE headers and sections
  4. Process relocations (fix addresses)
  5. Resolve imports (patch IAT)
  6. Call driver's entry point
  7. Clear fingerprints

Anti-Detection: Fingerprint Clearing

Windows tracks loaded drivers through multiple data structures. kdmapper clears these to hide its presence:

MmUnloadedDrivers — List of recently unloaded drivers
PiDDBCacheTable — Driver database cache
g_KernelHashBucketList — Kernel hash bucket list
Wdfilter Runtime structures — Windows Defender tracking
PsLoadedModuleList — Active driver list (via unlinking)

Where These Are

These structures are undocumented and move between Windows versions. kdmapper handles this through:

Pattern scanning for structure signatures
Relative offsets from known exported functions
PDB parsing for exact offsets per build

PDB Offset Support

Windows updates change kernel structure layouts. kdmapper can parse PDB (Program Database) files from Microsoft's symbol server to get exact offsets for any Windows build:

SymbolsFromPDB tool:
  1. Downloads PDB for target Windows build
  2. Parses structure definitions
  3. Extracts field offsets
  4. Generates offsets.ini for kdmapper

Hooking Strategy

To maintain execution after the Intel driver is unloaded, kdmapper hooks a rarely-used function that will persist:

Target: NtAddAtom in ntoskrnl.exe
Rarely called by normal applications
Always present in all Windows versions
Hook jumps to our allocated driver's code

What I Learned

Studying kdmapper taught me about Windows kernel internals, PE format details, and how security boundaries can be bypassed through third-party drivers. The sophistication of the fingerprint clearing shows how much telemetry modern Windows collects and how complex the cat-and-mouse game is.

Security Implications

BYOVD attacks are difficult to prevent because:

Vulnerable drivers are often legitimate hardware drivers
Blocking them breaks real hardware functionality
Signature revocation is slow and affects many users
New vulnerable drivers are discovered regularly

Microsoft's HVCI (Hypervisor-enforced Code Integrity) attempts to solve this by only allowing drivers in a strict allowlist, but adoption is limited due to hardware requirements and compatibility issues.