Connect to luma3ds gdb stub with "GNU gdb local agent via GADP/TCP"

[SirEnder125]

Hey. Someone recently told me:

If 3ds includes a gdb stub compatible with 7.0 or greater, you can use the "GNU gdb over GADP" interface.

I'm not sure if it is compatible. But Luma3ds does have a gdb stub. But the debugger gives me this error:

java.util.concurrent.CompletionException: java.lang.RuntimeException: agent terminated unexpectedly.

[d-millar]

Can you connect to the stub via gdb?

[d-millar]

Actually, I think I'm confused - the error you sent implies the agent died, but the command I suggested you run shouldn't be running an agent. Did you connect using "GNU gdb over GADP"?

[d-millar]

Hmmm, not sure that's right either - hold off, let me consult tomorrow, maybe give you better advice

[SirEnder125]

Actually, I think I'm confused - the error you sent implies the agent died, but the command I suggested you run shouldn't be running an agent. Did you connect using "GNU gdb over GADP"?

There isn't actually something called that. Only GNU gdb local agent via GADP/TCP.

Can you connect to the stub via gdb?

Yes.

Hmmm, not sure that's right either - hold off, let me consult tomorrow, maybe give you better advice

Okay.

[SirEnder125]

Okay, this is where I am so far:
I thought my 2DS was freezing because something went wrong. But, someone told me that
that is supposed to happen.
If it is, then, GADP connection over TCP is working fine. ALTHOUGH, it does not let me view
anything. If I connect to it via gdb (arm-none-eabi-gdb.exe) it does nothing until I type continue,
or c. Whereas in ghidra there is no continue option. What can I do?

[d-millar]

I keep forgetting you're on a Windows box....OK, right, so you're doing the right thing, but I probably haven't provided enough detail again. Either the "GNU gdb local agent over GADP/TCP" or the "IN-VM gdb local debugger" options should work as long as you specify the correct command in the "GDB launch command" parameter (in your case /path/to/arm-none-eabi-gdb.exe") . I would recommend the latter as it will give you more info if it dies and is easier to debug if we have to go that route.

