Questions regaring debugging on Windows using dbgeng IN-VM

[mxtsdev]

After using the debugger in Ghidra for a while I have a few additional questions that I have not been able to find an answer to. They all pertain to dbgeng IN-VM debugger on a Windows x86-64 target.

1. Is it possible to set/enable breakpoints before a module is loaded and have these breakpoints activate when the module is loaded and remain set/enabled between (re)launches?

2. Is it possible to avoid attaching to the conhost process and focus solely on my target? Upon launch, the debugger is suspended in conhost multiple times, and I have to manually switch to the process I want to debug.

3. Is it possible to obtain more detailed information when the debugger breaks on an exception? I can't discern which exceptions are causing the debugger to suspend in order to disable automatic suspend for those exceptions.

4. Can anything be done when memory regions fail to be mapped correctly except manually activating “Force full view” on each launch? I have a bunch of dynamic memory regions that do not get mapped and are not loaded(saved?) in the trace. Goto fails, the memory can’t be viewed, and even with "Force full view" the right-click action "Goto ram:" in the registers view remains hidden for all those regions.

Some related notes:

• In the Objects view processes only display the process ID, not the name of the process (dbgeng, seems process name is used in dbgmodel).
• The settings under Process > Debug > Events > Options appear to not be saved across Ghidra sessions.

[d-millar]

@mxtsdev Will take a stab at answering these from memory - am traveling and can’t verify my answers right now, so take what I say with a grain of salt.

Am pretty sure the Windows debuggers do not support saving breakpoints between runs. Ghidra will save them in the Breakpoints window, but you will have to re-enable them for each run. We considered re-enabling them automatically, but that has downsides as well, e.g. what if you wanted them saved but not enabled. All of that said, there’s a possibility if you restart from the Interpreter console that the underlying debugger will do the right thing. Haven’t tested this.

Re conhost, I don’t believe so. It’s an interesting question, but I’m unaware of support for this in the dbgeng/dbgmodel API.

Re exception information, I will have to check whether that’s available from the Interpreter. I am pretty sure the break event does not provide more info than we expose, but again I should check that.

Re memory regions, for most targets forcing full view is not your best option. Assuming you have a populated Module list in the Modules window, most of the modules should map to loaded Ghidra programs by name. There are several reasons why they might not - the program could have been compiled with a different name, renamed on the file system, or renamed when loaded into Ghidra. The pull-down allows you to map a listed module to an existing program and that mapping will be remembered across runs.

The process name should be a property on the process node in the Objects list, but we’re could definitely consider adding it to the display.

Saving Event/Exception settings also seems like a pretty reasonable idea.

[mxtsdev]

Thank you!

I've been looking into the memory region issue I mentioned earlier, but I can't seem to figure it out. The issue occurs sporadically, but occasionally, everything works perfectly with the same setup.

Both the program and module names are identical and the normal program segments are all mapped correctly.

In essence what is happening is that some dynamically allocated memory regions where data is stored during program execution are not "loaded" (not in the trace) in the sense that Goto fails for those memory addresses.

If I suspend the debugger in a function that does work on a group of dynamically allocated objects and inspect the Registers Window, the registers will hold pointers to these objects in different dynamically allocated memory regions. Some of these regions can be inspected using Goto, but for others, Goto fails with the message "Address not in trace."

Once I step a a few times, a memory region that was previously accessible may become inaccessible. Does this have anything to do with how Ghidra stores traces around the current instruction..?

[d-millar]

Hmmmm, OK - will add a ticket for that, as well. Have a theory, although not a full solution. At a guess, the Region/Module lists are getting stale and are out-of-sync with the current state of the processor. We used to update them on every event, but the updates are extremely expensive and were making stepping unusable.

As a workaround, when you see the GoTo fail, perhaps try refreshing either the root Objects node or the individual Module/Memory nodes.

[mxtsdev]

I've done some additional testing with the suggested workarounds of refreshing both the root Object node and the individual Module/Memory nodes, but neither of them appears to help in my case. For context, this issue occurs as soon as I hit the first breakpoint upon launching an application in the debugger.

Goto immediately starts working after Force full view is enabled and stops working again as soon as it is turned off. Same thing is also true for watches.

Another thing to note is that even with Force full view enabled the Registers view right-click and select Goto ram context menu option remains hidden, even if I step in the debugger to force the Registers view to refresh.

Another longshot, but I read somewhere that Flush caches on the Debugger target could potentially help with similar issues, but it makes no difference in my case.

[d-millar]

OK, all of that is good to know. I think we should probably make GoTo in the dynamic listing always work unless the memory read of the target address fails. Seems a little lame to have to have that address in the maps. Appreciate the extra testing! Will definitely hit all of these after next week when I’m back near a computer.

[mxtsdev]

Thanks again for all your help! Ghidra is really an amazing piece of software, and you and the rest of the team have done a fantastic job with it.

[d-millar]

OK, getting back to work here....and I have an answer on the conhost question. If you start up dbgeng or dbgmodel in Targets, open Object->Connectors, select "Launch process", and then use the "Launch (X)" button to start debugging your target, you will notice a number of additional options for controlling the target/debugging session. In particular, the field "Create Flags" defaults to 1, which is DEBUG_PROCESS. If you set this to 2 (DEBUG_ONLY_THIS_PROCESS), only your target will be debugged and conhost will be ignored.

On other fronts, have a fix in to add the executable name to the process node in Objects and a fix to write exception info to the Interpreter console. Looked into saving event/exception settings, but this is not something windbg does by default and there does not appear to be an obviously relevant API call. We can probably do it in Ghidra proper, but it's a bit messy. In the meantime, you could put the equivalent "sx*" commands in a file and execute that from the Interpreter on start-up. (Not ideal, I realize, but may take me a while to code up a clean Ghidra-only solution.)

[mxtsdev]

Oh, didn't know about that flag, that is going to be helpful. And I see the other things just got merged into the public repo today so I will check them out too. Thank you!

[mxtsdev]

Honestly so excited about the results. These changes plus "only this process" flag makes setup in the debugger a breeze now :)

There aren't even any exceptions anymore. The debugger simply breaks automatically on start, I enable the breakpoints and let it run, and next thing the breakpoint is hit. Goto works and memory can be read without "Force full view".

I couldn't find an answer to this when I searched just now - does Ghidra support scripting the debugger for stepping, setting breakpoints, reading registers etc.?

[d-millar]

Yep, the debugger is fully scriptable. As with all of Ghidra, the entire API is exposed. Dan has also simplified things considerably by writing a FlatDebuggerAPI, similar to the main flat API, that simplifies standard debugger tasks. That said, callbacks from inside debugger events are (I believe) currently restricted to the capabilities of the underlying native debugger, e.g. I don't believe it's currently possible to call Ghidra's scripting interface from inside a breakpoint handler.