Ghidrathon icon indicating copy to clipboard operation
Ghidrathon copied to clipboard
verified publisher icon mandiant

Installing and running on Windows

Open rchildre3 opened this issue 3 years ago • 5 comments

First off, great work on the development and architecture of this plugin I'm looking forward to Ghidra + Python3 scripts!

I wanted to document my process on attempting to getting this plugin running:

Prerequisites notes

Python

Python 3.10 was installed through the Windows Store i.e. installed to: %LocalAppData%\Packages\PythonSoftwareFoundation.Python.3.10_...\ and therefore pip --user install jep installed to: %LocalAppData%\Packages\PythonSoftwareFoundation.Python.3.10_...\LocalCache\local-packages\Python310\site-packages\jep

Java

Eclipse Adoptium OpenJDK installed to: C:\Program Files\Eclipse Adoptium\jdk-11.0.16.101-hotspot with both bin\client\jvm.dll and bin\server\jvm.dll

Building

Build succeeded with a small deprecation warning, observable with this diff:

diff --git a/build.gradle b/build.gradle
index 618e1e7..0aa608b 100644
--- a/build.gradle
+++ b/build.gradle
@@ -53,6 +53,10 @@ tasks.matching { it.name != 'copyJepNativeBinaries' && it.name != 'installJep' }
     task.dependsOn copyJepNativeBinaries
 }
 
+tasks.withType(JavaCompile) {
+    options.deprecation = true
+}
+
 // from here we use the standard Gradle build provided by Ghidra framework
 
 //----------------------START "DO NOT MODIFY" SECTION------------------------------

See: #9

And the Jep binaries were correctly discovered and bundled with the Ghidra plugin under dist/

Installing

I get a Ghidra Exception on loading the plugin after a restart:

%USERPROFILE%\.ghidra\.ghidra_10.1.5_PUBLIC\Extensions\Ghidrathon\os\win_x86_64\jep.dll: Can't find dependent libraries
java.lang.UnsatisfiedLinkError: %USERPROFILE%\.ghidra\.ghidra_10.1.5_PUBLIC\Extensions\Ghidrathon\os\win_x86_64\jep.dll: Can't find dependent libraries

in investigating the jep.dll with ldd in git bash Thanks Windows

ldd ./.ghidra/.ghidra_10.1.5_PUBLIC/Extensions/Ghidrathon/os/win_x86_64/jep.dll
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffc5eea0000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffc5d3c0000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffc5c380000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ffc5ed90000)
        jep.dll => %USERPROFILE%/.ghidra/.ghidra_10.1.5_PUBLIC/Extensions/Ghidrathon/os/win_x86_64/jep.dll (0x7ffc50b60000)
        ucrtbase.dll => /c/Windows/System32/ucrtbase.dll (0x7ffc5cb70000)
        vcruntime140.dll => /c/Windows/System32/vcruntime140.dll (0x7ffc35bd0000)
        jvm.dll => not found
        python310.dll => not found
        api-ms-win-crt-heap-l1-1-0.dll => /c/Program Files/Eclipse Adoptium/jdk-11.0.16.101-hotspot/bin/api-ms-win-crt-heap-l1-1-0.dll (?)
        api-ms-win-crt-runtime-l1-1-0.dll => /c/Program Files/Eclipse Adoptium/jdk-11.0.16.101-hotspot/bin/api-ms-win-crt-runtime-l1-1-0.dll (?)
        api-ms-win-crt-stdio-l1-1-0.dll => /c/Program Files/Eclipse Adoptium/jdk-11.0.16.101-hotspot/bin/api-ms-win-crt-stdio-l1-1-0.dll (?)
        api-ms-win-crt-convert-l1-1-0.dll => /c/Program Files/Eclipse Adoptium/jdk-11.0.16.101-hotspot/bin/api-ms-win-crt-convert-l1-1-0.dll (?)
        api-ms-win-crt-string-l1-1-0.dll => /c/Program Files/Eclipse Adoptium/jdk-11.0.16.101-hotspot/bin/api-ms-win-crt-string-l1-1-0.dll (?)

There are two unreachable DLLs

  • jvm.dll could not be found out of the Eclipse Adoptium OpenJDK install directory (or maybe not able to disambiguate between the two?)
  • python310.dll seems to not be distributed with the windows store build (perhaps a static build?)

I understand that these are likely issues specific to Jep itself however I wanted to report general usability issues to either make more meaningful Ghidra error messages and to upstream these issues to Jep is called for.

Thanks again for the project!

Operating System: Windows 11 21H2 22000.856 Java Version: OpenJDK 11.0.16.1 Ghidra Version: 10.1.5 Gradle Version: 7.5.1 Python Version: 3.10.7 Jep Version: 4.0.3

rchildre3 avatar Sep 21 '22 16:09 rchildre3

Thank you for the report and helpful context @rchildre3 - we will do some digging here to see how we can improve usability. We will upstream the issue if it's Jep-specific.

mike-hunhoff avatar Oct 31 '22 18:10 mike-hunhoff

Encountered similar issue on Windows and here are the problems I noticed and my solutions for them:

  1. If we are running a virtual environment, or in any case any user environment is needed, we shall start Ghidra within that environment. However, the default ghidraRun.bat starts Ghidra as a background process:
call "%~dp0support\launch.bat" bg jdk Ghidra "%MAXMEM%" "" ghidra.GhidraRun %*

The arg bg here makes launch.bat start Ghidra with start command and /I which basically purges the environment (with only basic Cmd.exe environment pass to it):

if "%BACKGROUND%"=="y" (
	set JAVA_CMD=!JAVA_CMD!w
	start "%APPNAME%" /I /B "!JAVA_CMD!" %CMD_ARGS%
	...
) else (
	"%JAVA_CMD%" %CMD_ARGS%
)

This caused the DLL dependency issue on my side.

  1. In typical conda setup (Miniconda3 in my case), PYTHONHOME and PYTHONPATH is not set, and this lead to a crash with following error:
Python path configuration:
  PYTHONHOME = (not set)
  PYTHONPATH = (not set)
.
.
.
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

The solution in my case is:

  1. Change bg to fg in ghidraRun.bat.
  2. Set PYTHONPATH and PYTHONHOME to CONDA_PREFIX before starting Ghidra.

Here is a simple wrapper to start Ghidra:

setlocal

call <PATH_TO_YOUR_CONDA>\activate.bat <YOUR_VIRTUAL_ENV>
set PYTHONHOME=%CONDA_PREFIX%
set PYTHONPATH=%CONDA_PREFIX%
call <PATH_TO_YOUR_GHIDRA>\ghidraRun.bat

idl3r avatar Nov 21 '23 08:11 idl3r

在 Windows 上遇到了类似的问题，以下是我注意到的问题以及我的解决方案：

  1. 如果我们运行的是虚拟环境，或者在任何情况下都需要任何用户环境，我们将在该环境中启动 Ghidra。但是，默认情况下会将 Ghidra 作为后台进程启动：ghidraRun.bat
call "%~dp0support\launch.bat" bg jdk Ghidra "%MAXMEM%" "" ghidra.GhidraRun %*

这里的参数使 start Ghidra 使用命令，并且基本上清除环境（只有基本的 Cmd.exe 环境传递给它）：bg``launch.bat``start``/I

if "%BACKGROUND%"=="y" (
	set JAVA_CMD=!JAVA_CMD!w
	start "%APPNAME%" /I /B "!JAVA_CMD!" %CMD_ARGS%
	...
) else (
	"%JAVA_CMD%" %CMD_ARGS%
)

这导致了我这边的DLL依赖问题。

  1. 在典型的 conda 设置（在我的情况下是 Miniconda3）中，并且未设置，这会导致崩溃并出现以下错误：PYTHONHOME``PYTHONPATH
Python path configuration:
  PYTHONHOME = (not set)
  PYTHONPATH = (not set)
.
.
.
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

就我而言，解决方案是：

  1. 更改为 。bg``fg``ghidraRun.bat
  2. 在启动 Ghidra 之前设置 和 to。PYTHONPATH``PYTHONHOME``CONDA_PREFIX

下面是启动 Ghidra 的简单包装器：

setlocal

call <PATH_TO_YOUR_CONDA>\activate.bat <YOUR_VIRTUAL_ENV>
set PYTHONHOME=%CONDA_PREFIX%
set PYTHONPATH=%CONDA_PREFIX%
call <PATH_TO_YOUR_GHIDRA>\ghidraRun.bat

Thank you very much. I encountered the same problem and solved it perfectly according to the method you provided.

g0mxxm avatar Dec 28 '23 05:12 g0mxxm

To add on to this issue, I've had a similar one when attempting to load Ghidrathon using a Windows Store distribution of Python. The steps to reproduce are:

  1. Install Python from the Windows Store (Tested this with 3.9/3.8)
  2. Run the pip install command to install jep.
  3. Run python ghidrathon_configure.py with the Ghidra directory. This will run successfully with no errors.
  4. Attempt to load Ghidrathon via Window > Ghidrathon in Ghidra. The exception that is thrown is a JepException stating that the Python executable is not valid, and to please reconfigure Ghidrathon.

I wasn't able to find a way around this issue using a Windows Store Python version and resorted to installing it via the Python website. After that, Ghidrathon worked just fine.

Please let me know if there's any other information I can provide, as it seems that any user(?) trying to use Python from the Windows Store would have this issue.

b4cktr4ck2 avatar Feb 15 '24 19:02 b4cktr4ck2