When you connect, the device may or may not be running. If it has broken, you'll be in the same state as you were with gdb.exe, and, when you select the process/inferior in the Objects Provider, the green resume/continue button should be enabled. If it's not (i.e. it's running), selecting the same object should enable the interrupt/pause button. If neither of those are true, you'll probably need to do something else in the Interpreter Console. The Interpreter Console is basically (more or less) the same environment as the gdb shell. If you are entering something like "target remote host:port" in gdb, you will have to do the same in the Interpreter. (If the Interpreter isn't visible, launch it from the Objects Provider.) You may also want to read a bit of the help - most of the windows don't display useful info until you are tracing the target.

[d-millar]

Oh, and to clarify "GADP connection over TCP" won't work. That's really only for talking to a remote Ghidra agent running on a different box (potentially connected to a client). If you were using that, the stub was probably extremely confused because we were talking GADP to it and it only speaks RSP. Am guessing you may get the agent died message again, but, if you run from Eclipse, you may get a stack trace that'll help us figure out why. Does that all make sense?

[SirEnder125]

I don't really get it. On my 2ds, I have Luma3ds and I turn on the debugger and
it gives me my 2ds' IP address. I go to the process list, enable the game I am playing
and it gives me port 4000 (Usually). IN-VM gdb local debugger does not let me
connect to and IP/port. But, as I said, GADP connection over TCP works fine, it
does what GDB does. GDB seems to work fine after I enter continue, though, it
does not have a GUI. So I want to use Ghidra. Ghidra does not allow a continue
as far as I've seen. Where can it be found?

[SirEnder125]

Sorry for the giant image, but this is what Ghidra looks like:

The IP and port are what luma3ds gives me.
When I try to connect, it says "connecting...", yet never un-greys out the buttons.
ALL the buttons, "pause"/"resume" are greyed out.

[d-millar]

Yeah, this is definitely confusing - I appreciate your hanging in there and giving it a try! So, what I think is happening in the "GADP connection" case is you're telling it the host and port, it's doing the TCP handshake and connection, but the underlying protocol is not what it's expecting - so it hangs. Admittedly, this looks like it connected but probably not.

Try this: specify your version of gdb in the IN-VM GDB pane. I think you MAY be able to also add the host:port as arguments in the same field, but I'm not sure about that. If you don't, you'll need to open that Interpreter window and enter "target remote 192.168.2.3:4000". Let me know if you get that far!

[SirEnder125]

I'll try.

[SirEnder125]

Is this where I am supposed to enter the stuff?

[d-millar]

Yes, looks good -fire away!

[d-millar]

hit "Details"

[SirEnder125]

The specified procedure could not be found.

java.lang.UnsatisfiedLinkError: The specified procedure could not be found.

	at jnr.ffi.provider.jffi.NativeLibrary.loadNativeLibraries(NativeLibrary.java:87)
	at jnr.ffi.provider.jffi.NativeLibrary.getNativeLibraries(NativeLibrary.java:70)
	at jnr.ffi.provider.jffi.NativeLibrary.getSymbolAddress(NativeLibrary.java:49)
	at jnr.ffi.provider.jffi.NativeLibrary.findSymbolAddress(NativeLibrary.java:59)
	at jnr.ffi.provider.jffi.AsmLibraryLoader.generateInterfaceImpl(AsmLibraryLoader.java:158)
	at jnr.ffi.provider.jffi.AsmLibraryLoader.loadLibrary(AsmLibraryLoader.java:89)
	at jnr.ffi.provider.jffi.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:44)
	at jnr.ffi.LibraryLoader.load(LibraryLoader.java:325)
	at jnr.ffi.LibraryLoader.load(LibraryLoader.java:304)
	at agent.gdb.ffi.linux.Util.<clinit>(Util.java:27)
	at agent.gdb.ffi.linux.Pty.openpty(Pty.java:95)
	at agent.gdb.manager.impl.GdbManagerImpl.start(GdbManagerImpl.java:555)
	at agent.gdb.model.impl.GdbModelImpl.startGDB(GdbModelImpl.java:125)
	at agent.gdb.GdbInJvmDebuggerModelFactory.build(GdbInJvmDebuggerModelFactory.java:52)
	at ghidra.app.plugin.core.debug.gui.target.DebuggerConnectDialog.connect(DebuggerConnectDialog.java:231)
	at java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1967)
	at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2308)
	at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:405)
	at java.desktop/javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:262)
	at java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:279)
	at java.desktop/java.awt.Component.processMouseEvent(Component.java:6635)
	at java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3342)
	at java.desktop/java.awt.Component.processEvent(Component.java:6400)
	at java.desktop/java.awt.Container.processEvent(Container.java:2263)
	at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5011)
	at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321)
	at java.desktop/java.awt.Component.dispatchEvent(Component.java:4843)
	at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4918)
	at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4547)
	at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4488)
	at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2307)
	at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772)
	at java.desktop/java.awt.Component.dispatchEvent(Component.java:4843)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95)
	at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
	at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:117)
	at java.desktop/java.awt.WaitDispatchSupport$2.run(WaitDispatchSupport.java:190)
	at java.desktop/java.awt.WaitDispatchSupport$4.run(WaitDispatchSupport.java:235)
	at java.desktop/java.awt.WaitDispatchSupport$4.run(WaitDispatchSupport.java:233)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.desktop/java.awt.WaitDispatchSupport.enter(WaitDispatchSupport.java:233)
	at java.desktop/java.awt.Dialog.show(Dialog.java:1070)
	at java.desktop/java.awt.Component.show(Component.java:1716)
	at java.desktop/java.awt.Component.setVisible(Component.java:1663)
	at java.desktop/java.awt.Window.setVisible(Window.java:1031)
	at java.desktop/java.awt.Dialog.setVisible(Dialog.java:1005)
	at docking.DockingDialog.setVisible(DockingDialog.java:354)
	at docking.DockingWindowManager.lambda$doShowDialog$6(DockingWindowManager.java:1709)
	at ghidra.util.Swing.doRun(Swing.java:292)
	at ghidra.util.Swing.runNow(Swing.java:208)
	at ghidra.util.Swing.runNow(Swing.java:163)
	at docking.DockingWindowManager.doShowDialog(DockingWindowManager.java:1713)
	at docking.DockingWindowManager.showDialog(DockingWindowManager.java:1734)
	at docking.AbstractDockingTool.showDialog(AbstractDockingTool.java:154)
	at ghidra.app.plugin.core.debug.gui.target.DebuggerTargetsProvider$ConnectAction.actionPerformed(DebuggerTargetsProvider.java:109)
	at docking.menu.ToolBarItemManager.lambda$actionPerformed$0(ToolBarItemManager.java:128)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

