GhidraGPT: LLM Actions Wired Into Ghidra's Decompiler Right-Click Menu

The gap GhidraGPT fills between decompiled C and a readable function

Ghidra's decompiler gives you C-like output with names like iVar3 and param_2. Turning that into something a human can read is manual work: renaming variables, guessing types, writing a one-line comment about what the function does. GhidraGPT targets exactly that step. The README describes three right-click actions in a GhidraGPT submenu, available from both the Decompiler and the Listing views. Explain produces a natural-language summary of the selected function. Rewrite recovers a descriptive function name, renames locals and parameters, infers types, updates the prototype, adds inline comments, and then applies that markup back into the Ghidra database. Audit reviews the same decompiled code for likely security issues such as unbounded copies, integer overflows and unchecked returns. The audience is a reverse engineer who is already in Ghidra and wants a first pass at naming and annotation without leaving the tool. It is not aimed at someone who wants automated whole-binary analysis, and the README is explicit that every action operates on a single function at a time.

One function in, one streamed answer out: the data flow

The mechanism is simpler than the feature list suggests. You select a function and pick an action. The plugin takes that function's current decompiler output as the only context and sends it to the configured provider. The response streams token-by-token into a dedicated GhidraGPT console panel. For Explain and Audit the output stays in the console as text. For Rewrite there is a second half: the model returns structured markup, and the plugin writes it into the program, which is why that action changes your database rather than just printing a suggestion. The README states plainly that there is no interprocedural or whole-program analysis. That single sentence determines most of the tool's behaviour. If a function calls a helper that validates a length, the model cannot see the helper. If a buffer is sized in one function and filled in another, the model sees only half the story. The streaming console is a real design choice rather than a cosmetic one: on a long function you can read the beginning of the answer and decide whether the rest is worth waiting for.

Building the extension and pointing it at a provider

Installation is a Maven build against a local Ghidra install. The README gives these commands:

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

The packaged extension lands at target/GhidraGPT-<version>.zip. You then use File, Install Extensions, click the plus button, select that zip, and restart Ghidra. The plugin is enabled when prompted, or through File, Configure, GhidraGPT, GhidraGPTPlugin. Configuration is a panel inside Ghidra where you pick a provider and model and enter an API key. Model, temperature, max tokens and request timeout are all adjustable, and for most providers the model list can be fetched live. Ollama needs no key because it runs locally. Ten provider options are listed, including OpenAI, Anthropic, Google Gemini through an OpenAI-compatible endpoint, Cohere, Mistral, DeepSeek, Grok, OpenRouter, Ollama, and a generic OpenAI-compatible entry where you supply a custom base URL. The requirements are Ghidra 12.1.x, JDK 21 or newer, Maven, and network access to the provider unless you are on Ollama.

The API key is obfuscated, not encrypted, and the README says so

The key you enter is saved locally to ~/.ghidragpt/config.properties. The README describes the storage as lightly obfuscated with XOR and states directly that this is not encryption and should not be treated as secure at-rest storage. It recommends a scoped, rotatable key and protecting the file accordingly. Take that at face value. Anything that reads your home directory can recover the key, and a key with broad account permissions turns a local file read into a billing or access problem. This is not a flaw the maintainer is hiding; it is documented in the installation section, which is the right place for it. The practical consequence is that the tool is a poor fit for a shared workstation or a jump host, and a good fit for a laptop where you already control the filesystem. The same reasoning applies to the code you send: Explain, Rewrite and Audit all transmit decompiled C to the provider you configured, so a hosted provider means the binary's logic leaves your machine. Ollama is the only listed option that keeps that traffic local.

Audit is a lead generator, not static analysis

The Audit action is the feature most likely to be misread. The README calls it a best-effort, single-function review by the model, not sound static analysis, and notes the absence of cross-function dataflow or call-graph context. It instructs you to treat findings as leads to verify rather than proof. That framing is honest and it matches the architecture: a model reading one function's decompiled C can notice a memcpy whose length argument is a parameter, but it cannot determine whether every caller bounds that parameter. The failure mode is asymmetric. A missed bug costs you nothing you did not already have, since you were going to review the function anyway. A confident false positive costs time, and a confident false negative can cost more if you treat the Audit output as a checklist and stop reading the code. Use it to decide where to look, not to decide that a function is clean. The same caution applies to Rewrite: inferred types and prototypes are the model's best guess, and they are written into the database, so an incorrect type can propagate into later analysis you do by hand.

Where GhidraGPT sits next to Ghidra's own script console

The obvious alternative is not another plugin but Ghidra's built-in scripting environment. Ghidra ships with a Python and Java scripting API, and you can write a script that pulls a function's decompiled C and posts it to an HTTP endpoint yourself. That approach costs you an afternoon and gives you exactly the context you choose: you can walk the call graph, gather callee decompilation, and assemble a prompt that includes the helper functions GhidraGPT cannot see. The trade-off runs the other way too. A script is yours to maintain, it has no configuration panel, no streaming console, no provider list, and no model-fetching, and every provider change is an edit to your code. GhidraGPT is the packaged version of that script with ten providers wired in and a right-click entry point. If your need is one-off and highly context-dependent, the script wins. If your need is a repeatable Explain or Rewrite pass across many functions with minimal setup, the extension wins. Neither approach gives you sound interprocedural analysis, which is what a dedicated static analysis tool is for.

Version cadence, licence and what maintenance actually costs you

The repository shows a v1.2.1 release in December 2025, then v1.3.0 and v1.4.0 on consecutive days in July 2026. That pattern suggests bursts of activity rather than a steady release rhythm, which is worth knowing if you plan to depend on it. The extension is licensed under Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, but it also means you must preserve the licence and attribution notices in any redistributed build. Nothing here is legal advice; read the LICENSE file in the repository for the actual terms. The real maintenance cost is not the plugin, it is the coupling to Ghidra. The README states the extension declares compatibility with the Ghidra version it is built against, and lists Ghidra 12.1.x plus JDK 21 or newer. A Ghidra upgrade can therefore require a rebuild against the new install directory before the extension loads. Budget for that on every Ghidra bump, and check the release notes for a build matching your version rather than assuming the zip you have will keep working.

Editorial conclusion

Adopt GhidraGPT if you already work inside Ghidra and want a second opinion on one function at a time, especially if you run Ollama locally and never want decompiled code to leave the machine. Skip it if your question is interprocedural, because the README states there is no call-graph or cross-function dataflow context, and skip it on shared or untrusted workstations where the XOR-obfuscated key file at ~/.ghidragpt/config.properties would be readable. Before relying on it, verify three things: that your Ghidra build matches the 12.1.x line the extension declares compatibility with, that your JDK is 21 or newer, and that a Rewrite action on a throwaway function produces markup you are willing to keep, since that action writes names, types and comments back into the Ghidra database.

Official sources

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