KDNET over USB

Remote kernel debugging (not only) your Windows on ARM

October 16, 2018

Windows on ARM is slowly getting its way on the market (again). Some Windows internals enthusiasts can’t wait to peek under the hood, which goes hand-in-hand with question whether attaching remote kernel debugger - and disabling Secure Boot - is possible. Of course, it is.

Recently I’ve got lucky enough to put my hands on HP Envy x2, which - at the time of this writing - is only one of 3 devices on the market that officially supports Windows 10 on 64-bit ARM (other 2 devices being ASUS NovaGo and Lenovo Miix 630). Currently, all 3 devices have Snapdragon 835, a Qualcomm 64-bit ARM (aarch64) CPU and generally, these devices don’t differ much in the terms of technical specifications.

I’d like to note that while I was able to make remote kernel debugging work with HP Envy x2, it might not be possible for other devices. Specifically, I’ve been told that while disabling Secure Boot is possible on ASUS NovaGo, attaching remote kernel debugger via KDNET over USB is not. This might be because HP Envy x2 has USB-C, while ASUS NovaGo has regular USB 3.1 port. I know nobody who tried this on Lenovo Miix 630, but assuming it has USB-C as well, it should work.

As for USB cable, any USB-C to USB-C or even USB-C to USB-A cable should do the trick. I’ve been using my charging cable from Samsung Galaxy S9+ (USB-C to USB-A) without any problems.

Today, when someone wants to debug the Windows kernel remotely, it’s mostly done via network - KDNET. MSDN offers detailed documentation on how to achieve that. But what if you’re presented with a device - such as laptop, tablet or phone - that doesn’t have any Ethernet port? If you have a device with USB port, EHCI/xHCI controller that supports debugging, you can use a special USB cable and follow MSDN instructions. Unfortunatelly, this method has several disadvantages:

  • Not all EHCI/xHCI controllers are capable of debugging
  • Debugging USB cables are not cheap - and often even hard to find
  • USB debugging is known to not always work very reliably

The another option is to make KDNET work over USB. “What is that?!”, you may ask, followed by “…there’s nothing on MSDN about that!”. And you’d be kinda right. After a bit of googling, you’ll find out that there are some mentions about it burried deep down in Windows HLK Test reference or Azure’s github on how to connect Inventec Avatar device (whatever that is) to Windows 10 IoT.

They both mention having VirtEth.exe as a prerequisite, which I was unable to find on the Internet. Apparently, it’s supposed to be packed in Windows Phone Kit which appears to be available only to particular OEM/vendors. I started to lose any hope, when suddenly I just spotted a new network adapter in my network settings:

kdnet

so, it’ll maybe work somehow!

After a bunch of ipconfig commands and a few trial-and-errors, I actually succeeded. I’m not sure how recent this feature is and since which Windows version is this feature available (the only computers I’ve tested it with are running Windows 10 RS5). I’m not even sure if Microsoft decides to properly document this debugging method. But in any case, here are steps you need to perform:

  1. Disable Secure Boot via BIOS settings (on HP Envy x2 hold ESC button during boot)
  2. Connect PCs with USB cable
  3. On target: 
    bcdedit /debug on
bcdedit /dbgsettings net hostip:169.254.255.255 port:50000 key:1.2.3.4

    (dummy IP, because we don’t know what address will be assigned to the host)

  4. Reboot target
  5. During boot of the target, the host should should make that familiar “USB connected beep”, and Windows KDNET USB-EEM network adapter should show up under Network Connections folder in the Control Panel
  6. Get IP address of that network adapter, either via double-click & detail, or via ipconfig (it might take some time until the IP is assigned)
  7. It might take some time before target starts to boot - in my case it’ll freeze during boot for ~30s (waiting for debugger), then the boot will resume
  8. Once is target booted, do on target: 
    bcdedit /dbgsettings net hostip:X.X.X.X port:50000 key:1.2.3.4

    where X.X.X.X = correct IP of host’s KDNET adapter determined in step #6

  9. Also on target: ipconfig, and look for Ethernet adapter with (Kernel Debugger) in its name, take note of its IP address
  10. Reboot target
  11. On host: windbg -k net:port=50000,key=1.2.3.4,target=<target ip> - or use WinDbgX preview

… it might take some time until it connects

Note: If it doesn’t work, check your firewall settings.

Next Post →