NationalSecurityAgency / ghidra

Ghidra is a software reverse engineering (SRE) framework
https://www.nsa.gov/ghidra
Apache License 2.0
49.06k stars 5.65k forks source link

Can't build swig bindings for lldb #6628

Open heartpunk opened 2 weeks ago

heartpunk commented 2 weeks ago

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!!!

heartpunk@REDACTED-MacBook-Pro ghidra_11.1_PUBLIC % LLVM_HOME=/Users/heartpunk/llvm-project GHIDRA_INSTALL_DIR=`pwd` ./Ghidra/Debug/Debugger-swig-lldb/macos_debugger_lldb_build_from_brew.sh --verbose --debug
+ '[' -z /Users/heartpunk/ghidra_11.1_PUBLIC ']'
+ '[' '!' -z /Users/heartpunk/ghidra_11.1_PUBLIC ']'
+ pushd /Users/heartpunk/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-swig-lldb
~/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-swig-lldb ~/ghidra_11.1_PUBLIC
+ LLVM_VERSION=16
+ brew install llvm@16
Warning: llvm@16 16.0.6_1 is already installed and up-to-date.
To reinstall 16.0.6_1, run:
  brew reinstall llvm@16
++ mktemp -d
+ LLVM_TEMP_DIR=/var/folders/sc/zl1g6ny95zj9lv5zvn7s7dm40000gn/T/tmp.ASCr9z4B3R
+ brew unpack --patch --destdir /var/folders/sc/zl1g6ny95zj9lv5zvn7s7dm40000gn/T/tmp.ASCr9z4B3R llvm@16
==> Unpacking llvm@16 to: /var/folders/sc/zl1g6ny95zj9lv5zvn7s7dm40000gn/T/tmp.ASCr9z4B3R/llvm@16-16.0.6
==> Downloading https://github.com/llvm/llvm-project/releases/download/llvmorg-16.0.6/llvm-project-16.0.6.src.tar.xz
Already downloaded: /Users/heartpunk/Library/Caches/Homebrew/downloads/8cbb1836057b964f8f1bea2eee120bd27a78aa698ba2d5263996f3071234b47e--llvm-project-16.0.6.src.tar.xz
++ echo /var/folders/sc/zl1g6ny95zj9lv5zvn7s7dm40000gn/T/tmp.ASCr9z4B3R/llvm@16-16.0.6
+ export LLVM_HOME=/var/folders/sc/zl1g6ny95zj9lv5zvn7s7dm40000gn/T/tmp.ASCr9z4B3R/llvm@16-16.0.6
+ LLVM_HOME=/var/folders/sc/zl1g6ny95zj9lv5zvn7s7dm40000gn/T/tmp.ASCr9z4B3R/llvm@16-16.0.6
+ '[' '!' -d /var/folders/sc/zl1g6ny95zj9lv5zvn7s7dm40000gn/T/tmp.ASCr9z4B3R/llvm@16-16.0.6 ']'
++ brew --prefix llvm@16
+ BREW_LLVM=/opt/homebrew/opt/llvm@16
+ export 'LDFLAGS=-L/opt/homebrew/opt/llvm@16/lib/c++ -Wl,-rpath,/opt/homebrew/opt/llvm@16/lib/c++,-L/opt/homebrew/opt/llvm@16/lib'
+ LDFLAGS='-L/opt/homebrew/opt/llvm@16/lib/c++ -Wl,-rpath,/opt/homebrew/opt/llvm@16/lib/c++,-L/opt/homebrew/opt/llvm@16/lib'
+ export 'PATH=/opt/homebrew/opt/llvm@16/bin:/Users/heartpunk/llvm-bin:/Users/heartpunk/.rvm/gems/ruby-3.1.2/bin:/Users/heartpunk/.rvm/gems/ruby-3.1.2@global/bin:/Users/heartpunk/.rvm/rubies/ruby-3.1.2/bin:/Users/heartpunk/.local/bin:/Users/heartpunk/.cabal/bin:/Users/heartpunk/.ghcup/bin:/Users/heartpunk/.nvm/versions/node/v18.13.0/bin:/Users/heartpunk/.pyenv/shims:/opt/homebrew/opt/python@3.10/bin:/opt/homebrew/opt/ruby/bin:/opt/homebrew/lib/ruby/gems/3.1.0/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin:/Applications/Wireshark.app/Contents/MacOS:/Applications/VMware Fusion Tech Preview.app/Contents/Public:/usr/local/go/bin:/Users/heartpunk/.cargo/bin:/Applications/iTerm.app/Contents/Resources/utilities:/Users/heartpunk/.local/bin:/Users/heartpunk/.rvm/bin:/Users/heartpunk/go/bin:/Users/heartpunk/.dirtybin/'
+ PATH='/opt/homebrew/opt/llvm@16/bin:/Users/heartpunk/llvm-bin:/Users/heartpunk/.rvm/gems/ruby-3.1.2/bin:/Users/heartpunk/.rvm/gems/ruby-3.1.2@global/bin:/Users/heartpunk/.rvm/rubies/ruby-3.1.2/bin:/Users/heartpunk/.local/bin:/Users/heartpunk/.cabal/bin:/Users/heartpunk/.ghcup/bin:/Users/heartpunk/.nvm/versions/node/v18.13.0/bin:/Users/heartpunk/.pyenv/shims:/opt/homebrew/opt/python@3.10/bin:/opt/homebrew/opt/ruby/bin:/opt/homebrew/lib/ruby/gems/3.1.0/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin:/Applications/Wireshark.app/Contents/MacOS:/Applications/VMware Fusion Tech Preview.app/Contents/Public:/usr/local/go/bin:/Users/heartpunk/.cargo/bin:/Applications/iTerm.app/Contents/Resources/utilities:/Users/heartpunk/.local/bin:/Users/heartpunk/.rvm/bin:/Users/heartpunk/go/bin:/Users/heartpunk/.dirtybin/'
+ export CPPFLAGS=-I/opt/homebrew/opt/llvm@16/include
+ CPPFLAGS=-I/opt/homebrew/opt/llvm@16/include
++ echo /opt/homebrew/opt/llvm@16
+ export LLVM_BUILD=/opt/homebrew/opt/llvm@16
+ LLVM_BUILD=/opt/homebrew/opt/llvm@16
+ gradle buildNatives

