Now that you have a driver running on the target system, it’s time to learn how to debug it if the need arises.
In the first part, you configured the virtual machine for kernel debugging over a virtual serial port, and connected to the kernel debugging session using WinDbg. Familiarity with WinDbg commands for unmanaged debugging is a major plus here, but there are numerous new extension commands that are available only in kernel-mode which you will have to learn anyway.
Commands you might need:
- bp to set a breakpoint
- u to disassemble code
- dt module!STRUCT 0xdeadbeef to inspect an object
- dd 0xdeadbeef L10 to show the first 10 DWORDs at the specified address
Here are some things to try now that your driver is in the picture:
- Set a breakpoint in your DriverEntry and inspect the DRIVER_OBJECT you received
- Set a breakpoint in your DriverDispatch with a condition on the IRP containing the IOCTL_SAYHELLO code you defined
And here are some general ideas to play with while you’re in the kernel debugger:
- Set a breakpoint in KiSystemService and disassemble the system service dispatcher, the component that handles a system call request from user-mode and calls the appropriate service in kernel mode using a lookup table
- Inspect the system service table
- Locate the system’s active process list—it is in the global variable KiProcessListHead which points to a LIST_ENTRY structure—and use it to traverse the link nodes (KPROCESS and EPROCESS structures)
Next up: using a real-to-life kernel-mode API to do something remotely useful from our driver.