Cannot debug a PE from a non-Windows platform

[25pwn]

I am running Fedora Rawhide.

In Debug Adapter Settings, Adapter Type is blank and clicking on it shows nothing. binaryninja.debugger.debugadaptertype.DebugAdapterType.get_available_adapters(bv) returns an empty list. I am unable to use remote debugging.

This used to work, but it stopped working some time ago. How do I fix this issue?

[psifertex]

Unfortunately Fedora is not a supported platform. That said, this sounds more like a corrupted download. Have you tried the usual uninstall, reinstall a fresh version, double check the hashes of your download? Try both latest stable and dev as well.

[xusheng6]

I am running Fedora Rawhide.

In Debug Adapter Settings, Adapter Type is blank and clicking on it shows nothing. binaryninja.debugger.debugadaptertype.DebugAdapterType.get_available_adapters(bv) returns an empty list. I am unable to use remote debugging.

This used to work, but it stopped working some time ago. How do I fix this issue?

Could you please give more details on how you used it when it previous worked? Were you doing local debugging, or remote debugging? What is the thing you are debugging?

[25pwn]

I'm pretty sure it's not a corruption, but I reinstalled just to be safe.

I was remote debugging windows and linux binaries.

I did a bit more testing and it seems the issue only happens on PE files. With ELF and macho I do get ["LLDB"] in the dropdown and binaryninja.debugger.debugadaptertype.DebugAdapterType.get_available_adapters(bv).

[xusheng6]

Yeah I just downloaded the clang+llvm-18.1.8-x86_64-pc-windows-msvc.tar.xz and there is a bin/lldb-server.exe in it. I think this does not exist in LLDB 16.0 build. This makes it more promising because maybe they included it because it now works!

[xusheng6]

Yeah it seems that LLDB 18.1 has made some improvement against 16.0. If I try to set the remote-debugging in LLDB 16.0, it actually crashes right after I try to connect to it:

PS C:\Users\xusheng\libclang\16.0.0\bin> .\lldb-server.exe p --server --listen 0.0.0.0:31337
Connection established.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: C:\\Users\\xusheng\\libclang\\16.0.0\\bin\\lldb-server.exe p --server --listen 0.0.0.0:31337
1.      Program arguments: C:\\Users\\xusheng\\libclang\\16.0.0\\bin\\lldb-server.exe p --server --listen 0.0.0.0:31337
Exception Code: 0x80000003
#0 0x00007ff7a7108da0 (C:\Users\xusheng\libclang\16.0.0\bin\lldb-server.exe+0x68da0)
#1 0x00007ff7a710a5b7 (C:\Users\xusheng\libclang\16.0.0\bin\lldb-server.exe+0x6a5b7)
#2 0x00007ff7a710adb3 (C:\Users\xusheng\libclang\16.0.0\bin\lldb-server.exe+0x6adb3)
#3 0x00007ff7a811f67c (C:\Users\xusheng\libclang\16.0.0\bin\lldb-server.exe+0x107f67c)
#4 0x00007ffe592c257d (C:\Windows\System32\KERNEL32.DLL+0x1257d)
#5 0x00007ffe5a9caf28 (C:\Windows\SYSTEM32\ntdll.dll+0x5af28)

However, with LLDB 18.1, at least the connection can be established and the target can be executed properly:

(lldb) platform connect connect://127.0.0.1:31337
  Platform: remote-windows
    Triple: x86_64-pc-windows-msvc
OS Version: 6.2.0 (Windows NT 6.2.0)
  Hostname: DESKTOP-NTLKJTP
 Connected: yes
WorkingDir: C:\Users\xusheng\Downloads\clang+llvm-18.1.8-x86_64-pc-windows-msvc\bin
    Kernel: Windows NT 6.2.0
      Host: Windows 6.2.0
(lldb) r
(lldb) Process 10308 launched: 'C:\Users\xusheng\debugger_build\debugger\test\binaries\Windows-x86_64\helloworld.exe' (x86_64)
Process 10308 exited with status = 10 (0x0000000a)

However, it still seems to me that the debugging itself is not working properly:

(lldb) b -s helloworld.exe -a 0x140001338
Breakpoint 1: where = helloworld.exe`helloworld.exe[0x0000000140001338], address = 0x0000000140001338
(lldb) r
Process 9304 launched: 'C:\Users\xusheng\debugger_build\debugger\test\binaries\Windows-x86_64\helexe' (x86_64)
Process 9304 stopped
* thread #1, stop reason = breakpoint 1.1
    frame #0: 0x00007ff631a61338 helloworld.exe
->  0x7ff631a61338: int3
    0x7ff631a61339: subl   $0x28, %esp
    0x7ff631a6133c: callq  0x7ff631a6159c
    0x7ff631a61341: addq   $0x28, %rsp

For a helloworld.exe we use in our unit test, the LLDB when the entry breakpoint is hit, LLDB reports the byte as int3 instead of the original "sub rsp, 0x28". This issue is known in llvm/llvm-project#60063, which actually prompted us to disable the LLDB adapter for PE files. In other words, LLDB 18.1 does get better in terms of remote debugging, but the debugging itself still malfunctions.

@25pwn I remember you said you can debug it normally -- are you not seeing the erroneous "int3" instruction while using the above setup?

[xusheng6]

However, it seems that the bug only happens when I set the breakpoint via b -s -a command. If I used b symbol to set a breakpoint on a function, it actually works:

(lldb) b __p___argv
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) r
1 location added to breakpoint 1
(lldb) Process 16572 launched: 'C:\Users\xusheng\debugger_build\debugger\test\binaries\Windows-x86_64\helloworld.exe' (x86_64)
Process 16572 stopped
* thread #1, stop reason = breakpoint 1.1
    frame #0: 0x00007ffe58372310 ucrtbase.dll`__p___argv
ucrtbase.dll`__p___argv:
->  0x7ffe58372310 <+0>:  leaq   0xfea81(%rip), %rax
    0x7ffe58372317 <+7>:  retq
    0x7ffe58372318 <+8>:  jno    0x7ffe5837236d            ; __stdio_common_vfwprintf + 61
    0x7ffe5837231a <+10>: popq   %rbp
(lldb) bt
* thread #1, stop reason = breakpoint 1.1
  * frame #0: 0x00007ffe58372310 ucrtbase.dll`__p___argv
    frame #1: 0x00007ff631a612b3 helloworld.exe
    frame #2: 0x00007ffe592c257d kernel32.dll`BaseThreadInitThunk + 29
    frame #3: 0x00007ffe5a9caf28 ntdll.dll`RtlUserThreadStart + 40
(lldb) breakpoint list
Current breakpoints:
1: name = '__p___argv', locations = 1, resolved = 1, hit count = 1

[xusheng6]

I have created an issue to track further development on the matter: Vector35/debugger#613

[25pwn]

I'd like to request re-enabling the lldb adapter for all platforms on dev(also stable if possible). The feature was definitely usable, and even if it's broken for some users, I think it's better to enable it for users that can make it work(maybe add a warning that it's experimental, or add it as an experimental option).

[xorhex]

Experiencing the same thing. PE file is loaded into BN, but the connect to remote dbg server shows nothing in the drop down.

BN: 4.1.5902 (f2165c5d)
Host OS: Ubuntu 24.04.1 LTS

[xusheng6]

Remote debugging Windows PE from Linux is not supported yet. You can only do so from another Windows machine. Vector35/debugger#70

[xusheng6]

I will continue to explore the possible route to support remote Windows debugging from a non-Windows OS, but it is not supported yet