---------------------------------------------------
Build Date: 2021-Feb-02 1555 CST
Ghidra Version: 9.3
Java Home: C:\Program Files\Amazon Corretto\jdk11.0.10_9
JVM Version: Amazon.com Inc. 11.0.10
OS: Windows 10 10.0 amd64
Workstation: 192.168.2.16

[d-millar]

Ah, that's very helpful, but it may be where my expertise ends - I will grab one of the other guys tomorrow who understands the Pty implementation. Sorry, it wasn't an immediate win!

[SirEnder125]

Okay, thanks. Don't worry about it, it's okay.

[SirEnder125]

Oh, by the way, how do I open the interpreter?

[d-millar]

(I say "immediate" although I realize you've been working at this for weeks!)

[d-millar]

If it connected, it would be the little console-shaped icon in the Objects Provider at the far left of the toolbar

[SirEnder125]

Ohhhhh, okay. Thanks a lot.

[nsadeveloper789]

Sorry, I'm entering the conversation a little late. Several things to point out. First, as of now, the GDB connector (whether IN-VM or via GADP/TCP) is only supported on Linux. We use openpty() to interact with GDB's CLI, so that we can interrupt by simulating Ctrl-C on the terminal. This can't (to my knowledge) be done using just stdin. That said, openpty is not available on Windows, and I haven't taken the time to find its equivalent.

So, the simplest, though perhaps disappointing answer, is to just build and run Ghidra on Linux. Then you can use all the GDB stuff "out-of-the-box." If you insist on using Ghidra for Windows, and/or your like a good adventure, then proceed:

You can use a Linux VM to host GDB, then connect to it from Ghidra on Windows. While I've not tested this myself, you might be able to forego the Linux VM for WSL. It'll probably work for WSL2, since that is essentially a Linux VM. I'm not as confident for WSL1, but it could.

Note that the GADP connection over TCP cannot connect directly to a GDB stub. GADP is Ghidra's in-house protocol for communicating with its connectors. (GDB stubs use RSP, which we don't connect to directly.) We often run the actual connector in a separate "agent" process, because they are more prone to crash. Should they crash, we don't want it to take all of Ghidra with it. (the IN-VM variants loads the connector in Ghidra's process, the via GADP/TCP variants launch the agent and automatically connect via GADP). The "GADP connection over TCP" connector is used when you've already launched an agent, which is a less-common use case, but applies here. In a sense, the agent just wraps GDB as a means of translating GADP to RSP.

Thus, you must build and launch the agent manually on Linux, and connect to it from your Windows Ghidra. In your ghidra repo (presumably on Windows), run:

gradle nodepJar

This will generate Ghidra/Debug/Debugger-agent-gdb/build/libs/Debugger-agent-gdb-nodep.jar. Copy that into your Linux VM, and ensure you have an OpenJDK-11 installed as the default JVM. Run it to get its command-line options:

