Connecting Ghidra Debugger to WSL via SSH

[astrelsky]

This is going to be super rough as I have no idea what I am doing. I'm trying to use GNU gdb via SSH1 and can't figure out how to establish a connection. Here is what I do know how to do.

Connecting to WSL via SSH:

• From command prompt enter ssh astre@DESKTOP-3RR5B89.
  (Note: That is what appears when opening the normal WSL terminal 😉)
• Enter password when prompted.
• WSL connection is established and I'm greeted with the terminal.

Connecting gdb to remote target:

• From the WSL terminal run gdb-multiarch
• From the gdb interpreter enter target remote localhost:24689
• Remote connection is established and once everything stops I can get info on threads, memory, registers, etc.

Regarding this DebuggerDevGuide, is this specifically referring to pcode emulation or emulation in general?

I also usually enter set debug remote 1 in the gdb interpreter prior to connecting since the remote gdb stub is still a work in progress. Is it safe to assume that these extra details won't interfere with anything?

[d-millar]

OK, so you're probably going to have to make a few modifications to /etc/ssh/sshd_config, using nano or your favorite editor from the WSL shell. In particular, because we're using a somewhat dated ssh library, you'll need to support older key exchange algorithms. (Yeah, we know - we're working on it, but the options in the Java ssh library space are a bit weak.) My config contains a handful of things. Not sure these are all necessary, but will copy them here for completeness:

AllowUsers
Port 8888 (obviously, this can be whatever you want in the high port space)
KexAlgorithms +diffie-hellman-group1-sha1 (thanks to @jrmuizel for these)
Ciphers +aes128-cbc
PasswordAuthentication yes
ChallengeResponseAuthentication yes
UsePAM yes
X11Forwarding yes
xAcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server

Am pretty sure I only modified the first four of those, but again for completeness. After modifying the config, you'll probably have to "sudo service ssh --full-restart". Ssh in once to insure the initial queries have been answered and won't require attention from Ghidra.

At this point, you should be able to select "GDB over SSH" using the Targets window "New connection" icon, and specifiy:

GDB launch command: /usr/bin/gdb-multiarch
Use existing session via new-ui: (I would try unchecked first, as that's simpler, but you can start gdb-multiarch in WSL and attach to it if you prefer)
SSH-hostname: (I think I used the actual IP here versus the DESKTOP-Xxx - will check)
SSH TCP port: 8888 (or whatever you put in the config)
SSH username: astre
SSH identity: (blank)

Assuming that works (!), you can then do the target-specific stuff in the Interpreter window. This will certainly include "target remote localhost:24689", but might also include things like "set architecture xxx". Keep in mind if your target doesn't support certain commands like "info proc mappings" and "maintenance info sections ALLOBJ", you may have to dummy out those commands in a script and run that script to get various aspects of the debugger working. Specifics are discussed in the help files and Issues/Discussions on GitHub, but, if windows other than Objects and the Interpreter are empty or the Dynamic Listing isn't tracking, this is where you need to start.

Using "set debug remote 1" or "set debug serial 1" should redirect to the Interpreter ("should") and should not have an effect on the debugger behavior. That said, maybe try the basic functionality without them first to be sure.

Re emulator comments in the DebuggerDevGuide, those were meant to apply to building either a front- or back-edge for pcode emulation. As you may notice, we have support for stepping forward via the emulator while debugging as exploratory execution. Our intention is to build that out moving forward, possibly to include other forms of execution.

Debugging support for emulators in general is a topic we're very interested in, but, as noted in our releases notes, not our primary immediate focus. As a result (see all of the above), getting the debugger up and connected to your favorite emulator may be a bit cumbersome. Suggestions appreciated - we're definitely open to ideas at this point. And, of course, if anything I've said here is incorrect or insufficient, feel free to give us a shout. Will do our best to fill in the blanks.

[astrelsky]

Sweet thank you. I was able to get it connected. One thing I noticed right off the bat though is that Ghidra incorrectly claims it is an untrusted or unknown host when it is not. I even deleted the known_hosts file and made another connection to re-add it and still received that warning.

[d-millar]

I've definitely noticed some weirdness, especially regarding the new entries in sshd_config. For example, I've occasionally gotten it in a state where I can ssh from Ghidra but not from cmd. With luck, the move from Ganymed to JSch will resolve some of these problems. My ssh expertise is a little weak generally, but @nsadeveloper789 is working the issue and am confident he'll come up with a more stable solution.

[d-millar]

Having trouble recreating that - you have an agent open and are connected and then you close the tool?

[astrelsky]

Having trouble recreating that - you have an agent open and are connected and then you close the tool?

So scratch that, the cause is elsewhere. This seems to occur everytime for me so I'll debug it and track down where it is coming from.

[astrelsky]

So unfortunately this seems to be beyond my ability to debug. It doesn't occur when I have breakpoints set but does when they aren't set. Hopefully this will be of some help but other than that it's all I got.

DEBUG Remote SSH pty: /dev/pts/1  (SshPtyChild.java:89) 
DEBUG When selecting paths by name the first path element must be the name of the root node - path: Objects  (GTreeSelectNodeByNameTask.java:50) 
2
DEBUG Terminating agent.gdb.manager.impl.GdbManagerImpl@7a295570  (GdbManagerImpl.java:756) 
ERROR Error: Uncaught Exception! 
NullPointerException - Cannot invoke "java.lang.Integer.intValue()" because the return value of 
"agent.gdb.pty.PtySession.waitExited()" is null  (SwingExceptionHandler.java:80) 
java.lang.NullPointerException: Cannot invoke "java.lang.Integer.intValue()" because the return value of "agent.gdb.pty.PtySession.waitExited()" is null
	at agent.gdb.manager.impl.GdbManagerImpl.waitGdbExit(GdbManagerImpl.java:741) ~[Debugger-agent-gdb.jar:?]
GdbManagerImpl.java:741
	at java.lang.Thread.run(Thread.java:832) [?:?]
Thread.java:832
DEBUG STDOUT,CLI reader exiting because java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@7df22f8[Not completed, task = java.util.concurrent.Executors$RunnableAdapter@46e228c3[Wrapped task = agent.gdb.manager.impl.GdbManagerImpl$$Lambda$1367/0x0000000801785650@42ddb4c7]] rejected from java.util.concurrent.ThreadPoolExecutor@61618dd3[Shutting down, pool size = 1, active threads = 0, queued tasks = 0, completed tasks = 63]  (GdbManagerImpl.java:148) 

[nsadeveloper789]

Debug Connections are actually managed by the "Front End" or "Project" tool, not the individual tools. While not really tested yet, the idea is that multiple concurrent "Debugger" tools can share a pool of connections. To clean everything up, try "Debugger -> Disconnect All" from the Front End.
The messages you pasted there... are those just from the log, or do those pop up in a stack trace dialog? Is that something you see when the connection persists? Or is it just an unrelated NPE?

[astrelsky]

Debug Connections are actually managed by the "Front End" or "Project" tool, not the individual tools. While not really tested yet, the idea is that multiple concurrent "Debugger" tools can share a pool of connections. To clean everything up, try "Debugger -> Disconnect All" from the Front End.
The messages you pasted there... are those just from the log, or do those pop up in a stack trace dialog? Is that something you see when the connection persists? Or is it just an unrelated NPE?

The messages are from the log I think. It is really what was printed in the vscode terminal while debugging. That NPE is what I get when disconnecting. It doesn't happen while debugging which leads me to suspect some sort of race condition.