Cutter: Remote GDB debugger fails

[lars18th]

Environment information

• Local: Cutter 1.10.3 in Windows 10 64bit

• Remote: Linux 3.10 x64 in embbeded platform

• Remote command: "gdbserver 0.0.0.0:9000 /root/my_binary my_params"

• Remote binary: "my_binary" is ELF64 with stripped data

Describe the bug

When I _LOAD_ the binary in the Windows machine I can see the pseudo-code of the decompiled functions.
However, when I _CONNECT_ to the remote gdbserver running the binary, all the decompiled code changes to // WARNING: Bad instruction - Truncating control flow here, and all funcitons are empty.

To Reproduce

Steps to reproduce the behavior:

1. Open the ELF binary in the Windows Cutter using the "file" option (first copy the file to the client machine).
2. Select the decompiler tab.
3. Start the remote binary with the gdbserver tool.
4. Connect to the remote GDB debugger with the IP:PORT.
5. See error

Expected behavior

When connecting to a remote GDB server the local information will be preserved.

I hope you fix this error soon, as it will improve a lot the remote work.
Regards.

[lars18th]

Hi,

I feel (I'm not sure) that _after_ connecting to the Remote GDB I need to execute "MAP FILE" to load the local copy of the binary.

However:

• If I do this, then the Cutter enters in a infinite loop doing "decompiling..." and after some minutes it crashes.
• If this is the expected procedure (connect to the Remote GDB and MAP the file) then I suggest to add the option for selecting the file in the same window that defines the remote GDB server.
• Anyway I recommend to not _unload_ the local file when connecting to a remote GDB server. That's because if the user has loaded it then it's expected to run the same binary.

I hope you can fix and improve this.
Thank you!

[lars18th]

Hi,

Please help me to understand the _correct_ behaviour to debug a _REMOTE_ binary:

• When connecting to the remote GDB server... how I can LOAD the binary file? This question has sense as the Decompiler seems to load from the _local_ memory and not from the _remote_ memory. Or almost, if it reads from the remote, then it doesn't work.

Any idea?

[lars18th]

Hi,

If I'm a noobie asking about this, then please point me towards how to use Cutter with remote GDB sessions.
If not, then please help me to fix this issue.

Thank you!

[yossizap]

If I'm a noobie asking about this, then please point me towards how to use Cutter with remote GDB sessions.

The question is completely fine. Sorry, it took me a while to get to this issue.

Connecting to remote gdb only requires setting the IP/port fields in the remote debug dialog. No other actions are required and it seems that you already passed that stage.

I feel (I'm not sure) that after connecting to the Remote GDB I need to execute "MAP FILE" to load the local copy of the binary.

Shouldn't be necessary.

This seems to be an issue when opening gdbserver from windows, doing the same in Linux works perfectly fine(Once you reach a function that can be decompiled, the entry point also prints . I am currently looking into this to find a solution.

[lars18th]

Hi @yossizap ,

Thank you to review this issue. :smile:

To have good information: You're saying that if I use a "remote" Cutter running in Linux connected to a gdbserver running in another Linux box then it will work? If yes, then I'll check it, as my error is using the Windows Cutter version.

Regards.

[yossizap]

To have good information: You're saying that if I use a "remote" Cutter running in Linux connected to a gdbserver running in another Linux box then it will work?

Yep, tested as I wrote and it worked well for main. Didn't look into it further but it didn't have any errors and the text highlight in decompiler view was synced with disassembly.

[lars18th]

Thank you @yossizap !
Then I'll try runing it in WSL... https://discourse.appimage.org/t/run-appimage-on-windows/177

Regards.

[lars18th]

Hi @yossizap ,

It seems that Cutter AppImage runs fine inside WSL1. However, I see this:

• If I open with the option "Don't open any file" to connect only to the GDB server, then in this case the socket connection is not stablished. It's a requirement to open the binary file first (from a local copy) and after connect to the remote gdbserver ? I tested with native Windows version and with the AppImage over WSL and every time I see this error. Futhermore I don't see the option to open directly from start a "Remote GDB session".
• When using the AppImage connected the remote GDB server, decompiler don't show good data... even if I try "r2dec" or "Ghidra": Error: no "good" data given (all invalid opcodes). Any idea? Even the Disassembly shows "invalid".

Thank you for your time!

[yossizap]

If I open with the option "Don't open any file" to connect only to the GDB server, then in this case the socket connection is not stablished.

We don't have an option (yet) to directly connect to gdb:// in Cutter but it is possible with radare2. This usage is unsupported.

It's a requirement to open the binary file first (from a local copy) and after connect to the remote gdbserver ?

Yes

When using the AppImage connected the remote GDB server, decompiler don't show good data... even if I try "r2dec" or "Ghidra": Error: no "good" data given (all invalid opcodes). Any idea? Even the Disassembly shows "invalid".

Even when locally opening the binary from the remote session? Didn't try with WSL

Also, we should solve this for windows, it shouldn't be necessary to use WSL or a linux machine. It will just take some time.