When LLM Decompilers Recompile More and Preserve Less

Forum topic · 小凯 · 2026-09-09

Summary

This paper examines LLM-based decompilers, which are now judged almost entirely by recompilability and re-executability — whether their output builds and passes shipped input/output tests. The authors show these metrics can reward the wrong path: a function may recompile and pass every shipped test yet diverge on other legitimate inputs, and a disclosed vulnerability may silently disappear from the recompiled code. To close this evaluation gap, they propose Decompile-Diverge, a behavioral-comparison oracle that synthesizes per-function drivers, grows a fuzzing corpus from a reference implementation, and re-runs decompiled code on the same inputs to detect behavioral changes. Across eight systems in nine configurations, candidates that passed all shipped tests still diverged on the authors' corpus in 4.9% of cases overall, up to 13% for a single system. On 300 real GitHub library functions and 287 CVE-related functions, recompilability and behavioral fidelity diverge: the strongest distilled LLM raised Ghidra's build rate from 75% to 90% while match rate fell from 74% to 62%, and up to one in ten disclosed vulnerabilities showed crash-absence in its output. Source-level analysis attributes divergence to introduced fields, types, callees, and guards.

When LLM Decompilers Recompile More and Preserve Less

Field: ML Authors: Chang Liu, Edward Raff, Kristopher Micinski Published: 2026-09-04 arXiv: 2609.05370

Summary

Decompilation recovers high-level source from compiled machine code and serves as a foundation for security tasks such as vulnerability detection and malware analysis. Traditional decompilers like Ghidra and Hex-Rays expose whatever they cannot resolve as visible placeholders and often emit pseudocode that will not compile or execute. LLM-based decompilers produce clean, idiomatic C and are now judged almost entirely by recompilability and re-executability: whether the output builds and passes its shipped input/output tests.

This paper shows that these metrics can reward the wrong path: a function may recompile and pass every shipped test yet diverge on other legitimate inputs, and a disclosed vulnerability may disappear from the recompiled code with no visible trace of the crash. No existing benchmark captures these failures.

To address this gap, the authors propose Decompile-Diverge, a behavioral-comparison oracle that does not rely on fixed or hand-written tests: it synthesizes drivers for each function, grows a fuzzing corpus from a reference implementation, and re-runs the decompiled code on the same inputs to detect changes in function behavior.

Key findings

Across eight systems in nine configurations, candidates that passed all shipped tests still diverged from the original implementation on the authors' input corpus: 4.9% overall, up to 13% for a single system.
On 300 real GitHub library functions and 287 CVE-related functions, recompilability and behavioral fidelity can come apart: the strongest distilled LLM raised Ghidra's build rate from 75% to 90%, while the match rate dropped from 74% to 62%.
Up to one in ten disclosed vulnerabilities exhibited crash-absence in the LLM output — the bug silently disappears.
Source-level analysis attributes the divergence to introduced fields, types, callees, and guards, which replace the visible unknowns left behind by traditional tools.

---

*Auto-collected on 2026-09-09*

When LLM Decompilers Recompile More and Preserve Less

Summary

When LLM Decompilers Recompile More and Preserve Less

Summary

Key findings

Tags