When LLM Decompilers Recompile More and Preserve Less

Paper: 2609.05370 Authors: Chang Liu, Edward Raff, Kristopher Micinski Categories: cs.CR, cs.AI

The Gap

Decompilation is the indispensable craft of reversing compiled binary machine code back into high-level human-readable C source code. It underpins malware reverse engineering, vulnerability discovery, patch verification, and firmware audits. Traditional decompilers like Ghidra or Hex-Rays IDA Pro operate on deterministic abstract interpretation. When they fail to recover a data structure or control flow, they expose ugly placeholders, complex pointer casts, or raw goto statements that often do not recompile cleanly.

The arrival of large language models sparked a revolution in decompilation. LLM-based decompilers produce beautiful, idiomatic C code with descriptive variable names and structured loops. Academic benchmarks quickly crowned this new wave, judging models almost exclusively on two metrics: recompilability (whether the generated C code builds without syntax errors) and re-executability (whether the recompiled binary passes the author’s shipped unit tests).

This paper exposes the lethal hazard behind those metrics. A decompiled function can easily recompile and pass a handful of simple happy-path unit tests, while completely corrupting the binary’s actual semantic behavior on edge cases. Worst of all, when decompiling binaries containing documented memory corruption vulnerabilities, LLM decompilers routinely rewrite tricky pointer arithmetic into clean, sanitized buffers. The vulnerability vanishes from the source code, blinding malware analysts and security auditors to the real exploit.

[COMPILED MACHINE CODE] Contains subtle pointer arithmetic & boundary vulnerability
             |
             +------------------------------+------------------------------+
             v                                                             v
  [TRADITIONAL: GHIDRA / IDA]                                   [LLM DECOMPILER]
  Messy, uncompilable pseudocode                                Beautiful, idiomatic C code
  - Exposes raw memory offsets                                  - 95%+ Recompilability score
  - Preserves exact crashing paths                              - Passes basic unit tests
  - Hard for humans to read quickly                             - BUT: "smooths over" unsafe logic
             |                                                             |
             v                                                             v
  True Vulnerability Preserved                                  Vulnerability Silently Erased!

The Increment

One sentence: Before this paper, high recompilability was celebrated as the gold standard of LLM decompilation; after it, the Syracuse and CrowdStrike team proves that recompilability actively incentivizes models to hallucinate safe code, demonstrating that LLM decompilers frequently recompile more while preserving less semantic reality.

Core Mechanism

The authors formalize this divergence through Decompile-Diverge, a differential fuzzing and behavioral auditing oracle designed specifically for decompiled code.

Rather than relying on limited, author-supplied test suites, Decompile-Diverge pairs the original compiled binary and the recompiled LLM candidate, feeding them hundreds of thousands of inputs generated via LibFuzzer-guided differential testing:

1. Differential Execution Oracle: The fuzzer executes both binaries side-by-side with identical inputs, comparing return values, memory writes, and standard output streams to uncover behavioral deviation.
2. Crash & Vulnerability Preservation Auditing: The framework feeds known proof-of-concept exploit payloads into both binaries. In numerous instances, the original binary crashed with a segmentation fault or buffer overflow, whereas the LLM-recompiled binary completed cleanly because the LLM had replaced dynamic pointer bounds with fixed, safe array indices.
3. Semantic Inversion Diagnosis: The authors discovered that refinement models and end-to-end models regularly substitute tricky loops with standard textbook algorithms that look plausible but implement the opposite control logic.

   DECOMPILE-DIVERGE AUDITING PIPELINE

           [Original Binary (C)]
                     |
       +-------------+-------------+
       |                           |
       v                           v
  [Test Input / Fuzzing]     [Decompiler] -> [LLM Recompiled Binary (C')]
       |                                              |
       +--------------------+-------------------------+
                            |
                            v
            [Differential Behavioral Oracle]
                            |
         +------------------+------------------+
         v                                     v
   [Semantic Divergence]             [Vulnerability Erasure]
   Output C != Output C'             Original Crashes;
   on edge-case inputs               Decompiled Code Silently Passes

To understand why this happens, consider a structural metaphor of a restoration artist fixing a damaged ancient manuscript. A traditional conservator leaves torn edges, stained parchment, and missing words as blank spaces with bracketed question marks. It is ugly and unreadable as a bedtime story, but a historian can see exactly what survived. An LLM restorer is an overly eager apprentice who fills every torn paragraph with smooth, lyrical prose. The resulting book reads effortlessly and wins awards for grammar, but the apprentice has accidentally written out the murder confession that was the sole reason detectives were inspecting the scroll.

Key Concepts

• Recompilability Illusion: The false assumption that because decompiled source code builds without compiler errors, it must accurately represent the behavior of the source binary.
• Vulnerability Erasure: The failure mode where an LLM decompiler replaces unsafe pointer operations or buffer offsets with sanitized idioms, causing security analysts to miss critical flaws.
• Differential Behavioral Fuzzing: Testing original and decompiled binaries against extensive randomized edge-case inputs to identify functional divergences that escape static unit tests.

Framework Shift

Before (Current LLM Decompiler Evaluation):
Assembly -> [LLM] -> C Code -> `gcc C Code` -> [Passes Build?] -> High Score!
(Rewards hallucinated safe code that compiles easily)

After (Decompile-Diverge Differential Protocol):
Assembly -> [LLM] -> C Code -> [Differential Fuzzing vs Original Binary]
                                            |
                         +------------------+------------------+
                         v                                     v
                 [Semantic Fidelity]                 [Exploit Preservation]

From rewarding superficial syntactic validity to enforcing differential runtime equivalence under adversarial inputs, the core shift is unmasking the aesthetic hallucinations of LLM code models.

Expert Assessment

Problem choice: Crucial for the software security industry. Decompilation tools are used in high-stakes environments where believing an inaccurate decompilation can lead to disastrous false-negative vulnerability assessments.

Method maturity: Using LibFuzzer differential execution provides an objective, uncheatable ground truth that does not rely on LLM judges.

Experimental integrity: The inclusion of CrowdStrike malware engineers grounds the paper in operational reality. The case studies showing real CVEs vanishing in recompiled source are deeply alarming.

Writing quality: Exceptional clarity. The distinction between syntax recovery, operational re-executability, and deep semantic equivalence is articulated with surgical precision.

Verdict: strong accept — Essential reading for any team applying LLMs to reverse engineering or program analysis.

Takeaways

• Never trust an LLM decompiler for vulnerability audits without cross-verifying against raw Ghidra/IDA assembly offsets.
• High recompilability is often an inverse indicator of faithfulness: models that try to guess missing types often hallucinate away tricky edge-case bugs.
• Benchmark designers for code generation must abandon shallow unit tests in favor of differential fuzzing against the original executable.