Kuna：Coding Agent 时代的反编译器开发

介绍 Kuna 发布背后的背景、动机与思考。Kuna 是一款面向 Agent 优先设计、可进行自主改进的新型反编译器。

今天，我发布了 Kuna：这是我在夏季担任美国空军研究实验室（AFRL）访问教师研究员、Metalware研究员期间开发的一款实验性反编译器。不过，当我说“我一直在开发”它时，需要澄清一点：这个项目中几乎每一行代码都是由 LLM 编写的。

不过，就目前而言，在 C 程序的控制流结构化能力上，这款反编译器已经可以与行业标准 IDA Pro（9.2）匹敌：根据近期基准测试结果，Kuna 可在 44.4% 的函数上实现完美结构化，而 IDA 的这一比例为 45.7%。这在很大程度上得益于自主改进：LLM 会研究自己在基本指标上表现逊于 IDA Pro 的样例，而这些指标是在过去几年中才出现的。通过这种策略，它能够借助试错，有效地“学习”另一款反编译器如何解决困难问题。

IDA Pro 也并非这一改进过程中唯一被研究的反编译器。这项大规模改进实验还涉及 Ghidra 与 angr 反编译器；我在博士期间一直是后者的核心开发者，相关经历可见这里。这种学习方法使 LLM 能够在 Kuna 中重新实现 angr 的 20 多项基础功能，而这些功能是我们经过多年努力、依靠反编译领域的科学进展才设计出来的。我强调这些，是为了说明该项目并不只是“垃圾产出（slop）”：这是一种真正的实验性方法，用于开发一款具有科学研究价值、并且能够自动变得更好的工具。

Kuna 与 Hex-Rays 的片段对比，展示 angr 中一项常用的 switch 功能

话虽如此，我也希望承认这种方法的局限性，以及这项工作可能会如何影响研究社区。

首先，Kuna 的诞生离不开科学家和工程师数十年来推动反编译研究的长期努力。Kuna 实际上是 NSA 的 Ghidra 的 Rust 移植版本，并经过重构，使其更接近 angr 的流水线。这也是我近期不打算离开 angr 反编译器的原因。angr 反编译器仍是我开发前沿反编译算法时首先使用的工具，因为它本就是为此而设计的。

另一方面，Kuna 是一项_实验_，旨在观察仅凭高层次科学反馈能够实现什么。现阶段，在 Kuna 中手写任何内容都会明显更加困难。Kuna 需要 angr（以及其他开源研究成果）；而我希望经过更多时间后，angr 也会需要 Kuna——前提是这项实验取得成功。

第二，Kuna 即便要开始“自动”改进，也需要科学洞见，这或许解释了为何据我所知，尚无其他反编译器采取这种做法。走到这一步，需要发现新的基础指标，研究什么结果符合人工逆向工程的价值判断，并通过多年的洞察来理解一项有意义的基准测试需要怎样的数据。简言之：这同样不是_自动化研究_；它仍需要由人类主导的研究。

第三，也是最后一点，这款反编译器仍有大量进步空间。我们在结构化方面表现不错，但反编译并不只有结构化！我们还需要改善类型、优化、可重新编译性、变量识别……你明白我的意思。这终究是一项实验，目的是验证能否在用于开发 Kuna 的框架下实现所有这些目标。而我（我们）非常需要你的帮助。

如果你对 Kuna 的内部机制、项目目标，或自动改进的工作方式感兴趣，可以查看代码，或者等待后续更具技术深度的文章。与往常一样，我想感谢那些帮助我完善想法、推动研究向前发展的人。我的博士生导师 Fish 和 Yan 是我研究工作最重要的灵感来源。我也感谢 Metalware、AFRL 和美国国防部提供的洞见，它们帮助我的研究产生实际影响。

实验的下一处检查点再见！

Blog

Kuna: Decompiler Development in the Age of Coding Agents

Background, motivation, and thoughts around the release of Kuna, a new agent-first decompiler designed for autonomous refinement.

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!