Kuna: Decompiler Development in the Age of Coding Agents
11–20 of 24 posts
Re: Kuna: Decompiler Development in the Age of Coding Agents
#12Not sure why someone would want to use an LLM to build a new decompiler instead of training an LLM to BE a decompiler. Especially given the fact that you have an infinite training set to train that LLM from (compilers can generate as much training data as you could possibly want).
I read this less as “build a decompiler with an LLM instead of training one to decompile,” and more as a different loop: you still get an artifact you can measure and improve against IDA / Ghidra / angr. Training on infinite compiler data is powerful for the first path; this post is mostly about the second one (i think, but i could wrong).
Re: Kuna: Decompiler Development in the Age of Coding Agents
#13Re: Kuna: Decompiler Development in the Age of Coding Agents
#14Not sure why someone would want to use an LLM to build a new decompiler instead of training an LLM to BE a decompiler. Especially given the fact that you have an infinite training set to train that LLM from (compilers can generate as much training data as you could possibly want).
Re: Kuna: Decompiler Development in the Age of Coding Agents
#15Re: Kuna: Decompiler Development in the Age of Coding Agents
#16Kuna is originally Ghidra ported to Rust, but it has changed quite a bit since. The results shown in the screenshot on the site are not a feature in Ghidra, which includes the Switch layout and some of the variable simplification. It's from Ghidra, previously talked about here [1].
> It would be cool to see agentic interpretation of function and variable names.
On DecBench, which I also created last week, you can see just that for Codex and Claude when given only assembly [2]. They dominate, but also have some significant recall problems.
> Why not train an LLM to be a decompiler instead of make one
Over the last two decades, this has been attempted _many_ times [3]. To date, there has been no successful project/paper that can compete with traditional decompilers on fundamental metrics. I speculate this is due to their inability to abstract the many-to-one mapping of optimization to code. This can change, but I desired to take a different approach.
If frontier labs continue to get better, they will become the de facto decompilation users. Why not get LLMs to help LLMs? Design a core decompiler that helps them more than others :).
[1]: https://www.youtube.com/watch?v=VP29biKLoSw
[2]: https://decbench.com/leaderboard/?dataset=sample-set
[3]: https://decompilation.wiki/fundamentals/neural-decompilation...
Re: Kuna: Decompiler Development in the Age of Coding Agents
#17Haven't used IDA much lately, but after looking at the screenshot with that IDA PRO decompiled code in their website I feel like Ghidra is already ahead of them in this area :D
Re: Kuna: Decompiler Development in the Age of Coding Agents
#18It would be cool to see agentic interpretation of function and variable names. It can see and track the flow of data a lot faster than a human can so if given some context, maybe it could synthesize names for them.
Re: Kuna: Decompiler Development in the Age of Coding Agents
#19Not sure why someone would want to use an LLM to build a new decompiler instead of training an LLM to BE a decompiler. Especially given the fact that you have an infinite training set to train that LLM from (compilers can generate as much training data as you could possibly want).
Re: Kuna: Decompiler Development in the Age of Coding Agents
#20Haven't used IDA much lately, but after looking at the screenshot with that IDA PRO decompiled code in their website I feel like Ghidra is already ahead of them in this area :D
Based on today's results, IDA Pro is ahead by 15 percentage points, which would mean, statistically, IDA Pro will recover perfect source code for 15% more functions than Ghidra on average.