Od:windows Kernel Debug

Getting Started with kernel debugging

The kernel program runs in the kernel state, so it cannot be debugged as if it were a user-state application. For the kernel debugging knowledge, please refer to the "software debugging" this book. At present, kernel debugging mainly has the following three kinds of methods.

One is to use the hardware debugger, which establishes a connection to the CPU through a specific interface (such as JTAG) and reads its state, such as the ITP debugger.

The second is to insert interrupt handlers and drivers specifically for debugging in the kernel. When the operating system kernel is interrupted, these interrupt handlers and drivers take over the system's hardware, create a simple environment that can be run by the debugger, and use their own drivers to handle user input, output, such as SoftICE and Syser debuggers.

The third is to add debugging support in the system kernel, when the need to break into the debugger, only keep this part of the debugging code is still running, because the normal kernel service has been stopped, so debugger program is not possible to run in the same system, So this method requires the debugger to run in another system, which communicates information through a communication cable.

The recommended kernel debugging method for the Windows operating system is the third, which requires a connection between the debugged system and the debug system, so far there are three connections: serial port, 1394, and USB2.0.

At first, kernel debugging was mostly done by two-machine debugging. With the wide use of virtual machine technology, two-machine debugging is gradually replaced by virtual machine debugging. This section describes a very handy way to debug virtual machine cores-"using Named pipes (Named pipe) to emulate serial ports". Specifically, a serial port is virtualized in the virtual machine and mapped to the host's named pipe . In this way, all read and write operations to the serial port in the virtual machine are converted by the virtual machine management software to read and write to the named pipes in the host system, and the debugger running on the host system can communicate with the kernel debug engine in the virtual machine through this named pipe.

This method of virtual machine debugging kernel realizes single machine debugging, its advantage is simple and convenient, but there are some shortcomings, it is difficult to debug the hardware related driver, and the other is when a breakpoint is set on some function or instruction that involves the underlying operation (interrupt, exception, or I/O). May cause the virtual machine to restart unexpectedly, third , when the target system is interrupted to the debugger, the current virtual machine management software consumes very high CPU, more than 90%. In general, however, this debugging method is sufficient to debug the currently published kernel vulnerabilities.

Let's take a look at how to debug this method using WINDBG and VMware. As mentioned in VMware support, the WINDBG after the 4.0.18.0 version supports debugging through the pipe.

Od:windows Kernel Debug