ghidra-rpc: an agentic skill that lets an LLM drive Ghidra on its own

Reverse engineering as an agent workload

ghidra-rpc, developed at Cellebrite Labs, is an agentic skill that gives a large language model hands on Ghidra, the open-source reverse engineering suite, so it can perform analysis tasks autonomously: decompiling functions to pseudo-C, tracing call graphs, renaming and annotating symbols, defining data structures, patching instructions and diffing binary versions, all without a human clicking through the UI.

The mechanism is a persistent background daemon with a command line interface that returns structured JSON. Any AI coding assistant that can run shell commands, the README names pi, Claude Code and Cursor, can drive a full reverse engineering session by issuing commands and reasoning over the results. The skill layer is the product: SKILL.md, agent instructions and a Python package wrapping Ghidra's capabilities into discrete, composable commands.

What the model is allowed to do

The capability table in the README divides the work into six areas. Understanding: decompile functions, disassemble, inspect control-flow graphs and P-code. Navigation: trace callers and callees, search strings and byte patterns, find cross-references. Annotation: rename functions and symbols, add comments, set bookmarks and tags. Type recovery: define structs, unions and enums, retype variables, set function signatures. Patching: assemble instructions through SLEIGH, write raw bytes, override flow types. And binary diffing: version-track two builds, diff changed functions, and match functions across builds via BSim.

That last area, BSim-backed function matching across versions, is what turns the tool from an analysis convenience into a patch-analysis workflow: point it at two builds of the same product, and the agent can identify what changed and annotate the differences, a task documented as one of the three guided flows alongside binary audits and vulnerability research.

Quick start, and the first agent prompt

Prerequisites are Ghidra 11 or newer, Python 3.11 or newer, Java 17 or newer, and uv. The README's setup is two lines, pointing an environment variable at a Ghidra installation and installing the tool:

export GHIDRA_INSTALL_DIR=/opt/ghidra_12.0
uv tool install /path/to/ghidra-rpc

Once installed, the intended interface is conversational. The README's example prompt asks the agent to load /usr/bin/ls into Ghidra and find any unsafe string operations, and the agent composes the command sequence itself. For manual use or debugging, the same primitives are exposed directly: start a daemon headlessly against a project, load a binary, decompile a function, list cross-references to strcmp, rename a placeholder symbol to parse_args.

A list-instances command reports running daemons as JSON with project paths, modes and process IDs, so an existing session can be adopted rather than restarted, with a follow-up command attaching to the binaries already loaded.

The warm daemon, and why changes survive

The architecture keeps Ghidra running in-process through PyGhidra, with the JVM warm between commands, so there is no re-analysis on every invocation, which is the difference between a usable agent loop and a ten-minute-per-question one. Persistence is equally deliberate: renames, comments, type definitions and patches are saved to the Ghidra project after every command, so all the agent's work remains visible when a human later opens the same project in the Ghidra GUI.

That hand-off property matters for team workflows: the agent does the tedious first pass, and the analyst picks up a Ghidra project that already carries the recovered names, types and annotations, reviewable with the normal GUI tooling. The LLM agent and the daemon talk over a local transport using newline-delimited JSON, keeping the boundary simple and debuggable.

Runtime paths designed for sandboxes

A section most projects would omit documents every file the tool touches, and the scheme is deterministic: all paths derive an eight-character hash from the absolute project path, so each project gets its own socket, log and session file with no collisions. Unix sockets serve Linux and macOS, authenticated loopback TCP metadata serves Windows, and background daemons log to per-project files.

A single environment variable, GHIDRA_RPC_STATE_DIR, redirects both per-project session files and the global registry to a custom directory, which the README calls out as useful in sandboxed or CI environments. The global session registry maintains itself: starting a daemon adds an entry, stopping removes it, and list-instances prunes entries whose endpoint file has disappeared, such as after a crash. For teams running agents in ephemeral CI containers, that combination of determinism and cleanup is the difference between a tool and a liability.

Guided workflows, licence and limits

Beyond the reference docs, the repository ships three workflow guides: binary audit, vulnerability research and patch analysis, which frame the tool for its intended audiences, analysts and researchers working binaries they are authorized to examine. Reverse engineering tooling is dual-use by nature, and the responsible boundary is the standard one for the field: analyze software you have the right to analyze, such as your own products, malware samples in a research context, or authorized assessments.

Two housekeeping facts complete the picture. The README's licence section states MIT, but the repository tree contains no LICENSE file, so verify before reuse; and the prerequisites stack, Ghidra 11+, Java 17+, Python 3.11+ and uv, plus a local Ghidra installation, is the real installation cost. Two releases exist, and the last push was on 2026-09-17, so the project is current and moving with an active changelog.

Against clicking, and against headless scripts

The traditional alternative is a human analyst driving Ghidra's GUI: precise, contextual, and slow at scale, with every rename and navigation costing clicks. The older automation alternative is headless scripting, Ghidra's analyzer can run scripts, but scripts are static: they do the same thing every run, and adapting to what the binary actually contains is the analyst's job.

ghidra-rpc's slot is between those: an agent reads the decompilation, decides what to investigate next, iterates, and leaves persistent, GUI-visible annotations behind, with the JSON boundary keeping each step inspectable in the transcript. The verification responsibility does not disappear, an LLM can misname a function or misread a type, but because every change lands in the Ghidra project, review is a diff in a tool analysts already trust rather than a log file nobody reads.

Editorial conclusion

ghidra-rpc fits reverse engineers, malware analysts and vulnerability researchers who already work in Ghidra and want an AI agent to handle the repetitive layers of analysis, leaving persistent, reviewable annotations in the project. Skip it if you do not run Ghidra locally with Java 17 and the required toolchain, or if your workflow requires posting comments and interacting with live targets, which is not what this drives. Verify it on a binary you know well: install with uv, run the daemon, ask your agent to decompile a function whose behavior you already understand, and judge whether the agent's annotations match your own reading before letting it work unattended.

Frequently asked questions

Official sources

1. cellebrite-labs/ghidra-rpc on GitHub
2. Issues
3. README
4. Releases