11

I have a 64 bit application that when runs will load a dll (plugin) I want to debug only this plugin, I have tried setting x64dbg to break on dll load, but two issues, this app loads hundreds of other dlls, and when I do get to my dll and try and step through I seem to get stuck in ntdll.dll rather than the one of my interest.

Is there are a better way of doing this? or any other debugger that is better suited for this job? I do have IDA pro aswell but I am more familiar with the olly/x64 program.

Improve this question

3 Answers 3

Reset to default
8

I'm going to add my findings as an answer as it turns out its actually very simple in the new debuggers (I don't believe ollyDBG has this function).

X32DBG and X64DBG can be used with the same process

1) Open the executable file (exe) in the debugger (depending on whether exe is 32bit or 64 bit choose the right debugger)

2) select the "breakpoints" tab

3) find the section titled "dll breakpoints"

4) Right click in this section and choose "add" type in the name of the dll file. Eg "module.dll"

5) Now run your process, the debugger will break when this dll is loaded

Improve this answer
1
  • 1
    that is nice feature addition to x64dbg exodia and the team keeps on improving x64dbg
    – blabb
    Commented Jul 10, 2017 at 2:50
4

There are several easy steps to do it:

  • If you have a source code, you can create a very basic endless loop at the beginning of your code and once this dll will load, hitting a break will eventually bring you to that loop. At that point you can just manually step out from it and continue your debugging.
  • If you do not have a source, the you can patch the dll at the entry point with 0xcc for break point or 0xEB 0xFE (jmp 0x0) for endless loop. In the case of break point opcode, you will trigger debugger on execution. In the second case, you can do what I've described previously.
    • for patching you can use any hex editor. CFF Explorer could be very convenient for that where it can point you to entry point and with internal hex editor you can add the patch. Do not forget to write aside the original bytes to restore after the debugger breaks.
Improve this answer
2
  • Thanks for your reply, so am I understanding correctly that i should add "0xcc" to the entry point line (replace the EP with that command?) which will trigger a breakpoint? I should have also pointed out this file is packed with upx, and I am having no end of trouble trying to unpack it, (there's no PUSHAD and a LOT of different PUSH commands)
    – Raz Razman
    Commented Jun 18, 2017 at 23:26
  • yes, if you replace the original byte with 0xcc. Load your application with the debugger and once the dll will be loaded, the bp will trigger. If this is indeed UPX, try to look for an indirect control transfer like "jmp reg" and set the BP on it (after you start debugging the target dll).
    – PhoeniX
    Commented Jun 19, 2017 at 13:23
2

debugging a dll is kinda tougher than debugging a stand alone executable. as none of tbe functions that are exported will have a call to them thetefore finding the argument and then type of tbe argument type of return calling convention all becomes tougher than a refetenced function.

some ways to debug them standalone isto write a wrapper exe with load library call and take on from there combined with static analysis.

you can also load a dll in a standalone manner if you have windbg. with. windbg -z foo.dll. this will load the dll as a dump file and will stop in the AddressOfEntryPoint.

if it were 32 i could have said use ollydbg with loaddll and call export function but since you say 64 bit i dont know if x64dbg has a similar functionality

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.