Debugging an x86_64 executable on an arm64 M2 mac

[viktorb1]

Is it possible to debug an executable that is written in x86_64 on an arm64 M2 mac? If so, would you need to install the x86_64 jdk along with all the x86_64 dynamic libraries and basically set up x86_64 Ghidra to make it work? Currently, I have arm64 jdk installed and I ran buildNatives which likely installed all the arm64 binaries. However, when I try launching the program in the debugger using the "LLDB via GADP" option, I get a timeout with a "error: SBTarget is invalid". I suppose this is caused by incompatible architectures, although I am not sure because I am new to this. Any advice would be greatly appreciated!

[d-millar]

I think the instructions in Issue #6095 should fix this problem. That said, if it doesn't, let us know. The lldb executable usually has packaged versions for arm64 and x86_64. I believe it'll choose the correct one based on the target (but I could be wrong about that). If it doesn't, you'll probably end of debugging Rosetta, which, I'm sure, will not be a pleasant experience.

Side note: any particular reason you're using the GADP variant? If both Ghidra and the target are local, I would recommend using the "IN-VM" version, just because it's easier to debug (and faster) than the GADP version.

[viktorb1]

Screen.Recording.2024-01-09.at.4.40.53.PM.mov

I feel like I'm getting closer, but I'm still not sure what I'm doing wrong. Running a sample executable works fine in lldb, but running it in the Ghidra debugger gives some strange output.

[d-millar]

Any chance your process ended? The greyed-out entries in the Objects tree suggest it terminated. Am guessing the Disassembly error is related.

[viktorb1]

Why would the process end if the code as shown has a scanf() function waiting for user input? I thought you should be able to interact with the program and provide user input as you can when you run the program in lldb. Is that not the case?

[d-millar]

Right, reasonable expectation, but bear in mind there's essentially one terminal, and sharing that between the debugger and the target is a little tricky. The easiest solution is to start the target, so it has it's own terminal, and then attach. That said, that solution doesn't allow you to debug the startup sequence. There are workarounds involving writing a stub to host your target. The debugger course, included with the distro, has an example. If you need this immediately, I would try adapting anyptrace.c. On OSX, you'll have to replace the "prctl" logic with the mac equivalent.

This is a problem we're very aware of and actively working on solutions for.

[viktorb1]

By debugger guide, do you mean this? https://github.com/NationalSecurityAgency/ghidra/blob/master/GhidraDocs/GhidraClass/Debugger/A1-GettingStarted.md

I did not know it existed. I'll have to read it, hopefully it covers how to attach to an existing terminal. Thank you for all your help!

[d-millar]

Yep, all the docs in that dir are related to the debugger and give a good bit more detail than the F1 Help pages. Keep us posted if you hit more issues.

[viktorb1]

Hey @d-millar, I was following along with the debugger tutorial and I'm a little bit stuck on A3 - Importing libc. The error I get is The module /usr/lib/dyld was not found in the project. I researched this and it seems like dyld is an executable file that is responsible for loading dynamic libraries such as libc, so I'm not sure why it is stuck on this. I also notice that the file /usr/lib/dyld exists on my computer and if I try selecting it and processing it using the button in the actions column, nothing happens and the error remains. Any ideas why this might be happening?

I believe this error is preventing me from seeing the "The module /lib64/libc.so.6 was not found in the project" error that the tutorial talks about.

[d-millar]

@viktorb1 Sadly, I am on the road without a computer. Am going to let @nsadeveloper789 take this one, as he’s the expert on the course.

[nsadeveloper789]

I'll admit, I've not tried the tutorial on macOS. While I knew we'd need some work to "port" it to Windows, I assumed little/no effort would be needed to "port" it to macOS. I don't know off the top of my head how Apple arranges its C runtime, though.

A guess as to why the /usr/lib/dyld error remains: It's possible it's a symlink, and so the name of the import doesn't match what lldb/Ghidra thinks is the module name. This can usually be overcome by manually mapping. When you import, pay attention to the name Ghidra actually assigns the program database. Once the import is complete, ensure it's the active program. Then, from the Modules window, right click the dyld entry and select "Map to [name]" where [name] is the name of the new import.

I don't think this is what's preventing the libc.so.6 error, as that name is specific to Linux. Look through the top pane of the Modules window for anything that could be the C runtime. If you find it, double-click its base address in the table. This should cause the equivalent error message to appear, and you can import/map as directed in the tutorial.

Note it's possible the toolchain static links the C runtime, so it may not have a module entry. If that's the case, this particular part of the tutorial will not apply. Instead, you'll need to find where in your executable the C runtime was placed. If it's applying some global optimizations, the linker might only include the subset of functions actually used by the executable. On the up side, those static-linked routines will already be mapped to the executable's Ghidra program database.