Can't build swig bindings for lldb #6628
Comments
|
@heartpunk Am happy to provide more detailed instructions for building using SWIG, but we’re really really really recommending you use the newer and much much easier to install version of the debugger based on traceRMI and a Python3 interface. Is there a reason you’re opting for the older JNI interface? |
|
Nope, wasn't aware of that option. Which is it??? The frida thing? |
|
Tried what I found here more or less, and ended up with this in the terminal. Not sure if this is what you were referring to in your last comment though. |
|
@heartpunk Yes and no. The class has been re-written and should be helpful, but I think I would begin with the help section for the debugger. A couple of things that might help get you started. The tl;dr version: the Targets plugin has been replaced by the Connections plugin, and the Objects plugin has been replaced by the Model plugin. The new versions are very similar to the old ones on the surface, so you shouldn’t need too much info to get you going with them. If both the old and new plugins are installed, you will see two “bug” buttons on the Toolbar. I would recommend removing the old plugins just to eliminate any possible confusion. If you end up hating the new stuff, putting back the old plugins is easy enough. The other thing you want to check is that your default version of python3 is the same python compiled into lldb. To get the version in lldb, start up lldb, enter “script import sys”, and then “script sys.version”. It’s possible (although unlikely) lldb was compiled without python. If so, let us know - can be fixed, but probably requires more details. If the default version of python is a match, you’ll want to make sure Google protobuf and psutil are installed. I usually use “python3 -m pip install google” and “python3 -m pip install psutil”. All of this is one-time work. If you’re not a python person (I’m not), it can be a bit confusing, but once it’s done it’s done. From that point on, debugging should only involve loading a program into the debugger listing, configuring lldb via the dialog, and thereafter hitting the bug. (The dialog will want the full path to lldb if it’s not the path, same for the executable, and the start command you prefer, i.e. do you want to break on start.) Am quite sure I’ve left stuff out, but am available for questions as you go. We appreciate your trying out the new versions - ultimately, we’re hoping it makes your experience with the debugger better. |
|
I'm new to ghidra! I tried all you said as best I could manage, but still the same error. I even modified the |
|
Excellent - welcome to Ghidra! Are you up for a troubleshooting exercise? If it's any encouragement, you're are literally the first issue posted on the new debugger, so anything you share here will help a lot of folks. If you are, what I would try first: (1) Open up a terminal and run "lldb". If not, let us know the version of lldb you're running ("lldb --version") , the version of python ("python --version"), and the version of python in lldb ("lldb" -> "script import sys" -> "script sys.version". If it did succeed, then we need to figure out whether the launch script is somehow mis-computing it. The launch script lives in "/Users/xxx/path_to/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/data/debugger-launchers/local-lldb.sh". You can modify it fairly easily. I would suggest adding the line "echo $PYTHONPATH" around line 48. If it doesn't agree with the path you used above (or if you don't see the echo in the Terminal window), we have some more work to do. |
|
Alright, I'm following along with that. Did a fair bit of investigation just now and this is almost certainly an issue with pyenv (though it didn't go away when I tried to hack that outta the equation; I haven't tried a more proper try w/o it yet). Going to keep poking around w/it and modifying the launch script you mentioned and report back a bit later! |
Ok I had misunderstood, but have followed your instructions for the case where importing ghidratrace doesn't work (it didn't in any case I tried). It seems that script isn't being invoked at all, based on having modified it to print like you said, and seeing nothing printed anywhere. Now, I'm also noticing my ghidra lives in |
|
(Oh, oh, I see. The |
|
OK, so that helps. The first thing I would check - make sure you installed 'psutil' and 'google' in the correct version of python, i.e. as opposed to what I said before, use "python3 -m pip install psutil" and "python3 -m pip install google". If that's actually the problem, there's probably on error at the top of the Debug Console window to that effect. If it's not egregiously long, maybe send us the Debug Console contents? Often we see things that tip us off to the real error. (Obviously, sanitize anything you're worried about out.) Quite possible that the PYTHONPATH logic is actually working as designed but an early failure is masking the issue. |
|
Re "how lldb invocations know to look for such a launch script at all " (just read that bit), not magic at all as we're invoking lldb, not the other way around. In other words, when you select "lldb" from the bug pull-down, we run local-lldb.sh. The comment tags at the top of the shell command are used to populate the dialog (ok, that part is a little bit magical) and set various variables used by the script and eventually by the python code. The shell sets the PYTHONPATH variable and then runs lldb (line 67), passing in the commands that set-up the target and importing the ghidra logic. I am surprised you are not seeing your "echo" edits. Suggests either an issue with having multiple versions or a failure very early in the shell script. Maybe put one in very early, say before the "export" logic? |
ok so it was showing the edits i made, i had misunderstood that you meant to go and run lldb in ghidra, not on the terminal. i double checked the packages are installed in the correct python |
|
OK, just trying to figure out where we are now.... The example in your last post is from lldb run from a terminal, correct? I would not expect "ghidra trace connect" to work from there, if so, because the python import does not create the corresponding ghidra commands for lldb. This is definitey confusing will agree, but you should be able to execute "script ghidra_trace_connect('127.0.0.1:53664')" after "script import ghidralldb". The fact that these names are matched and thus almost the same probably will throw people off - hadn't considered this. In general, though, this is not what you want to be doing. You really want to be executing from the Ghidra terminal - better still, you want to rely on the debugger executing all those commands for you automatically. Does the command above fail in the Ghidra Terminal launched after you hit the bug? or are you not getting that far? |
|
This is the output after I click checks notes Debugger -> Configure and Launch ... -> lldb I didn't execute those manually! It is the output in the ghidra terminal though, yes. |
|
as for the differently named command, here's how that went when I gave it a try |
|
OK, hmmmm - that’s too bad. If you scroll up in the Terminal window, what are the first things you see? |
is all of it |
|
Double hmmmm - ok, anm away from my computer right now, but, when I get back, will do the same, and see if I can spot any differences. I do apologize - I thought this would be much simpler and certainly expected it to be easier to troubleshoot. I really appreciated your patience. |
|
Wow, ok, so I ran the debugger on a copy of the decompiler included with Ghidra, which I'm guaranteed to have debug access to. It lives at ghidra_11.1_PUBLIC/Ghidra/Features/Decompiler/os/mac_arm_64/decompile. I used the following options: I will play around with this some more tonight and drag in the big guns tomorrow. I am definitely not seeing/thinking of something, because it really seems like you did all the right things. |
|
Oh, and I goofed in my comments regarding ghidra_trace_connect. You'd need to do something like "script from ghidralldb.commands import *" first for it to work and even then it need a bunch of parameters. |
|
One more possible experiment you could do if you are so inclined. Run Ghidra using ghidra_11.1_PUBLIC/support/ghidraDebug instead of ghidraRun and make note of any lines that say ERROR in the launching console. Mine looks like: |
|
just tried again w/confirming those options, and fyi the results of doing so are included in the above terminal dump, which is from the ghidra terminal run w/ |
|
OK, thanks! Although, sadly, not a single clue there. You're using jdk 22 vice my 21. I may download and try that, but that seems very unlikely. Let me cogitate a bit more. More as I know more - you may be the topic of tomorrow's team meeting. :) |
|
Thanks for all the help!!! Hope the meeting proves fruitful. |
|
OK, our best guess so far is that the commands.py file somehow got corrupted. I've seen file corruption on download before, so this is a maybe although I still think a stretch. commands.py lives in ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src/ghidralldb. The contents of that directory should look like: -rwxr-xr-x@ 1 llero staff 614 Jun 7 14:32 init.py and the dir above it: drwxr-xr-x@ 9 llero staff 288 Jun 12 09:58 ghidralldb Another possible sanity check, from the Terminal after the connect attempt, try: 
|
|
hard to type too much to explain what's going on but i believe the solution is explained between these two pastes. I'm pretty sure ghidra won't look in the local home directory for package installs, but system python isn't writable by default in osx! from my terminal, before ghidra interaction from ghidra terminal same terminal session as before resumed after ghidra after checking, even sudo won't resolve this so i think we're making progress at least??? |
yea that seems sensible |
|
Maybe another sanity check: /usr/bin/python3 -m pip -V |
|
|
Hmmm, mine is: pip 21.2.4 from /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/site-packages/pip (python 3.9) but I feel like that should only matter if there's a permissions issue. |
|
OK, @nsadeveloper789 is suggesting "/usr/bin/python3 -m pip install protobuf=3.20.3" (vs. google) and then verifying with "from google import protobuf". |
|
|
OK, wow - that might have worked. (I'm going to have to get him to explain the difference to me.) Maybe try Ghidra now? |
|
Seems to be working??? I've never seen it that way before so I can't be entirely sure, but this seems like it might be a debugger waiting for me to play with it! I'd screenshot but no easy way to redact. |
|
I'll keep poking at it and if it does seem to actually be working still, I'll close this a bit later! |
|
|
Yep re redaction. At this point, I'd see if you can repeat the tutorial results. Possibly before tackling your own target. |
|
Ahh, good idea. I'll do that. The above paste is from my target. |
|
(Ahh, come to think of it, the above is almost certainly just SIP being on still.) |
|
AHHH, that looks great! The permissions thing is standard Apple security stuff. Basically, lldb has to have debugging permissions (which it should unless you built it from scratch) and the target has to have "allow debugging". |
|
Yes, re SIP - although if I remember correctly, you can enable per-target debugger with SIP still enabled. Will do some googling. |
|
Oh if you find a pointer for that it'd be great. I'd prefer to not disable SIP unless necessary! |
|
OK, took me a while but.... Copy your target somewhere not in a system/system-related directory. If it's a package, you may want to extract the arm64 or x64 executable from it. Make sure the copy is still executable. Then "codesign -s lldb_codesign -f target" (where lldb_codesign is a certificate I'd already made with debug permissions - details here https://stackoverflow.com/questions/58356844/what-are-the-ways-or-technologies-to-sign-an-executable-application-file-in-mac ). Should (fingers-crossed) be debuggable then. |
|
This is probably starting to get into a new issue ... oh right I forgot to do the test targets first but, since I've got the info anyway I'll share it! It seems like the program is partly launching to debug but partly not? Unclear! The ghidra terminal output for completness' sake: |
|
(the codesign thing worked! wouldn't be here w/o it.) |
|
OK, so looks like your process terminated - did you use the "process launch --stop-at-entry" option? |
|
It seems to quite self evidently be working now!!! This looks just like a debugger should. |
|
It does die as soon as I resume it though, huh. |
|
hmmm, well, first thing I woould check - does it behave that way in lldb w/o Ghidra or jusst in Ghidra? If just in Ghidra, one of two (?) things is happening. Either something went wrong in the Ghidra logic (possible) or we haven't registered a break for some exception that lldb has. It's been a while since I've looked at the lldb commands for handling execptions and events. I thought we default to break for most of them, but would have to check. All of that would also have to be handled through the command-line. Am sure we don't have GUI elements for those yet. If Ghidra went south, there should be errors in either the Debug Console in the GUI or the ghidraDebug shell if you're using it. If lldb's behavior is the same, you either need to set up the exception handling or some set of breakpoints. Also, could be that the target has detected the debugger and is punting (if it's that kind of app). |
|
"Use breakpoint set -E c++ to break on all exceptions and breakpoint set -F std::range_error to break on a specific exception." from stackoverflow |
|
Giving this a try now! |
|
two things:
|
|
Regarding the missing mapping, there could be a lot of reasons for that. Basically, the error means there's a mismatch between the name known to the OS while executing and the name of the program in Ghidra. Could be because the program was renamed after it was compiled. Could have been renamed on import. Could have been renamed in Ghidra after it was imported. In all of these cases, you can open the Modules window, find the module that is a match, and right-click to "Map Module to....", which will bring up a dialog. Select the entry in there, hit OK, and that association will be memoized, allowing the debugger to translate between dynamic and static addresses. On the second point, I thought we solved that, no? Or are you running lldb from the command line? I can't quite tell from your post. In any case, you have to make sure that either the PYTHONPATH environment variable contains the paths to pypkg/src in Debugger-rmi-trace and Debugger-agent-lldb, or you have to install those packages in lldb's version of python using "python -m pip install" or the equivalent. |
d-millar
added
Status: Waiting on customer
|
I had a similar issue where |
Tried following the instructions, tried everything could find in all the relevant issues reported here. Retried again in a fresh install, here's a transcript of what happened. Please help!!!
The text was updated successfully, but these errors were encountered: