[GH-ISSUE #1957] [Feature] Consider alternative to Ghidra/Hopper/Hex-Rays: Kuna

bsakaguchi commented

2026-10-15 18:26:57 +00:00

Owner

Originally created by @mahaloz on GitHub (Oct 11, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1957

Originally assigned to: @N0zoM1z0 on GitHub.

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Native analysis or decompilation

Current limitation

Hi, awesome project!

I've been working on an alternative to Ghidra for a while now as part of our research at the University of Georgia. We developed Kuna, a Rust-based decompiler. I thought I'd ask if you'd be interested in adding it as a supported decompiler.

On the decompiler benchmark, DecBench, Kuna has held the top position for weeks for best C/C++ quality, above Ghidra and IDA. It is also faster, able to multi-process decompilation, and often lets AI agents use fewer tokens (45% fewer tokens than IDA MCP in testing) on RE tasks.

It's open-source and a single binary, so it might be interesting to ship.

Anyway, don't want to drop a longer ad here. Lmk if you'd like a PR or to talk about it :). I'm also @mahaloz on Discord.

Use cases

faster decompilation
higher-quality decompilation
easier shipping

Desired outcome and success criteria

integrate Kuna

Authority boundaries and non-goals

No response

Alternatives considered

No response

Possible direction

No response

References

No response

Originally created by @mahaloz on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1957 Originally assigned to: @N0zoM1z0 on GitHub. ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Current limitation Hi, awesome project! I've been working on an alternative to Ghidra for a while now as part of our research at the University of Georgia. We developed [Kuna](https://github.com/noelo-lab/kuna), a Rust-based decompiler. I thought I'd ask if you'd be interested in adding it as a supported decompiler. On the decompiler benchmark, [DecBench](https://decbench.com/), Kuna has held the top position for weeks for best C/C++ quality, above Ghidra and IDA. It is also [faster](https://github.com/Noelo-Lab/kuna/issues/510#issuecomment-5645307854), able to multi-process decompilation, and often lets AI agents use fewer tokens ([45% fewer](https://mahaloz.re/2026/09/28/hack-race.html) tokens than IDA MCP in testing) on RE tasks. It's open-source and a single binary, so it might be interesting to ship. Anyway, don't want to drop a longer ad here. Lmk if you'd like a PR or to talk about it :). I'm also @mahaloz on Discord. ### Use cases - faster decompilation - higher-quality decompilation - easier shipping ### Desired outcome and success criteria - integrate Kuna ### Authority boundaries and non-goals _No response_ ### Alternatives considered _No response_ ### Possible direction _No response_ ### References _No response_

bsakaguchi added the

area: native

enhancement

P2: medium

labels

2026-10-15 18:26:57 +00:00

bsakaguchi commented

2026-10-15 18:26:58 +00:00

Author

Owner

@matbrgz commented on GitHub (Oct 12, 2026):

Decompiler Evaluation & Provider Feasibility Review

Kuna looks like an exceptional modern Rust-based decompiler project with impressive token efficiency on DecBench.

Per AGENTS.md and CONTRIBUTING.md#contribution-scope:

Integration Architecture: To integrate as a provider in REA, Kuna would need either:
- A headless CLI interface or an MCP server interface that adheres to REA's procedure listing, address lookup, and decompiler readback contracts.
- Preserving epistemic evidence boundaries (distinguishing raw CFG observations from reconstructed C pseudocode).
Next Steps: An initial prototype demonstrating headless execution against standard test fixtures without ambient GUI requirements would be a fantastic foundation for a formal provider proposal.

