[ur-whale]

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

[mahaloz]

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.