The proper way to use GDB via SSH from Windows to Linux host?

[Igorprostoff]

While trying to solve a simple Crackme, written for Linux, I wanted to try out the new debugger feature by using the "GDB via SSH" option in Ghidra, by connecting from Windows host (where the Ghidra is running) to the WSL2 host, where the GDB is able to debug the Crackme. But after I successfully connect from Ghidra to the Linux host with my login and password and provide the executable path as a command-line parameter, the only thing I see is a program output in the Interpreter window.
Is this the right way to use this feature or am I doing something wrong?

[d-millar]

@Igorprostoff The fact that you have output to the Interpreter window is a good sign - means you’re half way there. Do you have a tree in the Objects window? If so, ids the tree opened up to the process. (It’s supposed to do this automatically, but doesn’t always seem to work correctly.) Opening to the process will trigger the recording, which in turn enables all the other windows. (Yeah, I know - not the greatest design. We’re working on fixing it.)

[Igorprostoff]

Thanks a lot for the quick response!
Yes, I can see the Objects window with one process in the "inferiors" section, but after trying to expand it's content (such as breakpoints, memory, and modules) I see an error "Request for children timed - out - try refreshing the node" and nothing more happens.

Also, I forgot to mention, that there is an error, occurring right after I connect to the host with SSH:

Command completed with <GdbCommandDoneEvent {} >, not any of [class agent.gdb.manager.evt.GdbCommandRunningEvent]
java.lang.IllegalStateException: Command completed with <GdbCommandDoneEvent {} >, not any of [class agent.gdb.manager.evt.GdbCommandRunningEvent]
	at agent.gdb.manager.impl.GdbPendingCommand.checkCompletion(GdbPendingCommand.java:234)
	at agent.gdb.manager.impl.cmd.AbstractLaunchGdbCommand.complete(AbstractLaunchGdbCommand.java:52)
	at agent.gdb.manager.impl.cmd.AbstractLaunchGdbCommand.complete(AbstractLaunchGdbCommand.java:22)
	at agent.gdb.manager.impl.GdbPendingCommand.finish(GdbPendingCommand.java:71)
	at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)

---------------------------------------------------
Build Date: 2021-Jul-08 1512 EDT
Ghidra Version: 10.0.1
Java Home: C:\Program Files\AdoptOpenJDK\jdk-11.0.10.9-hotspot
JVM Version: AdoptOpenJDK 11.0.10
OS: Windows 10 10.0 amd64
Workstation: IGOR-PC.mshome.net

But this error doesn't always appear.

[d-millar]

Hmmm, well, that isn't as good. :)

A couple of more questions, I don't think this matters for the SSH case but version of gdb in WSL2? Also, can you execute standard gdb commands in the Interpreter window or do you just see output? Also, I guess, what is the output?

[Igorprostoff]

The GDB version is: GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
The execution of regular GDB commands in the interpreter fails, I get no output, here is the interpreter output:

[d-millar]

Hmmm, do you have the same issues running something mundane, like plums or xclock?

[Igorprostoff]

All of the mentioned commands work when I debug xclock, but they don't when I debug the crackme and I guess, that your conjecture about the problem with the "main" function is right, because, as far as I can understand, the crackme just handles after printing the banner because it is listening to the TCP ports (and it also reacts to connection to them, by printing more information), but gdb still can't execute any commands, which are sent to it with CLI. This happens also when I try to debug it with GDB without ghidra, by using the command "start" instead of "starti".
Also, the Ctrl+I combination doesn't help in this situation and it seems that Ghidra writes the line "(gdb)" before the commands, so the user thinks that he can execute the commands, while he can't.
Here is the attempt to execute commands with Ghidra interpreter:

And here is the attempts to execute commands with CLI of WSL2 :

The solution with manually setting the exec-file and starting its execution with the "starti" command from the ghidra interpreter works partly because I can see more information about the program in the "Objects" tab, but I can't see the dynamic listing of the program.
I also tried to debug this crackme on my WSL2 with Ghidra by connecting to the host with VNC and launching the GDB locally IN-VM and it works fine - I can see the dynamic listing, the stack info, threads, breakpoints, etc. And it works OK without manually starting the execution with the "starti" command like I have to do on Windows with an SSH connection to Linux.

[d-millar]

Wow, ok - thanks for trying all this. All your information helps a lot. Will try to reproduce these errors on WSL2 tomorrow if I can. The VNC test was particularly interesting - good call. Am out of ideas for the moment, but will keep banging on this. Would definitely like to get it solved.

[d-millar]

OK, we found the problem, and we definitely owe you a beer. It's a major problem, and I'm somewhat surprised it hasn't affected a lot of other folks. It will be fixed in 10.0.2. That said, if you're building and/or running your own copy out of Eclipse, I can point you to the code to modify. It's a one line fix, namely, in GdbManagerImpl::doExecute move the end brace after "curCmd = pcmd;" (around line 726?) to the end of the thenAccept block (around line 743?). Points to @nsadeveloper789 for id'ing the bug and the fix! After the fix, I tested it for the Launch case and the "file"+"starti" case, and both populated all the windows including the Dynamic listing. You may still need to map the executable in Modules to get the Static listing to track the Dynamic listing because the paths will be different across the WSL/Windows boundary (may).

[Igorprostoff]

Wow, thank you for help with this issue! Glad to hear that my case helped to find such kind of problem😊.

[astrelsky]

OK, we found the problem, and we definitely owe you a beer. It's a major problem, and I'm somewhat surprised it hasn't affected a lot of other folks. It will be fixed in 10.0.2.

Bystander effect.

[ryanmkurtz]

Fixed by 19fa121