kn-live-dbg: A Debugger‑Like Windows Kernel Live Debugging Tool

When you need to study kernel behavior on Windows, the first instinct is to pull out WinDbg; kn‑live‑dbg offers a lightweight, debugger‑looking kernel memory browser that moves memory to a user‑mode TUI.

Tool Positioning: Looks Like a Debugger but Isn’t

kn‑live‑dbg (Kernel Live Debugger) extracts the essence of LiveKD into a pure kernel memory access tool.

The kernel driver handles low‑level tasks via MmCopyMemory IOCTLs for virtual and physical memory read/write, while a privileged user‑mode TUI manages driver lifecycle, symbol loading, type parsing, and interaction, bypassing traditional debugging protocols.

This architecture removes the need for KDNET network debugging and a second machine; a single local console suffices.

Architecture Breakdown: Driver Layer + User‑Mode Layer

Kernel driver layer (KnLiveDbg.sys)

Virtual memory operations: translate virtual to physical via page‑table walk and use MmCopyMemory for read/write.

Physical memory operations: direct physical memory read/write, also based on MmCopyMemory.

Module enumeration: call NtQuerySystemInformation to obtain the list of loaded kernel modules.

Device name is \\.\KnLiveDbg, with DACL allowing only Administrators and SYSTEM, and operates in single‑instance mode.

User‑mode layer (KnLiveDbg.exe)

Manages driver installation, start, stop, and removal via SCM.

Loads kernel symbols with DbgHelp (defaulting to Microsoft symbol server).

Provides a WinDbg‑compatible command set.

Optionally routes complex commands to a DbgEng backend. KnLiveDbgProbe.sys acts as a forward‑control test driver that maintains known‑address test buffers to verify read/write accuracy.

Core Features Overview

Memory Read/Write

Virtual memory read: d* commands (db/dc/dd/dq…) support multiple data formats.

Physical memory read: phys commands operate on physical addresses.

Virtual memory write: e* commands (eb/ew/ed/eq…) default to System process (PID 4) context.

Physical memory write: !db/!dw/!dd/!dq commands.

Address Translation

Virtual to physical: vtop performs an x64 page‑table walk on any kernel virtual address.

LA57 detection: automatically detects PML5 paging and reports physical addresses of each page‑table entry.

Process DTB translation: vtop /process <pid> uses the process’s EPROCESS.Pcb.DirectoryTableBase as CR3.

Process‑aware commands: d* /process <pid> and e* /process <pid> automatically switch process context.

Symbols and Types

Symbol resolution: x, ln, addr commands with module filtering.

PDB type parsing: parses UDT types from the NT kernel PDB.

Object manager callback enumeration: callbacks lists object manager filters, registry callbacks, process/thread/image load callbacks, Minifilter callbacks, and annotates function address, module, and context type.

Type display: dt and dtx support recursion depth control, structure expansion, and bit‑field display.

Built‑in AI Assistance

ai plan

: given an operation target, AI plans execution steps. ai explain: explains the result of a read‑only command. ai run: executes one or more steps from an AI‑generated plan. ai write: writes memory after AI confirms safety. ai report: generates a debugging session report.

The AI role is advisory command planning, helping the user think through actions rather than performing them automatically.

Command Coverage: WinDbg Compatibility

Memory read/write : d*, da, db, dc, dd, dD, df, dp, dq, du, dw, dW, dyb, dyd, e*

Physical memory : phys, pdb, pdw, pdd, pdq, !db, !dw, !dd, !dq

Symbol/Module : .sympath, .reload, lm, x, ln, addr

Type parsing : dt, dtx (supports recursion and bit‑fields)

Callback enumeration : callbacks [object|registry|process|thread|imageload|minifilter]

Memory search : s (-b|-w|-d|-q)

Memory compare/fill/move : c, f, m

Disassembly : u, uf

Process context : procctx, peb/ped/peq, !eb/!ew/!ed/!eq, pe*

Driver status : drvstatus, probe, version

Stop‑state commands ( kd, kdinit), parser‑heavy commands, extensions, and meta‑commands are routed to the DbgEng backend.

Build and Runtime Requirements

Build dependencies

Visual Studio 2022

Windows Driver Kit (WDK) 10.0.26100.0

x64 Developer Shell or PowerShell with MSBuild in the default path

Third‑party: Zydis v4.1.1 (vendored at third_party/zydis/amalgamated)

Runtime requirements

Enable test‑signing mode ( bcdedit /set testsigning on) or sign the driver with an EV certificate.

Run the EXE with administrator privileges.

Single‑instance execution; only one KnLiveDbg.exe process may run.

Quick build

.\tools\build.ps1 -Configuration Release

The release package is created at release\KnLiveDbg-<version>-Release-x64.zip, containing EXE/SYS files, runtime, PDB/CER/CAT files, and configuration.

Launch

cd .\x64\Release
.\KnLiveDbg.exe

On launch the tool automatically installs/updates the driver, creates the service, waits for driver readiness, downloads NT kernel symbols to a local symbols cache, loads the probe driver, then displays a colored banner and dashboard, ending with the knkd> prompt.

Practical Scenarios

Scenario 1: Enumerate Kernel Callbacks

callbacks object
callbacks registry
callbacks process
callbacks minifilter

Security researchers often need to know which kernel callbacks are registered, as they are hook points for EDRs and targets for attackers. kn‑live‑dbg parses PDB type information to annotate callback function addresses, module names, and context structures, offering far higher efficiency than manual parsing.

Scenario 2: Read Boot‑Loaded Kernel Modules

lm filter ntoskrnl
x nt!PsLoadedModuleList
query <address> 100

Enumerate loaded kernel modules and inspect key data structures without setting up a KDNET network debugging environment; a single command retrieves the information.

Scenario 3: Direct Physical Memory Read

phys 0x1000 100

Direct physical access is useful for firmware dump analysis, memory‑image forensics, and similar tasks.

Conclusion

kn‑live‑dbg is a purpose‑built kernel security research tool. It does not aim to replace WinDbg; rather, it addresses WinDbg’s inconvenience in certain scenarios. For quick kernel memory read/write, symbol lookup, and callback enumeration, it is far lighter; for full debugging protocols and breakpoint support, WinDbg remains the primary choice.

Project URL: https://github.com/kernullist/kn-live-dbg