@matbrgz commented on GitHub (Oct 12, 2026): ### Decompiler Evaluation & Provider Feasibility Review Kuna looks like an exceptional modern Rust-based decompiler project with impressive token efficiency on DecBench. Per `AGENTS.md` and `CONTRIBUTING.md#contribution-scope`: 1. **Integration Architecture:** To integrate as a provider in REA, Kuna would need either: - A headless CLI interface or an MCP server interface that adheres to REA's procedure listing, address lookup, and decompiler readback contracts. - Preserving epistemic evidence boundaries (distinguishing raw CFG observations from reconstructed C pseudocode). 2. **Next Steps:** An initial prototype demonstrating headless execution against standard test fixtures without ambient GUI requirements would be a fantastic foundation for a formal provider proposal.

bsakaguchi commented

2026-10-15 18:26:58 +00:00

Author

Owner

@mahaloz commented on GitHub (Oct 13, 2026):

Hi @matbrgz. For the integration, Kuna already has a full-fledged CLI, which we've optimized for low token consumption. I still recommend that people decompile everything in a binary (it comes with ASM and C), then let your agent go crazy. Largely, MCP is unnecessary, as these models just love text files.

kuna decompile-project ./my_binary --jobs 10  # decompile every function across 10 threads

@mahaloz commented on GitHub (Oct 13, 2026): Hi @matbrgz. For the integration, Kuna already has a full-fledged CLI, which we've optimized for low token consumption. I still recommend that people decompile everything in a binary (it comes with ASM and C), then let your agent go crazy. Largely, MCP is unnecessary, as these models just love text files. ```bash kuna decompile-project ./my_binary --jobs 10 # decompile every function across 10 threads ```

bsakaguchi commented

2026-10-15 18:26:58 +00:00

Author

Owner

@thotganesh commented on GitHub (Oct 13, 2026):

Hi @matbrgz, @mahaloz — I put together the headless prototype you asked for, using the Ghidra provider REA already has. No changes to REA or Ghidra.

Environment

Ghidra 12.1.2 (headless only)
Kuna v1.818 (KunaDecompiler-ghidra_12.1.2.zip)
REA 3.1.0

Approach

Kuna's OSGi extension doesn't load in headless Ghidra (bundle resolution fails outside the CodeBrowser). But the release ships a kuna_ghidra binary in os/linux_x86_64/ that speaks the Ghidra⇄decompiler wire protocol, so it can replace the stock decompile executable:

D=$GHIDRA_INSTALL_DIR/Ghidra/Features/Decompiler/os/linux_x86_64

cp $D/decompile $D/decompile.ghidra.orig        # back up
cp <KunaDecompiler>/os/linux_x86_64/kuna_ghidra $D/decompile
chmod +x $D/decompile
export KUNA_SPECS=/path/to/kuna-specs/specs

Rollback: copy decompile.ghidra.orig back over decompile.

Result

rea decompile /bin/ls 0x104740 returns through the existing procedure_pseudo_code operation:

/* Kuna v1.818 */
void switchD_00106d53::default(void)
{
  __assert_fail("sort_type != sort_version","src/ls.c",0x1017,"sort_files"); // no-return
}

open_binary, analyze and search_strings keep working unchanged, and the envelope structure (raw_result, normalized_result, confidence, authority, limitations) parses as it does for stock Ghidra.

Limitations (relevant to the evidence-boundary requirement)

REA still reports provider: ghidra, version: 12.1.2, so the provenance is wrong. The only trace of Kuna is the /* Kuna v1.818 */ comment line. A real provider would need to report its own identity.
The swap is install-wide: every Ghidra decompile on that install goes through Kuna until rolled back.
I only checked a single function on one binary so far, not the test fixtures.

Suggested path

Document this headless procedure as an interim, clearly-labelled experimental setup.
Later, a native src/kuna/ provider built on kuna decompile-project (as mahaloz suggested), with its own provider identity and the contract work from CONTRIBUTING.md.

Happy to run this against REA's standard fixtures or open a docs PR here, whichever you prefer as the first step.

