Loading a dll in the debugger

[astrelsky]

It would be nice to be able to open a dll in the debugger and have the debugger be able to load it automatically for you. I know with x64dbg you can just open it and it creates an executable to load it. Something like that would be nice.

[nsadeveloper789]

I've not looked at this too much, but I wonder if you can use rundll32 as part of a workaround. Perhaps this is what x64dbg is doing under the hood? In any case, I don't remember its command-line parameters exactly, but I suspect you can prepend it to the suggested command line using the "Launch" button and see how it goes.

[astrelsky]

I'm looking to get DllMain to run which would occur from loading it. I'm sure I could make this occur via rundll32 example.dll,#1 which would work in theory since it has to load the dll. I'm not sure if this will work if the dll has no exports though.

I could be overthinking this and may have just expected it to be more intuitive and handled automatically.

[astrelsky]

I managed to be able to do it by making another program which loads it dynamically. I just have to open the dll as well in the debugger and and do a "map module to DLLNAME". Of course this only works if you don't need to analyze DllMain otherwise you're still out of luck. Unfortunately while you can step through the dll code, you get no dynamic view and cannot see any memory the dll uses,

[nsadeveloper789]

You might try refreshing the "Memory" node in the Objects view, after the dll has been loaded.

[astrelsky]

You might try refreshing the "Memory" node in the Objects view, after the dll has been loaded.

It doesn't appear even when stepping through the dll code. The only things listed are [PRIVATE], main.exe, and [IMAGE_UNKNOWN]. It was present in the "Modules" node but got stuck loading the children for symbols and then things went south from there.

It's mostly noise but here is the log.
application.log

[nsadeveloper789]

That indicates the new regions (belonging to example.dll) are not known to Ghidra, yet. In theory, right-clicking the Memory node and selecting Refresh (maybe a couple times, according to @d-millar ), should get Ghidra and/or the dbgeng connector to re-enumerate the virtual memory map to update that list.

[astrelsky]

That indicates the new regions (belonging to example.dll) are not known to Ghidra, yet. In theory, right-clicking the Memory node and selecting Refresh (maybe a couple times, according to @d-millar ), should get Ghidra and/or the dbgeng connector to re-enumerate the virtual memory map to update that list.

It instead forgets everything it knew, kinda like me sometimes 🤣 . No matter how many times I refresh it it either doesn't change or everything that was under memory is gone. Breakpoints and stepping works just fine I just can't see anything in the dynamic view for the dll. I can tell it is stepping and breaking correctly from the static listing. I get the same exact behavior if I link to the dll directly instead of doing reflective loading as well.