WinDbg/KD protocol support

[XVilka]

• [x] Plain WinDbg protocol support - when radare2 is running on the same machine as kernel debugging enabled
• [ ] Working via Serial link (using libserialport - crossplatform LGPLv3 library)
  • [ ] Userspace programs debugging
  • [ ] Kernel debugging
• [ ] Working via ethernet connection (using r_socket, probably sharing some code with shlr/gdb) - https://github.com/radareorg/radare2/pull/17340
• [ ] KVDM (Hyper-V) protocol support
• [ ] Add reversible debugging support (time travel debug)

[radare]

ref https://github.com/radare/radare2/pull/1692

[Manouchehri]

Aside from the lack of support in anything except for 8, 8.1 and 10, is there any reason to use a virtual serial device instead of Ethernet?

[radare]

A serial port requires much less code to work, so its usually less intrussive to debug kernels over serial port than ethernet. Networking requires a lot of logic and drivers to work. Serial port debugging is not supported on win>=8?

[radare]

At the end, the protocol is the same, so, it should be possible to use r2 with socat

[XVilka]

@Manouchehri @radare Ethernet is in TODO, but it much more complex. And it has some differences between windbg over serial and over ethernet.

[Manouchehri]

@radare Sorry, serial debugging is included in Windows >= 8 as well. I meant that in addition to serial debugging, there's also network debugging (and is not included in < 8). My bad for wording that poorly.

I've heard some complaints about performance when using a 115.2 Kbps serial link; at the same time, I rarely see anyone using the kernel-mode debugger with Ethernet, so I wanted to double check to make sure I wasn't overlooking something.

bcdedit seems to insist upon creating a key for network debugging. I don't see a flag for forcing it off, so slightly more than just piping traffic needs to be done.

@JumpCallPop already has a lot of the work done with libKDNET. I couldn't find any other work done on KDNET aside from this. If anyone else has more information, feel free to pipe in. =)

@XVilka Thanks. Any suggestions on where I should start? If not, I'll just poke around.

[XVilka]

@Manouchehri see the https://github.com/radare/radare2/tree/master/shlr/wind - this is the implementation of the WinDbg protocol and this is a radare2 part of WinDbg support https://github.com/radare/radare2/blob/master/libr/debug/p/debug_wind.c

Here is the documentation how to work with it using radare2 https://github.com/radare/radare2/blob/master/doc/windbg

I think you need to see shlr/wind/transport.[ch] and shlr/wind/iob_pipe.c

Please, notice that all WinDbg code should be under LGPLv3.

[XVilka]

@Manouchehri and a bit more links: You can find Windbg protocol description in this BlackHat paper https://www.blackhat.com/presentations/bh-usa-07/Stewart/Presentation/bh-usa-07-stewart.pdf

See also VirtualKD program http://virtualkd.sysprogs.org/ Sources http://virtualkd.sysprogs.org/download_source/

And KD protocol description http://articles.sysprogs.org/kdvmware/kdcom/ Packet log http://virtualkd.sysprogs.org/kd_VMXPPRO/

WinDbg protocol sniffer - https://code.google.com/p/windbgshark/

http://www.msuiche.net/2014/01/12/extengcpp-part-1/ http://www.msuiche.net/2014/01/15/developing-windbg-extengcpp-extension-in-c-com-interface/ http://www.msuiche.net/2014/01/20/developing-windbg-extengcpp-extension-in-c-memory-debugger-markup-language-dml-part-3/ http://www.msuiche.net/2014/04/28/developing-windbg-extengcpp-extension-in-c-symbols-part-4/

[XVilka]

And of course, see the famous PyKD sources too https://pykd.codeplex.com/

[Manouchehri]

Perfect, thanks! Glad I asked, those links should keep me busy for awhile.

[XVilka]

@Manouchehri and a few more links

http://standa-note.blogspot.ca/2015/06/reverse-engineering-winbg-for-profit.html https://github.com/tandasat/ListWorkItems