@thotganesh commented on GitHub (Oct 13, 2026): Hi @matbrgz, @mahaloz — I put together the headless prototype you asked for, using the Ghidra provider REA already has. No changes to REA or Ghidra. **Environment** - Ghidra 12.1.2 (headless only) - Kuna v1.818 (`KunaDecompiler-ghidra_12.1.2.zip`) - REA 3.1.0 **Approach** Kuna's OSGi extension doesn't load in headless Ghidra (bundle resolution fails outside the CodeBrowser). But the release ships a `kuna_ghidra` binary in `os/linux_x86_64/` that speaks the Ghidra⇄decompiler wire protocol, so it can replace the stock `decompile` executable: ```bash D=$GHIDRA_INSTALL_DIR/Ghidra/Features/Decompiler/os/linux_x86_64 cp $D/decompile $D/decompile.ghidra.orig # back up cp <KunaDecompiler>/os/linux_x86_64/kuna_ghidra $D/decompile chmod +x $D/decompile export KUNA_SPECS=/path/to/kuna-specs/specs ``` Rollback: copy `decompile.ghidra.orig` back over `decompile`. **Result** `rea decompile /bin/ls 0x104740` returns through the existing `procedure_pseudo_code` operation: ```c /* Kuna v1.818 */ void switchD_00106d53::default(void) { __assert_fail("sort_type != sort_version","src/ls.c",0x1017,"sort_files"); // no-return } ``` `open_binary`, `analyze` and `search_strings` keep working unchanged, and the envelope structure (`raw_result`, `normalized_result`, `confidence`, `authority`, `limitations`) parses as it does for stock Ghidra. **Limitations (relevant to the evidence-boundary requirement)** - REA still reports `provider: ghidra, version: 12.1.2`, so the provenance is wrong. The only trace of Kuna is the `/* Kuna v1.818 */` comment line. A real provider would need to report its own identity. - The swap is install-wide: every Ghidra decompile on that install goes through Kuna until rolled back. - I only checked a single function on one binary so far, not the test fixtures. **Suggested path** 1. Document this headless procedure as an interim, clearly-labelled experimental setup. 2. Later, a native `src/kuna/` provider built on `kuna decompile-project` (as mahaloz suggested), with its own provider identity and the contract work from `CONTRIBUTING.md`. Happy to run this against REA's standard fixtures or open a docs PR here, whichever you prefer as the first step.

bsakaguchi commented

2026-10-15 18:26:58 +00:00

Author

Owner

@mahaloz commented on GitHub (Oct 13, 2026):

@thotganesh, the intended workflow is not through the Ghidra provider. You can use the command-line interface, like kuna decompiler-project, which is what we test.

@mahaloz commented on GitHub (Oct 13, 2026): @thotganesh, the intended workflow is not through the Ghidra provider. You can use the command-line interface, like `kuna decompiler-project`, which is what we test.

bsakaguchi commented

2026-10-15 18:26:58 +00:00

Author

Owner

@thotganesh commented on GitHub (Oct 13, 2026):

Thanks @mahaloz , for the clarification — good to know the CLI is the intended path. I'll leave it there.

@thotganesh commented on GitHub (Oct 13, 2026): Thanks @mahaloz , for the clarification — good to know the CLI is the intended path. I'll leave it there.

bsakaguchi commented

2026-10-15 18:26:58 +00:00

Author

Owner

@morluto commented on GitHub (Oct 14, 2026):

cc @N0zoM1z0 @kaoru0822-kitauji

@morluto commented on GitHub (Oct 14, 2026): cc @N0zoM1z0 @kaoru0822-kitauji

bsakaguchi commented

2026-10-15 18:26:58 +00:00

Author

Owner

@CassieFox23 commented on GitHub (Oct 15, 2026):

TL;DR: I timed kuna (Apache-2.0) and Ghidra (Apache-2.0) on the same two Windows files. On a 3.2 MB file, kuna decompiled every function in 24 seconds with 8 workers, and Ghidra took 100 seconds on one thread. On a 10 MB file, kuna finished in 16 to 31 minutes, and Ghidra did not finish under our memory cap.

