How to make REA use Kuna as decompiler when Ghidra runs headless

3 answers

• Best answerAgentArmor teamTeam3d ago

  Status: fixed. Kuna support shipped in REA through #3832, #3854 and #3855: readiness/rea doctor checks, a project cache, and function, pseudocode, and assembly retrieval via the Kuna CLI (kuna decompile-project). The merged provider takes ELF and Mach-O files; Windows PE is refused for now. The Kuna author stated in the thread that the intended integration path is the CLI, not a Ghidra provider swap.

  Until the native provider existed, one headless prototype worked with Ghidra 12.1.2, Kuna v1.818 and REA 3.1.0: swap Kuna's kuna_ghidra binary into the headless Ghidra decompiler directory so REA's existing Ghidra provider calls Kuna underneath.

  bashCopy to clipboard

  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
  

  Then rea decompile /bin/ls 0x104740 returned Kuna output through procedure_pseudo_code, with a /* Kuna v1.818 */ marker. Rollback is copying decompile.ghidra.orig back over decompile. Limitations confirmed in the thread: the swap is install-wide, REA still reports provider: ghidra, version: 12.1.2, and only one function on one binary was verified. The Kuna author recommended the CLI workflow kuna decompile-project ./my_binary --jobs 10 (also spelled decompiler-project) as the intended path. General advice: replacing a binary inside a tool install runs third-party code on everything that install decompiles, so keep the backup; now that the native provider is merged, prefer it over the swap.

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmor teamTeam3d ago

  What @thotganesh tried on GitHub (Worked)

  Replaced Ghidra 12.1.2's headless decompile binary with Kuna's kuna_ghidra binary and set KUNA_SPECS, so REA's Ghidra provider ran Kuna. rea decompile returned Kuna pseudocode, but the swap was install-wide and REA still reported the Ghidra provider identity.

  Source: https://github.com/morluto/rea/issues/1957#issuecomment-6148514202 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmor teamTeam3d ago

  What @CassieFox23 tried on GitHub (Outcome unclear)

  Benchmarked kuna decompile-project and decompile-all --jobs 8 against Ghidra on two Windows binaries. Kuna was faster on a 3.2 MB file (23.68 s vs 99.93 s for all functions), but Ghidra hit the memory/time cap on a 10 MB file, function counts differed, and C output quality was not read. First results only.

  Source: https://github.com/morluto/rea/issues/1957#issuecomment-6185035952 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport