PAPER REVIEW
DecLLM
LLM-Augmented Recompilable Decompilation
for Enabling Programmatic Use of Decompiled Code
ISSTA 2025
Proc. ACM Softw. Eng. Vol.2, ISSTA081, pp.1841–1864
Wai Kin Wong, Daoyuan Wu, Huaijin Wang, Zongjie Li, Zhibo Liu, Shuai Wang (HKUST)
Qiyi Tang, Sen Nie, Shi Wu (Tencent Keen Security Lab)
THE PROBLEM
Decompiler output is readable, but does not compile
IDA Pro and Ghidra optimize for readability.
Good enough for a human analyst — but a machine cannot reuse it.
1
Undefined types and global symbols
2
Phantom references the decompiler invented
3
Incorrectly inferred function signatures
4
Syntax the compiler rejects
// Ghidra / IDA Pro output
undefined8 FUN_00101189(void)
{
undefined auStack_28 [32];
__isoc99_scanf(&DAT_00102004,
auStack_28);
process(&dword_0);
return 0;
}
$ gcc out.c
error: unknown type 'undefined8'
error: 'DAT_00102004' undeclared
error: 'dword_0' undeclared
MOTIVATION
Recompilable output unlocks source-level tooling
1
Binary
the analysis target
▶
2
Decompiler output
will not compile
▶
3
DecLLM repair
iterative loop
▶
4
Recompiles
CodeQL now applies
CodeQL-based vulnerability analysis requires a compilable version
That is analysis you cannot run on a binary directly. Recompilation closes the gap.
PILOT STUDY (§3)
"Can't we just ask an LLM to fix it?" — No.
The starting point
17.3%
A one-shot LLM recompiled only 52 of 300 binaries.
More than half of the failures clustered in one category — which is where the case for an iterative loop comes from.
PRIOR WORK
Everything before this optimized readability
APPROACH
REPRESENTATIVE
GOAL
WHAT IT LEAVES OPEN
Traditional decompilers
IDA Pro, Ghidra
Readability for analysts
Output does not compile
Rule-based repair
heuristic fixes
Recompilability
8% success — too brittle
Neural decompilation
LLM4Decompile, SLaDe, Nova
Regenerate source end-to-end
Judged on re-executability, not integration
LLM refinement
DeGPT (NDSS'24)
Readability via LLM
Still not compilable
Same authors' precursor
DecGPT (2023)
Recompilability
Static feedback only
DecLLM's position: the first to treat recompilability as the primary objective, using off-the-shelf LLMs and both static and dynamic feedback.
FRAMEWORK (§4)
Architecture
Stripped binary
Decompiler · IDA Pro / Ghidra
LLM · GPT-3.5 / GPT-4
no fine-tuning, no training corpus
① STATIC · recompile
compiler errors collected
② DYNAMIC · execute
tests · AddressSanitizer · fuzzing
Recompilable C code
compiler errors
runtime mismatch
CodeQL analysis
+ headers extracted
from source
off-the-shelf,
prompted only
loop repeats until
both checks pass
Red annotation marks the step that makes the pipeline not fully source-free — discussed in the critique.
DESIGN (§4)
An iterative repair loop with two oracles
Decompiler output
STATIC REPAIR
Recompile, then feed the compiler error messages back into the prompt
multiple rounds
DYNAMIC REPAIR
Execute, detect semantic inconsistency, feed it back
after compilation succeeds
▶
▶
No fine-tuning. GPT-3.5 and GPT-4 are used off the shelf.
No training corpus is required, and success is judged by the compiler and the runtime — not by string comparison against ground-truth source.
DESIGN (§4)
What Dynamic Repair actually uses
1
Test cases
I/O mismatch detection
Compares expected against observed output
2
AddressSanitizer
Memory error detection
ASAN messages go straight into the prompt
3
Fuzzing
Input-space exploration
Reaches paths the test suite misses
The three together detect semantic inconsistency, and the result feeds the next round's prompt.
CASE STUDY (§6)
A real repair — fixing the decompiler's own defect
BEFORE
process(&dword_0);
// phantom global invented by the decompiler
AFTER
process(0);
// substituted after reading the ASAN message
▶
WHAT THE PAPER REPORTS
Given the ASAN error message alongside the decompiler output, DecLLM substituted a constant for the phantom reference, eliminating a runtime fault that originated in the decompiler itself.
→ The LLM corrected a defect in its input, not one of its own.
DESIGN TRADE-OFF (§6)
Whole file, or one function at a time?
Whole-file
used for benchmark evaluation
＋ Global context is available
＋ Undefined globals can be inferred
－ The LLM introduces memory corruption
－ Errors entangle across functions
Per-function
used for real-world binaries
＋ Far less noise in the prompt
＋ Zero memory-corruption cases
－ Cannot infer undefined globals
－ Cannot fix type-inference errors
The paper notes that a single function per prompt reduces noise, but rules out inferring undefined globals and repairing type-inference errors.
DATASET (§5)
Three corpora, three different jobs
DATASET
CHARACTER
WHY IT IS IN THE PAPER
WHAT IT CANNOT SHOW
Code Contest
small, self-contained, ships with tests
the I/O pairs make dynamic repair possible at all
nothing about real software
GNU Coreutils
real utilities, cross-function state
the actual stress test — and the costliest to repair
still open-source, symbols available
DARPA CGC
purpose-built vulnerable binaries
ground-truth flaws for the CodeQL study
synthetic by construction
300
binaries (pilot / RQ1)
2
decompilers · IDA Pro, Ghidra
2
LLMs · GPT-3.5, GPT-4
O0–O3
optimization levels
Read the fourth column. Two of three corpora are synthetic or exercise-scale, and all three are open-source with symbols. No stripped, obfuscated, commercial or firmware binaries appear anywhere.
DATASET (§5)
Research Questions
RQ 1: Effectiveness of DecLLM
RQ 2: Real-World Applications
RQ 3: Error Analysis of Hard Cases
RQ1 · BENCHMARKS
RQ1 — iteration is what moves the number
APPROACH
MECHANISM
RECOMPILED
WHY IT STALLS THERE
DecRule
rule-based heuristic fixes
8%
cannot handle the error classes decompilers emit
DeGPT
readability-oriented LLM
10%
its edits add comments, not fixes
One-shot LLM
single prompt, no feedback
17.3%
52 of 300 — no signal telling it what broke
DecLLM
iterative loop, two oracles
74%
feedback closes the gap
The delta that matters
17.3% → 74%
Same models, same prompts. The only change is that failures are fed back. This isolates the loop as the mechanism — the cleanest result in the paper.
But note the comparison
DeGPT was never designed for recompilability — it optimizes readability. Reporting it at 10% compares a tool against a goal it never claimed. The honest baseline is the one-shot LLM at 17.3%.
RQ1 · BENCHMARKS
RQ1 — iteration is what moves the number
APPROACH
MECHANISM
RECOMPILED
WHY IT STALLS THERE
DecRule
rule-based heuristic fixes
8%
cannot handle the error classes decompilers emit
DeGPT
readability-oriented LLM
10%
its edits add comments, not fixes
One-shot LLM
single prompt, no feedback
17.3%
52 of 300 — no signal telling it what broke
DecLLM
iterative loop, two oracles
74%
feedback closes the gap
The delta that matters
17.3% → 74%
Same models, same prompts. The only change is that failures are fed back. This isolates the loop as the mechanism — the cleanest result in the paper.
But note the comparison
DeGPT was never designed for recompilability — it optimizes readability. Reporting it at 10% compares a tool against a goal it never claimed. The honest baseline is the one-shot LLM at 17.3%.
RQ2 · REAL-WORLD BINARIES
RQ2 — every baseline scores exactly zero
METHOD
COREUTILS
CGC
WHY
DecRule
0
0
cannot handle the errors in decompiler output
DeGPT
0
0
its changes only add comments
LLM4Decompile-ref
0
0
produces conflicting content that will not compile
DecLLM (GPT-3.5)
69
83
62.8% overall
DecLLM (GPT-4)
76
95
70.7% overall
What the zeros really say
No prior method recompiled a single real binary. That makes the contribution unambiguous — but it also leaves no baseline to measure against. A jump from zero cannot be graded.
Sanity check on the totals
(69+83)/62.8% ≈ (76+95)/70.7% ≈ 242
Both rows imply the same denominator, so the reported averages are internally consistent — about 242 real-world binaries.
Counts are from the paper's Table 5. The 242 total is derived from the reported percentages, not stated directly.
RQ3 · FAILURE ANALYSIS
RQ3 — the remaining 30% is not the model's fault
FAILURE SOURCE
COUNT
LAYER RESPONSIBLE
Decompiler cannot distinguish addresses from data
10 of 32
decompiler front-end
Remaining categories in the paper's taxonomy
22 of 32
mixed — see §8
Why this is the most reusable finding in the paper
Nearly a third of the hard failures originate before the LLM is ever invoked. Scaling the model, improving the prompt, or adding more rounds cannot recover information the decompiler already destroyed.
The implication the paper does not draw:
if variable and type recovery is the binding constraint, then work on those — not on better repair loops — is where the remaining headroom lives.
Only the address/data category is quantified in the material available here; the full taxonomy is in §8 of the paper.
DATASET (§5)
Three corpora, three different jobs
Code Contest
competitive programming
Small, self-contained programs that ship with test cases.
Why: the I/O pairs make dynamic repair possible at all.
GNU Coreutils
real-world utilities
Larger programs with system calls and cross-function state.
Why: the stress test. The paper notes these cost sharply more — they carry more errors.
DARPA CGC
Cyber Grand Challenge
Purpose-built vulnerable binaries with known flaws.
Why: gives ground-truth vulnerabilities for the CodeQL evaluation.
300 binaries (RQ1 set) · 2 decompilers IDA Pro, Ghidra · 2 LLMs GPT-3.5, GPT-4
Evaluating across two independent decompilers is a genuine strength — the result is not an artifact of one front-end.
RESULTS (RQ1–RQ2)
The ceiling for off-the-shelf LLMs is around 70%
74%
benchmark recompilation rate
74 of 100 previously non-recompilable outputs now compile
62.8%
GPT-3.5
real-world average
70.7%
GPT-4
real-world average
RQ3 — dissecting the failing 30%
Of 32 binaries that would not recompile, 10 failed because the decompiler could not distinguish addresses from data
Not a limit of the LLM — a defect in the input decompiler, propagated downward. When variable recovery breaks, everything above it breaks.
APPLICATION (§7)
Running CodeQL on the recompiled code
HOW IT IS VALIDATED
Not merely that it runs. The CodeQL findings on the recompiled code are compared against the findings on the original source to measure semantic consistency.
$ codeql database create db \
--language=cpp \
--command="gcc repaired.c"
$ codeql database analyze db
-> vulnerability findings
Analysis that is impossible to perform on a binary directly
The real contribution is not the accuracy figure — it is connecting the source-level tool ecosystem to binaries.
SUMMARY
Takeaways
1
It redefined the goal
Recompilability, not readability. From what a human reads to what a machine can reuse.
2
Iteration is the mechanism
One-shot LLM: 17.3%. Iterative loop: 74%. The loop produces the result, not the prompt.
3
The oracles are the compiler and the runtime
Success is decided by compilation and execution, not by comparison against ground-truth source.
4
The bottleneck was not the LLM
Many failures trace back to variable and type recovery defects in the decompiler.
DOI 10.1145/3728958 · ISSTA 2025
My Thoughts
Pros
Cons