Kernel-Dumper

Kernel-Dumper is a simple cross-process module image dumper for Windows x64. Reads a target process's main module straight out of its address space via a signed kernel driver — zero injection, zero write.

User-mode hooks? Doesn't see us, we never call OpenProcess. 👀 Kernel-mode callbacks? Not tripped, we never create a thread in the target. Anti-cheat watchdogs? Still sipping their coffee, we only read.

Tested on Windows 10 22H2 through Windows 11 25H2 ✔️

Also known to work against processes guarded by VMProtect, Themida, Enigma, and a certain unmentionable list of user-mode anti-cheats — because MmCopyVirtualMemory from ring-0 is below every hook they can place.

Note: Admin required (the tool creates and starts a service for the driver).

Note: Driver image is embedded in driver_blob.h. If VulnerableDriverBlocklist is enforcing on your box, the driver will fail to load — see Common issues below.

Usage:

Kernel-Dumper.exe <process_name_or_pid>

examples:
    Kernel-Dumper.exe Notepad.exe
    Kernel-Dumper.exe notepad
    Kernel-Dumper.exe 14528

Output:

Writes two files to .\<process>-<YYYY-MM-DD>\ next to the executable:

image.bin         raw module image (PE), ready to open in IDA/Ghidra/BinaryNinja
snapshot.json     metadata — pid, base, size, PE timestamp, unreadable ranges

Chunks that fail to read (unmapped pages, guard regions) are zeroed in image.bin and recorded as holes in snapshot.json:

"holes": [["0x12000","0x1000"], ["0x4A000","0x2000"]]

So you can tell signal from stub.

Features:

Cross-process memory read via MmCopyVirtualMemory (walks right past user-mode hooks)
Target by name OR by PID — Toolhelp resolves the inverse
Auto service create + start, random service name per run (no fingerprint to tail)
PE timestamp extracted from the dumped bytes (useful for diffs across patches)
Deterministic output filenames (<process>-<date>) for diff-friendliness
Reads work against processes with anti-tamper (VMProtect, Themida, user-mode AC)
Also works perfectly fine against notepad.exe, if that is the kind of thing you tell your mom you are doing

Building:

• Install Visual Studio: https://visualstudio.microsoft.com/downloads/
• Install Windows SDK: https://developer.microsoft.com/windows/downloads/windows-sdk/
• Open Kernel-Dumper.sln
• Choose Release|x64
• Build

Output lands at x64\Release\Kernel-Dumper.exe.

Requirements:

• Admin shell (service creation + driver load)
• Target must be on the same architecture (x64)
• VulnerableDriverBlocklist disabled or lenient enough to allow the embedded driver

Common issues

[-] driver load failed (gle=577) / gle=1058

The embedded driver tripped the Microsoft Vulnerable Driver Blocklist.

Disable it (requires reboot): open regedit.exe, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\Config, set VulnerableDriverBlocklistEnable as dword with value 0, reboot. More info at Microsoft.

Alternatively, swap driver_blob.h for your own BYOVD binary — the client only cares about the IOCTL interface documented in driver.h.

[-] drv_open failed (gle=5)

ACCESS_DENIED. You are not elevated. Run the shell as administrator. Ring-0 doesn't negotiate with user-mode medium integrity. 😎

[-] target '…' not found

The process is not running, the name is misspelled, or the target is a 32-bit process on a 64-bit OS (SysWOW64) and this is the x64 build. x86 build in Release|Win32 is left as an exercise.

Many holes in image.bin

Usually fine — PE sections marked discardable or on-demand paged (resources, .pdata, etc.) will show up as holes. If you see holes in .text, the target is likely applying runtime code mutation (packer / VMProtect / Themida); you captured the state at that instant.

What this tool does not do

• No DLL injection
• No manual mapping
• No thread hijacking
• No byte patching
• No scanning of the target's heap

It is a one-way read: MmCopyVirtualMemory from target to local buffer, buffer to disk. If you need the broader stuff, this is the wrong tool, and probably a different repo under a different account on a different coffee shop Wi-Fi.

Why this works against stuff that doesn't want to be read

Short version: user-mode anti-tamper draws its moat at the kernel boundary and assumes nothing hostile crosses it. Signed drivers cross it by definition. Once we are in ring-0 with the target's EPROCESS, every page they thought was private is a memcpy away.

Protection matrix, roughly:

Layer	Blocks us?
OpenProcess ACL / SeDebugPrivilege strip	no — we never call it
PsSetCreateProcessNotifyRoutine	no — we don't create a thread in the target
Hooked ReadProcessMemory / NtReadVirtualMemory	no — we don't call them
Page guard flags	no — MmCopyVirtualMemory reads anyway
Code integrity on our driver	yes — see Blocklist in Common issues

So the only thing that stops Kernel-Dumper is Microsoft's own driver blocklist, which is itself bypassable by swapping the embedded blob for one Microsoft has not caught up to.

Credits

Driver client code adapted from BYOVD research around the SHA-256 published on loldrivers.io. The CVE is public, the driver is signed, and Microsoft's blocklist tracks it (eventually).

Have Fun!!