Debugging the Windows kernel on VMware Part Two

Posted on Jun 6, 2024

In this article, I will guide you on how to set up KDNET on a VMWare instance of Windows 10 for debugging. If you haven’t already, I encourage you to read part one of my guide, which provides additional context on this topic, especially regarding WinDbg.

Debugging over the Network

The diagram below illustrates the topological setup we will focus on in this tutorial. While we are using the same physical PC for both the host and guest OS. This configuration however, can be adapted to work with separate machines on the same network, such as a laptop.

One of the significant advantages of network debugging over using a COM port is the substantial increase in speed and efficiency. The COM port method is inherently limited by its maximum baud rate, typically capped at 115,200 bits per second. This limitation makes the serial debugging process slower and less responsive, especially when dealing with large amounts of data or more complex debugging scenarios. In contrast, network debugging, such as using KDNET, leverages much faster network speeds, allowing for quicker data transmission and more efficient communication between the host and guest systems. This not only accelerates the debugging process but also makes it more seamless and less cumbersome, significantly enhancing productivity and the overall debugging experience.

Prerequisites

Assumptions & Remarks

There are some assumptions made, for example you are targeting x64 and not x86. It is also assumed the guest OS is Windows 10 and Secure Boot is disabled. Ensuring these conditions are met is crucial for following the steps outlined in this tutorial effectively.

Setup

Below are the setup instructions for the tutorial. In theory it should all work however, everyone’s network configuration is different so you may face issues with connectivity depending on how your firework is setup.

Our network topology will look like this:

You might assume we will connect using a static IP address setup on the guest or even on both the host and guest. However, since we are initiating this connection very early in the boot process of Windows, the Kernel Debugging Engine does not interact with the standard IP driver you see in the network adapter settings on Windows. Essentially, the kernel debugger has its own independent driver stack.

It’s worth noting that the debugging engine can use a static IP range of 169.254.x.x if the /nodhcp command is issued with bcdedit. However, in this tutorial, we will not be using that approach. Instead, we will utilize DHCP and use the hostname to connect.

VMWare Workstation

To keep things simple, we will configure the network settings of the VM to use NAT. Ensure you have set this up as shown in the screenshot below:

Connectivity Test

Before issuing any commands for KDNET we need to first test if there is connectivity between the Host and Guest.

The first step is to enable Network Discovery on the Host OS. Network discovery is a setting that affects whether your computer can see (find) other computers and devices on the network and whether other computers on the network can see your computer. It’s one of several settings that are turned on when you turn on network sharing.

Make sure you have this enabled for your specific network, that could be private or public it all depends on your setup.

Once we have done this we will need to verify that we can ping the Host OS from the Guest OS.

  1. To get your Host machine’s hostname open up command prompt on the host and run the command whoami.
  2. Then on the VM try to ping the host with the ping -4 <hostname> command.
    If you get a timeout or are unable to ping the host you may need to enable pings in the firewall rules. To do this run wf.msc, go to Inbound Rules and enable File and Printer Sharing (Echo Request - ICMPv4-In).
  3. Now we have connectivity from the Guest to the Host we need to ping the Guest from the Host. I found that using the hostname of the guest sometimes is troublesome with NAT so try to ping the VM’s IP address instead.
  4. On the VM run ipconfig /all and record the IP address.
  5. On the Host now run ping -4 <ip address> with the IP address you got from the Guest. It should ping without issue.

If you have any issues with the connectivity check all the steps above again and review your firewall rules on both the Host and the Guest. Once this is all working you are good to move on to setting up KDNET.

KDNET

To setup KDNET successfully we will need to first install the Windows SDK. You can avoid installing unnessersary components by only selecting Debugging Tools for Windows in the installatoin wizard. (See screenshot below)

Setup Steps:

  1. Once that is installed you will need to copy two files over to the Guest VM Find the kdnet.exe and VerifiedNICList.xml files in the SDK. By default, the files are located in the following location:

    "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64"
    
  2. Copy these two files into a folder on your Guest VM. For example C:\KDNET\

  3. Open up a command prompt terminal in Administrator mode and cd to that directory.

  4. To verify your NIC is supported run kdnet.exe it should output something like this:

    C:\KDNET>kdnet.exe
    
    Network debugging is supported on the following NICs:
    busparams=3.0.0, Intel(R) 82577L Gigabit Network Connection, KDNET is running on this NIC.
    
    Network debugging is not supported on any of this machine's USB controllers.
    
  5. If network debugging shows supported you will then need to run: kdnet.exe <hostname> <port> For the port you can pick one between the acceptable range 50000-50039. For this tutorial I chose 50025.

  6. It will then present a message like the following:

    Enabling network debugging on Intel(R) 82577L Gigabit Network Connection.
    
    To debug this machine, run the following command on your debugger host machine.
    windbg -k net:port=50025,key=<a long key>
    
  7. Once you see this copy this message and save it somewhere as you will need that key on the Host OS to connect to the VM.

WinDbg

Now that we have configured the network debugging we move on to setting up WinDbg to now attach to our VM.

  1. Open WinDbg and select Start Debugging
  2. Select Attach to kernel, and select Net
  3. Set the settings like so, at this point this is self explanatory:
  4. Hit Ok and it should now attach to your Windows running in the VM.

If you have any issues connecting you may need to reboot the VM and try again.

Debug Symbols

It is important that you have setup the correct symbol path to resolve symbols of kernel and usermode modules.

  1. In Windbg go to File -> Settings -> Debugging Settings
  2. Under Debugging paths set the Symbol path.

You can set your symbol path to for example:

srv*
SRV*C:\SYMBOLS*http://msdl.microsoft.com/download/symbols

which will take advantage of the Microsoft public symbol server to automatically download the necessary symbols when WinDbg requires them.

The C:\SYMBOLS path mentioned above serves as the local cache for storing the downloaded PDB files. Microsoft specifies that if the local symbol cache location is omitted, the C:\ProgramData\Dbg\sym directory is utilized as the default storage location.

Conclusion

By following this guide, you should now be able to effectively set up and use KDNET for kernel debugging on a VMWare instance of Windows 10. The transition from using a COM port to network debugging significantly enhances the speed and efficiency of the debugging process, overcoming the limitations imposed by baud rate restrictions. Utilizing DHCP simplifies the setup, allowing for a seamless connection between the host and guest systems.