Kuna: Decompiler Development in the Age of Coding Agents • Hacker News Board

Re: Kuna: Decompiler Development in the Age of Coding Agents

#21

Post by ur-whale » Thu, Jul 30, 2026, 10:22 PM UTC

Rexxar wrote: post #19

ur-whale wrote: post #10

Not 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).

There is no point to have an LLM do what can be done faster and deterministically by standard algorithms.

> There is no point to have an LLM do what can be done faster and deterministically by standard algorithms

I think using the word "deterministically" in the context of decompilation is not a particularly good idea.

The code generated by a compiler can be arbitrarily complex and arbitrarily varied even before you take into account willful attempts at obfuscation to protect against reverse-engineering (for example, try futzing with compiler optimization flags to see how much the ASM changes).

The "high-level code to assembly" operator is thus not even really a function (same high level code can generate infinite variation of functionally equivalent assembly code) and any attempt at producing an inverse of this operator ... this really does not strike me as an environment where the word "deterministic" seems appropriate.

Re: Kuna: Decompiler Development in the Age of Coding Agents

#22

Post by ur-whale » Thu, Jul 30, 2026, 10:28 PM UTC

Tepix wrote: post #14

ur-whale wrote: post #10

Not 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).

LLMs are famously inefficient, expensive and unreliable.

> LLMs are famously inefficient, expensive and unreliable.

Maybe, but here I am suggesting an LLM specifically trained to do only machine code to high-level code reverse engineering.

I suspect this can be made both efficient and very reliable.

Especially given the fact that there is very often a path the verify if what the LLM produces is a valid answer (by testing if the high level code produced by the LLM, when compiled, behaves like the original machine code).

Re: Kuna: Decompiler Development in the Age of Coding Agents

#23

Post by mahaloz » Thu, Jul 30, 2026, 10:49 PM UTC

ur-whale wrote: post #22

Tepix wrote: post #14

Earlier quoted context omitted.

LLMs are famously inefficient, expensive and unreliable.

> LLMs are famously inefficient, expensive and unreliable. Maybe, but here I am suggesting an LLM specifically trained to do only machine code to high-level code reverse engineering. I suspect this can be made both efficient and very reliable. Especially given the fact that there is very often a path the verify if what the LLM produces is a valid answer (by testing if the high level code produced by the LLM, when com…

Answered above, but the gist is people have tried: https://decompilation.wiki/fundamentals/neural-decompilation..., and yet general LLMs from Anthropic and OpenAI appear to match or beat all of these works :(

Re: Kuna: Decompiler Development in the Age of Coding Agents

#24

Post by mahaloz » Thu, Jul 30, 2026, 10:53 PM UTC

ur-whale wrote: post #21

Rexxar wrote: post #19

Earlier quoted context omitted.

There is no point to have an LLM do what can be done faster and deterministically by standard algorithms.

> There is no point to have an LLM do what can be done faster and deterministically by standard algorithms I think using the word "deterministically" in the context of decompilation is not a particularly good idea. The code generated by a compiler can be arbitrarily complex and arbitrarily varied even before you take into account willful attempts at obfuscation to protect against reverse-engineering (for example, try…

I would call any traditional decompiler deterministic, though these can rely on probabilistic models to infer how to undo these optimizations.

A talk I did on this at Reverse Con (clipped to the important part): https://youtu.be/VP29biKLoSw?t=891

Many of these decompilers can infer what optimizations occurred by hints/patterns that are left behind.

This can be fundamentally different at times from LLMs, which have shown a degradation on unique architectures. I still believe the best approach will be a mixed method. Get 80% of the way there with traditional methods, and take the last 20% (which is the hardest) home with LLMs.