> Configure project :Debugger-swig-lldb
OS: Mac OS X
Arch: aarch64
Using platform: mac_arm_64

> Configure project :Decompiler
OS: Mac OS X
Arch: aarch64
Using platform: mac_arm_64

> Configure project :FileFormats
OS: Mac OS X
Arch: aarch64
Using platform: mac_arm_64

> Configure project :PDB
OS: Mac OS X
Arch: aarch64
Using platform: mac_arm_64

> Task :Debugger-swig-lldb:compileMainMac_arm_64SharedLibraryMainCpp FAILED
/Users/heartpunk/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-swig-lldb/src/main/cpp/LLDBWrapJava.cpp:317:10: fatal error: 'lldb/API/SBScriptObject.h' file not found
#include "lldb/API/SBScriptObject.h"
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':Debugger-swig-lldb:compileMainMac_arm_64SharedLibraryMainCpp'.
> A build operation failed.
      C++ compiler failed while compiling LLDBWrapJava.cpp.
  See the complete log at: file:///Users/heartpunk/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-swig-lldb/build/tmp/compileMainMac_arm_64SharedLibraryMainCpp/output.txt
   > C++ compiler failed while compiling LLDBWrapJava.cpp.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

BUILD FAILED in 1s
2 actionable tasks: 2 executed
<-------------> 0% WAITING
> IDLE
heartpunk@REDACTED-MacBook-Pro ghidra_11.1_PUBLIC % system_profiler SPSoftwareDataType
Software:

    System Software Overview:

      System Version: macOS 14.5 (23F79)
      Kernel Version: Darwin 23.5.0
      Boot Volume: Macintosh HD
      Boot Mode: Normal
      Computer Name: REDACTED's MacBook Pro
      User Name: REDACTED (heartpunk)
      Secure Virtual Memory: Enabled
      System Integrity Protection: Enabled
      Time since boot: 3 days, 6 hours, 55 minutes