java -jar Debugger-agent-gdb-nodep.jar -h`

You will probably need the --gadp-args, -H and -g parts. For HOST, put the IP of your VM's virtual adapter. (Leave it localhost under WSL.) For GDB put the full path to GDB. Note that when you run it, it'll present a (gdb) prompt. Ignore that, it does nothing anymore. It'll pop up a graphical window so that it's obvious it's running. Please consider the security implications: Do not listen on an adapter/port that is connected to a real network. There is no authentication or encryption applied, and it's a debug port.

Now, from Ghidra on Windows, hit the connect button and select "GADP connection over TCP". Set the network address to your VM's virtual adapter's IP (again, localhost for WSL.) Set the port to 12345, and click connect. You should eventually receive the GDB prompt in Ghidra. You can then proceed as you normally would to connect GDB to your stub.

[SirEnder125]

I guess I could try Linux VM, but it may take up too much ram.
Just to clear up one thing, I can interrupt gdb with CTRL-C on Windows,
too. I don't know if you said that couldn't be done but that's kinda what
I got. I'll try the linux vm some time I guess, I'll let you know if it works.

[nsadeveloper789]

Ctrl-C is surprisingly complicated on Linux. Again, I'm not sure the nuances on Windows. It might turn out to be simpler there, but we've not done it yet.

Simply sending Cltr-C (character 3) down stdin does not interrupt the process. It has to be interpreted by a private/pseudo terminal (pty), which then signals the appropriate process with the interrupt. We also can't just interrupt the process ourselves, because it might be a remote target. GDB takes care of these nuances for us, if we can properly emulate a terminal and send Ctrl-C.

[SirEnder125]

Well, when I open gdb (in tui mode, at least) it lets me interrupt my 2ds.
Hmm if only gdb could talk to ghidra... 🤔

[DrChat]

@nsadeveloper789 Windows offers an equivalent API to openpty() called ConPTY.

They've also written a detailed blog post on the new API.
For brevity, this is a direct link to a usage example of the new API as part of the blog post.
The following is an excerpt of their usage example:

    HANDLE hOut, hIn;
    HANDLE outPipeOurSide, inPipeOurSide;
    HANDLE outPipePseudoConsoleSide, inPipePseudoConsoleSide;
    HPCON hPC = 0;

    // Create the in/out pipes:
    CreatePipe(&inPipePseudoConsoleSide, &inPipeOurSide, NULL, 0);
    CreatePipe(&outPipeOurSide, &outPipePseudoConsoleSide, NULL, 0);

    // Create the Pseudo Console, using the pipes
    CreatePseudoConsole(
        {80, 32}, 
        inPipePseudoConsoleSide, 
        outPipePseudoConsoleSide, 
        0, 
        &hPC);

    // Prepare the StartupInfoEx structure attached to the ConPTY.
    // This function is defined in the blog post, definition omitted in this code block for brevity.
    STARTUPINFOEX siEx{};
    InitializeStartupInfoAttachedToConPTY(&siEx, hPC);

    // Create the client application, using startup info containing ConPTY info
    wchar_t* commandline = L"c:\\windows\\system32\\cmd.exe";
    PROCESS_INFORMATION piClient{};
    fSuccess = CreateProcessW(
                    nullptr,
                    commandline,
                    nullptr,
                    nullptr,
                    TRUE,
                    EXTENDED_STARTUPINFO_PRESENT,
                    nullptr,
                    nullptr,
                    &siEx->StartupInfo,
                    &piClient);

[SirEnder125]

What does this mean?
What can be done with this in Ghidra to debug my 2DS?

[SirEnder125]

To emulate Linux, will I need Hyper-V?

[nsadeveloper789]

Yes.

[SirEnder125]

I do not have it.

[SirEnder125]

Which version of Linux would Ghidra's debugger work well on?

[SirEnder125]

Will the debugger ever work properly on windows? Or if it does now, to connect to 3ds-like devices?

[d-millar]

"Ever" is potentially a very long time, so hard to say. Unfortunately, as indicated in the documentation, your use case is really not high on our priority list. Our primary main goals are support for user-mode debugging of Windows' targets on Windows platforms and Linux targets on Linux platforms. Happy to keep you abreast, though, of changes that might make your use case more tenable.

[SirEnder125]

Thanks for your help.

[d-millar]

@SirEnder125 yes, the post by @DrChat means there is hope - we're looking into to it!

[SirEnder125]

Hey, that's great!! Please let me know if anyone gets that working.
Thanks a lot for replying after all this time. 👍🏻

[DrChat]

I opened an issue for this @ #2908.

[SirEnder125]

Hey, sorry to bother you guys again, but do you think that
the next Ghidra release will include the ConPTY support and
Luma3ds gdb stub debugging support?

[nsadeveloper789]

It is not likely. That said, we've added SSH support, which brings up 3 potentially useful points:

1. You can try installing an OpenSSH server for Windows (e.g., using Cygwin) and connecting to it via "localhost". However, we've only tested SSH support when the remote system is Linux or UNIX-like. Windows is not, so I don't know about it. Also try adding the "-i mi2" option, since that may reduce dependency on certain UNIX-like Pty features.
2. You can connect to a Linux VM (or WSL distro) with gdb and openssh installed very easily. Start the VM, launch Ghidra on Windows and point the GDB/SSH connector at its IP. (You don't need Hyper-V for WSL2)
3. We refactored the GDB connector to use a PtyFactory. If you're up to it, you can try implementing ConPTY support as a new PtyFactory.

Honestly, option 2 via WSL2 is probably your best option:
https://docs.microsoft.com/en-us/windows/wsl/install-win10
You don't need Hyper-V, just VirtualMachinePlatform.

[SirEnder125]

It is not likely. That said, we've added SSH support, which brings up 3 potentially useful points: ...

Oh. Well, I can wait until they get it working, if it's a planned feature. If not, fine.
But, I've tried option 2 and I can't seem to get it to work. Also, what version of
Ghidra has SSH support?

I have no idea what to do with this ubuntu thingy.

[nsadeveloper789]

This will install the SSH service and GDB in your Ubuntu distro on WSL.

sudo apt install openssh-server gdb

There may be some additional setup to get it working in WSL, but there are plenty of how-tos, e.g. https://superuser.com/questions/1123552/how-to-ssh-into-wsl
Once you have it working with a plain SSH client, like PuTTY, then you can try connecting with Ghidra. The debugger is not in any release, yet. You'll need to build from the latest source. Click the connect button, select "GDB over SSH" then use the same hostname/username as you did for PuTTY. Assuming you get connected, you should get a (gdb) prompt on screen, which you can use more or less like any (gdb) prompt. If/when Ghdira recognizes a target, it'll populate the UI.

[SirEnder125]

I installed openssh-server and gdb. How do I open openssh-server?

[SirEnder125]

Okay. I connected with PuTTY. I am about to connect with Ghidra.

[d-millar]

Hey,

Going to weigh in here just to make sure we're all on the same page - if I say anything wrong, feel free to jump in because I'm not sure I have the complete picture myself.

So, as I understand your scenario, you have Ghidra running on Windows (effectively the client) and the gdbstub on luma3ds (effectively the server). The gdbstub "speaks" the RSP protocol, so to communicate with it we need something that speaks RSP on the client side.

Because we do not have an RSP client for, well, anything, we typically rely on a middleman. On Linux, this is gdb, which we wrap as a gdb agent. In that scenario, Ghidra launches gdb and speaks GADP to it. Gdb translates those requests to RSP and talks to the target (in your case luma3ds). On Linux, we can also create an SSH connection to GDB, issue the commands directly, and get the same result.

For Windows, gdb running under Windows proper is basically a non-starter, so your options are either (a) gdb running on WSL, or (b) gdb running on a different machine. If luma3ds had an SSH server, you could talk directly to that, but I don't think it does. (Correct me if I'm wrong on this.)

So, let's say we're going WSL. I know exactly nothing about WSL so again correct me if I say something stupid, but, in this case (or even in the second machine) case, you'll want to install the openssh server and gdb on the middleman. Sounds like you have already done this. When you launch the openssh server, you can, I believe, specify a host and a port for clients to talk to it. If you don't specify, the host is localhost and the port is 22. If the server is running under WSL, can the main windows account access it as localhost? I don't know the answer to this, actually.

If it can, you'll want to (a) launch the openssh server, and (b) connect from Ghidra using "GDB over SSH" with the parameters set to /path/to/gdb, localhost, 22, and your username for WSL. On a good day, this will launch gdb in the WSL environment. From there, though, you'll still have to connect to the luma3ds. Probably, easiest to do this from the Interpreter using "target remote" etc.

Yell if this is unclear (or, of course, incorrect) :/
D

[SirEnder125]

Thanks, that cleared up a lot. Uh, I got this error:

[nsadeveloper789]

FWIW, some technical clarification: GADP is not involved when you use GDB over SSH. Ghidra talks SSH to the SSH server, commands it to run GDB in a pseudo-terminal, and then speaks GDB/MI to GDB over that SSH channel. When new-ui is supported, it'll command the SSH server to open a second pseudo-terminal, so that Ghidra can acces both the console and mi2 interpreters.

[d-millar]

OK, so am guessing you've already done this, but the first thing I would try is opening a Windows cmd window and issuing the command "ssh [email protected]:2222". There are two reasons for doing this: (1) ssh does some set-up on the very first connection that's hard to get right any other way, and (2) it might give you some insight if the ssh connection itself is failing. Assuming you've already done this, my guess is one of two things is going wrong - either gdb is not actually at /usr/bin/gdb ("which gdb" should tell you the actual path) or the path is a link. For reasons I don't quite understand, various tools are not happy with links. If so, "ls -l" the ostensible path, get the real path, and replace the first argument with that.

[d-millar]

OK, so is that IP address for the WSL client or a separate machine? Guessing you can't ping it either?

[nsadeveloper789]

Looking at the screenshots, I see two potential problems.

1. I think you forgot a / at the begging /usr/bin/gdb. Honestly, that could probably just be gdb anyway, since it should be on the system PATH.
2. The version of GDB (7.11.1) you're using could be problematic. It's about 4 years old and doesn't support the new-ui command. You can try your version, but you'll need to use gdb -i mi2 (or /usr/bin/gdb -i mi2) for the Launch command. I'd recommend you upgrade to the latest LTS version of Ubuntu (20.04), though. We've tested with GDB 7 on occasion, but we primarily work with versions 8 and 9, sometimes 10. With version 8 or later, you should not use -i mi2.

[SirEnder125]

OK, so is that IP address for the WSL client or a separate machine? Guessing you can't ping it either?

It is for a WSL client. No, I cannot ping it either.

[SirEnder125]

Looking at the screenshots, I see two potential problems.

1. I think you forgot a / at the begging /usr/bin/gdb. Honestly, that could probably just be gdb anyway, since it should be on the system PATH.
2. The version of GDB (7.11.1) you're using could be problematic. It's about 4 years old and doesn't support the new-ui command. You can try your version, but you'll need to use gdb -i mi2 (or /usr/bin/gdb -i mi2) for the Launch command. I'd recommend you upgrade to the latest LTS version of Ubuntu (20.04), though. We've tested with GDB 7 on occasion, but we primarily work with versions 8 and 9, sometimes 10. With version 8 or later, you should not use -i mi2.

Well, I installed that GDB by running sudo apt-get install gdb. And I don't know how else to get GDB.
Where can I get version 8 or 9?

[SirEnder125]

I downloaded GDB again and got GNU gdb (Ubuntu 9.1-0ubuntu) 9.1
and I connected in Ghidra and it still shows v7.11.1. PuTTY is showing
9.1, as well.

[d-millar]

Sorry, once again, probably not clear enough.... With code.bin in the Static window and the debugger running, go to Modules window. There should be two buttons on the top - one that looks like a double-sided arrow and one next to it that looks like a page. The mouse-over hover for the arrows icon will say "Map the current trace to the current program using identical addresses." If you've loaded code.bin at 0x100000 or rebased it there, that's probably an OK option. If you need to map the two at a relative offset, choose the icon to the right, which says "Map the current trace to various programs manually." The pull-down further to the right (with the "Settings" icon) has other options.

[viocar]

Right - the double-sided arrow does add something to the Static Mappings window, but nothing appears in the Modules window, and the Dynamic listing remains empty. Though just now I noticed that now the breakpoints do work - I just thought it wasn't working because nothing was populating the Modules window. Okay, neat. Thanks, and sorry about stumbling around so much. Now pretty much all that's left to get working is the Dynamic listing and I should have pretty much everything...?

[d-millar]

I think nothing in Modules is ok if you have the static mapping. That said, I'm a little concerned about the lack of content in the Dynamic Listing. Are there any threads listed in the Threads window and/or can you navigate to a thread in the model pane and double-click it?

[viocar]

Yeah, there's seven threads listed, but they think the PC is set to 00000000 (gdb also thinks this when I interrupt execution). However, the registers view correctly displays the registers of each thread - just nothing in the Dynamic window, which thinks I'm "nowhere."

[nsadeveloper789]

For this, I might need to see the contents of the Stack window. The UI will first try to read PC from the stack trace. If that's not present, then it'll read it from the register context. Also try typing bt into GDB, and capture that output for us, please.

[viocar]

Stack isn't showing much (despite it saying (running), it is stopped):

bt also has problems:

(gdb) bt
#0  0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Possibly an issue with the emulator's gdb stub?

[viocar]

Sometimes I can get a little more info out of it, but it's still not right:

[d-millar]

Ah, but you're running. If you break, do you get the same results?

[viocar]

Yeah, the state here is "STOPPED" - is that different from a break? Regardless of the state, I've never seen anything in the Dynamic window.

[d-millar]

Hmmm, the view you posted seems a little inconsistent. STOPPED should mean broken, but the threads also say "running", and it looks like commands issued in the terminal are telling you the target is running, as well. Sometimes we see this before the first break, but could be something else going on, I suppose.

[viocar]

Yeah, sometimes the (gdb) prompt doesn't show up after a break, but it will still accept inputs as though it's there. I'm not sure what the cause is.

[viocar]

Oh, I did get it to show it stopped somewhat more "properly." There's also some error messages in the gdb console which may be instructive? (But still no Dynamic window, and "PC" in threads still shows 00000000 even as the registers show the correct value,)

[d-millar]

OK, maybe double-click on one of those threads in Threads. Also, trying going to the Model pane and navgiating down to and double-clicking a thread there.

[viocar]

No luck. Double-clicking threads clearly "selects" them, but nothing appears in the Dynamic window.

[d-millar]

Hmmm, sadness. Maybe @nsadeveloper789 will have a better idea tomorrow.

[viocar]

No problem! I appreciate all the help you've been giving.

[d-millar]

One more thought: select the Dynamic window, hit G for "goto" or right-click to get it and type in manually one of the thread PCs.

[viocar]

Gives an error: "Address 00302f68 not in trace"

[nsadeveloper789]

I believe the empty Dynamic Listing is because of no result for info proc mappings. There are two alternative solutions. I recommend the second:

1. Fake the response by defining the command, usually in a GDB script. I believe we have a template for this in Ghidra/Debug/Debugger-agent-gbd/data/scripts/fallback_info_proc_mappings.gdb. You may need to refresh the "Memory" node in the Model window after you apply that script.
2. Enable Force Full View in Ghidra:
   • From the menu's: Window → Debugger → Regions. This should pull up the Regions window, usually in the lower left.
   • In its drop-down menu, enable Force Full View. That will display all addresses in the Dynamic Listing, whether they are valid on the target's memory or not.

Just to put everything together (as far as I can tell from convo above), what I'd recommend:

1. Launch your script and connect to your target.
2. Enable Force Full View (this should get saved for later sessions)
3. Map module identically (Modules window, left-right arrow button)
4. Verify Listings are synced, and their byte contents match.

[viocar]

Thanks. Force Full View has got the Dynamic listing mostly working:

As you can see, most of the instructions are not disassembled until they need to be. This is fine, though, since you can sync the program counter between the dynamic and static listings and just read the static listing.

One last thing I'm not sure of - is there a way to view the program's memory? The 3DS maps its heap from 0x08000000 to 0x0FFFFFFF, so I've added that to the static mappings, but, well, it's not static, so nothing is showing up in the Dynamic view.

As you can see, 2f517c loaded [r5+#0xba] into r6, which was recorded in the register view as 0x14, and the x command in gdb correctly returned 0x14, but I can't see it in the Dynamic view. Should I perhaps be looking somewhere else?

[nsadeveloper789]

Ah. I forget if we've fixed this in later versions, yet, but if GDB doesn't have the memory map, i.e., info proc mappings, then Ghidra's memory reading logic gets confused. I might change my recommendation and say use the provided script template to fake out info proc mappings. I think you'll need to adjust it for a 32-bit memory space instead of 64.

If that doesn't go well, then the workaround to manually get gdb to update Ghidra's memory view is to type the following into gdb:

ghidra trace tx-open "Put" "ghidra trace putmem $r5+0xba 4"

That will cause gdb to compute the address $r5+0xba (just like in x or display), and transfer at least 4 bytes starting there to Ghidra. (It will actually transfer the full page(s) containing that range.) Sadly, if you use this workaround, you'll have to type that command every time you want an up-to-date view, or work out how to hook it into gdb. Note that a grey background in the Dynamic Listing means the values are not up to date.

[viocar]

Hey, I've decided to get back to this again after a little break. The fake mappings script doesn't seem to work. I've edited and run it, and when I do info proc mappings in gdb, it tells me: 0x8000000 0xFFFFFFF 0x8000000 0x0 3dsmem - is this the correct way to try to get it to map bytes 0x8000000 through 0xFFFFFFF, or have I done it wrong? The tx-open workaround works, with the drawbacks you mentioned.

[d-millar]

@viocar Greetings - always nice to have folks come back! :)

So, a couple of notes:
(1) You may not have to do this anymore - try using "Force Full View" from the pul-down in the top right corner of Regions.
(2) The format of this command may have changed depending on the version of gdb you're using, i.e. it may now have a "permissions" column before the last, so you might have to enter "0x80000000 0xFFFFFFFF 0x80000000 0x0 rwxp 3dsmem".

[viocar]

Thanks! Adding rwxp did it.

[viocar]

I tried to enable editing live values in this newly defined memory region (which does appear in the "Regions" menu, by the way), but I get the following error when I actually try to change them: Editing not allowed: Failed to write <addr>: ghidra.program.model.mem.MemoryAccessException: Read-only mode

I've searched around trying to figure out how to get it out of read-only mode, but I can't tell if it's a setting I can change (the region is set to be writable), or if it's a consequence of how the regions were manually set, or something else. Using the set command in the gdb console does let me successfully edit values.

[d-millar]

How (exactly) are you trying to edit the values, i.e. through the Watches View, the Terminal, some other way?

[viocar]

Sorry, I should have been clearer. I've opened a Memory View, then I clicked the pencil-on-paper icon with the tooltip Enable/Disable editing of bytes in Byte Viewer panels. (Ctrl+Alt+E), then, upon clicking on a value and attempting to type a new one, I get the error message in the bottom left that I wrote in the previous message.

[d-millar]

No problem, just trying to understand what you’ve tried.

I’ll have to verify this with @nsadeveloper789, but I don’t think you can do this. Just to be clear (and quite possibly you’re already aware of this), there are two sets of memory typically - memory corresponding to various program objects (static) and memory corresponding to the running target (dynamic). In the normal debugger layout, there are two views, one for each.

If I remember correctly, the Byte Viewer only maps to the static memory. (This was certainly true at one point, and there was a ticket in for adding dynamic memory - I’m not 100% certain it hasn’t changed.) Assuming that’s true, you’re options are (1) to use the Watch View (and honestly I don’t remember exactly how to do it from there off the top of my head - might be in the documentation), or (2) via the usual gdb command in the Terminal window.

[viocar]

Hmm, I've been using the Memory View to look at the values in RAM, and they seem to update just fine, such as in the screenshot (it's red because I've closed the debugger), so it seems like it can do dynamic memory? Perhaps I'm misunderstanding.

[d-millar]

OK, I apparently, am completely out-of-touch with the latest changes. (So sad....)

Go to the main toolbar and look for something that looks like a little bullseye. On the pull-down to its right, you should see several options including "Control Target w/ Edits Disabled" and "Control Target". Am guessing yours is set to the former. Switch it to "Control Target" (which should convert the bullseye to a bullseye+dart. Unless I miss my guess, the memory will then be editable.

Sorry for the confusion - past my bed-time. :)

[viocar]

Yep, that did it. Thanks again! It seems like I can't edit registers this way (the Registers tab just doesn't respond to keypresses and there doesn't seem to be any interface dedicated to editing them), but this isn't a pressing problem since the 3DS emulator has a bug that causes register changes from gdb to be discarded. Still, if I can figure out how to fix that bug, it would be nice to be able to make those changes from Ghidra.

[d-millar]

One thing to try: from the Model View, open the tree until you get to the current frame, right click on the frame (not the Registers node, if I remember correctly), and see if there’s a write_register option.

[viocar]

I've tried right-clicking just about everything in here, but I can't get a write_register option to show up. Additionally, the registers don't read out correctly in the Model View (the endianness is wrong):

[nsadeveloper789]

We recently fixed an issue with writing registers, particularly with gdb, from the Registers and Watches views. Those changes should be available in the master branch. Otherwise, you'll need to wait for the next release. Editing register values from the Model view is not currently supported, but it's something we're looking at.