Is remote kernel debugging supported?

[colinsim1]

Hello! I have the latest DEV build but I can't seem to figure out how to do remote kernel debugging for a Windows 10 VM.
I have activated kernel debugging on the VM and I do seem to get a connection when I try "attach to a kernel" on my host.
I use the "-k" as a flag and fill in the options with "net:50000=port,key=encryption_key" and I get the welcome message:

Connected to target on port 50000 on local IP .
You can get the target MAC address by running .kdtargetmac command.

However any commands I enter don't generate a response. Is this currently unsupported?

[d-millar]

Hey Colin,

The answer is "Should" but I've said that before and been proven wrong. Am testing it out right now as I type. It sounds like you did everything correctly (points for working through the UI). The one detail I'm not sure of, assuming this is the first time you've connected to the target machine, it will be running when you connect, i.e. we don't force a break. If you select Session[0] in the Objects view and it is running, the pause button should be enabled. Commands in the Interpreter window won't work until the target is paused. Any chance this is the issue?

[colinsim1]

Hi D-millar,

Thanks, I'm actually running into another issue now. When I try to use a command I get access denied errors.

Unable to add extension DLL: kdexts
Unable to add extension DLL: kext
Unable to add extension DLL: exts
SECURE: File not allowed to be loaded - C:\WINDOWS\SYSTEM32\dbghelp.dll
Error code: Win32 error 0n5
The call to LoadLibrary(ext) failed, Win32 error 0n2
"Het systeem kan het opgegeven bestand niet vinden."
Please check your debugger configuration and/or network access.

When I try to attach to a system process this give me

Cannot debug pid -1, Win32 error 0n5
"Access denied."

I tried this as an administrator but it didn't work either.
When using kd from the command line everything works fine.

Do you have any idea what is going on?

[d-millar]

I think I need a few more details on what exactly you're trying, i.e. are you getting those error messages for every command or a specific command and are you executing the command that's triggering the errors from the Interpreter window or do you believe some action in the GUI is triggering them? Also, might help to know if you're connecting via the dbgeng connection or the dbgmodel connection and whether you're using the IN-VM connector or the GADP agent connection.

Short answer, unfortunately, is I haven't seen those errors. We don't explicitly load those extension DLLs or the dbghelp.dll, but various functions in the kd command interface could easily trigger them. Just to be clear, when you get these errors are you attached to the kernel VM, as you were describing before, or trying to debug the system process locally using the normal attach commands?

Assuming the latter, I could easily believe that, even if you start up Ghidra from an administrative cmd window or run it as administrator directly, the process that's doing the attach may not have the correct rights. Specifically, for the IN-VM case, I believe the ghidraRun script does not necessarily convey its rights to the actual Java process. I'll have to check on this, but I have a dim recollection of that being an issue. If you're running the GADP agent and spawning it from the Target view, it probably also will not have administrative privileges. One alternative is to spin up the agent directly as administrator and then connect to it using the "GADP connection over TCP" connection. I'm going to have to look/ask around though because I do not remember the command to invoke the agent as a standalone process. Might be obvious from a process list but....we should probably include that as an invokable script for just this scenario.

[d-millar]

Thinking about it some more - I realize why I'm not seeing the problem. If you decide at some point you'd like to try out the dbgmodel version a la the new Windbg Preview, you'll have to drop the contents of the Winbg Preview directory that contains dbghelp.dll, winxp, winext, etc into C:\Program Files\Amazon Corretto\jdk 11.0.4_10\bin. This will have the same affect, i.e. those versions will be accessed before the System32 versions. Apologies for not thinking of this before! I did this a while back and apparently am getting old.

[colinsim1]

When I copied the old Windbg files to the directory it worked alot better than me manually reloading the dll's everytime. Thank you.
However I can't seem to find the new Windbg Preview install directory. Also, how does your setup look for dynamic listing of kernel driver of a Windows VM? In my session all modules get mapped to base address 00000000 with max address ffffffff. Do you have any idea how to get dynamic listing to work?

[defcon8]

@colinsim1

I solved the problem by issuing the following commands:

Where exactly did you enter these commands?

[d-millar]

@defcon8 @colinsim1 listed the commands above:

.unloadall
.load C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\winxp\exts.dll
.load C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\winxp\kdexts.dll
.load C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\symproxy\symsrv.dll
.load C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\winext\ext.dll
.load C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\winext\kext.dll
.load C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbghelp.dll
.sympath C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\sym

but am guessing that's not your exact issue? Are you having problems with symbols or something else?

[d-millar]

Ah, apologies - you said "where". In the Interpreter window.

[d-millar]

@colinsim1 Yeah, the download for Windbg Preview store things in a less-than-intuitive place. If I remember correctly, it ends up in %LocalAppData%\Microsoft\WindowsApps and you may have to play around with FileExplorer to get that to display. You don't need the GUI components for Ghidra, just the stuff in lib.

[d-millar]

@colinsim1 I seem to have lost your last two comments (did you delete them?) - in any case, the modules list for the kernel modules in fact is incorrect. Have located the bug - will get it into the build soon. Thanks for pointing it out!