Today, I’m releasing Kuna, an experimental decompiler I’ve been developing over the summer while working as a visiting faculty researcher at the Air Force Research Lab (AFRL) and a research fellow at Metalware. However, when I say that I have been developing, I should clarify that an LLM has written nearly every line of code in this project.
Yet, as it stands now, this decompiler rivals the industry standard, IDA Pro (9.2), in control flow structuring on C programs: in recent benchmark results, Kuna achieves perfect structuring on 44.4% of functions, compared with IDA’s 45.7%. This was largely achieved through autonomous refinement: the LLM studies examples where it performs worse than IDA Pro on fundamental metrics, which have only emerged over the last few years.
Using this strategy, it can effectively learn how another decompiler solves a hard problem through trial and error. IDA Pro was also not the only decompiler studied in this improvement process. This large refinement experiment also involved Ghidra and the angr decompiler; I spent my entire PhD as a core developer of the latter. This method of learning allowed an LLM to reimplement, in Kuna, more than 20 fundamental features from angr, which took us years to design through scientific advancements in decompilation. I emphasize all of this to clarify that this project is more than just slop: it is a truly experimental approach to developing a scientifically interesting tool that gets better automatically.
A snippet from Kuna and Hex-Rays showing a popular angr switch feature
With all of that said, I also want to acknowledge limitations in this approach and how this work might affect the research community.
First, Kuna is only possible through the decades-long efforts of scientists and engineers advancing decompiler research. Kuna is, in fact, a Rust port of the NSA’s Ghidra, reworked to more closely match angr’s pipeline. That is also why I don’t plan on leaving the angr decompiler any time soon. The angr decompiler is still the first place I go to for developing frontier algorithms in decompilation, simply because it was designed for that.
Kuna, on the other hand, is an experiment in seeing what can be done with high-level scientific feedback alone. At this point, it would be significantly harder to write anything by hand in Kuna. Kuna needs angr (and other open-source research), and my hope is that, after more time, angr will need Kuna (if the experiment is a success).
Second, Kuna requires scientific insight to even begin “automatic” refinement, which likely explains why no other decompiler has done this yet (that I know of). Getting to this point required discovering new fundamental metrics, studying what aligns with human reversing values, and gathering insights over years to understand what data a meaningful benchmark requires. The gist: this is also not automatic research; it requires research led by humans.
Third, and finally, there is still significantly more progress to be made in this decompiler. We are doing well on structuring, but decompilation is more than just structuring! We need to improve types, optimizations, recompilability, variable identification… you get the idea. This is, after all, an experiment to see if it is even possible to achieve all those things within the framework we’re using to develop Kuna. And I (we) could really use your help.
If you are interested in the internals of Kuna, the goals of the project, or how automatic improvement works, go check out the code or wait for a more technical follow-up post. As always, I’d like to acknowledge those who have helped me refine my ideas and push forward the research. My PhD advisors, Fish and Yan, are the biggest sources of inspiration for my research. I am also grateful for the insights from Metalware, AFRL, and the Department of Defense, which help make my research impactful.
See you all at the next checkpoint of the experiment!