Ghidra Installation Tutorial with Java Runtime and JDK: A Step-by-Step Guide

When launching Ghidra with the provided scripts in and/support, you may encounter the following error messages: Problem: Java runtime not found. Solution: A Java runtime (java/java.exe) is required to be on the system PATH. Please see the Requirements section for what version of Java must be pre-installed for Ghidra to launch.

Ghidra Installation Tutorial with Java Runtime and JDK tutorial

Download File

Ghidra uses an existing Java runtime on the PATH (Java 1.7 or later) to locate a version of Java that Ghidra supports (in this case, Java 11). If Ghidra fails to find Java 11 in the standard locations, you will be prompted to enter the path to Java 11's installation directory. Note that this path should be Java's installation directory (also called "java home"), not the bin directory found within the installation directory.

When utilizing PKI authentication for a Ghidra Server a set of certificates for trusted Certificate Authorities (CA) must be collected and added to a cacerts keystore file created using the Java keytool. The Java keytool can be found within the Java Development Kit (JDK) provided with Ghidra (java/bin/keytool) or any other Java distribution. The default cacerts keystore file location is Ghidra/cacerts and is also specified by the ghidra.cacerts property setting within the server.conf file. Uncomment this specification within the server.conf file to activate use of the cacertsfor all incoming SSL connections (i.e., all Ghidra client users must install and employ theuse of their personal PKI signing certificate for both headed and headless use - see PKI Certificates). Clients can also impose server authenticationfor all HTTPS and Ghidra Server connections by creating the cacerts file and enabling the ghidra.cacerts property setting within the support/launch.sh and/or launch.bat scripts.

• Be sure to backup your projects and tools to ensure that the new Ghidra installation does not overwrite any of your data. Individual program files upgraded to a newer version of Ghidra can not be opened with an older version.

• Uninstall an installed Ghidra Server Service by following the Uninstall Service instructions corresponding to your operating system (Windows or Linux/Mac-OSX).

• Unzip the new Ghidra distribution to a new installation directory (general unpacking and installation guidelines may be found in ghidra_x.x/docs/InstallationGuide.html).

• Copy the old repositories directory to the new Ghidra Server installation directory.

• Copy the wrapper.app.parameter.# lines from your old server/server.conf file to the new installation server/server.conf. For 5.0 release and earlier, your old server.conf file is located within a platform-specific directory (core/os/). No other changes should be made to your new server.conf file. Do not replace the new server.conf file with your old server.conf file, as this could cause server problems.

• If desired, install the Ghidra Server Service from the new installation server subdirectory by following the instructions corresponding to your operating system (Windows or Linux/Mac-OSX).

WARNING! As of Ghidra 7.0 a new project/server storage implementation, Indexed-V1, has been added which is not compatible with older versions of Ghidra. The Indexed-V0 filesystem storage allows longer filenames and paths to exist within a project, while the V1 version expands support to facilitate some of the very large project/repository features introduced in Ghidra 7.0. Since the legacy storage implementation (Mangled) used by older projects and repositories is still supported, conflicting storage behavior may exist between a Ghidra project and its server repository for long filename/path support. It is highly recommended that all server repositories and associated projects be migrated to the new Indexed storage implementation in a coordinated fashion after making a complete backup. All new Ghidra projects will utilize the new Indexed storage implementation, so care should taken when creating shared projects with older repositories.

While working on trying to get around this exact problem, I went ahead and tried to mess with getting the bin folder to behave as though it were built with eclipse by symlinking. I only tested it for the Features/Utility sub-project, but I was able to rm -r bin/main and then ln -s build/classes/java/main bin/main, and I can load ghidra in dev mode using ghidraRun, and it launches just fine. 2ff7e9595c