Kuna: an agent-first decompiler built to be refined by other agents

What Kuna is for, and the assumption behind it

Kuna starts from a claim about who reads decompiler output. The README states that LLM agents like Codex are increasingly the ones using decompilers, while humans read the agents' logs. If that is your workflow, the priorities change: text quality matters more than a GUI, and the decompiler becomes a bottleneck on large binaries, so speed matters too. Kuna is aimed at that reader, not at a human staring at a decompilation window. It is written in Rust, was originally ported from Ghidra, and has since diverged on features and pipeline design. The README calls the whole thing an experiment to establish how far autonomous refinement of decompilers can push research. That framing should set expectations: this is not a product with a support contract, it is a research vehicle. The intended users are reverse engineers and security researchers who drive decompilation from an agent framework, plus anyone who wants a Ghidra-compatible decompiler core they can call from a script.

The phase model and the natural language spec

The engineering design is organized around two ideas. First, the decompiler is phase based: each stage is well defined so an LLM can find the code when it needs to change something, and so debugging has a clear boundary. The README points to `docs/phases.md` for the stage model at a glance, and notes that the runtime registry is queryable through the `stage list`, `stage map` and `stage catalog` console commands. Second, every impactful feature or algorithm should be described, at least in part, in the natural language specification under `./docs/spec`. That spec exists so a human can audit the high-level ideas without reading Rust. The option system is tiered and documented in `docs/options.md`; the README describes transforms as the LLM control surface, with a generated symptom index. The practical consequence is that features are meant to be toggleable per call, because a reverser may want high-level code while a pwner wants low-level code. That is a real design position, and it explains why `--option` exists on the CLI rather than a fixed pipeline. Whether the spec stays in sync with the code is the open question; the repository structure suggests the spec is treated as a first-class artifact rather than a comment dump.

Installing Kuna and decompiling your first function

Kuna is distributed as a single Rust binary. The README says it runs on most systems, with Linux, Windows and macOS supported, and that prebuilt binaries are on the releases page. If you build from source, the `kuna` binary ends up at `decompiler/target/release/kuna`. The top-level Makefile builds the console binaries, the SLEIGH compiler and the CLI together:

make binaries

That target runs `cargo build --release -p kuna-console -p kuna-harness -p kuna-slacomp -p kuna-cli` inside `decompiler/`. Once you have the binary, decompile a single function by name:

kuna decompile ./a.out main

For a stripped binary you supply an address and pass `--addr`:

kuna decompile ./stripped.bin 0x401040 --addr

To decompile everything at once, the README gives this command, which returns a `.c`, a `.h` and an `.asm` file:

kuna decompile-project ./a.out

Options can be flipped per invocation. The README's example changes an internal feature, which it describes as useful for LLMs:

kuna decompile ./a.out main --option compareform canonical

If you are driving the decompiler from an agent, Kuna ships a skill inside the binary. `kuna install-skill` sets it up for Claude Code, Codex and OpenCode offline; `--dir DIR` targets other agents and `--print` just reads the skill out. The skill file itself lives at `skills/kuna/SKILL.md`.

Three ways to run it, and what each one costs you

The CLI is the primary surface, but the README documents two others. The browser build uses WebAssembly, and because the work happens on your machine the binary stays private; the hosted instance is at kuna.noelo.org/decompile, and the code to deploy your own site is in `./integrations/web`. The third path is the Ghidra GUI: because Kuna started as a Ghidra port, the output format remains largely compatible, and you can use the Kuna core as the Ghidra decompiler inside the traditional GUI. You either build the extension from `./integrations/ghidra` or download it from the releases page. The README's install steps are to download the zip named `kuna-version-KunaDecompiler-ghidra....zip`, use File, Install Extensions, `+`, select the zip, restart, then go to File, Configure, Miscellaneous and check KunaDecompilerPlugin. After that a decompilation should carry a `/* Kuna v{version} */` marker. To go back to the stock decompiler you disable the plugin in File, Configure. The README is explicit that not all native Ghidra features are supported yet and asks users to report issues. That is the honest boundary of the Ghidra path: it is a backend swap, not a full replacement of the Ghidra experience.

Where Kuna is the wrong tool

The README is candid about the Ghidra extension: all native Ghidra features are not yet supported. If your workflow depends on a Ghidra feature the port has not covered, swapping the backend will cost you more than it saves. The second limitation is structural. Kuna optimizes for decompilation text and speed, and the README says this means striking a balance between features and speed rather than maximizing features. A tool built that way will not match a mature decompiler on breadth of analysis. Third, the project is an experiment, and the README says so directly; the autonomous refinement goal means the pipeline is expected to change as agents rewrite it. If you need a decompiler whose behavior is frozen across versions, this is not it. The releases listed are dated within days of each other, so version numbers move quickly and pinning matters. Finally, the README does not document rollback or downgrade procedures, so if a new release regresses on your binary you have no documented path back beyond fetching an older release artifact yourself.

How it differs from Ghidra and from LLM-assisted decompilers

The nearest comparison is Ghidra itself, and the difference is not the output format, which the README says stayed largely compatible, but the intended consumer. Ghidra is a full reverse engineering suite with a GUI, visualization and a broad feature set built for a human analyst. Kuna keeps the decompiler core, drops the suite around it, and optimizes the text for an agent to read. It also exposes a tiered option catalog as the control surface, so a caller can ask for high-level or low-level output per invocation, which is not how Ghidra's decompiler is normally driven. The other comparison is LLM-assisted decompilation tools that wrap an existing decompiler and post-process its output with a model. Kuna inverts that: the decompiler itself is the Rust engine, and agents are pointed at the source and the natural language spec under `./docs/spec` to refine the engine rather than paraphrase its output. The README frames the goal as designing datasets, prompts and tools for LLMs to keep improving the decompiler, with DecBench providing the data and metrics. That is a different bet from prompt-level cleanup, and it is the part of the project that is genuinely untested over a long horizon.

Licence, build cost and what maintenance looks like

Kuna is Apache-2.0, with a NOTICE file at the repository root; the usual Apache-2.0 obligations around attribution and notice retention apply, and anything beyond that is a question for your own counsel. The build is driven by the top-level Makefile. `make binaries` compiles the console binaries, the harness, the SLEIGH compiler and the CLI in one Cargo invocation, and `make specs` compiles every vendored `.slaspec` into `.sla` files next to the spec using the SLEIGH compiler. The Makefile comment states that end-to-end correctness is `make test`, and that the built specs decode the corpus to 675/675. Building from source therefore means building a Rust workspace plus a SLEIGH compiler, not just one crate. The repository layout includes `.devcontainer/`, `integrations/`, `specs/`, `tests/` and `tools/`, so there is more surface than a single binary suggests. On maintenance: the last push was on 2026-09-17, the same day as the v1.526 release, and the repository is not archived. Releases v1.508, v1.515 and v1.526 landed on 2026-09-15, 2026-09-16 and 2026-09-17 respectively, which tells you the version stream moves fast. Fast releases mean you should pin a version in any pipeline rather than tracking `main`.

Editorial conclusion

Adopt Kuna if you are decompiling optimized C for an LLM agent to read, or if you want a Ghidra-compatible decompiler backend that can be scripted and tuned per call. Skip it if you need a stable, fully documented decompiler with a GUI of its own, or if your workflow depends on Ghidra features the port does not yet cover. Before committing, run `kuna decompile-project` on one of your own binaries and diff the output against Ghidra's on the same file, and check the option catalog under `docs/options.md` for the knobs your case needs.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Noelo-Lab/kuna on GitHub
3. Project website
4. README
5. Releases