heartpunk@REDACTED ghidra_11.1_PUBLIC %
d-millar commented 2 weeks ago

@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?

heartpunk commented 2 weeks ago

Nope, wasn't aware of that option. Which is it??? The frida thing?

heartpunk commented 2 weeks ago

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.

(lldb) ghidra trace connect "127.0.0.1:57675"
error: 'ghidra' is not a valid command.
d-millar commented 2 weeks ago

@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.
First, if you were using the debugger in the past, you’ll need to reconfigure the tool to expose two new plugins. The easiest way to do this is to simply import a new Debugger tool from the Default Tools chest. Alternatively, you can reconfigure it by hand using the Configure dialog.

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.

heartpunk commented 2 weeks ago

I'm new to ghidra! I tried all you said as best I could manage, but still the same error. I even modified the ghidraRun script to check which python is in scope right before it invokes ghidra!!!

d-millar commented 2 weeks ago

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". (2) Inside lldb, issue the command "script import ghidratrace". This should fail with a "ModuleNotFoundError: no module named 'ghidratrace'. (3) Exit lldb. In the same terminal, issue the command "export PYTHONPATH=/Users/xxx/path_to/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-rmi-trace/pypkg/src;/Users/xxx/path_to/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src". (4) Now run "lldb" and "script import ghidratrace". It should succeed this time.

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.

heartpunk commented 2 weeks ago

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!

heartpunk commented 2 weeks ago
heartpunk@REDACTED ~ % lldb --version
lldb-1500.0.404.7
Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4)
heartpunk@REDACTED ~ % python --version
Python 3.12.3
heartpunk@REDACTED ~ % python3 --version
Python 3.9.6
heartpunk@REDACTED ~ % lldb
(lldb) script import sys
(lldb) script sys.version
'3.9.6 (default, Mar 29 2024, 10:51:09) \n[Clang 15.0.0 (clang-1500.3.9.4)]'
(lldb)

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 /Applications (ok I actually have it at home too, but that's a different install ack) and wondering how lldb invocations know to look for such a launch script at all anyway??? Seems like magic to me.

heartpunk commented 2 weeks ago

(Oh, oh, I see. The PYTHONPATH setting is how it knows to make that module available.)

d-millar commented 2 weeks ago

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.

d-millar commented 2 weeks ago

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?

heartpunk commented 2 weeks ago
3.9.6 (default, Mar 29 2024, 10:51:09) 
[Clang 15.0.0 (clang-1500.3.9.4)]
3.11.0b5 (main, Aug 16 2022, 09:17:48) [Clang 13.1.6 (clang-1316.0.21.2.5)]
(lldb) version
lldb-1500.0.404.7
Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4)
(lldb) script import ghidralldb
(lldb) target create "REDACTED"
Current executable set to 'REDACTED' (arm64
(lldb) ghidra trace connect "127.0.0.1:53664"
error: 'ghidra' is not a valid command.
(lldb) 

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

d-millar commented 2 weeks ago

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?

heartpunk commented 2 weeks ago

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.

heartpunk commented 2 weeks ago

as for the differently named command, here's how that went when I gave it a try

error: 'ghidra' is not a valid command.
(lldb) script ghidra_trace_connect('127.0.0.1:53664')
Traceback (most recent call last):
  File "<input>", line 1, in <module>
NameError: name 'ghidra_trace_connect' is not defined
(lldb) 
d-millar commented 2 weeks ago

OK, hmmmm - that’s too bad. If you scroll up in the Terminal window, what are the first things you see?

heartpunk commented 2 weeks ago
/Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-rmi-trace/pypkg/src:/Applicat
ions/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src:
3.9.6 (default, Mar 29 2024, 10:51:09) 
[Clang 15.0.0 (clang-1500.3.9.4)]
3.11.0b5 (main, Aug 16 2022, 09:17:48) [Clang 13.1.6 (clang-1316.0.21.2.5)]
(lldb) version
lldb-1500.0.404.7
Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4)
(lldb) script import ghidralldb
(lldb) target create "REDACTED"
Current executable set to 'REDACTED' (arm64)
.
(lldb) ghidra trace connect "127.0.0.1:51384"
error: 'ghidra' is not a valid command.
(lldb) script ghidra_trace_connect('127.0.0.1:53664')
Traceback (most recent call last):
  File "<input>", line 1, in <module>
