Paper deep dive
Constraint-Guided Multi-Agent Decompilation for Executable Binary Recovery
Yifan Zhang, Xiaohan Wang, Yueke Zhang, Kevin Leach
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 97%
Last extracted: 6/21/2026, 7:38:43 AM
Summary
Agent4Decompile is a multi-agent framework designed to improve the re-executability of decompiled C code from binaries. It employs a hierarchical, three-level constraint-guided refinement process: (1) Syntax validation via parsing, (2) Compilation validation via GCC, and (3) Behavioral equivalence validation via test-driven execution. When a constraint fails, specialized LLM agents use structured error feedback (e.g., GCC errors or test case diffs) to iteratively refine the code. The framework demonstrates significant improvements in re-executability over baseline decompilers (Ghidra, Angr, RetDec) and state-of-the-art LLM-based methods like LLM4Decompile, proving that execution-based validation is essential for achieving behavioral correctness.
Entities (9)
Relation Signals (6)
Agent4Decompile → outperforms → LLM4Decompile
confidence 100% · our approach (84.1%) outperforms LLM4Decompile (80.3%)
Agent4Decompile → uses → LLM
confidence 100% · The framework employs specialized LLM agents to iteratively refine the code.
Agent4Decompile → uses → ExeBench
confidence 100% · evaluating Agent4Decompile on 1,641 binaries from ExeBench
Agent4Decompile → improves → Ghidra
confidence 90% · improving baseline decompiler output by 28-89 percentage points.
Agent4Decompile → improves → Angr
confidence 90% · improving baseline decompiler output by 28-89 percentage points.
Agent4Decompile → improves → RetDec
confidence 90% · improving baseline decompiler output by 28-89 percentage points.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Decompilation -- recovering source code from compiled binaries -- is essential for security analysis, malware reverse engineering, and legacy software maintenance. However, existing decompilers produce code that often fails to compile or execute correctly, limiting their practical utility. We present a multi-agent framework that transforms decompiled code into re-executable source through Multi-level Constraint-Guided Decompilation (MCGD). Our approach employs a hierarchical validation pipeline with three constraint levels: (1) syntactic correctness via parsing, (2) compilability via GCC, and (3) behavioral equivalence via LLM-generated test cases. When validation fails, specialized LLM agents iteratively refine the code using structured error feedback. We evaluate our framework on 1,641 real-world binaries from ExeBench across three decompilers (RetDec, Ghidra, and Angr). Our framework achieves 84-97% re-executability, improving baseline decompiler output by 28-89 percentage points. In comparison with state-of-the-art LLM-based decompilation methods using the same GPT-4o backbone, our approach (84.1%) outperforms LLM4Decompile (80.3%), SK2Decompile (73.9%), and SALT4Decompile (61.8%). Our ablation study reveals that execution-based validation is critical: compile-only approaches achieve 0% behavioral correctness despite 91-99% compilation rates. The system converges efficiently, with 90%+ binaries reaching correctness within 2 iterations at an average cost of $0.03-0.05 per binary. Our results demonstrate that constraint-guided agentic refinement can bridge the gap between raw decompiler output and practically useful source code.
Tags
Links
- Source: https://arxiv.org/abs/2604.23940v1
- Canonical: https://arxiv.org/abs/2604.23940v1
Trouble viewing inline? Open PDF directly →
Full Text
71,937 characters extracted from source content.
Expand or collapse full text
Constraint-Guided Multi-Agent Decompilation for Executable Binary Recovery Yifan Zhang ∗ ,Xiaohan Wang ∗ ,Yueke Zhang,Kevin Leach † Vanderbilt University ∗ Equal contribution. † Corresponding author: kevin.leach@vanderbilt.edu Abstract Decompilation—recovering source code from compiled binaries— is essential for many software engineering tasks, like program analysis, reverse engineering, and legacy software maintenance. However, existing decompilers produce code that often fails to recompile or execute correctly, limiting their practical utility in set- tings where changes to decompiled source must be lowered again to binary form. Recent advances in agentic AI offer a promising direc- tion: by defining structured workflows with clear validation signals, LLM agents can iteratively refine code toward correctness without task-specific training. In this paper, we present Agent4Decompile, a multi-agent framework that transforms decompiled code into re-executable source through multi-level constraint-guided refine- ment. Our approach operates in three stages: (1) syntax validation ensures parseable C code; (2) compilation validation catches type errors and missing declarations; (3) execution validation uses test- driven behavioral equivalence against the original binary. When validation fails at any level, specialized LLM agents refine the code using structured error feedback. We conduct the largest decompi- lation experiment to date, evaluating Agent4Decompile on 1,641 binaries from ExeBench across three decompilers (Ghidra, Angr, RetDec)—a benchmark that enables fine-grained analysis across op- timization levels, function categories, and decompiler architectures. Agent4Decompile achieves 40–46% re-executability on this large- scale benchmark, improving baseline output by 18–28 percentage points. Compared to state-of-the-art methods, Agent4Decompile (50.3%) outperforms single-pass LLM refinement (35.2%) and fine- tuned LLM4Decompile (12.1%) by 15–38 percentage points. Our ablation study reveals that execution-based validation is critical: compile-only approaches achieve only 32–42% re-executability de- spite 99–100% compilation rates. Moreover, Agent4Decompile con- verges efficiently, with most binaries reaching correctness within 2 iterations. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. Conference’17, Washington, DC, USA © 2026 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-x-x-x-x/Y/M https://doi.org/10.1145/n.n 1 Introduction Decompilation is the process of recovering high-level source code from compiled binary executables. This challenging task is a linch- pin for many software security and reverse engineering tasks. Secu- rity analysts rely on decompilation for malware analysis [43], vul- nerability discovery [31], and understanding proprietary or legacy software [9]. An ideal decompiler would produce source code that is not only readable but also re-compilable and re-executable — that is, capable of being compiled and executed to produce the same behavior as the original binary. Such re-executable decompilation would enable powerful downstream applications including binary rewriting, automated patching, and fuzz testing of source code recovered via decompilation. Unfortunately, existing decompilers fall far short of this ideal. State-of-the-art tools like Ghidra [27], IDA Pro [12], and RetDec [17] employ sophisticated program analysis techniques, but produce output that frequently contains syntactic errors, type mismatches, and semantic inconsistencies. Our empirical analysis reveals that raw decompiler output achieves only 22–26% re-executability across different tools (Table 1). This gap between decompiler output and usable source code represents a substantial barrier to practical binary analysis workflows. Recent advances in Large Language Models (LLMs) have sparked interest in leveraging neural approaches for decompilation [37,38]. These methods treat decompilation as a translation task, training or prompting LLMs to convert assembly or decompiled pseudocode into compilable C code. While promising, existing LLM-based ap- proaches face fundamental limitations: they operate in a single-shot manner without feedback, lack mechanisms to verify behavioral correctness. More fundamentally, these limitations suggest that de- compilation cannot be solved as a single-pass translation problem. In this paper, we present Agent4Decompile, a multi-agent frame- work that transforms decompiled code into re-executable source through multi-level constraint-guided refinement. Our key insight is that decompilation is inherently a multi-level problem arising from the lossy nature of compilation. During compilation, code is lowered to assembly and machine code, leading to a loss dif- ferent types of information at different stages. Consequently, no single validation signal can recover all lost information. Variable and struct names are discarded early, causing syntax-level inconsis- tencies in decompiled output; type information is erased, leading to compilation failures; and control flow semantics are obscured by optimization, resulting in behavioral mismatches. Crucially, these error classes are not jointly optimizable: execution feedback cannot fix syntax errors, and compilation diagnostics cannot detect seman- tic mismatches. This necessitates a hierarchical validation strategy that integrates complementary signals across levels. arXiv:2604.23940v1 [cs.SE] 27 Apr 2026 Conference’17, July 2017, Washington, DC, USA Yifan Zhang ∗ ,Xiaohan Wang ∗ ,Yueke Zhang,Kevin Leach † Vanderbilt University ∗ Equal contribution. † Corresponding author: kevin.leach@vanderbilt.edu // Ghidra undefined8 main() local_c = FUN_11e9(); printf("%d", local_c); ✗ (a) Raw Output L2: undefined ref L3: expect 120, got 0 (b) Feedback int factorial(int n) if(n<=1) return 1; return n*factorial(n-1); ✓ (c) Refined Code Figure 1: Motivating example: (a) Raw Ghidra output contains undefined functions and type errors. (b) Multi-level constraints provide structured feedback: L2 catches missing function references, L3 catches behavioral errors. (c) Agent4Decompile produces correct, re-executable code through iterative refinement. Therefore, we formulate decompilation refinement as a progres- sive search space reduction: given the vast space of possible C pro- grams, each constraint level defines a successively smaller feasible subspace—L1 (syntax) restricts to parseable programs, L2 (compila- tion) further narrows to type-correct programs, and L3 (execution) identifies behaviorally equivalent programs. Figure 1 illustrates this progression. By decomposing the search into hierarchical stages, Agent4Decompile makes the refinement tractable: rather than searching the entire program space with a single weak signal, we progressively filter through increasingly precise constraints, each providing targeted feedback for its corresponding error class. Our ablation study reveals a critical finding: compilation success does not imply behavioral correctness. A compile-only validation approach (Levels 1+2) achieves 99–100% compilation rates but only 32–42% re-executability; the code compiles but produces incor- rect outputs. Incorporating execution-based validation (Level 3) improves re-executability to 43–50%, closing part of this gap. This result underscores the necessity of end-to-end validation for re- executable decompilation. On a 157-binary benchmark, Agent4Decompile improves re- executability from 22–26% (baseline) to 43–50% across three decom- pilers (Ghidra, Angr, and RetDec), representing improvements of 18–28 percentage points. Compared to state-of-the-art refinement methods, Agent4Decompile (50.3%) outperforms single-pass LLM refinement (35.2%) and fine-tuned LLM4Decompile-Ref (12.1%) by 15–38 percentage points. The system scales effectively: on 1,641 binaries from ExeBench, Agent4Decompile maintains 40–46% re- executability with an average of 1.5–2.3 iterations per binary. This paper makes the following contributions: (1)Insight: We identify that compilation success does not imply behavioral correctness: a 57–68 p gap exists between compile rate (99%) and re-executability (32–42%). This motivates multi- level validation with execution feedback (§3). (2) System: We present Agent4Decompile, a multi-agent frame- work that iteratively refines decompiled code through syntax, compilation, and execution constraints, improving re-executability from 22–26% to 43–50% across three decompilers (§4). (3)Evaluation: We demonstrate 15–38 p improvement over prior refinement methods on 1,641 binaries, with ablations show- ing L3 execution feedback is essential for behavioral correct- ness (§5). We release all benchmarks and artifacts at: https:// anonymous.4open.science/r/agent4decompile-artifacts-0F69. 2 Background We provide background on binary decompilation and LLMs for code understanding, which form the foundation of our approach. 2.1 Binary Decompilation Decompilation converts compiled binary executables back into human-readable source code. Unlike disassembly (which produces assembly from binaries), decompilation aims to recover high-level constructs such as control flow statements, data types, and variable names in a higher level language (typically C). Modern decom- pilers follow a multi-stage pipeline [43]: binary parsing loads the executable and identifies code/data sections; disassembly converts machine code to assembly instructions; control flow recovery recon- structs the control flow graph (CFG); type recovery infers variable types from usage patterns; and code generation produces source code from the intermediate representation. Three factors make decompilation fundamentally challenging [43]. First, compilation is an inherently lossy transformation: informa- tion such as variable names, comments, and high-level abstractions are irreversibly lost as high level source code is lowered to assembly and then to machine code. Second, compiler optimizations (inlin- ing, loop unrolling, dead code elimination) obscure the program’s original structure or the intent of the original developer. Third, the diversity of calling conventions, instruction set architectures, and compiler behaviors creates a vast space of possible binary patterns. Modern decompilers fall into three architectural categories: •Rule-based decompilers (e.g., Ghidra [27], IDA Pro [12]) use hand-crafted pattern matching rules developed over decades to recognize code patterns and produce output. •Lifting-based decompilers (e.g., Angr [35], RetDec [17]) trans- late binary code to an intermediate representation (IR) such as VEX or LLVM IR, then lower to source code. •ML-based decompilers leverage machine learning to learn the mapping from binary to source code, either through neural ma- chine translation [10] or large language models [38]. Each architecture exhibits distinct error patterns: rule-based decom- pilers may miss modern compiler idioms; lifting-based decompilers can introduce IR artifacts; ML-based approaches may hallucinate or generate syntactically invalid code. A fundamental question in decompilation is: when is the decom- piled code correct? Syntactic equivalence, where decompiled code is textually identical to the original source, is rarely achievable due to information loss. Semantic equivalence, where decompiled code produces the same outputs as the original binary for all inputs, Constraint-Guided Multi-Agent Decompilation for Executable Binary RecoveryConference’17, July 2017, Washington, DC, USA represents the ideal goal but is generally undecidable. We therefore adopt behavioral equivalence as our correctness criterion: we say the decompiled code is correct if it compiles, executes, and produces outputs matching the original binary on a set of test inputs. This re-executability metric is stricter than mere compilation success and provides a practical approximation of semantic equivalence. 2.2 LLMs for Code Understanding Given the challenges of traditional decompilation, recent work has turned to large language models as a complementary approach. Models such as Codex [6], CodeLlama [32], and StarCoder [23] are trained on large corpora of source code and demonstrate remarkable capabilities in code generation [6], code summarization [1], and bug detection [30]. These models capture both syntactic patterns and semantic relationships in code. Recent work applies LLMs directly to decompilation. LLM4Decompile [38] fine-tunes language models on assembly-to-C pairs, achieving state- of-the-art results on decompilation benchmarks. However, these approaches operate in a single-pass manner: given binary input, they produce source code without iterative refinement, leaving many errors uncorrected. LLM-based agents extend language model capabilities by en- abling interaction with external tools and environments [34,44]. Agents can execute code, observe outputs, and iteratively refine their solutions based on feedback. This paradigm has shown success in code generation [13], debugging [7], and program repair [41]. Our work builds on this agent paradigm, using execution feedback to guide iterative decompilation refinement. 3 System Design We introduce Agent4Decompile, a system that transforms decom- piled C code into re-executable source through constraint-guided LLM refinement. Figure 2 illustrates our approach: given a binary, a traditional decompiler produces initial code퐶 0 , which then passes through three levels of validation (syntax, compilation, execution), with LLM-based repair at each level until the output compiles and behaves equivalently to the original binary. 3.1 Overview Scope and Assumptions. We target stripped ELF binaries compiled from C with standard optimization levels (O0–O3). We assume test inputs are available for behavioral validation, either from domain knowledge, fuzzing, or LLM-generated cases. We do not address ob- fuscated binaries or architectures beyond x86-64; these extensions are left to future work. Pipeline. Agent4Decompile operates as a four-stage pipeline: (1) decompilation using an off-the-shelf decompiler, (2) post-processing to normalize output, (3) optional multi-decompiler consensus, and (4) constraint-guided LLM refinement. This section focuses on the refinement stage, which is our main contribution. Existing decompilers operate in a single pass: they produce out- put without any mechanism to detect or correct errors. Agent4Decompile addresses this limitation by treating decompilation as an iterative process guided by executable constraints. Our key insight is that decompilation errors manifest at different levels, and each level provides distinct diagnostic signals: Figure 2: Overview of Agent4Decompile. A binary is first processed by a traditional decompiler (e.g., Ghidra) to pro- duce initial code퐶 0 . The code then passes through a three- level constraint hierarchy: L1 (syntax), L2 (compilation), and L3 (execution). At each level, failures trigger a specialized LLM agent that repairs the code using error feedback. Code that passes all three levels yields re-executable output퐶 ∗ . •L1: Syntax errors (e.g., missing semicolons) indicate malformed code that cannot be parsed by the compiler front-end. • L2: Compilation errors (e.g., type mismatches between decla- rations and uses of variables) indicate semantic inconsistencies. •L3: Execution errors (e.g., wrong outputs) indicate behavioral divergence from the original binary. The three levels form a validation pipeline: L1 checks syntax, L2 checks compilation, and L3 checks behavioral equivalence. When validation fails at any level, a specialized LLM agent receives the error feedback and proposes targeted repairs. Code passing all three levels yields re-executable output. 3.2 Constraint Hierarchy We first define the domains used in our formalization. LetSdenote the set of all strings,C ⊂ Sthe set of syntactically valid C pro- grams, andBthe set of executable binaries. We define the following operators: • parse :S →C∪⊥ attempts to parse a string as C code. • compile :C →B∪⊥ compiles valid C code to a binary. • exec:B×I →Oexecutes a binary on input푖 ∈Iand returns output 표 ∈ O. L1: Syntax Constraints. Given decompiled code퐶 ∈S, the syntax constraint holds if퐶 is parseable: 휙 1 (퐶)≜ parse(퐶)≠⊥ When휙 1 (퐶)= false, the parser returns error messages퐸 1 in- dicating the location and nature of syntax errors (e.g.,line 15: expected ‘;’ before ‘’). Separating syntax validation from compilation provides more localized feedback, enabling targeted repairs before attempting the more complex compilation step. L2: Compilation Constraints. The compilation constraint holds if parsed code compiles successfully: 휙 2 (퐶)≜ 휙 1 (퐶)∧ compile(parse(퐶))≠⊥ Conference’17, July 2017, Washington, DC, USA Yifan Zhang ∗ ,Xiaohan Wang ∗ ,Yueke Zhang,Kevin Leach † Vanderbilt University ∗ Equal contribution. † Corresponding author: kevin.leach@vanderbilt.edu When휙 2 (퐶)= false, the compiler returns error messages퐸 2 with type information and symbol resolution failures. Note that휙 2 (퐶) ⇒ 휙 1 (퐶): compilation subsumes parsing. L3: Execution Constraints. Given a test suite푇=(푖 1 ,표 1 ), . . .,(푖 푛 ,표 푛 ) derived from the original binary퐵, the execution constraint holds if the recompiled code produces matching outputs: 휙 3 (퐶,푇)≜ 휙 2 (퐶)∧∀(푖,표) ∈ 푇 : exec(compile(퐶),푖)=표 When휙 3 (퐶,푇)= false, we obtain the failing test case(푖,표 exp ,표 act ) as diagnostic feedback. This level validates behavioral equivalence— the ultimate goal of decompilation. 3.3 LLM-Based Repair Agents Agent4Decompile employs three specialized LLM agents, one for each constraint level. While the agents share a common prompt structure, each receives level-specific error feedback tailored to its repair task. Prompt Structure. All agents receive prompts with four compo- nents: (1) System instruction: A fixed preamble establishing the repair task and output constraints (return only corrected C code, no explanations or markdown formatting). (2)Constraint status: The current validation state indicating which levels have passed and which has failed. (3) Error feedback: Diagnostic information from the failing con- straint (detailed below). (4)Current code: The complete decompiled source to be repaired. Each agent outputs the full corrected code directly, without chain- of-thought explanations. This design ensures parseable output and reduces token cost. Syntax Repair Agent (L1). When휙 1 (퐶)fails, the syntax agent re- ceives GCC parser errors (truncated to 500 characters). GCC’s error messages include file, line, and column information, enabling the LLM to localize syntax fixes such as missing semicolons, unbalanced braces, or malformed literals. Compilation Repair Agent (L2). When휙 2 (퐶)fails, the compilation agent receives GCC compiler errors (truncated to 500 characters). These messages provide type information and symbol resolution failures, guiding fixes such as adding missing#includedirectives, correcting type mismatches, or declaring undefined identifiers. Execution Repair Agent (L3). When휙 3 (퐶,푇)fails, the execution agent receives a structured summary rather than raw output: •Up to two failing test cases, each showing: input, expected output (from the original binary), actual output (from the recompiled code), and a unified diff (first 10 lines). •A diagnostic checklist prompting the LLM to consider common behavioral error sources: incorrect variable initialization, control flow divergence, arithmetic errors (e.g., signed vs. unsigned), and off-by-one mistakes. This richer feedback compensates for the difficulty of L3 repairs, where errors manifest as behavioral divergence rather than local- ized syntax or type issues. Stateless Iteration. Each agent operates statelessly: it receives only the current error feedback, not a history of past repair attempts. Algorithm 1 Constraint-Guided Refinement Require: Binary 퐵, test suite푇 , decompiler 퐷 , max iterations 푁 Ensure: Refined code퐶 ∗ or Failure 1: 퐶 ← 퐷(퐵)⊲ Initial decompilation퐶 0 2: for 푘= 1 to 푁 do 3: (ℓ,퐸) ← Validate(퐶,푇)⊲ Returns (level, errors) 4: if ℓ= Pass then 5:return퐶⊲ All constraints satisfied 6: end if 7: 퐶 ← Agent ℓ (퐶,퐸)⊲ LLM repair for level ℓ 8: end for 9: return Failure 10: function Validate(퐶,푇 ) 11: if ¬휙 1 (퐶) then return(퐿1, ParseErrors(퐶)) 12: end if 13: if ¬휙 2 (퐶) then return(퐿2, CompileErrors(퐶)) 14: end if 15: if ¬휙 3 (퐶,푇) then return(퐿3, FailedTests(퐶,푇)) 16: end if 17: return(Pass,∅) 18: end function While maintaining error history could help avoid repeated mistakes, stateless operation reduces prompt length and API cost. We analyze this convergence behavior in §3.4. 3.4 Iterative Refinement Algorithm 1 formalizes the refinement procedure. The Validate function encapsulates the constraint hierarchy, returning both the failing level and diagnostic errors. This design simplifies the main loop and ensures consistent error handling. Convergence. Each iteration aims to advance the code to a higher constraint level. While regression is possible (e.g., fixing a compi- lation error may introduce a syntax error), we observe monotonic progress in most cases. Our experiments (§5) show that most suc- cessful refinements converge within 3 iterations. Bounded Iterations. The iteration limit푁ensures termination even for difficult cases. We use푁=7 as a conservative upper bound; in practice, cases that do not converge within 5 iterations rarely succeed with additional attempts. 4 Implementation We implement Agent4Decompile in approximately 5,000 lines of Python. The system comprises four main components: decompiler wrappers that provide a unified interface to multiple backends, con- straint validators that check syntax, compilation, and execution correctness, LLM-based repair agents that fix errors at each level, and a refinement loop orchestrator that coordinates the iterative process. We design the system for extensibility, allowing new de- compilers and LLM backends to be added through well-defined interfaces. Constraint-Guided Multi-Agent Decompilation for Executable Binary RecoveryConference’17, July 2017, Washington, DC, USA 4.1 Decompiler Integration Agent4Decompile integrates three decompilers to generalize across different architectural approaches. Ghidra 11.2 [27], developed by the NSA, employs rule-based analysis and is invoked through its analyzeHeadlesscommand-line interface. Angr 9.2 [35] lifts bina- ries to the VEX intermediate representation and provides a Python API for programmatic access. RetDec 5.0 [17] combines LLVM- based decompilation with machine learning for type recovery and is accessed via command-line interface. We abstract these differences behind a unified interface: each decompiler wrapper accepts a binary path and returns decompiled C source code as a string. This design allows Agent4Decompile to work with any decompiler that produces C output, enables straight- forward addition of new backends, and supports multi-decompiler consensus when comparing outputs from multiple tools. 4.2 Constraint Validators Each constraint level is implemented as a standalone validator that returns either success or structured error feedback suitable for LLM consumption. For syntax validation (L1), we invoke GCC with the-fsyntax-only flag, which performs parsing without full compilation. This ap- proach is faster than full compilation and produces focused error messages about syntax issues such as missing semicolons, unbal- anced braces, and malformed literals. We capture parser errors from stderr and truncate them to 500 characters before passing to the repair agent, as longer error messages provide diminishing returns while increasing prompt cost. For compilation validation (L2), we invoke GCC with strict warn- ing flags (-Wall -Wextra -Werror) to catch semantic errors includ- ing type mismatches, undeclared identifiers, and linkage failures. The compilation errors provide richer diagnostic information than syntax errors, including type expectations and suggested fixes. For execution validation (L3), we compile the decompiled code, execute it with test inputs, and compare outputs against the origi- nal binary. Execution is sandboxed with a 10-second timeout and 256MB memory limit to prevent runaway processes. Expected out- puts are pre-computed by running the original binary on the same inputs, establishing ground-truth behavioral oracles. 4.3 LLM Configuration While our approach is model-agnostic, we use DeepSeek V3.2 [26] as the default LLM for all repair agents because of its strong code un- derstanding capabilities and API availability. For repair agents, we use temperature 0.0 to ensure deterministic, reproducible outputs across runs. We set a maximum output length of 4,096 tokens, which suffices for most decompiled functions. For larger functions exceeding this limit, we increase the cap to 8,192 tokens. API failures due to rate limits or timeouts trigger exponential backoff with up to three retries; persistent failures are logged and the binary is marked as failed for manual inspection. 4.4 Infrastructure We process multiple binaries in parallel using Python’s Process- PoolExecutor, with each binary running in an independent pro- cess to enable linear speedup on multi-core machines. Intermediate results are cached to avoid redundant computation: decompiler out- puts are keyed by binary hash, test oracles (expected outputs from the original binary) are stored alongside the binary, and successful refinement results are cached for incremental re-runs. All LLM interactions are logged with full request/response pairs, enabling post-hoc analysis and debugging of refinement failures. For reproducibility, we pin all tool versions (GCC 11.4, Ghidra 11.2, Angr 9.2, RetDec 5.0), and use temperature 0.0 for deterministic LLM outputs. Code and data will be released upon publication. 5 Evaluation We evaluate Agent4Decompile on two benchmarks across three decompiler architectures, comparing against state-of-the-art meth- ods and analyzing the contribution of each design component. Our evaluation addresses four research questions: •RQ1 (Effectiveness): How effective is Agent4Decompile at im- proving decompilation quality, and does it scale to larger bench- marks? •RQ2 (Ablation): What is the contribution of each constraint level (L1, L2, L3) to the overall system performance? •RQ3 (Comparison): How does Agent4Decompile compare to existing decompilation refinement approaches? •RQ4 (Security): Can Agent4Decompile-refined code enable practical security analysis while preserving vulnerability seman- tics? 5.1 Experimental Setup Benchmarks. We use two benchmarks. First, the 157-Binary benchmark comprises 125 ExeBench [2] binaries and 32 custom binaries, curated for detailed analysis and SOTA comparison. The ExeBench portion consists of 32 functions compiled at four op- timization levels (O0–O3), with 3 functions missing O0 variants; these include 17 functions from real-world open-source projects (real_test) and 15 synthetic functions (synth_test). The custom portion consists of 8 textbook algorithms (e.g.,binary_search, bubble_sort,factorial,fibonacci) compiled at O0–O3, yield- ing 32 standalone programs withmain()entry points verified via stdout comparison. Second, the 1,641-Binary benchmark com- prises 1,561 ExeBench binaries and 80 custom binaries for scalability evaluation. The ExeBench portion consists of 396 functions from the test set—247 fromreal_test(real-world code) and 149 fromsynth (synthetic functions)—compiled at O0–O3. The custom portion adds 20 algorithm implementations (e.g.,heapsort,mergesort, quicksort, bst, gcd) disjoint from the 157-binary benchmark. We evaluate on ExeBench [2] rather than HumanEval-Decompile [38] or MBPP [3], which are commonly reported in decompilation lit- erature. ExeBench presents a more challenging testbed: functions are larger, derived from real-world open-source projects, and com- piled across multiple optimization levels (O0–O3). Additionally, Conference’17, July 2017, Washington, DC, USA Yifan Zhang ∗ ,Xiaohan Wang ∗ ,Yueke Zhang,Kevin Leach † Vanderbilt University ∗ Equal contribution. † Corresponding author: kevin.leach@vanderbilt.edu Table 1: Comprehensive evaluation on the 157-binary benchmark. We report syntax validity (L1), compilation success (L2), and re-executability (L3). Best results are in bold.Δ denotes percentage point improvement over the baseline. Baseline+ Agent4Decompile횫 Improvement DecompilerL1L2L3L1L2L3ΔL1ΔL2ΔL3 Ghidra (Rule) 86.0 86.0 22.3 100.0 100.0 50.3+14.0+62.4+28.0 Angr (Lifting) 79.0 65.0 24.8 100.0 100.045.2+21.0+35.0+20.4 RetDec (ML)98.7 98.7 25.5 99.4 99.443.3+0.7+0.7+17.8 Average 87.9 67.1 24.2 99.8 99.8 46.3 +11.9 +32.7 +22.1 ExeBench provides IO-pair test cases with concrete expected out- puts, which our feedback-based iterative refiner leverages to iden- tify specific behavioral errors. In contrast, the original HumanEval [6] benchmark was designed for Python with assertion-based testing for automated black-box verification; this design was preserved when the benchmark was converted to C for decompilation evalua- tion. Assertion-based test cases provide only binary pass/fail signals without actionable diagnostic information—a benchmark design choice that limits their utility for iterative refinement. Decompilers. We evaluate three decompilers representing differ- ent architectures: RetDec [17] (ML-based, uses LLVM IR), Ghidra [27] (rule-based, industry standard), and Angr [35] (lifting-based, uses VEX IR). Metrics. We report three metrics corresponding to increasingly strict correctness levels: L1 Syntax Rate (percentage of outputs that parse successfully, checked viagcc -fsyntax-only -w file.c), L2 Compile Rate (percentage that compile successfully, checked viagcc -c file.c), and L3 Re-exec Rate (percentage that execute correctly on test inputs by comparing output against ground-truth, original binary execution). Re-exec rate (L3) serves as our primary metric since it captures behavioral correctness. Configuration. We use DeepSeek-V3.2 [26] as the base model for each agent for all experiments, with maximum 5 refinement iterations and 10-second execution timeout. 5.2 RQ1: Effectiveness and Scalability How effective is Agent4Decompile at improving decompilation quality, and does it scale to larger benchmarks? Table 1 presents results on the 157-binary benchmark across all decompilers and metrics. Agent4Decompile substantially im- proves re-executability for all three decompiler architectures: Ghidra improves from 22.3% to 50.3% (+28.0 p), Angr from 24.8% to 45.2% (+20.4 p), and RetDec from 25.5% to 43.3% (+17.8 p). To assess scal- ability, we evaluate on the full 1,641-binary ExeBench benchmark (Table 2). Agent4Decompile achieves 40–46% re-executability across all decompilers, with Ghidra performing best (46.0%) followed by Angr (40.9%) and RetDec (39.9%). Pipeline Effect. Table 1 shows improvements at each constraint level. Agent4Decompile raises syntax validity (L1) from 87.9% to 99.8% and compilation success (L2) from 67.1% to 99.8%—near- perfect. Most importantly, re-executability (L3) nearly doubles from 24.2% to 46.3% (+22.1 p). The remaining gap between L2 (99.8%) Table 2: Scalability analysis on the 1,641-binary ExeBench benchmark. We report re-executability (L3) across optimiza- tion levels (O0–O3).Δdenotes percentage point improvement over the baseline. O0ΔO1Δ DecompilerBaselineOursBaselineOurs Ghidra25.7 50.4+24.724.0 47.0+23.0 Angr30.643.7+13.128.042.9+14.9 RetDec20.642.4+21.819.740.7+21.0 Average25.6 45.5 +19.9 23.9 43.5 +19.6 O2ΔO3Δ DecompilerBaselineOursBaselineOurs Ghidra24.0 45.7+21.721.5 40.9+19.4 Angr27.341.7+14.422.235.1+12.9 RetDec19.739.9+20.212.936.4+23.5 Average23.7 42.4 +18.7 18.9 37.5 +18.6 and L3 (46.3%) reflects the fundamental difficulty of decompilation: producing code that compiles is straightforward, but achieving correct runtime behavior requires resolving semantic errors that are invisible to the compiler. This is precisely why our approach uses L3 execution feedback as the ultimate correctness check. Optimization Level Robustness. Performance varies by 5–10 p across optimization levels O0–O3 (Table 2), with O0 achieving the highest rates (45.5% average) and O3 the lowest (37.5%). This gap re- flects the increased difficulty of decompiling aggressively optimized code: O3 applies function inlining, loop unrolling, and dead code elimination that obscure original program structure. Nevertheless, Agent4Decompile achieves consistent improvements across all optimization levels, demonstrating robustness to compiler transfor- mations. Iterative Refinement Example. Figure 3 illustrates the pipeline effect with a concrete example. The functioniordersorts four in- tegers, but Ghidra’s O3 output contains type errors and convoluted control flow. L1+L2 refinement produces code that compiles (Iter 2), but execution reveals wrong output on 4/10 test cases. Only with L3 feedback—concrete failing I/O pairs—can the agent identify the Constraint-Guided Multi-Agent Decompilation for Executable Binary RecoveryConference’17, July 2017, Washington, DC, USA void iorder(int i, int j, int k, int l, int *i1, int *j1, int *k1, int *l1) int y[5],tem,i,j,k; y[1]=i; y[2]=j; y[3]=k; y[4]=l; for(j=2;j<=4;j++) for(i=1;i<=j-1;i++) if (y[i]>y[j]) tem=y[j]; for(k=j;k>=i+1;k--) y[k]=y[k-1]; y[i]=tem; *i1=y[1]; *j1=y[2]; *k1=y[3]; *l1=y[4]; ITER 0: score 0/3 Ground Truth ITER 2: score 2/3, 4/10 io_pairs wrong output ITER 3: score 3/3, io_pairs ALL PASS void iorder(int param_1,...,int *param_8) int local_44 = param_1; int iStack_40 = param_2; int iStack_3c = param_3; int iStack_38 = param_4; -// 50 lines of goto+ memmove + int temp; // ← simple swap variable + if (local_44 > iStack_40) temp=local_44; local_44=iStack_40; iStack_40=temp; + if (local_44 > iStack_3c) temp=local_44; local_44=iStack_3c; iStack_3c=temp; + if (local_44 > iStack_38) temp=local_44; local_44=iStack_38; iStack_38=temp; + if (iStack_40 > iStack_3c) temp=iStack_40; iStack_40=iStack_3c; iStack_3c=temp; + if (iStack_40 > iStack_38) temp=iStack_40; iStack_40=iStack_38; iStack_38=temp; + if (iStack_3c > iStack_38) temp=iStack_3c; iStack_3c=iStack_38; iStack_38=temp; *param_5=local_44; *param_6=iStack_40; *param_7=iStack_3c; *param_8=iStack_38; int main() return 0; void iorder(...) - long in_FS_OFFSET;// ← REMOVED - long local_30; // ← REMOVED - local_30 = *(long *)(in_FS_OFFSET+0x28);// ← REMOVED ... // still uses memmove memmove(&iStack_40,&local_44,0xc); // gotologic has bugs if (bVar1) gotoLAB_0010120f; ... - __stack_chk_fail(); // ← REMOVED +int main() return 0; // ← ADDED void iorder(int param_1,...,int *param_8) bool bVar1; // ← ERROR: unknown type long in_FS_OFFSET;// ← ERROR: undeclared ... local_30 = *(long *)(in_FS_OFFSET+ 0x28); // stack canary ... if (bVar1) gotoLAB_001012c7; // complex gotologic ... memmove(&iStack_40,&local_44,0xc); // low-level memory op ... __stack_chk_fail(); // stack check Figure 3: Iterative refinement ofiorder(4-integer sorting, Ghidra O3). Iter 0 (raw output) fails all tests due to type errors andgoto-based control flow. Iter 2 compiles but produces wrong output on 4/10 test cases. Iter 3, guided by L3 execution feedback, rewrites the sorting logic and passes all tests. flawed sorting logic and rewrite it correctly (Iter 3). This demon- strates that execution feedback is essential for catching behavioral errors invisible to compilation. Finding 1: Agent4Decompile improves re-executability by 18–28 percentage points across all decompiler types and scales to 1,641 binaries with 40–46% success rate. 5.3 RQ2: Ablation Study What is the contribution of each constraint level (L1, L2, L3) to the overall system performance? To understand the contribution of each constraint level, we com- pare four configurations: Baseline (no refinement), L1 only (syntax checking), L1+L2 (syntax + compile), and Full Agent4Decompile (L1+L2+L3 with execution). Table 3 shows the results. Baseline Analysis. Raw decompiler outputs exhibit distinct error profiles. Ghidra achieves 86.0% syntax validity but only 37.6% com- pilation success due to undefined type annotations (undefined4, bool), resulting in 22.3% re-executability. RetDec produces highly compilable code (98.7% L1/L2) due to aggressive type normalization, but achieves only 25.5% re-executability—the code compiles but produces incorrect behavior. Angr achieves 79.0% syntax validity and 65.0% compilation, with 24.8% re-executability, reflecting VEX IR artifacts that reduce code quality. All three baselines cluster around 22–25% re-executability, motivating the need for iterative refinement. Iteration Budget Analysis. Figure 4 shows how re-executability improves with each refinement iteration. All three decompilers ex- hibit rapid initial improvement: Ghidra jumps from 25% to 40% after a single iteration, while RetDec rises from near-zero baseline to 25%. By iteration 2, performance reaches 40–45% across all decompilers. Subsequent iterations yield diminishing returns, adding only 3–5 p. This pattern validates our bounded iteration strategy (max 5 0 (baseline) 1234 LLM Refinement Iterations 20 30 40 50 Re-exec Rate (%) 45.9% 40.8% 39.8% Ghidra Angr RetDec Figure 4: Convergence analysis: re-executability improves with refinement iterations across all decompilers. Most gains occur within the first 2 iterations, with diminishing returns thereafter. Ghidra reaches 45.9%, Angr 40.8%, and RetDec 39.8% after 4 iterations. iterations): most successful refinements converge quickly, while binaries that fail after 2–3 iterations rarely benefit from additional attempts. The convergence behavior is consistent across decompiler architectures, suggesting that the multi-level constraint hierarchy effectively guides the LLM toward correct solutions within a small number of iterations. The Compile-Correct Gap. L1+L2 achieves 99–100% compile rate but only 32–42% re-executability. This 57–68 p gap between com- pilation success and behavioral correctness represents semantic errors invisible to the compiler: code that parses, type-checks, and links, yet produces wrong outputs at runtime. These errors arise from decompiler artifacts (incorrect type casts, wrong operator precedence, misinterpreted control flow) that are syntactically valid but semantically incorrect. L3 Execution Feedback. Adding L3 constraints improves re-execu- tability by 8.0–10.4 p (21–33% relative improvement). L3 feedback provides concrete failing test cases—specific inputs where expected and actual outputs diverge—enabling the agent to localize and fix behavioral errors that compilation cannot detect. The remaining gap between L2 (99–100%) and Full Agent4Decompile (42–50%) reflects the fundamental difficulty of decompilation: some semantic information is irreversibly lost during compilation. Decompiler-Specific Error Patterns. The three decompilers pro- duce distinct error patterns, yet Agent4Decompile addresses each through targeted feedback. Ghidra preserves internal type anno- tations (undefined4,bool) and stack canary artifacts causing L1 failures; L1 feedback guides the agent to replace these with stan- dard C types. RetDec achieves high compile rates (L2=98.7%) but collapses all types toint64_t, causing subtle L3 failures; execu- tion feedback reveals type mismatches through incorrect outputs, enabling the agent to infer lost types from function names and operation patterns. Angr produces VEX IR artifacts (uint128_t, [D]markers) causing both compilation and behavioral errors; L3 feedback enables iterative correction of these artifacts. Conference’17, July 2017, Washington, DC, USA Yifan Zhang ∗ ,Xiaohan Wang ∗ ,Yueke Zhang,Kevin Leach † Vanderbilt University ∗ Equal contribution. † Corresponding author: kevin.leach@vanderbilt.edu Table 3: Ablation study: contribution of each constraint level. Each cell reports syntax / compile / re-exec rates (%). ConfigurationGhidraRetDecAngr S / C / RS / C / RS / C / R Baseline86.0 / 86.0 / 22.398.7 / 98.7 / 25.579.0 / 65.0 / 24.8 L1 only100 / 100 / 36.0100 / 100 / 23.4100 / 100 / 28.8 L1+L2100 / 100 / 41.6100 / 100 / 35.2100 / 100 / 32.0 Agent4Decompile100 / 100 / 50.4 99.4 / 99.4 / 43.2 100 / 100 / 42.4 Table 4: Comparison with refinement baselines on 157-binary benchmark (Ghidra decompiler). All methods use identical decompiler output as input. Re-exec rate (%) reported. MethodO0O1O2O3Avg Ghidra Baseline (No Refinement)18.9%17.5%25.0%27.5%22.3% DeepSeek Single Pass43.2%40.0%35.0%22.5%35.2% LLM4Decompile-6.7B-v210.8%10.0%12.5%15.0%12.1% SK2Decompile (Simulated)32.4%17.5%20.0%15.0%21.0% Agent4Decompile (Ours)54.1% 50.0% 52.5% 45.0% 50.3% Finding 2: Compilation success does not imply behavioral cor- rectness: a 58–68 p gap exists between compile rate (99–100%) and re-executability (32–42%). L3 execution feedback closes part of this gap, adding 8.0–10.4 p (21–33% relative improvement). 5.4 RQ3: Comparison with Prior Work How does Agent4Decompile compare to existing decompilation refinement approaches? Our work refines decompiler output rather than performing end-to-end binary-to-source translation. We compare against three refinement approaches: DeepSeek Single Pass (general-purpose LLM without iteration), LLM4Decompile-6.7B-v2 [38] (fine-tuned refinement model), and SK2Decompile [37] (two-phase readability- focused refinement). Since the original SK2 model was trained on IDA Pro pseudocode, we simulate SK2Decompile by apply- ing its two-phase prompting strategy with DeepSeek on identi- cal Ghidra output: Phase 1 (Skeleton Extraction) recovers control flow structure, and Phase 2 (Skin Recovery) renames variables for readability. Table 4 shows that Agent4Decompile achieves 50.3% re-executability, outperforming DeepSeek Single Pass (35.2%) by 15.1 p, SK2Decompile (21.0%) by 29.3 p, and LLM4Decompile (12.1%) by 38.2 p. The baselines exhibit distinct failure modes. Single-pass refine- ment lacks error feedback—the model cannot identify which parts of its output are incorrect, so semantic errors that compile but fail at runtime go undetected. LLM4Decompile was trained on isolated pseudo-code without compiler-generated helper functions, causing it to ignore target functions when presented with full Ghidra out- put; this out-of-distribution sensitivity explains why it performs worse than raw Ghidra (12.1% vs. 22.3%). Although SK2Decompile is also a multi-stage refinement approach, its design objective dif- fers fundamentally from ours: SK2 navigates the trade-off between correctness preservation and readability improvement, rather than directly optimizing for re-executability. Phase 1 recovers program skeleton, and Phase 2 improves human readability by renaming variables—neither phase addresses type errors or semantic bugs. Variable renaming does not improve re-executability, and each LLM call risks introducing code deformations; two sequential calls compound this noise. The result is performance indistinguishable from the unrefined baseline (21.0% vs. 22.3%), demonstrating that readability-oriented refinement provides no benefit for functional correctness. In contrast, Agent4Decompile’s feedback-based iterative re- finer targets re-executability as its optimization goal. Rather than balancing correctness against readability, our agent workflow uses L3 execution feedback as the guiding signal: concrete failing test cases with expected outputs enable the agent to identify which parts of the code produce incorrect behavior. Iterative refinement allows incremental correction—the agent does not need to produce a perfect output in one pass, but can progressively fix type mis- matches, off-by-one errors, and semantic bugs across iterations. The 29.3 p gap between Agent4Decompile (50.3%) and SK2Decompile (21.0%) demonstrates that the choice of optimization objective is de- cisive: execution feedback drives meaningful semantic corrections, while readability transformations merely introduce noise without improving functional correctness. Finding 3: Execution-guided refinement outperforms single- pass, fine-tuned, and readability-focused approaches by 15–38 p. Optimizing for the correct objective (re-executability via test feedback) is essential; readability-oriented transformations provide no benefit for functional correctness. 5.5 RQ4: Downstream Security Applications Can Agent4Decompile-refined code enable practical security analysis while preserving vulnerability semantics? A key concern for binary analysis and decompilation is whether refinement preserves exploitable vulnerabilities (i.e., preserving a vulnerability during decompilation facilitates comprehension of that vulnerability). To evaluate this, we create 5 standalone pro- grams with known vulnerabilities (buffer overflow, integer overflow, null pointer, format string, double-free), then inject these patterns into 23 Agent4Decompile-refined code samples. Each sample is tested with safe inputs to verify correctness and crafted exploit in- puts to trigger vulnerabilities. Table 5 shows that Agent4Decompile preserves 100% of vulnerability patterns. For exploitability, 43% of injected vulnerabilities are immediately triggerable, with integer overflow and format string achieving 100%. The remaining vulner- abilities require specific runtime conditions (heap state for double- free, precise buffer sizes). On standalone vulnerable programs with proper harnesses, 100% of exploits trigger successfully. Real-world binaries often lack debug symbols, so we also evaluate robustness to symbol stripping. We test 20 binaries before and after stripping withstrip –strip-all. After stripping, binaries lose 100% of their symbols (avg 32→0), and function naming degrades significantly: only 12.7% of functions retain meaningful names vs. 52.5% in original binaries. Critically, raw decompiled code from both versions fails to compile (0% compile rate), demonstrating that Agent4Decompile refinement is essential regardless of symbol availability. Constraint-Guided Multi-Agent Decompilation for Executable Binary RecoveryConference’17, July 2017, Washington, DC, USA Table 5: Vulnerability preservation: patterns retained and exploits triggered on ground-truth vulnerable code. Vuln TypeSamples Pattern Preserved Exploit Triggered Buffer overflow44 (100%)0 (0%) Integer overflow55 (100%)5 (100%) Null pointer44 (100%)0 (0%) Format string55 (100%)5 (100%) Double-free55 (100%)0 (0%) Total2323 (100%)10 (43%) Finally, we evaluate fuzzing capability. From 30 targets strat- ified by decompiler, Agent4Decompile increases fuzzability by 6.6×: 33% of refined binaries are fuzz-ready vs. 5% for raw de- compiled code, achieving 65.5% average coverage. We define fuzz- ready as code that (1) compiles with coverage instrumentation (gcc –coverage), (2) accepts auto-generated harnesses, and (3) executes without immediate crash on seed inputs. The 6.6×improvement stems from two factors: Agent4Decompile raises the compilation rate from 35% to 99%, and the compiled code contains fewer struc- tural defects (missing symbols, pointer errors) that would otherwise abort fuzzing campaigns prematurely. Finding 4: Agent4Decompile preserves 100% of vulnerabil- ity patterns (43% immediately exploitable); handles stripped binaries; enables 6.6× more fuzzing. 6 Discussion We discuss limitations, threats to validity, and failure analysis. 6.1 Limitations Our work has three main limitations in scope, benchmark coverage, and model behavior. First, we focus on single-function decompi- lation rather than whole-program analysis. ExeBench functions are relatively small and self-contained, whereas real-world binaries involve multi-function interactions, stripped symbols, and complex control flow; extending to full binaries requires handling inter- procedural dependencies and shared state. Our feedback mecha- nism also requires IO-pair test cases, which limits direct comparison with assertion-based benchmarks (HumanEval-Decompile, MBPP) without format conversion. Second, several targets are explicitly out of scope. We do not aim to recover exact original source code—variable names, com- ments, and certain structural choices are irrecoverably lost during compilation. We do not target obfuscated binaries (virtualization, control flow flattening, opaque predicates), which require special- ized deobfuscation as preprocessing. Our implementation focuses on x86-64 Linux ELF binaries following recent decompilation lit- erature [18,37,38]; extension to other architectures (ARM, MIPS) and platforms (Windows PE, macOS Mach-O) is straightforward but not evaluated. Third, LLMs may exhibit semantic drift, “fixing” code by overfit- ting to test cases rather than recovering true semantics. We observe this in 75% of failures where code compiles and runs but produces incorrect output. Our L3 execution constraints catch many such GhidraRetDec Angr 0 25 50 75 100 Share of Failures (%) 41% 30% 46% 25% 40% 28% 30% 26% 22% n=844n=940n=924 Function inlining Logic error Signature mismatch Residual syntax Figure 5: Failure root cause distribution on the 1,641-binary benchmark. errors, but some false positives may remain. Additionally, our vul- nerability pattern analysis (34.7% preservation rate) detects code structures rather than exploitability; true vulnerability preserva- tion requires executing actual exploits, though we validated this direction with CGC binaries achieving 96.7% pattern preservation. 6.2 Threats to Validity Three validity concerns apply to our evaluation. For internal va- lidity, implementation choices such as prompts, iteration limits, and timeouts affect results; we mitigate this by reporting abla- tions across configurations and using standard settings through- out. For external validity, our benchmarks may not represent all real-world scenarios—production binaries may be larger or contain anti-analysis code—though we partially address this by including 247 functions from real-world open-source projects in ExeBench’s real_testpartition. For construct validity, re-executability serves as a proxy for semantic correctness, and code that passes tests may still differ semantically on untested inputs; we mitigate this through diverse test generation covering edge cases (zero, negative, boundary values) and achieving 66% average line coverage. 6.3 Failure Analysis Figure 5 decomposes the failures that remain after refinement into four root causes across the three decompilers. The dominant fail- ure mode is function inlining (39%), where compiler optimizations merge the target function intomain(), leaving no recoverable func- tion body after preprocessing. This represents a fundamental lim- itation of binary-level analysis that no refinement can overcome. The second category, logic errors (31%), represents cases where refined code compiles and links correctly but produces incorrect output on test inputs, reflecting the limits of LLM-based seman- tic recovery. Notably, RetDec exhibits a disproportionately high logic error rate (40%) compared to Ghidra (25%) and Angr (28%), likely due to its conservative type strategy that collapses parameter types toint64_t; the resulting code compiles trivially but carries systematic type errors that the agent cannot always repair within five iterations. Signature mismatch (26%) occurs when the refined function’s prototype differs from the ground-truth header expected by the test harness, causing linker failures despite correct internal logic. Finally, residual syntax errors account for only 4% of failures, confirming that syntax repair is effectively saturated. Conference’17, July 2017, Washington, DC, USA Yifan Zhang ∗ ,Xiaohan Wang ∗ ,Yueke Zhang,Kevin Leach † Vanderbilt University ∗ Equal contribution. † Corresponding author: kevin.leach@vanderbilt.edu 6.4 Future Work Several directions could extend this work. Beyond test-based con- straints, future work could incorporate stronger specifications— formal constraints derived from binary analysis, type informa- tion from recovered signatures, and program invariants discov- ered through dynamic analysis—to provide stronger correctness guarantees. Supporting assertion-based benchmarks (HumanEval- Decompile, MBPP) through assertion-to-IO conversion would also enable broader comparison with prior decompilation work. On the systems side, our current implementation processes func- tions independently; extending to whole-program decompilation requires handling inter-procedural dependencies and shared state. Integrating deobfuscation techniques as a preprocessing step would extend applicability to protected software. Using open-source mod- els (CodeLlama, DeepSeek-Coder) would eliminate API costs and enable deployment in air-gapped environments, with initial experi- ments suggesting comparable performance. Finally, the refinement loop generates valuable training data in the form of binary-to-working-C-code pairs. Fine-tuning on this data could improve single-pass performance and reduce iteration counts, creating a virtuous cycle between inference-time refinement and model improvement. 7 Related Work We discuss several lines of related work to Agent4Decompile, then place our work in context. 7.1 Binary Decompilation and Analysis Binary decompilation has a long history, beginning with founda- tional work by Cifuentes [9]. Modern tools—both commercial (IDA Pro [12]) and open-source (Ghidra [27], Angr [35], RetDec [17])— employ sophisticated techniques for control flow recovery [16], type inference [22], and variable recovery [4]. Despite these ad- vances, raw decompiler output is typically difficult to read, lacks rich semantics, and frequently fails to compile or execute correctly. Recent AI-based approaches frame decompilation as machine translation, using RNNs [14], Transformers [25], or hybrid meth- ods [10]. More recent LLM-based systems achieve stronger re- sults: LLM4Decompile [38] fine-tunes on decompilation pairs, while SALT4Decompile [39] and SK2Decompile [37] use two-phase ab- straction. However, all these approaches operate in a single pass without self-correction—once an error occurs, it propagates to the final output. Agent4Decompile addresses this limitation through iterative refinement with execution feedback. Evaluating decompilation quality has evolved from syntactic sim- ilarity [18] to re-executability, as adopted by recent benchmarks [2, 38]. Complementary binary analysis techniques—symbolic execu- tion [5,8], fuzzing [33,40], and similarity detection [31,42]—could further strengthen validation; we leave their integration to future work. 7.2 LLMs for Code Code LLMs such as Codex [6], CodeLlama [32], and StarCoder [23] excel at generation and completion, while also demonstrating strong code understanding capabilities including summarization [1], doc- umentation [15], and bug detection [30]. However, these models are trained on well-formed source code, not the malformed out- put of decompilers. Agent4Decompile bridges this gap by provid- ing structured feedback that guides general-purpose LLMs toward decompilation-specific repairs. The LLM agent paradigm extends these capabilities through tool use and iterative reasoning. ReAct [44] combines reasoning and act- ing; Reflexion [34] enables learning from mistakes; MetaGPT [13] coordinates multi-agent collaboration. Agent4Decompile applies this paradigm to decompilation, using the compiler and executor as feedback tools. 7.3 Program Repair Automated program repair (APR) techniques fix bugs given fail- ing tests [11,20], using generate-and-validate search [21] or sym- bolic constraints [28]. LLM-based approaches use conversational feedback [41], fine-tuning [36], or self-debugging [7]. Iterative re- finement with execution feedback also appears in code generation: CodeRL [19] and AlphaCode [24] filter candidates by test results, while self-repair [29] studies LLM self-correction capabilities. These repair methods assume compilable input. Agent4Decompile extends the repair paradigm to decompiled code, which often fails at syntax or compilation before execution-based repair can begin— motivating our multi-level constraint design. 7.4 Positioning Agent4Decompile combines strengths from multiple research lines while addressing their limitations. From program repair, we adopt iterative refinement with test feedback, but extend it to non- compilable input through multi-level constraints. From LLM agents, we adopt tool-augmented reasoning, but specialize it for decompila- tion with compiler and executor feedback. Unlike fine-tuned mod- els [38] requiring expensive training, we use general-purpose LLMs with task-specific prompting. Unlike two-phase methods [37,39] that abstract away details, we preserve full decompiler output and incrementally fix errors. 8 Conclusion In this paper, we present Agent4Decompile, a multi-agent system for constraint-guided decompilation that dramatically improves the quality of decompiled code. Decompilation errors manifest at different levels (syntax, compilation, and execution), and thus each level provides distinct diagnostic information to guide repair. Agent4Decompile iteratively refines decompiler output using specialized LLM agents guided by multi-level constraints. The L1 (syntax) and L2 (compilation) constraints catch structural errors early, while L3 (execution) constraints ensure behavioral correct- ness by comparing outputs against the original binary. Our evaluation demonstrates significant improvements: 18–28 percentage point improvement in re-executability across three de- compiler architectures (rule-based, lifting-based, ML-based), achiev- ing 43–50% re-executability on benchmarks of 157 to 1,641 binaries. Compared to state-of-the-art refinement methods, Agent4Decompile achieves a 15–38 percentage point advantage over single-pass and fine-tuned approaches. The system converges rapidly, with most successful refinements completing within 2 iterations. Constraint-Guided Multi-Agent Decompilation for Executable Binary RecoveryConference’17, July 2017, Washington, DC, USA Agent4Decompile enables practical use of decompiled code in downstream tasks: the recovered source can be compiled, executed, analyzed, and modified. This bridges the gap between binary anal- ysis and source-level tools, opening new possibilities for security auditing, legacy software maintenance, and malware analysis. Our ablation study reveals that execution feedback is essential— compilation success alone achieves 99–100% but only 32–42% re- executability, a 57–68 p gap. Adding L3 execution feedback closes part of this gap, improving re-executability by 8–13 p. This find- ing motivates incorporating execution-based constraints in future decompilation systems. 9 Data Availability Statement To support reproducibility, we provide an anonymized artifact con- taining the implementation, benchmarks, and materials used in this paper at the following anonymous repository: https://anonymous. 4open.science/r/agent4decompile-artifacts-0F69. The artifact is avail- able to reviewers during the review process and will remain publicly available upon publication. References [1]Toufique Ahmed and Premkumar Devanbu. 2022. Few-shot Training LLMs for Project-specific Code Summarization. In Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering (ASE). [2]Jordi Armengol-Estapé, Jackson Woodruff, Alexander Brauckmann, José Wesley de Souza Magalhães, and Michael F. P. O’Boyle. 2022. ExeBench: An ML-Scale Dataset of Executable C Functions. In Proceedings of the 6th ACM SIGPLAN International Symposium on Machine Programming. ACM. doi:10.1145/3520312. 3534867 [3] Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoc Le, et al.2021. Program synthesis with large language models. arXiv preprint arXiv:2108.07732 (2021). [4]Gogul Balakrishnan and Thomas Reps. 2007. DIVINE: Discovering Variables in Executables. In Proceedings of the 8th International Conference on Verification, Model Checking, and Abstract Interpretation (VMCAI). 1–28. [5] Cristian Cadar, Daniel Dunbar, and Dawson Engler. 2008. KLEE: Unassisted and Automatic Generation of High-Coverage Tests for Complex Systems Programs. In Proceedings of the 8th USENIX Symposium on Operating Systems Design and Implementation (OSDI). 209–224. [6]Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri, Gretchen Krueger, Michael Petrov, Heidy Khlaaf, Girish Sastry, Pamela Mishkin, Brooke Chan, Scott Gray, Nick Ryder, Mikhail Pavlov, Alethea Power, Lukasz Kaiser, Mohammad Bavarian, Clemens Winter, Philippe Tillet, Felipe Petroski Such, Dave Cummings, Matthias Plappert, Fo- tios Chantzis, Elizabeth Barnes, Ariel Herbert-Voss, William Hebgen Guss, Alex Nichol, Alex Paino, Nikolas Tezak, Jie Tang, Igor Babuschkin, Suchir Balaji, Shan- tanu Jain, William Saunders, Christopher Hesse, Andrew N. Carr, Jan Leike, Josh Achiam, Vedant Misra, Evan Morikawa, Alec Radford, Matthew Knight, Miles Brundage, Mira Murati, Katie Mayer, Peter Welinder, Bob McGrew, Dario Amodei, Sam McCandlish, Ilya Sutskever, and Wojciech Zaremba. 2021. Evaluating Large Language Models Trained on Code. arXiv preprint arXiv:2107.03374 (2021). [7]Xinyun Chen, Maxwell Lin, Nathanael Schärli, and Denny Zhou. 2024. Teaching Large Language Models to Self-Debug. In International Conference on Learning Representations (ICLR). [8]Vitaly Chipounov, Volodymyr Kuznetsov, and George Candea. 2011. S2E: A Platform for In-Vivo Multi-Path Analysis of Software Systems. In Proceedings of the 16th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS). 265–278. [9] Cristina Cifuentes. 1994. Reverse Compilation Techniques. In PhD Thesis, Queens- land University of Technology. [10]Cheng Fu, Huili Chen, Haolan Liu, Xinyun Chen, Yuandong Tian, Farinaz Koushanfar, and Jishen Zhao. 2019. CODA: An End-to-End Neural Program Decompiler. In Advances in Neural Information Processing Systems (NeurIPS). [11]Luca Gazzola, Daniela Micucci, and Leonardo Mariani. 2019. Automatic Software Repair: A Survey. IEEE Transactions on Software Engineering 45, 1 (2019), 34–67. [12]Hex-Rays. 2018. IDA Pro: The Interactive Disassembler. https://hex-rays.com/ida- pro/. [13]Sirui Hong, Mingchen Zhuge, Jonathan Chen, Xiawu Zheng, Yuheng Cheng, Ceyao Zhang, Jinlin Wang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, Chenyu Ran, Lingfeng Xiao, Chenglin Wu, and Jürgen Schmidhuber. 2023. MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework. arXiv preprint arXiv:2308.00352 (2023). [14]Deborah S. Katz, Jason Ruchti, and Eric Schulte. 2018. Using Recurrent Neu- ral Networks for Decompilation. In 2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengineering (SANER). 346–356. [15] Junaed Younus Khan and Gias Uddin. 2022. Automatic Code Documentation Gen- eration Using GPT-3. In Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering (ASE). [16]Johannes Kinder and Helmut Veith. 2008. Jakstab: A Static Analysis Platform for Binaries. In Proceedings of the 20th International Conference on Computer Aided Verification (CAV). 423–427. [17]Jakub Křoustek, Peter Matula, and Avast Software. 2017. RetDec: A Retargetable Machine-Code Decompiler Based on LLVM. https://github.com/avast/retdec. Presented at Botconf 2017. [18] Jeremy Lacomis, Pengcheng Yin, Edward J. Schwartz, Miltiadis Allamanis, Claire Le Goues, Graham Neubig, and Bogdan Vasilescu. 2019. DIRE: A Neural Ap- proach to Decompiled Identifier Naming. In Proceedings of the 34th IEEE/ACM International Conference on Automated Software Engineering (ASE). 628–639. [19] Hung Le, Yue Wang, Akhilesh Deepak Gotmare, Silvio Savarese, and Steven C. H. Hoi. 2022. CodeRL: Mastering Code Generation through Pretrained Models and Deep Reinforcement Learning. Advances in Neural Information Processing Systems (NeurIPS) (2022). [20] Xuan Bach D. Le, David Lo, and Claire Le Goues. 2016. History Driven Program Repair. IEEE Transactions on Software Engineering 42, 4 (2016), 318–339. [21] Claire Le Goues, ThanhVu Nguyen, Stephanie Forrest, and Westley Weimer. 2012. GenProg: A Generic Method for Automatic Software Repair. In IEEE Transactions on Software Engineering, Vol. 38. 54–72. [22]JongHyup Lee, Thanassis Avgerinos, and David Brumley. 2011. TIE: Principled Reverse Engineering of Types in Binary Programs. In Proceedings of the 18th Network and Distributed System Security Symposium (NDSS). [23]Raymond Li, Loubna Ben Allal, Yangtian Zi, Niklas Muennighoff, Denis Kocetkov, Chenghao Mou, Marc Marone, Christopher Akiki, Jia Li, Jenny Chim, Qian Liu, Evgenii Zheltonozhskii, Terry Yue Zhuo, Thomas Wang, Olivier Dehaene, Mishig Davaadorj, Joel Lamy-Poirier, Jo ao Monteiro, Oleh Shliazhko, Nicolas Gontier, Nicholas Meade, Armel Zebaze, Ming-Ho Yee, Logesh Kumar Umapathi, Jian Zhu, Benjamin Lipkin, Muhtasham Oblokulov, Zhiruo Wang, Rudra Murthy, Jason Stillerman, Siva Sankalp Patel, Dmitry Abulkhanov, Marco Zocca, Manan Dey, Zhihan Zhang, Nour Fahber Moustafa-Fahmy, Urvashi Bhattacharyya, Wenhao Yu, Swayam Singh, Sasha Luccioni, Paulo Villegas, Maxim Kunakov, Fedor Zh- danov, Manuel Romero, Tony Lee, Nadav Timor, Jennifer Ding, Claire Schlesinger, Hailey Schoelkopf, Jan Ebert, Tri Dao, Mayank Mishra, Alex Gu, Jennifer Robin- son, Carolyn Jane Anderson, Brendan Dolan-Gavitt, Danish Contractor, Siva Reddy, Daniel Fried, Dzmitry Bahdanau, Yacine Jernite, Carlos Mu noz Ferrandis, Sean Hughes, Thomas Wolf, Arjun Guha, Leandro von Werra, and Harm de Vries. 2023. StarCoder: May the Source Be with You! arXiv preprint arXiv:2305.06161 (2023). [24]Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrittwieser, Rémi Leblond, Tom Eccles, James Keeling, Felix Gimeno, Agustin Dal Lago, Thomas Hubert, Peter Choy, Cyprien de Masson d’Autume, Igor Babuschkin, Xinyun Chen, Po-Sen Huang, Johannes Welbl, Sven Gowal, Alexey Cherepanov, James Molloy, Daniel J. Mankowitz, Esme Sutherland Robson, Pushmeet Kohli, Nando de Freitas, Koray Kavukcuoglu, and Oriol Vinyals. 2022. Competition-Level Code Generation with AlphaCode. Science 378, 6624 (2022), 1092–1097. [25]Ruigang Liang, Ying Cao, Peiwei Hu, and Kai Chen. 2021. Neutron: An Attention- based Neural Decompiler. In Proceedings of the 2021 IEEE/ACM International Conference on Automated Software Engineering (ASE). [26]Aixin Liu, Aoxue Mei, Bangcai Lin, Bing Xue, Bingxuan Wang, Bingzheng Xu, Bochao Wu, Bowei Zhang, Chaofan Lin, Chen Dong, et al.2025. Deepseek- v3. 2: Pushing the frontier of open large language models. arXiv preprint arXiv:2512.02556 (2025). [27]National Security Agency. 2019. Ghidra. https://ghidra-sre.org/. Software Reverse Engineering Framework. [28]Hoang Duong Thien Nguyen, Dawei Qi, Abhik Roychoudhury, and Satish Chan- dra. 2013. SemFix: Program Repair via Semantic Analysis. In Proceedings of the 35th International Conference on Software Engineering (ICSE). 772–781. [29] Theo X. Olausson, Jeevana Priya Inala, Chenglong Wang, Jianfeng Gao, and Armando Solar-Lezama. 2023. Demystifying GPT Self-Repair for Code Generation. arXiv preprint arXiv:2306.09896 (2023). [30]Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and Ramesh Karri. 2022. Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions. In 2022 IEEE Symposium on Security and Privacy (SP). 754–768. [31]Jannik Pewny, Behrad Garmany, Robert Gawlik, Christian Rossow, and Thorsten Holz. 2015. Cross-Architecture Bug Search in Binary Executables. In 2015 IEEE Symposium on Security and Privacy (SP). 709–724. Conference’17, July 2017, Washington, DC, USA Yifan Zhang ∗ ,Xiaohan Wang ∗ ,Yueke Zhang,Kevin Leach † Vanderbilt University ∗ Equal contribution. † Corresponding author: kevin.leach@vanderbilt.edu [32]Baptiste Rozière, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiao- qing Ellen Tan, Yossi Adi, Jingyu Liu, Romain Sauvestre, Tal Remez, Jérémy Rapin, Artyom Kozhevnikov, Ivan Evtimov, Joanna Bitton, Manish Bhatt, Cris- tian Canton Ferrer, Aaron Grattafiori, Wenhan Xiong, Alexandre Défossez, Jade Copet, Faisal Azhar, Hugo Touvron, Louis Martin, Nicolas Usunier, Thomas Scialom, and Gabriel Synnaeve. 2023. Code Llama: Open Foundation Models for Code. arXiv preprint arXiv:2308.12950 (2023). [33]Kosta Serebryany. 2016. Continuous fuzzing with libfuzzer and addresssanitizer. In 2016 IEEE Cybersecurity Development (SecDev). IEEE, 157–157. [34]Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. 2023. Reflexion: Language Agents with Verbal Reinforcement Learning. In Advances in Neural Information Processing Systems (NeurIPS). [35] Yan Shoshitaishvili, Ruoyu Wang, Christopher Salls, Nick Stephens, Mario Polino, Andrew Dutcher, John Grosen, Siji Feng, Christophe Hauser, Christopher Kruegel, and Giovanni Vigna. 2016. SoK: (State of ) The Art of War: Offensive Techniques in Binary Analysis. In 2016 IEEE Symposium on Security and Privacy (SP). IEEE, 138–157. doi:10.1109/SP.2016.17 [36] André Silva, Sen Fang, and Martin Monperrus. 2023. RepairLLaMA: Efficient Representations and Fine-Tuned Adapters for Program Repair. arXiv preprint arXiv:2312.15698 (2023). [37]Hanzhuo Tan, Weihao Li, Xiaolong Tian, Siyi Wang, Jiaming Liu, Jing Li, and Yuqun Zhang. 2025. SK2Decompile: LLM-based Two-Phase Binary Decompilation from Skeleton to Skin. arXiv preprint arXiv:2509.22114 (2025). [38]Hanzhuo Tan, Qi Luo, Jing Li, and Yuqun Zhang. 2024. LLM4Decompile: De- compiling Binary Code with Large Language Models. arXiv:2403.05286 [cs.PL] https://arxiv.org/abs/2403.05286 [39] Yongpan Wang, Xin Xu, Xiaojie Zhu, Xiaodong Gu, and Beijun Shen. 2025. Salt4decompile: Inferring source-level abstract logic tree for llm-based binary decompilation. arXiv preprint arXiv:2509.14646 (2025). [40] Cerdic Wei Kit Wong. 2022. American fuzzy lop (AFL) fuzzer. (2022). [41]Chunqiu Steven Xia, Yuxiang Wei, and Lingming Zhang. 2023. Automated Program Repair in the Era of Large Pre-trained Language Models. In Proceedings of the 45th International Conference on Software Engineering (ICSE). IEEE. [42]Xiaojun Xu, Chang Liu, Qian Feng, Heng Yin, Le Song, and Dawn Song. 2017. Neural Network-based Graph Embedding for Cross-Platform Binary Code Simi- larity Detection. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (CCS). 363–376. [43]Khaled Yakdan, Sebastian Eschweiler, Elmar Gerhards-Padilla, and Matthew Smith. 2015. No More Gotos: Decompilation Using Pattern-Independent Control- Flow Structuring and Semantic-Preserving Transformations. In Proceedings of the 22nd Network and Distributed System Security Symposium (NDSS). Internet Society. [44]Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. 2023. ReAct: Synergizing Reasoning and Acting in Language Models. In International Conference on Learning Representations (ICLR).