[XVilka]

@Manouchehri and one more thing: if you want to help - we have one very annoying thing for now too:

At this point, we will get stuck here:

    [0x828997b8]> pd 20
           ;-- eip:
           0x828997b8    cc           int3
           0x828997b9    c20400       ret 4
           0x828997bc    cc           int3
           0x828997bd    90           nop
           0x828997be    c3           ret
           0x828997bf    90           nop

In order to skip that trap we will need to change eip and run 'dc' twice:

    dr eip=eip+1
    dc
    dr eip=eip+1
    dc

Now the Windows VM will be interactive again. We will need to kill r2 and
attach again to get back to control the kernel.

Preventing this somehow would be awesome. Good luck!

[XVilka]

@Manouchehri sorry for spamming you, but forgot also to mention that using RSocket (r_socket) will help you to forget about platform support, see https://github.com/radare/radare2/tree/master/libr/socket

For usage example see HTTP server sources https://github.com/radare/radare2/blob/master/libr/socket/http_server.c

[Manouchehri]

No problem, it's my fault for not joining the IRC channel. I'll get around to that sometime.

[Lekensteyn]

I wrote a Wireshark dissector for part of the Windbg/KD network protocol: https://github.com/Lekensteyn/kdnet

It is incomplete, but decryption works and most higher-level structures are dissected. Here is also a capture and the related Windbg output with a Windows 10 machine as debugger and Checked/Debug build of Windows 10 as debuggee: https://lekensteyn.nl/files/p651ra-acpi-debug/

Hope it helps in some way.

[radare]

Cc @skuater @jroimartin @xvilka

On 01 Jun 2016, at 19:26, Peter Wu notifications@github.com wrote:

I wrote a Wireshark dissector for part of the Windbg/KD network protocol: https://github.com/Lekensteyn/kdnet

It is incomplete, but decryption works and most higher-level structures are dissected. Here is also a capture and the related Windbg output with a Windows 10 machine as debugger and Checked/Debug build of Windows 10 as debuggee: https://lekensteyn.nl/files/p651ra-acpi-debug/

Hope it helps in some way.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[XVilka]

@Lekensteyn thanks a lot! I'll check this

[ghost]

Hello !

This will be usefull for you :

https://github.com/Winbagility/Winbagility/tree/master/src/Winbagility

2016-06-02 12:49 GMT+02:00 Anton Kochkov notifications@github.com:

@Lekensteyn https://github.com/Lekensteyn thanks a lot! I'll check this

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/1246#issuecomment-223258083, or mute the thread https://github.com/notifications/unsubscribe/AHFsulqnoXvy3mBvQQ_PN725Ajrv2a16ks5qHrUngaJpZM4CbXg4 .

[XVilka]

@xarkes can you please write small summary here, what is still missing. what doesn't work as expected, what can/should be done, what are biggest challenges on improving WinDbg support, like a note for a future developer, who will want to continue it?

[xarkes]

• [ ] Check that windbg:// still works after SIOL merge (could not check/fix it)
• [ ] Make "dc" and "dcu" work (for now only single stepping)

This would allow anyone to work more fluently with it. Then comes:

• [ ] Thread/Context switching
• [ ] Implement network transport to allow faster connection

That's all I have in mind for now

[XVilka]

@josediazfer since you are on Windows debugging you may also want to check this one, if you are interested.

[XVilka]

@GustavoLCR @pelijah FYI

[trufae]

any update on this issue @XVilka ?

[ret2libc]

This issue has been moved from radareorg/radare2 to radareorg/ideas as we are trying to clean our backlog and this issue has probably been created a long while ago. This is an effort to help contributors understand what are the actionable items they can work on, prioritize issues better and help users find active/duplicated issues more easily. If this is not an enhancement/improvement/general idea but a bug, feel free to ask for re-transfer to main repo. Thanks for your understanding and contribution with this issue.