NameError: name 'ghidra_trace_connect' is not defined
(lldb) 

is all of it

d-millar commented 2 weeks ago

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.

d-millar commented 2 weeks ago

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:

Screenshot 2024-06-11 at 9 13 18 PM

Gave me a pop-up about being unable to check for malware, but then:

Screenshot 2024-06-11 at 9 16 53 PM

which looks a lot like your results except for the error.

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.

d-millar commented 2 weeks ago

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.

d-millar commented 2 weeks ago

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:

Screenshot 2024-06-11 at 9 27 41 PM
heartpunk commented 2 weeks ago
heartpunk@REDACTED ~ % /Applications/ghidra_11.1_PUBLIC/support/ghidraDebug ; exit;
Listening for transport dt_socket at address: 18001
openjdk version "22.0.1" 2024-04-16
OpenJDK Runtime Environment Homebrew (build 22.0.1)
OpenJDK 64-Bit Server VM Homebrew (build 22.0.1, mixed mode)
INFO  Using log config file: file:/Applications/ghidra_11.1_PUBLIC/support/debug.log4j.xml  (LoggingInitialization.java:50) 
INFO  Using log file: /Users/heartpunk/Library/ghidra/ghidra_11.1_PUBLIC/application.log  (LoggingInitialization.java:51) 
INFO  Loading user preferences: /Users/heartpunk/Library/ghidra/ghidra_11.1_PUBLIC/preferences  (Preferences.java:122) 
INFO  Loading previous preferences: /Users/heartpunk/.ghidra/.ghidra_11.0.3_PUBLIC/preferences  (Preferences.java:175) 
INFO  Searching for classes...  (ClassSearcher.java:411) 
INFO  Ignoring class 'ghidra.GhidraClassLoader' from '/Applications/ghidra_11.1_PUBLIC/Ghidra/Framework/Utility/lib/Utility.jar'. Already found at '/Applications/ghidra_11.1_PUBLIC/Ghidra/Framework/Utility/lib/Utility.jar'.  (ClassSearcher.java:454) 
INFO  Ignoring class 'generic.jar.GClassLoader' from '/Applications/ghidra_11.1_PUBLIC/Ghidra/Framework/Utility/lib/Utility.jar'. Already found at '/Applications/ghidra_11.1_PUBLIC/Ghidra/Framework/Utility/lib/Utility.jar'.  (ClassSearcher.java:454) 
INFO  Class search complete (1420 ms)  (ClassSearcher.java:137) 
INFO  Initializing SSL Context  (SSLContextInitializer.java:76) 
INFO  Initializing Random Number Generator...  (SecureRandomFactory.java:37) 
INFO  Random Number Generator initialization complete: NativePRNGNonBlocking  (SecureRandomFactory.java:41) 
INFO  Trust manager disabled, cacerts have not been set  (ApplicationTrustManagerFactory.java:95) 
INFO  User heartpunk started Ghidra.  (GhidraRun.java:75) 
INFO  User settings directory: /Users/heartpunk/Library/ghidra/ghidra_11.1_PUBLIC  (GhidraRun.java:76) 
INFO  User temp directory: /var/folders/sc/zl1g6ny95zj9lv5zvn7s7dm40000gn/T/heartpunk-ghidra  (GhidraRun.java:77) 
INFO  User cache directory: /var/tmp/heartpunk-ghidra  (GhidraRun.java:78) 
DEBUG Recovery snapshot timer set to 5 minute(s)  (RecoverySnapshotMgrPlugin.java:170) 
INFO  Opening project: /Users/heartpunk/REDACTED  (DefaultProject.java:115) 
INFO  Ghidra startup complete (4860 ms)  (GhidraRun.java:92) 
INFO  Packed database cache: /var/tmp/heartpunk-ghidra/packed-db-cache  (PackedDatabaseCache.java:64) 
DEBUG Using cached packed database: /Applications/ghidra_11.1_PUBLIC/Ghidra/Features/Base/data/typeinfo/mac_10.9/mac_osx.gdt  (PackedDatabaseCache.java:364) 
DEBUG New Pty: /dev/ttys012 at (183,184)  (UnixPty.java:48) 
INFO  local Pty session. PID = 70599  (LocalProcessPtySession.java:34)
heartpunk commented 2 weeks ago

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: Screenshot 2024-06-11 at 9 13 18 PM Gave me a pop-up about being unable to check for malware, but then: Screenshot 2024-06-11 at 9 16 53 PM which looks a lot like your results except for the error.

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.

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/ghidraDebug