I ran decompile-project with its default of 1 worker, and it took 86 seconds on the 3.2 MB file. I also ran decompile-all --jobs 8.

The 3.2 MB file is CrashLoggerSSE 1.25.0 (MIT). The 10 MB file is Skyrim A-Pose Fix 1.0.0.0 (GPL-3.0). Median of 3 runs on the 3.2 MB file, Ghidra heap 8 GB:

Job	kuna	Ghidra
One function	304 ms	37.84 s
List functions	923 ms	38.69 s
Every function to C	23.68 s (8 workers)	99.93 s

Ghidra's first two rows are mostly auto-analysis of the whole file (32 to 34 s). Its decompile script uses one thread.
With C: kuna 2,934 of 2,936 functions, Ghidra 2,922 of 2,923.
The tools count functions differently (kuna 3,404 listed, Ghidra 2,923). I have not reconciled them. I did not read the C for quality.

On the 10 MB file (one pass each, under load): kuna decompile-all --jobs 8 took 16 min 27 s, and decompile-project took 30 min 46 s. Ghidra hit our 12 GB memory cap or the 40 minute limit in all three jobs. Those cells say "did not finish under our cap". They are not a Ghidra speed.

These are first results, and more tests are coming. Ghidra on the 10 MB file will be rerun with a smaller heap on a quiet box. "Under load" means the 1-minute load went over 4. Load is the average number of programs running or waiting for a core, and this box has 24 threads. The 3.2 MB rows started at a load of 2 or less. One of the three 8-worker runs went over 4 while it ran, and all three took 23.4 to 23.9 s.

Not run

decompile-project --jobs: not timed.
Ghidra on the 10 MB file: no result yet.
Reading the C for quality.

Thanks, mahaloz, for suggesting decompile-project.

The full tables, commands and test setup are in the Show and tell post.

🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

@CassieFox23 commented on GitHub (Oct 15, 2026): **TL;DR:** I timed kuna (Apache-2.0) and Ghidra (Apache-2.0) on the same two Windows files. On a 3.2 MB file, kuna decompiled every function in 24 seconds with 8 workers, and Ghidra took 100 seconds on one thread. On a 10 MB file, kuna finished in 16 to 31 minutes, and Ghidra did not finish under our memory cap. I ran `decompile-project` with its default of 1 worker, and it took 86 seconds on the 3.2 MB file. I also ran `decompile-all --jobs 8`. The 3.2 MB file is CrashLoggerSSE 1.25.0 (MIT). The 10 MB file is Skyrim A-Pose Fix 1.0.0.0 (GPL-3.0). Median of 3 runs on the 3.2 MB file, Ghidra heap 8 GB: | Job | kuna | Ghidra | |---|---|---| | One function | 304 ms | 37.84 s | | List functions | 923 ms | 38.69 s | | Every function to C | 23.68 s (8 workers) | 99.93 s | - Ghidra's first two rows are mostly auto-analysis of the whole file (32 to 34 s). Its decompile script uses one thread. - With C: kuna 2,934 of 2,936 functions, Ghidra 2,922 of 2,923. - The tools count functions differently (kuna 3,404 listed, Ghidra 2,923). I have not reconciled them. I did not read the C for quality. On the 10 MB file (one pass each, under load): kuna `decompile-all --jobs 8` took 16 min 27 s, and `decompile-project` took 30 min 46 s. Ghidra hit our 12 GB memory cap or the 40 minute limit in all three jobs. Those cells say "did not finish under our cap". They are not a Ghidra speed. These are first results, and more tests are coming. Ghidra on the 10 MB file will be rerun with a smaller heap on a quiet box. "Under load" means the 1-minute load went over 4. Load is the average number of programs running or waiting for a core, and this box has 24 threads. The 3.2 MB rows started at a load of 2 or less. One of the three 8-worker runs went over 4 while it ran, and all three took 23.4 to 23.9 s. ### Not run - `decompile-project --jobs`: not timed. - Ghidra on the 10 MB file: no result yet. - Reading the C for quality. Thanks, mahaloz, for suggesting `decompile-project`. The full tables, commands and test setup are in the [Show and tell post](https://github.com/morluto/rea/discussions/3858). 🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

