GhidraGPT: LLM-assisted reverse engineering inside the Ghidra decompiler

What GhidraGPT does that the decompiler alone does not

Ghidra's decompiler gives you C-like pseudocode with names like `uVar1` and `param_2`. Turning that into something a human can read is manual work: you decide what the function is for, rename the locals, fix the prototype, and write the comment. GhidraGPT automates that pass by sending the function's current decompiled output to a large language model and bringing the answer back into the tool.

The README describes three right-click actions under a `GhidraGPT` submenu. Explain produces a natural-language summary. Rewrite recovers a descriptive function name, renames locals and parameters, infers their types, updates the prototype, adds inline comments, and applies that markup back into the Ghidra database. Audit reviews the code for likely security issues such as unbounded copies, integer overflows and unchecked returns.

The audience is someone already inside Ghidra who wants a faster first draft of a function's meaning. It is not aimed at automated triage pipelines, and the README is explicit that all actions operate on a single function at a time, using its decompiler output as the only context.

One function in, one streamed response out

The data flow is short and worth understanding before you trust the output. You select a function in the Decompiler or Listing view and pick an action from the right-click menu. The plugin takes that function's current decompiled C, sends it to the configured provider, and streams the response token by token into a dedicated GhidraGPT console panel. For Rewrite, the model's structured answer is parsed and applied back to the program as names, types, a prototype and comments.

Two consequences follow from that design. First, context is whatever the decompiler currently shows for that function, so a helper called from three places is analyzed without knowing any of its callers. Second, the quality of the input matters: if the decompiler misidentified a type or split a function badly, the model reasons over the same mistake. Nothing in the README suggests a step that re-runs decompilation or feeds additional context.

The provider layer is pluggable. The README lists OpenAI, Anthropic, Google Gemini through an OpenAI-compatible endpoint, Cohere, Mistral AI, DeepSeek, Grok (xAI), OpenRouter, Ollama for local models with no API key, and a generic OpenAI-compatible option with a custom base URL. Model, temperature, max tokens and request timeout are adjustable, and for most providers the available models can be fetched live.

Building the extension and running your first Explain

The README gives a Maven build with the Ghidra install directory passed as an environment variable. Clone first, then package:

git clone https://github.com/weirdmachine64/GhidraGPT.git
cd GhidraGPT
GHIDRA_INSTALL_DIR=/path/to/ghidra mvn clean package

The packaged extension is written to `target/GhidraGPT-<version>.zip`. If the build fails immediately, the first thing to check is that `GHIDRA_INSTALL_DIR` points at a Ghidra 12.1.x installation, since the README states the extension declares compatibility with the version it is built against, and the build needs JDK 21 or newer.

Install the zip through Ghidra's extension manager, then restart. The README's steps are `File -> Install Extensions`, then click `+`, select `target/GhidraGPT-<version>.zip`, and restart Ghidra. After the restart, enable the plugin when prompted, or open `File -> Configure -> GhidraGPT -> GhidraGPTPlugin`. Then open the configuration panel, choose a provider and model, and enter an API key. Ollama needs no key. For a fully local setup the README's provider table lists Ollama as the option that runs without network access to a remote API.

With a provider configured, open a program, click into a function in the Decompiler view, right-click, and choose `GhidraGPT` then Explain. The answer streams into the GhidraGPT console panel. Rewrite is the action to try second, on a small function you can verify by hand, because it modifies the database rather than only printing text.

Key storage, scope limits and where Audit misleads

The README's own note on key storage is the sharpest limitation in the project. The API key is saved locally in `~/.ghidragpt/config.properties`, lightly obfuscated with XOR, which the README states is not encryption and should not be treated as secure at-rest storage. It recommends a scoped, rotatable key and protecting the file accordingly. If you work on a shared machine or in an environment where home directories are backed up or synced, that file is the thing to think about before you paste a key into the panel.

Audit is the second place to be careful. The README describes it as a best-effort, single-function review by the model, not sound static analysis: it has no cross-function dataflow or call-graph context, so findings should be treated as leads to verify, not proof. A buffer overflow that only becomes reachable because of a length computed two functions away will not be visible. A false positive from a bounds check the decompiler rendered confusingly is equally possible. Reading Audit output as a vulnerability report is the wrong use.

The third limit is scope. There is no interprocedural or whole-program analysis, so questions like "which functions reach this memcpy" or "what is this binary's overall structure" are outside what the plugin does. It is a per-function assistant bolted onto the decompiler view.

How it compares with scripted LLM pipelines and MCP bridges

The alternative most people reach for is a script that exports decompiled functions and feeds them to a model outside Ghidra. That approach gives you control over batching, prompt construction and how much context you include, and it can cover a whole binary rather than one function. The cost is that the results come back as text in a terminal or a file; you copy names and comments into Ghidra yourself, or you write a second script to apply them through the Ghidra API.

GhidraGPT's difference is placement rather than capability. The request originates from the right-click menu, the response streams into a Ghidra console panel, and Rewrite applies the model's output directly to the program's names, types, prototype and comments. That loop is shorter than an export-and-reimport script, and it is the reason to use the extension rather than a standalone pipeline. What you give up is the control a script gives you: the context is fixed to the selected function's decompiler output, and the actions are the three the plugin defines.

A second alternative is bridging Ghidra to a model through an external tool protocol so that an agent drives the analysis. That model of use is about letting a model issue many queries and build its own picture of the binary. GhidraGPT does not do that: the README describes a fixed set of actions on one function, with the model answering a single request rather than exploring the program.

Maintenance, licence and what upgrading costs

The repository is not archived, and the last push was on 2026-07-22, which is recent. Releases are tagged: v1.2.1 on 2025-12-16, then v1.3.0 on 2026-07-21 and v1.4.0 on 2026-07-22. The gap between v1.2.1 and v1.3.0 is roughly seven months, so the release cadence is not uniform, and the two July releases landing a day apart suggests a fix followed quickly after a feature release.

The practical upgrade cost sits in the Ghidra version coupling. The README states that the extension declares compatibility with the Ghidra version it is built against, and that Ghidra 12.1.x is the requirement, with JDK 21 or newer because Ghidra 12.x needs it. That means a Ghidra upgrade can require a rebuild against the new install directory before the extension loads, and you should check the declared compatibility rather than assume an older zip still works. There is no mention of an update channel inside Ghidra, so expect to rebuild and reinstall the zip yourself.

Licensing is Apache-2.0, and the README points at the LICENSE file in the repository for the terms. That covers the extension code. It does not cover what you send to a provider: prompts containing decompiled code leave your machine for every provider except Ollama, and the terms that apply to that data are the provider's, not the project's. Read the Apache-2.0 text and your provider's data policy rather than assuming the licence settles the question.

Editorial conclusion

Adopt GhidraGPT if you already work in Ghidra 12.1.x, want an explanation or a first-pass rename of a function without leaving the decompiler, and can accept that every request carries that function's decompiled C to a provider you choose. Do not adopt it as a substitute for cross-function analysis: the README states there is no interprocedural or whole-program analysis, and Audit is described as a best-effort single-function review, so its findings are leads rather than proof. Before relying on it, verify three things: that your Ghidra build matches the version the extension declares compatibility with, that your provider key is scoped and rotatable because ~/.ghidragpt/config.properties is only XOR-obfuscated, and that Rewrite's markup lands correctly on a function you can check by hand.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. weirdmachine64/GhidraGPT on GitHub