d-millar commented 2 weeks ago

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. :)

heartpunk commented 2 weeks ago

Thanks for all the help!!! Hope the meeting proves fruitful.

d-millar commented 2 weeks ago

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. filesize: 68436 lines: 2031 sha256sum: fd9562b0436095a931c6b6abecfc7d971a02d4ff5b73d060af065723302a7f3a

The contents of that directory should look like:

-rwxr-xr-x@ 1 llero staff 614 Jun 7 14:32 init.py -rwxr-xr-x@ 1 llero staff 11832 Jun 7 14:32 arch.py -rwxr-xr-x 1 llero staff 68436 Jun 12 09:58 commands.py -rwxr-xr-x@ 1 llero staff 26249 Jun 7 14:32 hooks.py -rwxr-xr-x@ 1 llero staff 23088 Jun 7 14:32 methods.py -rwxr-xr-x@ 1 llero staff 14552 Jun 7 14:32 schema.xml -rwxr-xr-x@ 1 llero staff 7311 Jun 7 14:32 util.py

and the dir above it:

drwxr-xr-x@ 9 llero staff 288 Jun 12 09:58 ghidralldb drwxr-xr-x@ 7 llero staff 224 Jun 7 14:32 ghidralldb.egg-info

Another possible sanity check, from the Terminal after the connect attempt, try:

Screenshot 2024-06-12 at 10 09 18 AM
heartpunk commented 2 weeks ago

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