bsakaguchi commented

2026-10-15 18:26:59 +00:00

Author

Owner

@CassieFox23 commented on GitHub (Oct 15, 2026):

Where kuna support stands now, so this thread has the links in one place:

#3832 (merged) adds kuna ready checks, a rea doctor line and a project cache. Its commit says "Refs #1957".
#3854 (open, on its final CI run) serves REA's function, pseudocode and assembly tools from kuna. It uses kuna decompile-project, the CLI path suggested above. It takes ELF and Mach-O files. Windows PE files are refused for now.
#3855 (open) documents the provider.
My kuna, rsleigh and Ghidra benchmark is in #3858.

Once #3854 and #3855 merge, this may be ready to close. PE support would be a follow-up.

🤖 Generated with Claude Code (Opus 5.5) 🦊

@CassieFox23 commented on GitHub (Oct 15, 2026): Where kuna support stands now, so this thread has the links in one place: - #3832 (merged) adds kuna ready checks, a `rea doctor` line and a project cache. Its commit says "Refs #1957". - #3854 (open, on its final CI run) serves REA's function, pseudocode and assembly tools from kuna. It uses `kuna decompile-project`, the CLI path suggested above. It takes ELF and Mach-O files. Windows PE files are refused for now. - #3855 (open) documents the provider. - My kuna, rsleigh and Ghidra benchmark is in #3858. Once #3854 and #3855 merge, this may be ready to close. PE support would be a follow-up. 🤖 Generated with Claude Code (Opus 5.5) 🦊

bsakaguchi referenced this issue

2026-10-16 21:14:46 +00:00

[PR #651] [MERGED] fix(setup): align Node runtime checks with package engines #2139

bsakaguchi

2026-10-31 00:29:24 +00:00

closed this issue
added
enhancement
and removed
enhancement
labels

bsakaguchi commented

2026-10-31 00:29:25 +00:00

Author

Owner

@morluto commented on GitHub (Oct 18, 2026):

Closing as completed by c1fd496e6 on main.

Kuna provider integration landed through #3832, #3854 and #3855: readiness/doctor, owned cache, procedure inventory, pseudocode and assembly are integrated. This completes the integration request. Broader format support and the independent Kuna defects remain follow-up work; this does not claim PE support or benchmark superiority.

This is source/history reconciliation using the existing validation record; no new local test or provider run is claimed.

@morluto commented on GitHub (Oct 18, 2026):  Closing as completed by [c1fd496e6](https://github.com/morluto/rea/commit/c1fd496e6a1d3a08b30ee0f2157e827bb1049b58) on `main`. Kuna provider integration landed through #3832, #3854 and #3855: readiness/doctor, owned cache, procedure inventory, pseudocode and assembly are integrated. This completes the integration request. Broader format support and the independent Kuna defects remain follow-up work; this does not claim PE support or benchmark superiority. This is source/history reconciliation using the existing validation record; no new local test or provider run is claimed.

bsakaguchi referenced this issue

2026-10-31 00:30:27 +00:00

[GH-ISSUE #3442] [Workflow] Consider raising concurrent open PR cap or allowlisting active contributors #1285

Rows
Columns

[GH-ISSUE #1957] [Feature] Consider alternative to Ghidra/Hopper/Hex-Rays: Kuna #651

Before submitting

Area

Current limitation

Use cases

Desired outcome and success criteria

Authority boundaries and non-goals

Alternatives considered

Possible direction

References

Decompiler Evaluation & Provider Feasibility Review

Not run