Bug: WindDbg integration not working

[FuzzySecurity]

For me the WinDbg integration is not working. I tried this on the mainline version and in dev as well. I tired also to Reinstall DbgEng Redistributable which didn't make any difference.

Sample output below of spawning a process to debug:

Loaded signature library: C:\Users\b33f\tools\BinaryNinja\signatures\windows-x86_64\msvcrt_windows-x86_64.sig
Loaded signature library: C:\Users\b33f\tools\BinaryNinja\signatures\windows-x86_64\ucrt_windows-x86_64.sig
59 functions matched total, 0 name-only matches, 0 thunks resolved, 67 functions skipped because they were too small
Analysis update took 8.620 seconds
No available/valid debug info parsers for `Raw` view
Analysis update took 0.013 seconds
Analysis update took 0.000 seconds
Analysis update took 0.000 seconds
Analysis update took 0.000 seconds
Analysis update took 0.000 seconds
Analysis update took 0.000 seconds
Failed to load dbgeng.dll, 127
Failed to connect process server

It looks ok on the filesystem.

Binary Ninja Version: 3.4.4080-dev Personal, 842d9298 Platform: Windows 11 Version 21H2

[xusheng6]

Hi @FuzzySecurity, thx for the bug report!

Do you have any anti-virus that could have injected the dbgeng.dll or dbghelp.dll into binaryninja.exe?

The issue is we must load a particular dbgeng.dll/dbghelp.dll that comes with the binary ninja installation, rather than the one that comes with the system. However, when anti-virus injects dbgeng.dll, they typically inject the system one.

Can you use some tool, e.g., ProcessExplorer to check the list of loaded DLLs in the binaryninja.exe?

[xusheng6]

I am transferring this issue to our debugger repo.

[FuzzySecurity]

Hey @xusheng6, I wouldn't expect AV/EDR to inject the dbg libraries into a process they inspect. But I checked for you dbgeng is loaded from the binja folder. dbghelp is not, it is loaded from System32 (I think this must be a path issue, it's not AV).

[xusheng6]

It is very likely caused by AV or some other products. In fact, I have helped another customer troubleshoot this issue and found out it is his AV injecting the dbghelp.dll. To figure out who actually causes the system dbghelp.dll to be loaded in binaryninja.exe, you can take the following steps:

1. Download process monitor from https://learn.microsoft.com/en-us/sysinternals/downloads/procmon
2. Set the filter to only include binaryninja.exe
3. Set the filter to only include profile events
4. Run binaryninja.exe
5. You should get a dbghelp.dll load event
6. Double-click the event and switch to the stack trace
7. You should be able to figure out the cause from the trace

[FuzzySecurity]

That really shouldn't be the case. The dbg libraries are not used by AV or EDR, they aren't meant to be. In any case, I completely disabled AV and you can see binja tries to look in a number of different places for the library before loading it from System32. Then later it tries to load again from the correct folder but I guess it doesn't because the same library is already present in the module memory space (it will be registered at that point in PEB_LDR_DATA).

I think the logic when the module is initially loaded by binja need a patch probably to look in the correct directory. Stack trace is fine.

[xusheng6]

1. dbghelp library is often used by AVs -- they use it to load PDB info and parse (and then protect) certain important structures. There could be other legitimate reasons for other software to inject that library into another process as well.
2. From the log you showed in the first image, I think that is very likely the case -- only the attempt to access the dbghelp.dll at 11:24 is triggered by our debugger code https://github.com/Vector35/debugger/blob/dev/core/adapters/dbgengadapter.cpp#L105-L153. However, as you mentioned, the dbghelp.dll is already loaded into the process for certain reason, so the load fails. The ones you selected at the top of the window is probably not an operation done by us.
3. Looking at the stack trace you provided, I think it is pretty similar to a remote thread start, which is a typical way for injecting a library into another process.
4. To further troubleshoot this issue, you should select only "Show Process and Thread Activity", and there should be multiple "Load Image" operations, find the one that is the dbghelp.dll, and check its stack trace.

[xusheng6]

Btw, have you joined our slack https://slack.binary.ninja?

[arizvisa]

heh. it's irrelevant nowadays, since everybody explicitly loads it by path instead of strongname, but you can do some things with SxS to ensure that you link with the exact versions of dbghelp/dbgeng that you require (https://github.com/arizvisa/dbgeng.msi/tree/master/Makefile). really, tho, m$ should've resolved this for all of us python-dbgeng-library users a long time ago.