heartpunk@REDACTED ~ % sha256sum /Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src/ghidralldb/commands.py
fd9562b0436095a931c6b6abecfc7d971a02d4ff5b73d060af065723302a7f3a  /Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src/ghidralldb/commands.py
heartpunk@REDACTED ~ % ls /Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src/ghidralldb
__init__.py arch.py     commands.py hooks.py    methods.py  schema.xml  util.py
heartpunk@REDACTED ~ % ls l /Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src/ghidralldb
ls: l: No such file or directory
/Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src/ghidralldb:
__init__.py arch.py     commands.py hooks.py    methods.py  schema.xml  util.py
heartpunk@REDACTED ~ % ls -l /Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src/ghidralldb
total 320
-rwxr-xr-x@ 1 heartpunk  staff    614 Jun  7 14:32 __init__.py
-rwxr-xr-x@ 1 heartpunk  staff  11832 Jun  7 14:32 arch.py
-rwxr-xr-x@ 1 heartpunk  staff  68436 Jun  7 14:32 commands.py
-rwxr-xr-x@ 1 heartpunk  staff  26249 Jun  7 14:32 hooks.py
-rwxr-xr-x@ 1 heartpunk  staff  23088 Jun  7 14:32 methods.py
-rwxr-xr-x@ 1 heartpunk  staff  14552 Jun  7 14:32 schema.xml
-rwxr-xr-x@ 1 heartpunk  staff   7311 Jun  7 14:32 util.py
heartpunk@REDACTED ~ % wc -l /Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src/ghidralldb/*
      16 /Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src/ghidralldb/__init__.py
     336 /Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src/ghidralldb/arch.py
    2031 /Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src/ghidralldb/commands.py
     714 /Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src/ghidralldb/hooks.py
     684 /Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src/ghidralldb/methods.py
     304 /Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src/ghidralldb/schema.xml
     258 /Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src/ghidralldb/util.py
    4343 total

from ghidra terminal

/Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-rmi-trace/pypkg/src:/Applica
tions/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src:
3.9.6 (default, Mar 29 2024, 10:51:09) 
[Clang 15.0.0 (clang-1500.3.9.4)]
3.11.0b5 (main, Aug 16 2022, 09:17:48) [Clang 13.1.6 (clang-1316.0.21.2.5)]
(lldb) version
lldb-1500.0.404.7
Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4)
(lldb) script import ghidralldb
(lldb) target create "REDACTED"
Current executable set to 'REDACTED' (arm64
).
(lldb) ghidra trace connect "127.0.0.1:61646"
error: 'ghidra' is not a valid command.
(lldb) dir(ghidralldb)
error: 'dir' is not a valid command.
(lldb) import ghidralldb
error: 'import' is not a valid command.
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> import ghidralldb
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src
/ghidralldb/__init__.py", line 16, in <module>
    from . import util, commands
  File "/Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-agent-lldb/pypkg/src
/ghidralldb/commands.py", line 29, in <module>
    from ghidratrace.client import Client, Address, AddressRange, TraceObject
  File "/Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-rmi-trace/pypkg/src/
ghidratrace/client.py", line 27, in <module>
    from . import trace_rmi_pb2 as bufs
  File "/Applications/ghidra_11.1_PUBLIC/Ghidra/Debug/Debugger-rmi-trace/pypkg/src/
ghidratrace/trace_rmi_pb2.py", line 5, in <module>
    from google.protobuf.internal import builder as _builder
ModuleNotFoundError: No module named 'google'
>>> import sys.executable
Traceback (most recent call last):
  File "<console>", line 1, in <module>
ModuleNotFoundError: No module named 'sys.executable'; 'sys' is not a package
>>> import sys
>>> print(sys.executable)
/Applications/Xcode.app/Contents/Developer/usr/bin/lldb
>>> print(sys.version)
3.9.6 (default, Mar 29 2024, 10:51:09) 
[Clang 15.0.0 (clang-1500.3.9.4)]

same terminal session as before resumed after ghidra

heartpunk@REDACTED ~ % python3 --version
Python 3.12.3
heartpunk@REDACTED ~ % /usr/bin/python3 --version
Python 3.9.6
heartpunk@REDACTED ~ % /usr/bin/python3 -m pip install psutil
Defaulting to user installation because normal site-packages is not writeable
Requirement already satisfied: psutil in ./Library/Python/3.9/lib/python/site-packages (5.9.6)
WARNING: You are using pip version 21.2.4; however, version 24.0 is available.
You should consider upgrading via the '/Applications/Xcode.app/Contents/Developer/usr/bin/python3 -m pip install --upgrade pip' command.
heartpunk@REDACTED ~ % /usr/bin/python3 -m pip install google
Defaulting to user installation because normal site-packages is not writeable
Requirement already satisfied: google in ./Library/Python/3.9/lib/python/site-packages (3.0.0)
Requirement already satisfied: beautifulsoup4 in ./Library/Python/3.9/lib/python/site-packages (from google) (4.12.3)
Requirement already satisfied: soupsieve>1.2 in ./Library/Python/3.9/lib/python/site-packages (from beautifulsoup4->google) (2.5)
WARNING: You are using pip version 21.2.4; however, version 24.0 is available.
You should consider upgrading via the '/Applications/Xcode.app/Contents/Developer/usr/bin/python3 -m pip install --upgrade pip' command.

after checking, even sudo won't resolve this

so i think we're making progress at least???

d-millar commented 2 weeks ago

Hmmm, you shouldn't have to sudo (and in my (very limited) experience sudo'ing with python is fraught with peril). I get the "Defaulting to user..." messages all the time without ill effect (other than annoyance at the messages).

In your second pane, could you try "dir(ghidralldb)" and "dir(ghidralldb.commands)" after "script" and "import ghidralldb"? You need to be in the scripting shell for those to mean anything.

d-millar commented 2 weeks ago

And, yes, on progress - I think!

heartpunk commented 2 weeks ago

I did the import again after entering script in the paste above!

heartpunk commented 2 weeks ago

Said import failed w/a traceback around the google module not being available, hence checking the python version and packages again.

heartpunk commented 2 weeks ago
heartpunk@REDACTED ~ % /usr/bin/python3 -m pip install google
Defaulting to user installation because normal site-packages is not writeable
Requirement already satisfied: google in /Library/Python/3.9/site-packages (3.0.0)
Requirement already satisfied: beautifulsoup4 in ./Library/Python/3.9/lib/python/site-packages (from google) (4.12.3)
Requirement already satisfied: soupsieve>1.2 in ./Library/Python/3.9/lib/python/site-packages (from beautifulsoup4->google) (2.5)
WARNING: You are using pip version 21.2.4; however, version 24.0 is available.
You should consider upgrading via the '/Applications/Xcode.app/Contents/Developer/usr/bin/python3 -m pip install --upgrade pip' command.
heartpunk@REDACTED ~ % /usr/bin/python3
Python 3.9.6 (default, Mar 29 2024, 10:51:09)
[Clang 15.0.0 (clang-1500.3.9.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import google
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'google'

from regular terminal

d-millar commented 2 weeks ago

I think that's ok - try "import protobuf", which is what we're using in the google package.

d-millar commented 2 weeks ago

Hmmm, I could be wrong about that. Try: lldb (lldb) script

import google

heartpunk commented 2 weeks ago
heartpunk@REDACTED ~ % /usr/bin/python3
Python 3.9.6 (default, Mar 29 2024, 10:51:09)
[Clang 15.0.0 (clang-1500.3.9.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import protobuf
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'protobuf'
>>> ^D
heartpunk@REDACTED ~ % lldb
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> import google
Traceback (most recent call last):
  File "<console>", line 1, in <module>
ModuleNotFoundError: No module named 'google'
>>> import protobuf
Traceback (most recent call last):
  File "<console>", line 1, in <module>
ModuleNotFoundError: No module named 'protobuf'
d-millar commented 2 weeks ago

OK, I think I am seeing your point above.

On my box, I have write permissions to ~/Library/Python/3.9/lib/site-packages. Do you?

d-millar commented 2 weeks ago

Sorry - lib/python/site-packages. And in it I have:

drwxr-xr-x 3 llero staff 96 Mar 5 10:57 google -rw-r--r-- 1 llero staff 539 Mar 5 10:57 protobuf-3.20.0-nspkg.pth drwxr-xr-x 10 llero staff 320 Mar 5 10:57 protobuf-3.20.0.dist-info

heartpunk commented 2 weeks ago
heartpunk@REDACTED ~ % ls -l ~/Library/Python/3.9/lib/python
total 0
drwx------  224 heartpunk  staff  7168 Jun 12 09:04 site-packages
heartpunk@REDACTED ~ % ls -l ~/Library/Python/3.9/lib/python/site-packages | egrep google\|protobuf
sophiesmithburg@Sophies-MacBook-Pro ~ %
d-millar commented 2 weeks ago

Any chance any of the parent dirs have less then full permissions for you?

d-millar commented 2 weeks ago

Am stuck on this post you made:

heartpunk@REDACTED ~ % /usr/bin/python3 -m pip install google Defaulting to user installation because normal site-packages is not writeable Requirement already satisfied: google in /Library/Python/3.9/site-packages (3.0.0) Requirement already satisfied: beautifulsoup4 in ./Library/Python/3.9/lib/python/site-packages (from google) (4.12.3) Requirement already satisfied: soupsieve>1.2 in ./Library/Python/3.9/lib/python/site-packages (from beautifulsoup4->google) (2.5) WARNING: You are using pip version 21.2.4; however, version 24.0 is available. You should consider upgrading via the '/Applications/Xcode.app/Contents/Developer/usr/bin/python3 -m pip install --upgrade pip' command. heartpunk@REDACTED ~ % /usr/bin/python3 Python 3.9.6 (default, Mar 29 2024, 10:51:09) [Clang 15.0.0 (clang-1500.3.9.4)] on darwin Type "help", "copyright", "credits" or "license" for more information.

import google Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'google'

That seems like it's telling you that you can't "import" from the system site-packages. Do you read it that way?

heartpunk commented 2 weeks ago

Any chance any of the parent dirs have less then full permissions for you?

heartpunk@REDACTED ~ % touch ~/Library/Python/3.9/lib/python/site-packages/foo
heartpunk@REDACTED ~ % ls -l ~/Library/Python/3.9/lib/python/site-packages | egrep foo
-rw-r--r--    1 heartpunk  staff       0 Jun 12 09:48 foo

seems no

heartpunk commented 2 weeks ago

Am stuck on this post you made:

heartpunk@REDACTED ~ % /usr/bin/python3 -m pip install google Defaulting to user installation because normal site-packages is not writeable Requirement already satisfied: google in /Library/Python/3.9/site-packages (3.0.0) Requirement already satisfied: beautifulsoup4 in ./Library/Python/3.9/lib/python/site-packages (from google) (4.12.3) Requirement already satisfied: soupsieve>1.2 in ./Library/Python/3.9/lib/python/site-packages (from beautifulsoup4->google) (2.5) WARNING: You are using pip version 21.2.4; however, version 24.0 is available. You should consider upgrading via the '/Applications/Xcode.app/Contents/Developer/usr/bin/python3 -m pip install --upgrade pip' command. heartpunk@REDACTED ~ % /usr/bin/python3 Python 3.9.6 (default, Mar 29 2024, 10:51:09) [Clang 15.0.0 (clang-1500.3.9.4)] on darwin Type "help", "copyright", "credits" or "license" for more information.

import google Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'google'

That seems like it's telling you that you can't "import" from the system site-packages. Do you read it that way?

yea that seems sensible

d-millar commented 2 weeks ago

Maybe another sanity check: /usr/bin/python3 -m pip -V

heartpunk commented 2 weeks ago
heartpunk@REDACTED ~ % /usr/bin/python3 -m pip -V
pip 21.2.4 from /Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/site-packages/pip (python 3.9)
d-millar commented 2 weeks ago

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.

d-millar commented 2 weeks ago

OK, @nsadeveloper789 is suggesting "/usr/bin/python3 -m pip install protobuf=3.20.3" (vs. google) and then verifying with "from google import protobuf".

heartpunk commented 2 weeks ago
heartpunk@REDACTED ~ % /usr/bin/python3 -m pip install protobuf==3.20.3
Defaulting to user installation because normal site-packages is not writeable
Collecting protobuf==3.20.3
  Using cached protobuf-3.20.3-py2.py3-none-any.whl (162 kB)
Installing collected packages: protobuf
Successfully installed protobuf-3.20.3
WARNING: You are using pip version 21.2.4; however, version 24.0 is available.
You should consider upgrading via the '/Applications/Xcode.app/Contents/Developer/usr/bin/python3 -m pip install --upgrade pip' command.
heartpunk@REDACTED ~ % /usr/bin/python3
Python 3.9.6 (default, Mar 29 2024, 10:51:09)
[Clang 15.0.0 (clang-1500.3.9.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from google import protobuf
d-millar commented 2 weeks ago

OK, wow - that might have worked. (I'm going to have to get him to explain the difference to me.) Maybe try Ghidra now?

heartpunk commented 2 weeks ago

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.

heartpunk commented 2 weeks ago

I'll keep poking at it and if it does seem to actually be working still, I'll close this a bit later!