Skip to content
Hydra Engine

Install Hydra Engine

Download the Windows x64 headless install, check its SHA-256, give it a JDK 25, and start the daemon. Linux and macOS build from source for now.

On this page

A release is one zip: a headless Ghidra install with the session daemon and its Python client inside. It does not include a JDK or Python. You need a JDK 25 and Python 3.10 or later.

Download and check the zip

Take hydra-engine-12.3-hydra.1-win_x86_64.zip and SHA256SUMS from Releases, then compare the hash before you unzip:

Get-FileHash hydra-engine-12.3-hydra.1-win_x86_64.zip   # compare with the line in SHA256SUMS
Expand-Archive hydra-engine-12.3-hydra.1-win_x86_64.zip C:\tools
$G = "C:\tools\ghidra_12.3_DEV"
$GS = "$G\Ghidra\Features\HeadlessSession\support\ghidra_session.py"

The folder is named after the Ghidra version the release is built on (ghidra_12.3_DEV), not after the release. Unzipped it is about 2,800 files and 639 MB. The rest of these pages assume $G and $GS from above.

Give it a JDK

The launcher is one Python file, ghidra_session.py, standard library only. It finds a JDK on its own, in this order: --java, java in its config.json, GHIDRA_SESSION_JAVA_HOME, JAVA_HOME_OVERRIDE in Ghidra's launch.properties, JAVA_HOME, the JDK Ghidra itself last saved for this version, then java on PATH. A JRE is skipped. To see what it picked without starting anything:

python $GS config

It prints the install, the JDK and its version, the state directory and every setting.

Start the daemon

python $GS ensure

ensure starts the daemon if none is running and prints its endpoint: port, protocol, versions and launch timings, never the token. The first start on a new install took 1.4 s here (cold class cache, no AOT cache); later clients join a running daemon instead of starting one.

On JDK 25 you can also train an AOT cache once. The engine's README measured the training run at about 26 seconds, and fast starts use the cache from then on:

python $GS aot

Linux and macOS

Releases are Windows x64 only, because that is where CI runs the test suites. The launcher and the module have no Windows-only code path, and a release dry run on 2026-10-26 built and passed the suites once on Linux x64 and macOS arm64, but neither is tested routinely. Build from source:

git clone https://github.com/RusticStack/hydra-engine.git
cd hydra-engine
./gradlew -I gradle/support/fetchDependencies.gradle -DnoEclipse   # once
./gradlew buildHeadless                                             # -> build/dist/ghidra_12.3_DEV

A cold build without a build cache took 6 to 16 minutes on Windows. gradle buildGhidra still builds the full Ghidra with its GUI.

The client on its own

on main · 12.3-hydra.2 Each release also ships hydra-client-<version>.zip: the same ghidra_session.py, stamped with the release, plus LICENSE and a short README.txt. If you write a tool against the daemon, pin the client and the engine of the same release together; Integrate explains the version check.

Stop or remove it

python $GS stop     # refused while other clients are connected; --force stops anyway

To remove it, stop the daemon, then delete the install folder and the state directory.

Checked against the engine on 2026-10-26. Every detail is in the README on GitHub.