Behavior Specification-Guided Program Synthesis for Binary Deobfuscation

Behavior Specification-Guided Program Synthesis for Binary Deobfuscation Kangchen Zhu∗† , Shangwen Wang∗‡ , Zhiliang Tian∗ , Zhouyang Jia∗ Xiaoling Li∗ , Jun Ma∗ , Jie Yu∗ , Xiaoguang Mao∗† ∗ College of Computer Science and Technology, National University of Defense Technology, Changsha, China † Also with the State Key Laboratory of Complex and Critical Software Environment

arXiv:2608.20628v1 [cs.SE] 21 Aug 2026

‡ Corresponding authors

Abstract—Deobfuscation is critical for reverse engineering and security analysis, as it restores readability and analyzability to obfuscated code. However, existing research primarily targets source-code deobfuscation, leaving binary-level deobfuscation, a more critical task given the unavailability of source code in real-world scenarios, largely underexplored. Current binary deobfuscation methods typically decompile binaries into pseudocode before applying structural transformations. However, this decompilation-based paradigm suffers from the loss of high-level semantics during compilation, such as precise types and source-level structures, often producing low-quality code and making it difficult to validate whether the recovered code preserves the intended runtime behavior of the original program. To address these limitations, we propose a paradigm shift from structural transformation to behavior-driven synthesis. Our core insight is that although obfuscation distorts a program’s internal structure, semantics-preserving transformations must retain its observable execution behavior. Building on this insight, we introduce B IN M IRROR, an approach that reframes binary deobfuscation as a behavior-specificationguided program synthesis task. By treating dynamic execution traces and interaction snapshots as behavioral specifications, B IN M IRROR synthesizes high-quality source code that is validated against observed runtime behaviors extracted from heavily obfuscated binaries. Extensive evaluations on 1.5 million synthetic obfuscated binaries show that B IN M IRROR significantly outperforms state-of-the-art baselines, achieving a 74.5% unit-test Pass@1 under extreme obfuscation. Furthermore, integrating B IN M IRROR into a downstream malware detection pipeline improves the detection of obfuscated in-thewild malware, increasing accuracy by 33.3% and F1-score by 37.1% compared with direct binary analysis. These results demonstrate the practical utility of B IN M IRROR for restoring semantic clarity in real-world security analysis.

1. Introduction Code obfuscation is a widely adopted software protection mechanism that applies semantics-preserving transformations to render programs structurally opaque while preserving their intended functionality [1]. Common transformations include dead code insertion [2], identifier renaming [3], instruction substitution [4], and control-flow flat-

tening [5]. While these techniques help protect intellectual property [6], [7], they are also frequently abused by attackers to hide malicious behaviors and evade detection [8]. Therefore, deobfuscation is essential for reverse engineering and downstream security tasks such as malware analysis and software plagiarism detection. Existing deobfuscation techniques are largely designed for source-code settings [1], [9], [10], [11], [12], [13]. These methods benefit from source-level information such as precise types, meaningful identifiers, and structured syntax, which guide pattern matching, program transformation, or learning-based rewriting. However, such assumptions rarely hold in practical security scenarios, where analysts often face stripped binary executables rather than source code [14], [15], [16]. A common workaround is to first decompile the obfuscated binary into C-like pseudocode and then apply source-level deobfuscation tools [1], [12]. Unfortunately, compilation and decompilation can remove or mis-recover high-level semantics, including variable types, source-level control structures, and contextual metadata [17]. As a result, decompilation-based pipelines may produce misleading pseudocode and make it difficult to check whether a reconstructed representation preserves observed runtime behavior. To overcome these limitations, we propose a paradigm shift: bypassing the static pattern matching on flawed decompiled pseudocode in favor of analyzing dynamic execution behavior. Our core insight is that while semanticspreserving obfuscation distorts a program’s internal structure and syntax, it must preserve the program’s observable behavior on executed paths [18], [19]. Specifically, for a given execution, the program’s externally observable interactions and side-effects should remain consistent [20], [21]. Here, we define execution behavior as the set of characteristics observed during runtime [22], and side-effects as state changes beyond simple value computation, such as modifying non-local variables, updating memory through references, or performing I/O operations [23]. Therefore, rather than treating decompiled pseudo as a reliable semantic substrate, we use observed runtime effects as an empirical behavioral anchor for guiding deobfuscation. Building upon the above observation, we propose B IN M IRROR, a novel end-to-end approach that reframes binary deobfuscation as a behavior-specification-guided program

synthesis task. This formulation does not claim that program synthesis is new in general; instead, its novelty lies in applying behavior-constrained synthesis to security-oriented binary deobfuscation, where static structure and decompiled pseudocode are often unreliable. Recognizing that Large Language Models (LLMs) have set new benchmarks in semantic inference and code synthesis [12], [24], [25], B IN M IRROR integrates an LLM as its core synthesis engine to translate low-level behavioral specifications, extracted from dynamic execution traces and interaction snapshots, into readable source-level reconstructions that are consistent with observed behavior. Specifically, B IN M IRROR operates in four sequential stages: (1) The Behavior Specification Capture stage observes the program’s dynamic runtime interactions and captures critical external events to construct an observed behavioral specification. By combining syscall-guided greybox fuzzing with dynamic binary instrumentation, it records execution context snapshots at key interaction points. (2) The Specification-Driven Noise Filtering stage extracts the instruction sequence responsible for the observed side-effects. It uses trace-enhanced backward data-flow slicing to filter out executed but behaviorirrelevant trace instructions, such as dispatcher updates, opaque-predicate computations, and MBA junk computations that do not contribute to the monitored behavior. (3) The Specification-Guided Code Synthesis stage reconstructs readable source-level code under the constraints imposed by the captured behavioral specifications. Leveraging a large language model as a semantic lifter, this stage constrains the code generation using captured input/output states and purified instruction slices, reducing unconstrained hallucination during binary-to-source lifting. Finally, (4) the TestBased Behavioral Validation stage executes the candidate code within a context-aware test harness to perform differential testing against the original binary on observed executions. Any behavioral discrepancies are fed back to the LLM through a closed-loop iterative refinement mechanism, enabling the system to iteratively improve the candidate code until it matches the captured behavioral specifications or reaches a predefined iteration bound. To comprehensively evaluate the effectiveness and practical utility of B IN M IRROR, we conducted extensive experiments. First, we constructed a massive synthetic benchmark, which consists of 1.5 million unique obfuscated binaries. We generate this dataset by applying four industry-standard obfuscators to obfuscate the collected source programs across four instruction architectures (x86, x64, ARM, MIPS) and four compiler optimization levels (O0-O3). We then evaluate the reconstructed code using Unit Test Pass Rate (Pass@1), which measures whether the compiled reconstruction passes the available source-level tests. Our results demonstrate that B IN M IRROR significantly outperforms state-of-the-art (SOTA) baselines, achieving a 74.5% unit-test Pass@1 under extreme obfuscation scenarios. To further understand when B IN M IRROR and existing tools succeed or fail, we also conduct a sample-level overlap and failure analysis, showing that B IN M IRROR is complementary to static, dynamic/symbolic, and learning-based baselines rather than

uniformly dominating them. Furthermore, to assess the quality and readability of the source-level reconstructions produced from multiple obfuscation levels, we measured the CodeBLEU [12], [26] and cyclomatic complexity [15]. The results show that B IN M IRROR yields clean, readable code, achieving an average of 68.4% CodeBLEU score and 76.2% reduction in cyclomatic complexity under extreme obfuscation. Finally, we demonstrated the downstream utility of our approach by integrating B IN M IRROR into a CFG-based Linux malware detector. The integration empowered existing detection engines to detect obfuscated malware with higher accuracy (+33.3%) and F1-scores (+37.1%), confirming that B IN M IRROR is effective in facilitating security analysis tasks. Notably, these validation results are bounded by the available tests and observed executions; B IN M IRROR does not prove semantic equivalence over all possible inputs. In summary, our contributions are as follows: • Paradigm Shift: We introduce a binary deobfuscation paradigm that shifts from traditional syntax-driven structural transformations to behavior-specification-guided program synthesis. • Approach: We propose B IN M IRROR , an end-to-end framework that combines syscall-guided behavior capture, trace-enhanced slicing, LLM-based synthesis, and differential testing to generate source-level reconstructions validated against observed runtime behaviors. • Extensive Evaluation: We evaluate B IN M IRROR on 1.5 million synthetic obfuscated binaries and real-world obfuscated malware, demonstrating strong test-based recovery effectiveness, readability improvement, and downstream malware-detection utility1 .

2. Background and Related Work Binary deobfuscation aims to recover readable and analyzable code from obfuscated binaries. In this paper, we focus on stripped binaries for which source-level information, such as variable names, precise types, and structured control flow, is unavailable or unreliable after compilation and decompilation. Our goal is to synthesize readable source code that is consistent with observed runtime behaviors and available tests. This validation is test-based and observationbounded, rather than a proof of semantic equivalence over all possible inputs. Static, symbolic, and dynamic deobfuscation. Existing binary deobfuscation techniques commonly rely on static analysis, solver-aided reasoning, or dynamic trace analysis [27]. Static tools inspect code structure without execution and apply pattern matching, algebraic simplification, data-flow analysis, or SMT-based reasoning to simplify obfuscation primitives [10], [28], [29], [30]. For instance, D810 [29] integrates into the Hex-Rays [28] microcode pipeline to perform backward variable tracking and pattern-based simplification. Dynamic and trace-based methods execute programs to observe concrete values, executed paths, and runtime side 1 The code and data used in our evaluation are available at https://zenodo. org/records/19067406.

Figure 1. A motivation example. (a) Type information such as uint8_t may be lost or mis-recovered during decompilation, causing a static deobfuscator or simplifier to incorrectly remove an overflow check from the recovered pseudocode. (b) By capturing execution-derived behavioral specifications, our approach constrains synthesis using observed runtime behavior and validates the recovered code against the captured behavior.

effects [1], [16], [31], [32], [33]. Representative systems such as QSynth [16] and Syntia [32] combine dynamic sampling, symbolic reasoning, or synthesis to simplify obfuscated expressions. However, these methods are often optimized for localized simplification rather than end-toend source recovery. They can be limited by predefined rules, state explosion, path coverage, and the cost of symbolic or enumerative search, especially when heavy controlflow flattening, bogus branches, MBA transformations, and decompiler-induced type loss make the static representation fragmented or misleading. Learning-based and LLM-based deobfuscation. Recent work increasingly explores learning-based deobfuscation, with LLMs showing strong potential for code understanding and rewriting [12], [13], [15], [26]. Prior studies have evaluated fine-tuned or prompt-based models for source-code deobfuscation, JavaScript deobfuscation, and malicious-code simplification [13], [26], [34]. For binary-level scenarios, a prevalent pipeline first lifts an obfuscated binary into C-like pseudocode or assembly and then applies sourcelevel optimization or LLM-based rewriting [1], [12], [15], [35]. For example, CHISEL [35] performs trace-informed compositional synthesis over decompiled pseudocode, while ChatDEOB [12] uses fine-tuned models after preliminary decompilation. Although effective in many cases, these pipelines remain sensitive to the semantic gap introduced by compilation and decompilation: precise types, identifiers, and source-level structure may be lost or mis-recovered, causing source-oriented models to infer incorrect logic or remove security-relevant behavior. B IN M IRROR addresses this limitation by grounding synthesis in dynamic execution traces and interaction snapshots rather than relying solely on decompiled pseudocode. Execution-derived specifications and program synthesis. Our work is also related to fuzzing, execution-based specification mining, and program synthesis. Greybox fuzzing generates inputs using lightweight feedback such as coverage [36], [37], [38], [39], while specification mining extracts behavioral facts or likely invariants from program executions [40]. These techniques provide empirical evidence

about program behavior, but their results are inherently bounded by observed executions: if an input does not trigger a path, the corresponding behavior cannot be captured. Program synthesis has also been explored for decompilation and structure recovery, such as recovering loops from hardware netlists or synthesizing structured programs from domainspecific intermediate representations [41], [42]. B IN M IR ROR is inspired by these directions but targets a different setting: security-oriented deobfuscation of heavily obfuscated stripped binaries, where source-level types, identifiers, and reliable structured pseudocode are often unavailable. Instead of recovering structure from explicit domain-specific semantics, B IN M IRROR extracts behavioral specifications from dynamic execution, filters trace-level noise, guides LLMbased source-code synthesis, and validates candidate code through differential testing on observed executions. Thus, B IN M IRROR complements prior work by treating observed runtime behavior as a specification for synthesizing and testvalidating readable source code from obfuscated binaries. B IN M IRROR does not claim novelty in dynamic tracing, slicing, synthesis, or LLM inference alone. Its contribution is a behavior-specification-guided reconstruction pipeline that turns runtime behavior into state-transfer constraints, extracts behavior-relevant binary slices, and synthesizes compilable C code validated on held-out executions, distinguishing it from expression-level synthesis and decompiler+LLM pipelines that mainly rely on recovered pseudocode.

3. Motivation Example Many current deobfuscation pipelines lift obfuscated binaries into C-like pseudocode and subsequently apply source-level transformations [1], [12], [15], [35]. However, this approach faces a critical limitation: compilation can remove or obscure high-level semantics, such as function names, source-level control structures, and precise variable types. Because the resulting pseudocode may lack this essential context, source-level tools can struggle to accurately interpret the program’s logic. Hence, this decompilationbased strategy may yield low-quality code or even remove

Behavior Specification Capture

Obfuscated Binary

Syscall-Guided Interaction Exploration Monitor

Behavior Specification Snapshots (Bspec )

Bspec =< k, SysID, Rinit , Minit > Dynamic Execution Instruction Trace (T)

Validated Source Code (Cvalidated )

Yes

Specification-Driven Noise Filtering

Specification-Guided Code Synthesis

LLM-based Semantic Lifter

Context-Aware Test Harness

1 Interpretation

Address Backward Normalization Slicing

Inputs/ Outputs

Instruction Sequence (Lext ) Behavior Snapshots

2 Abstraction 3 Construction

Test-Based Behavioral Validation

Differential Behavior Comparison

Candidate Code

No

Diff

Discrepancy Feedback & Behavior Diff (∆diff )

Execution Trace

Code Synthesis

Core Component

Iterative Refinement

Figure 2. Overview of B IN M IRROR, a four-stage behavior-specification-guided pipeline that captures observed runtime behavior, filters trace-level noise, synthesizes readable source code, and validates candidate programs through differential testing on observed executions.

security-relevant behavior when the decompiled representation is semantically misleading. To illustrate this limitation, we use a standard integeroverflow check as a motivating example. As shown on the left side of Figure 1, the source code is designed to detect an overflow when incrementing an 8-bit unsigned integer (uint8_t). Because a uint8_t occupies one byte, its valid range is 0 to 255. When the variable reaches its maximum value of 255, adding 1 mathematically yields 256 (100000000 in binary). However, under the 8-bit type constraint, the value wraps around to 0 (00000000 in binary). Consequently, the condition 0 < 255 evaluates to true, correctly invoking trigger_alert(). During compilation and decompilation, however, the precise uint8_t type may be lost or mis-recovered, depending on the compiler, optimization level, and decompiler heuristics. As shown in the upper right part of Figure 1, the decompiler may reconstruct the variable from a generic CPU register and promote it to a wider signed integer type, such as int v1. Under this recovered type, the expression v1 + 1 < v1 no longer captures the original 8-bit wraparound behavior and appears mathematically impossible in ordinary signed-integer arithmetic. When a static deobfuscator or simplifier processes this misleading pseudocode, it may conclude that the condition is always false and remove the branch as unreachable. As a result, the decompilationbased pipeline can eliminate a critical security check, even though the original binary still contains runtime behavior that triggers the alert. To overcome this limitation, our intuition is to shift the focus from transforming fragmented static syntax to analyzing observed dynamic execution behavior. For semantics-preserving obfuscation, although internal structure and syntax may be distorted, the externally observ-

able behavior on executed paths should remain consistent. As shown in the lower right part of Figure 1, our approach leverages this behavioral consistency by capturing concrete runtime states. By executing the binary with an overflow-triggering input, e.g., 255, we record the initial memory state (Minit : length = 255) and the observed branch outcome to form an execution-derived behavioral specification. These constraints provide factual runtime evidence for program synthesis and prevent the synthesizer from relying solely on flawed algebraic assumptions derived from decompiled pseudocode. Consequently, the synthesized code can preserve the observed wraparound behavior, for example, by generating a typeaware condition such as if ((uint8_t)(length + 1) < (uint8_t)length). This example highlights a real failure mode of existing decompilation-based deobfuscation pipelines and motivates our proposed solution: prioritizing observed runtime behavior over potentially misleading static syntax. Our idea shifts the paradigm from syntax-driven structural transformation to behavior-specification-guided program synthesis. By capturing dynamic execution states and validating synthesized code against the observed behavior, we reframe binary deobfuscation as a behavior-constrained synthesis task.

4. Approach 4.1. Overview Figure 2 illustrates the overview of B IN M IRROR. B IN M IRROR follows a four-stage pipeline that transforms observed runtime behavior into behavior-constrained sourcecode synthesis and test-based validation.

Phase I: Behavior Specification Capture. This stage observes dynamic runtime interactions and captures critical external events as execution-derived behavioral specifications. It combines syscall-guided greybox exploration with dynamic binary instrumentation (DBI) to record execution contexts at key interaction points. • Phase II: Specification-Driven Noise Filtering. This stage extracts the behavior-relevant instruction sequence from the dynamic trace. Starting from monitored interaction points, it applies trace-enhanced backward slicing to prune executed but behavior-irrelevant instructions, such as dispatcher updates, opaque-predicate computations, and MBA junk instructions. • Phase III: Specification-Guided Program Synthesis. This stage synthesizes readable source code under the constraints of the captured behavioral specifications. An LLM-based semantic lifter translates the purified instruction slice and its behavior snapshot into candidate code. • Phase IV: Test-Based Behavioral Validation. This stage executes the candidate code in a context-aware test harness and compares it with the original binary on observed executions. Behavioral discrepancies are fed back to the LLM through closed-loop refinement until the candidate matches the captured specifications or reaches a predefined iteration bound. •

4.2. Behavior Specification Capture This phase captures execution-derived behavioral specifications from the obfuscated binary Bobf . We focus on externally observable interaction behaviors, such as file I/O and network communication, because semantics-preserving obfuscation may distort internal code structures but should preserve such behaviors on executed paths. These interactions provide empirical runtime anchors for deobfuscation. The input is Bobf and an initial seed corpus I . The output is a set of dynamic instruction traces T = T (1) , T (2) , . . . , T (m) paired with behavior snapshots (1) (2) (m) BSP EC = Bspec , Bspec , . . . , Bspec . Each snapshot is: Bspec = ⟨k, SysID, Rinit , Minit ⟩,

(1)

where k is the trace index of the monitored interaction, SysID is the system call identifier, Rinit is the CPU register state, and Minit is the memory regions of the interaction. Syscall-Guided Exploration. Traditional fuzzing typically optimizes basic-block coverage (Covbb ) [36], [37], but this signal can be distorted by bogus control flows, flattened dispatchers, and opaque predicates in heavily obfuscated binaries. To reduce this distortion, B IN M IRROR adopts syscallguided greybox exploration [43], prioritizing inputs that trigger new externally observable interaction behaviors rather than merely increasing coverage over artificial control-flow structures. B IN M IRROR does not require source-level type information to bootstrap exploration. If sample inputs are available, they are used as seeds; otherwise, B IN M IRROR starts from empty inputs and random byte streams. During execution, the monitor observes input-related syscalls, such

as sys_read, sys_recv, sys_recvfrom, and filebacked input operations, to infer input channels and mutate the corresponding byte streams. The feedback signal is the novelty of interaction behavior instead of source-level coverage or type information. We model an execution’s observable interaction as a syscall sequence Ssys = ⟨s1 , s2 , . . . , sn ⟩, where s ∈ Ssyscall . The fuzzer maintains a global History of observed syscall sequences and preserves an input i ∈ I if executing Bobf (i) produces a new sequence. The objective is: [ max N-grams(Bobf (i)) . (2) i∈I

We set N = 3 to capture local interaction context while avoiding excessive state growth [43]. Syscall boundaries serve as interaction anchors rather than the sole semantic source; computation between boundaries is represented through register/memory snapshots, branch traces, and observed state-transfer relations. Interaction Monitoring and Snapshot Generation. During exploration, B IN M IRROR uses dynamic binary instrumentation (DBI) [31] to monitor runtime side effects. Rather than treating every executed instruction as equally important, the monitor listens for a predefined target syscall set Ωtarget ⊂ Ssyscall covering critical file-system operations, e.g., sys_open, sys_read, and sys_write, and network operations, e.g., sys_socket, and sys_connect. When a syscall in Ωtarget is invoked, the DBI engine suspends execution and triggers a bounded capture handler. The handler performs four steps: (1) interaction identification, reading the syscall number to obtain SysID; (2) pointer tracing, following architecture-specific calling conventions to inspect parameter registers and recursively trace memory pointers with depth limits and page-validity checks; (3) payload extraction, computing the payload length and safely dumping the referenced memory; and (4) state construction, recording the relevant registers and memory payloads as Rinit and Minit . The resulting Bspec serves as an execution-derived constraint for subsequent noise filtering, code synthesis, and behavioral validation.

4.3. Specification-Driven Noise Filtering This phase extracts trace-level instructions that contribute to the observed runtime behavior. Since the input is a dynamic trace, it does not remove never-executed dead code; instead, it filters executed but behavior-irrelevant instructions, such as flattened dispatcher updates, opaque-predicate computations, and MBA junk computations that appear in the trace but do not affect the monitored interaction. Given a dynamic trace T = ⟨i1 , i2 , . . . , in ⟩ and a behavior snapshot Bspec = ⟨k, SysID, Rinit , Minit ⟩ from Phase I, where ik triggers the monitored interaction, this phase outputs a behavior-relevant instruction slice Lext ⊆ T : Lext = ij ∈ T | j ≤ k ∧ Path(ij → ik ) |= Bspec ,

(3)

where Lext retains instructions in the transitive data-flow closure that contribute to the state specified by Bspec .

Address Normalization. Before slicing, B IN M IRROR normalizes runtime addresses to remove the offsets introduced by ASLR [44] and PIE [45]. For each instruction ij with runtime address Addrdyn (ij ), the system parses runtime memory mappings and static ELF headers to identify the dynamic load base Basedyn and the static base Basestatic . It then computes the relocation offset ∆ = Basedyn − Basestatic and maps the instruction to its static address: Addrstatic (ij ) = Addrdyn (ij ) − ∆.

(4)

This mapping aligns dynamic traces with static binary locations, enabling address-consistent dependency analysis. Trace-Driven Backward Slicing. Starting from the specification index k , B IN M IRROR traverses the trace backward and tracks an active dependency set V , initialized with Rinit ∪ Minit . For each instruction ij , the system computes its definition set Def (ij ) and uses the set U se(ij ). If Def (ij ) ∩ V = ∅, the instruction does not influence the monitored state and is discarded. Otherwise, it is added to Lext , and the dependency set is updated as V ← (V \ Def (ij )) ∪ U se(ij ). To further remove control-flow-flattening noise, B IN M IRROR applies an orthogonality check. If an instruction only updates scheduling-related architectural state, such as EFLAGS or RIP, and preserves the transitive dependency closure of V , it is treated as dispatcher noise and skipped. By combining dependency closure filtering with this orthogonality check, B IN M IRROR extracts a compact slice Lext that captures the computation needed to reproduce the monitored interaction while excluding trace-level noise designed to mislead traditional deobfuscators. Slicing is performed over executed instruction semantics rather than decompiler variables. We recover register and memory uses and definitions from architecturespecific operand semantics, including implicit flags, condition codes, stack updates, and ABI syscall arguments. For inter-procedural traces, traced callees are inlined, while unresolved indirect or library calls are summarized by observed arguments, return values, and memory effects. Heap, global, and multi-syscall state are represented through monitored address ranges and ordered protocol windows. Unresolved dependencies are retained conservatively, and unsupported side effects are marked unsupported. The slice preserves observed-execution dependencies, but does not claim all-path static completeness.

4.4. Specification-Guided Code Synthesis This phase lifts the behavior-relevant instruction slice Lext into readable source code that is consistent with the captured behavioral specifications. To reduce hallucinations and uncertainty in LLM-based code generation [46], [47], we ground synthesis in factual execution constraints derived from dynamic runtime behavior. The input consists of Lext and the behavior snapshot Bspec = ⟨k, SysID, Rinit , Minit ⟩; the output is candidate

source code Ccandidate . We formulate synthesis as conditionally constrained generation: arg

max

Ccandidate

P (Ccandidate | Lext , Bspec ).

(5)

Prompt Design. The structured prompt guides the LLM to reason from objective runtime facts rather than unconstrained guesses. It contains four compact components. First, the system prompt assigns the model the role of an expert reverse engineer and defines the task as synthesizing readable code constrained by dynamic execution observations. Second, the input context provides two factual inputs: the behavior-relevant instruction sequence Lext and the behavioral constraints derived from Bspec , including the initial state Spre , composed of Rinit and Minit , and the target interaction boundary Spost , defined by the syscall identifier and target memory state. Third, the instruction body asks the model to reason in three steps: infer the observed statetransfer relation ΦIO : Spre → Spost , abstract low-level instructions into high-level constructs, and construct standard C source code. Finally, the output constraint requires the model to emit only the candidate source code, omitting explanations and markdown metadata. By anchoring generation to the behavior-relevant slice and observed Spre → Spost relation, this stage reduces reliance on flawed pseudocode and guides code toward the captured runtime behavior.

4.5. Test-Based Behavioral Validation This final phase tests whether the synthesized candidate code reproduces the monitored runtime behavior and observable side effects of the original binary on observed executions. It provides test-based behavioral validation with respect to captured specifications. The input includes Ccandidate , Bobf , and the Phase-I behavior snapshot Bspec ; the output is Cvalidated if the candidate reproduces the captured behavior in a contextaware test harness. Context-Aware Test Harness. B IN M IRROR compiles Ccandidate into Binrec and executes it in an isolated Unicorn-based emulator [48]. The harness restores Rinit and Minit from Bspec , aligning the candidate reconstruction with the monitored context of the original binary slice. After synchronization, B IN M IRROR executes Bobf and Binrec under the same observed context. At the target interaction point, it extracts Sorig and Srec and checks behavioral consistency as: Sorig ≡ Srec ⇐⇒ (SysIDorig = SysIDrec ) ∧ (Argsorig = Argsrec ) ∧ (Memorig = Memrec ).

(6)

A candidate passes if the syscall identifiers, arguments, and relevant memory payloads match byte-level observations. This checks consistency with the captured snapshot, not allinput semantic equivalence. Discrepancy Feedback and Refinement. If Sorig ≡ Srec holds on the validation cases, the candidate is promoted

to Cvalidated . Otherwise, B IN M IRROR computes ∆dif f = Sorig ⊖ Srec and summarizes the mismatched syscall ID, argument, register, or memory payload as structured feedback (t+1) to the LLM. The synthesis engine then generates Ccandidate . The loop stops when the monitored discrepancy is eliminated or Nmax is reached, whose sensitivity is studied in § 7.1.

5. Experimental Setup 5.1. Research Questions We evaluate B IN M IRROR from five perspectives: effectiveness against baselines (RQ1), robustness across architectures and compiler optimizations (RQ2), contribution of individual components (RQ3), code quality and readability (RQ4), and downstream utility for CFG-based Linux malware detection (RQ5).

5.2. Datasets We construct two datasets: a controlled Synthetic Benchmark with available source-level tests, and MalBench, a realworld malware benchmark for practical security evaluation. Synthetic Benchmark. We construct the Synthetic Benchmark from CodeNet [49]. From 341,069 C/C++ programs, we retain 1,573 programs that are non-trivial, executable, and suitable for controlled obfuscation, requiring average cyclomatic complexity greater than 15, more than 150 source lines, and successful compilation and evaluationpipeline execution. The retained set is therefore a controlled benchmark rather than a representative sample of all CodeNet programs. We obfuscate the retained programs using O-LLVM [7], Hikari [50], Tigress [51], and Alcatraz [52]. We apply six transformations, BCF, SUB, FLA, MBA, Opaque Predicates, and ImmMov, and combine them into 63 non-empty configurations from L1 to L6. Each configuration is compiled across four architectures, x86, x64, ARM, and MIPS, and four optimization levels, O0–O3, with symbols and debugging information stripped. This expansion yields 1,585,584 synthetic obfuscated binaries from the 1,573 retained source programs. Appendix A reports the filtering reason-code distribution and audit metadata. MalBench. MalBench contains 500 active Linux obfuscated malware samples collected from VirusShare [53] and MalwareBazaar [54] between 2023 and 2025. Following prior malware-evaluation practice [26], [55], we retain samples flagged by at least 10 independent VirusTotal engines and exhibiting high cyclomatic complexity and heavily flattened control flow. Because in-the-wild malware lacks source code and unit tests, we use observed behavioral consistency as the validation oracle: reconstructed code must reproduce the monitored syscall sequences and input-output interactions under the same input harness. This oracle is bounded by observed executions and does not imply all-input semantic equivalence. For downstream detection, MalBench uses malware-family-aware partitions and a benign corpus

TABLE 1. I NPUT- INDUCED PATH COVERAGE .

Metric

Synthetic

MalBench

Basic-block coverage Branch-edge coverage Unique execution paths/sample

95% 90% 12 [4, 20]

88% 70% 8 [2, 16]

matched by platform, executable format, package source, and file-size range. We retain hashes, family labels, first-seen dates, sandbox policy, and benign provenance as metadata, but do not redistribute live malware. See Appendix B for more details about MalBench.

5.3. Evaluation Metrics We use three correctness-oriented metrics and three readability-oriented metrics. Compilation Rate (CR) measures the percentage of reconstructed programs that compile without manual intervention. Unit Test Pass Rate (Pass@1) measures whether the compiled reconstruction passes the available source-level tests in the Synthetic Benchmark. Execution Success Rate (ESR) evaluates MalBench by checking whether the original and reconstructed binaries produce the same monitored syscall sequences and I/O interactions under the same input harness. For code quality, Cyclomatic Complexity Reduction (CCR) measures control-flow simplification relative to raw IDA Pro decompilation, CodeBLEU measures structural and data-flow similarity to available ground-truth source code, and Halstead Effort Reduction (HER) measures lexical and cognitive-complexity reduction. Rates are computed over the full evaluated denominator, including pass, fail, timeout, and unsupported outcomes. LLM-based methods and B IN M IRROR are run five times with independent seeds and reported as mean± SD, while deterministic tools are run once under fixed versions/settings and therefore have SD=0.0. Held-Out Behavioral Validation. For dynamic specification experiments, we split observed executions into refinement and held-out sets before reconstruction. The Synthetic Benchmark uses 16 [8, 30] refinement inputs and 4 [2, 10] held-out inputs per sample, while MalBench uses 12 [3, 20] and 3 [2, 8], reported as median [IQR]. Synthetic inputs come from source-level harnesses and generated tests, whereas MalBench inputs include sandbox stimuli such as arguments, staged files, environment settings, and replay configurations. Only refinement inputs are used for prompts, feedback, and repair; held-out inputs are never exposed to any method or controlled variant. We normalize or mask time-, PID-, path-, and network-dependent fields, and mark unreplayable executions as unsupported. A reconstruction is credited only if it compiles and passes held-out source-level tests on the Synthetic Benchmark or syscall/I/O consistency checks on MalBench. Thus, validation reduces trace-level overfitting but remains bounded by explored executions. Coverage Reporting. We report input-induced path coverage to make the scope of the observation-bounded oracle ex-

TABLE 2. E FFECTIVENESS ON THE S YNTHETIC B ENCHMARK . CR AND PASS @1 ARE REPORTED FOR X 64-O0 BINARIES ACROSS OBFUSCATION LEVELS L0–L6 AS MEAN ± SD OVER FIVE RUNS . Method Ghidra D810 GooMBA ANGR Syntia Llama-3.1 Claude-3.5 GPT-4o CodeLlama Qwen2.5-C DeepSeek-C Recopilot ChatDEOB LLM+Dyn LLM+Dyn+Fb B IN M IRROR

L0 (Baseline) CR P@1 25.4±0.0 18.5±0.0 30.5±0.0 26.4±0.0 28.6±0.0 20.1±0.0 45.2±0.0 38.5±0.0 50.5±1.5 42.1±1.8 62.4±1.2 55.2±1.5 68.5±1.0 62.1±1.2 72.1±0.8 66.5±1.0 74.2±0.9 68.1±1.1 78.1±0.7 72.2±0.9 81.5±0.6 76.2±0.8 84.2±0.5 80.1±0.6 88.1±0.4 84.2±0.5 88.3±0.2 85.2±0.3 89.2±0.5 86.1±0.4 94.5±0.2 92.1±0.3

L1 CR 12.1±0.0 25.2±0.0 22.4±0.0 35.1±1.2 38.4±2.1 50.1±1.8 58.4±1.6 62.5±1.4 64.1±1.5 70.3±1.2 74.1±1.0 78.5±0.9 82.2±0.8 83.5±0.6 85.1±0.3 93.2±0.3

L2 P@1 5.2±0.0 20.1±0.0 15.3±0.0 28.4±1.4 30.5±2.4 42.5±2.0 50.2±2.0 55.4±1.8 56.2±1.8 64.1±1.5 68.3±1.2 72.4±1.2 76.1±1.0 79.1±1.5 80.5±1.2 90.5±0.4

CR 4.5±0.0 15.4±0.0 18.5±0.0 22.4±1.8 28.6±2.8 38.5±2.4 45.2±2.5 50.4±2.2 51.5±2.4 58.2±2.0 64.2±1.8 68.5±1.5 74.1±1.2 77.1±1.3 80.7±0.9 91.5±0.4

L3 P@1 1.0±0.0 10.2±0.0 10.4±0.0 15.6±2.0 20.4±3.1 30.1±2.8 38.4±2.8 42.1±2.6 44.1±2.6 51.2±2.4 56.1±2.1 61.2±1.8 68.2±1.6 69.2±1.4 71.2±1.5 88.2±0.5

plicit. Here, a sample denotes one reconstruction task, while an input denotes an execution stimulus, such as commandline arguments, stdin, staged files, environment settings, or sandbox replay configurations, used to trigger observable behavior. Coverage is measured over the behavior-relevant target region extracted for each reconstruction task, rather than over the entire binary. As shown in Table 1, the execution inputs cover 95% of target-region basic blocks and 90% of branch edges on the Synthetic Benchmark, and 88% and 70% on MalBench, respectively. The median number of unique execution paths per sample is 12 on the Synthetic Benchmark and 8 on MalBench, indicating that validation is not limited to repeatedly replaying a single path. These statistics do not imply complete path coverage or all-input semantic equivalence; instead, they make explicit the behavioral scope over which the reported reconstruction results are validated.

5.4. Baselines To provide a comprehensive evaluation, we compare B IN M IRROR with representative baselines across static analysis, symbolic/dynamic analysis, hybrid synthesis, and LLM-based paradigms. We compare B IN M IRROR with representative baselines from four categories: static tools, including Ghidra [56], D810 [29], and GooMBA [57]; symbolic/dynamic tools, including ANGR [58] and Syntia [32]; general-purpose and code LLMs, including GPT4o [59], Claude-3.5-Sonnet [60], Llama-3.1 [61], Qwen2.5Coder [62], CodeLlama [63], and DeepSeek-Coder [64]; and domain-specific binary/deobfuscation models, including Recopilot [65] and ChatDEOB [12]. To separate method effects from information-budget effects, we additionally include two controlled LLM variants: LLM+DynEvidence (LLM+Dyn), which receives the same bounded runtime traces and monitored snapshots as B IN M IRROR, and LLM+DynEvidence+Feedback (LLM+Dyn+Fb), which further receives the same compile/test feedback budget but does not perform trace-driven slicing or behavior-specificationguided constraint construction.

CR 1.2±0.0 5.1±0.0 8.2±0.0 10.5±2.2 18.2±3.2 25.4±3.1 30.5±3.2 38.2±3.0 38.2±3.1 46.1±2.8 51.4±2.5 56.2±2.2 64.2±2.0 66.8±2.5 72.6±2.6 89.4±0.5

L4 P@1 0.0±0.0 2.5±0.0 4.1±0.0 6.2±2.4 12.5±3.5 18.5±3.4 22.5±3.6 28.5±3.5 31.5±3.4 38.5±3.2 44.2±2.8 48.5±2.5 56.4±2.4 56.7±2.2 61.9±2.7 84.5±0.6

CR 0.0±0.0 1.8±0.0 2.5±0.0 4.2±1.5 10.1±2.6 15.2±2.8 20.1±3.0 25.5±3.2 26.5±3.2 34.2±3.0 38.2±2.9 44.1±2.8 51.5±2.6 56.6±2.8 60.1±3.3 87.2±0.6

L5 P@1 0.0±0.0 0.0±0.0 0.0±0.0 1.5±0.8 5.4±2.0 10.4±2.5 14.2±2.8 18.4±3.0 18.2±3.0 26.4±3.1 31.5±3.2 36.2±3.0 44.1±3.2 43.9±2.7 51.2±2.5 81.1±0.8

CR 0.0±0.0 0.0±0.0 0.0±0.0 1.0±0.5 4.5±1.8 8.5±2.1 12.4±2.5 15.2±2.8 16.4±2.8 22.1±2.8 26.4±3.0 31.2±3.2 38.2±3.5 44.2±3.7 53.8±2.8 84.5±0.8

P@1 0.0±0.0 0.0±0.0 0.0±0.0 0.0±0.0 2.0±1.2 5.2±1.8 8.5±2.2 10.5±2.5 10.5±2.6 14.2±2.9 20.2±3.1 24.4±3.4 31.5±3.8 34.4±3.2 42.5±3.5 77.2±1.0

L6 (Extreme) CR P@1 0.0±0.0 0.0±0.0 0.0±0.0 0.0±0.0 0.0±0.0 0.0±0.0 0.0±0.0 0.0±0.0 1.2±0.5 0.5±0.2 4.2±1.5 2.1±1.0 6.5±1.8 4.2±1.5 8.4±2.1 5.5±1.8 9.5±2.4 5.2±2.0 12.4±2.6 7.5±2.2 16.5±2.8 11.2±2.6 20.5±3.1 14.5±2.9 26.4±3.6 20.2±3.4 35.1±3.4 23.6±3.5 44.2±2.8 39.1±2.9 81.4±1.1 74.5±1.2

Because LLM-based approaches lack native support for direct end-to-end recovery from raw binaries, we first utilized standard decompilers to translate the obfuscated inputs into pseudocode before feeding them into the LLMs. See Appendix C for more details about baselines.

5.5. Implementation Details All experiments were conducted on a workstation equipped with dual Intel Xeon Gold 6248R processors, 512GB of RAM, and four NVIDIA RTX 4090 GPUs, running Ubuntu 22.04 LTS. All LLM-based baselines, controlled variants, and B IN M IRROR use fixed prompt templates, temperature = 0.2, top-p = 1.0, a 4K output cap, and the input budgets specified in Appendix C. We record exact model identifiers, provider/checkpoint information, prompttemplate hashes, retry limits, context-truncation policy, and seeds in the artifact logs. Held-out inputs are excluded from all prompts, feedback messages, repair rounds, and truncation decisions. More implementation details can be found in Appendix D.

6. Evaluation 6.1. RQ1: Effectiveness Table 2 reports CR and Pass@1 on x64-O0 Synthetic Benchmark binaries, with model names abbreviated for space. Specifically, we draw the following key observations. Baselines degrade under compositional obfuscation. Existing methods degrade as obfuscation becomes more compositional. Traditional static tools, such as Ghidra, D810, and GooMBA, and symbolic or dynamic techniques, such as ANGR and Syntia, drop to near-zero accuracy at higher levels because rule-based recovery and bounded exploration struggle with flattened control flow, artificial branches, and complex predicates. LLM-based methods are more resilient but still degrade sharply: GPT-4o drops from 66.5% Pass@1 at L0 to 5.5% at L6, while the domain-specific ChatDEOB reaches only 20.2% Pass@1 at L6. It suggests that larger

TABLE 3. E XECUTION SUCCESS RATE ON M AL B ENCH .

TABLE 4. S AMPLE - LEVEL OVERLAP ANALYSIS .

Method

Category

#Cases

Percentage

Both Succeed B IN M IRROR-Only Baseline-Only Both Fail

1,037 1,331 82 550

34.6% 44.4% 2.7% 18.3%

Ghidra D810 GooMBA ANGR Syntia Llama-3.1 Claude-3.5

ESR (%) 0.0 0.0 0.0 4.2 6.5 8.4 12.5

Method GPT-4o CodeLlama Qwen2.5-C DeepSeek-C Recopilot ChatDEOB B IN M IRROR

ESR (%) 15.2 18.4 22.5 25.4 31.2 36.5 65.8

models or task-specific fine-tuning are insufficient when the input is dominated by misleading obfuscated structure. BinMirror preserves effectiveness under severe obfuscation. In contrast, B IN M IRROR maintains substantially higher effectiveness under severe obfuscation. At L6, B IN M IRROR achieves 74.5% Pass@1, outperforming the strongest evaluated baseline, ChatDEOB, by 54.3 percentage points. It also achieves the highest compilation rate at L6, 81.4%, indicating that behavior-constrained synthesis and closedloop feedback help reduce invalid code generation. These results support the central design choice of reconstructing code from behavior-relevant slices and observed runtime constraints rather than directly transforming the obfuscated code structure. Controlled variants isolate the method effect. To test whether the gains of B IN M IRROR come from the proposed pipeline rather than from simply giving an LLM more runtime evidence, Table 2 includes two evidence-matched controlled variants. LLM+DynEvidence receives the same syscall traces and monitored I/O snapshots as B IN M IR ROR , and LLM+DynEvidence+Feedback further receives the same compile and test feedback budget. However, these variants do not perform trace-driven slicing or behaviorspecification-guided constraint construction, and held-out inputs are never exposed during refinement. Although the controlled variants improve over prior LLM baselines, the strongest one still trails B IN M IRROR by 22.2 percentage points in average Pass@1 and by 35.4 percentage points at L6. This result indicates that the improvement is not explained by a larger information budget alone, but by how B IN M IRROR organizes runtime observations into behaviorrelevant slices and synthesis constraints. BinMirror remains effective on real-world malware. Table 3 reports Execution Success Rate (ESR) on MalBench, a dataset of real-world Linux obfuscated malware. In this setting, traditional static tools such as Ghidra and D810 obtain zero ESR, while ANGR and Syntia reach only 4.2% and 6.5%, respectively. LLM-based methods show limited robustness, ranging from 15.2% for GPT-4o to 36.5% for ChatDEOB. By contrast, B IN M IRROR achieves 65.8% ESR, outperforming the strongest baseline by 29.3 percentage points. This result suggests that behavior-specificationguided reconstruction remains useful beyond controlled synthetic obfuscation, especially when real malware combines structural noise, environmental dependencies, and antianalysis behaviors. We interpret this result as behavioral consistency over the family-aware MalBench split, not as

recovery of complete malware source code. BinMirror covers many cases missed by baselines. We analyze sample-level overlap on 3,000 Synthetic Benchmark cases randomly sampled from L2, L4, and L6. D810, Syntia, and ChatDEOB represent static, dynamic/symbolic, and learning-based baselines, respectively. A sample is counted as a baseline success if any of the three baselines produces a reconstruction that passes the corresponding test suite. Table 4 shows that B IN M IRROR succeeds alone on 1,331 cases, or 44.4%, indicating that it recovers many samples missed by representative baselines. These B IN M IRROR-only cases mainly involve controlflow flattening, opaque predicates, MBA transformations, or decompiler-induced type and structure loss, where static structure becomes unreliable. Baseline-only cases account for 82 cases, or 2.7%, and mainly involve local expressionlevel obfuscation or simple opaque predicates that static or symbolic methods can simplify. The both-fail category accounts for 18.3%, showing that some cases remain difficult for all evaluated approaches, especially when generated inputs do not cover the relevant behavior or synthesis cannot produce compilable code under the captured constraints. Overall, the overlap analysis shows that B IN M IRROR expands the set of recoverable cases rather than merely improving already-solved ones, while still leaving room for complementary static and symbolic techniques on localized simplification tasks.

6.2. RQ2: Robustness To evaluate the robustness across architectures and optimizations, Figure 3 shows the results across different instruction set architectures, including ARM, MIPS, X86, and X64, and compilation optimization levels from O0 to O3. We compare B IN M IRROR with ChatDEOB, the strongest evaluated baseline in RQ1. Architectures. ChatDEOB shows a clear performance drop across different architectures. At Level-1 under O0, ChatDEOB achieves 84.86% on X64 but drops to 74.69% on ARM. This gap suggests a limitation in its reliance on decompiled pseudocode and architecture-specific structural patterns. It performs better on prevalent X64 structures but struggles with the distinct control-flow and instruction representations found in RISC architectures. In contrast, B IN M IRROR demonstrates stronger cross-architecture robustness. At Level-1 under O0, B IN M IRROR achieves 97.58% on X64 and maintains 86.05% on ARM. Even under extreme L6 obfuscation, B IN M IRROR maintains a 78.57% success

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

2

$50    

   

   

   

   

   

0,36    

   

   

   

   

   

;    

   

   

   

   

   

;    

   

   

   

   

   

































$50    

   

   

   

   

   

0,36    

   

   

   

   

   

;    

   

   

   

   

   

;    

   

   

   

   

   

/

/

/

/

/

/

Figure 3. Performance (Pass@1) across architectures and optimizations. Rows 1 and 2 show results for ChatDEOB [12] and B IN M IRROR across six obfuscation levels, respectively. TABLE 5. A BLATION STUDY ON THE S YNTHETIC B ENCHMARK . CR AND PASS @1 ARE REPORTED ACROSS OBFUSCATION LEVELS L0–L6 AFTER REMOVING EACH CORE COMPONENT FROM B IN M IRROR . Configuration w/o Backward Slicing w/o I/O Constraints w/o Iterative Refinement B IN M IRROR (Full)

L0 (No Obf.) CR Pass@1 88.4 82.5 91.5 85.2 92.1 88.4 94.5 92.1

CR 82.0 86.8 89.5 93.2

L1 Pass@1 73.1 80.4 85.2 90.5

CR 76.5 82.1 87.4 91.5

L2 Pass@1 65.4 74.5 82.1 88.2

rate on X64-O0 and 68.92% on ARM-O0, outperforming ChatDEOB’s 25.51% and 22.90% in the same settings. By relying on dynamic execution observations, B IN M IRROR reduces the syntax gap between different instruction sets.

Optimizations. We observe consistent performance degradation across compilation optimization levels. Higher optimizations (O2 and O3) introduce aggressive register allocation, instruction reordering, and function inlining, which can disrupt the expected pseudocode layout. ChatDEOB is sensitive to these changes. On the X64 architecture at L1, its performance decreases from 84.86% under O0 to 75.57% under O3. Under severe L6 obfuscation, the combination of aggressive optimization and complex transformations causes ChatDEOB to drop to 23.00% on X64-O3 and 20.82% on ARM-O3. In contrast, B IN M IRROR is less affected by compiler-induced structural changes. At Level-1 on X64, B IN M IRROR retains an 86.45% success rate even at O3. Under the most demanding L6 configuration, B IN M IRROR achieves 69.94% on X64-O3 and 61.82% on ARM-O3. These results suggest that behavioral constraints help B IN M IRROR maintain recovery effectiveness across architecture and optimization differences, although performance still decreases as optimization and obfuscation complexity increase.

CR 68.2 77.5 84.2 89.4

L3 Pass@1 54.8 67.2 77.5 84.5

CR 60.2 72.4 80.5 87.2

L4 Pass@1 45.1 61.2 71.4 81.1

CR 51.5 67.8 76.8 84.5

L5 Pass@1 36.2 54.5 65.8 77.2

L6 (Extreme) CR Pass@1 42.5 28.5 62.5 48.4 72.6 60.5 81.4 74.5

6.3. RQ3: Ablation Study To assess component contributions, we conduct ablation studies on three variants of B IN M IRROR, each removing one key component: trace-driven backward slicing (w/o Backward Slicing), dynamic I/O constraints during synthesis (w/o I/O Constraints), and context-aware differential testing with closed-loop feedback (w/o Iterative Refinement). As shown in Table 5, we evaluate all variants on the Synthetic Benchmark under x64-O0 across obfuscation levels L0–L6. Removing backward slicing and directly feeding raw traces to the LLM substantially degrades performance, especially under extreme obfuscation. At L6, Pass@1 drops from 74.5% to 28.5%, indicating that slicing is crucial for filtering dispatcher logic or MBA junk instructions before synthesis. Removing dynamic I/O constraints also reduces L6 Pass@1 to 48.4%, showing that behavioral specifications are important for grounding LLM generation. Finally, without iterative refinement, L6 Pass@1 falls to 60.5%, suggesting that differential testing and closed-loop feedback improve test-based behavioral consistency.

6.4. RQ4: Code Quality and Readability Table 6 presents the results on the Synthetic Benchmark using CodeBLEU, Cyclomatic Complexity Reduction

TABLE 6. C ODE QUALITY AND READABILITY ON THE S YNTHETIC B ENCHMARK . Method D810 [29] Syntia [32] GPT-4o [59] DeepSeek-Coder [64] ChatDEOB [12] B IN M IRROR (Ours)

L1 36.4 25.4 55.4 62.5 71.2 88.5

L2 25.1 16.8 46.2 54.1 63.8 84.6

CodeBLEU (↑) L3 L4 12.5 8.4 10.2 7.1 38.5 29.4 45.6 36.2 55.4 47.1 80.2 75.8

L5 6.1 5.2 22.1 29.5 39.8 72.1

L6 5.2 4.5 18.5 24.5 34.5 68.4

L1 31.5 22.5 58.2 65.2 74.5 93.5

CCR % (↑) L3 L4 8.2 4.5 8.4 5.0 35.4 26.8 48.5 37.1 58.2 46.5 85.4 82.1

L2 18.5 14.1 45.1 56.4 66.1 89.2

L5 2.8 3.1 19.5 26.4 36.2 78.8

L6 2.1 2.1 15.2 20.2 28.4 76.2

L1 34.2 18.6 52.1 60.4 71.8 91.2

L2 21.0 10.4 41.5 51.2 64.2 87.1

HER % (↑) L3 L4 10.5 3.2 5.2 3.1 32.4 23.1 42.1 31.5 56.5 45.1 82.6 78.4

L5 −2.1 2.0 16.8 23.4 34.8 75.2

L6 −5.8 1.5 12.4 18.5 25.6 72.8

TABLE 7. M ALWARE DETECTION PERFORMANCE ON OBFUSCATED BINARIES .

Detection Pipeline

Precision (%)

Recall (%)

F1-Score (%)

Accuracy (%)

HawkEye-Linux

61.4

48.2

54.1

58.2

64.2 (2.8↑) 76.8 (15.4↑) 92.4 (31.0↑)

56.0 (7.8↑) 72.4 (24.2↑) 90.1 (41.9↑)

59.8 (5.7↑) 74.5 (20.4↑) 91.2 (37.1↑)

62.4 (4.2↑) 75.8 (17.6↑) 91.5 (33.3↑)

HawkEye-Linux + D810 HawkEye-Linux + ChatDEOB HawkEye-Linux + B IN M IRROR (Ours)

(CCR), and Halstead Effort Reduction (HER) to evaluate structural complexity and human readability of the sourcelevel reconstructions across escalating obfuscation levels. Traditional static and dynamic tools exhibit rapid degradation as obfuscation intensifies, with D810 dropping to a negative HER of −5.8% at Level-6. This indicates that rulebased matching can generate excessive goto statements and redundant intermediate variables, making the decompiled output more complex and harder to read. Similarly, LLMbased methods experience a performance drop under compound obfuscations, as seen with the domain-specific ChatDEOB decreasing from 74.5% CCR at Level-1 to 28.4% CCR and 25.6% HER at Level-6. This vulnerability suggests that relying primarily on static syntactic patterns or supervised fine-tuning leaves models susceptible to hallucination when multi-layered structural noise disrupts the expected pseudocode distribution. In contrast, B IN M IRROR maintains stronger performance across all evaluated metrics and obfuscation levels. At Level-1, it achieves 88.5% CodeBLEU and reduces cyclomatic complexity by 93.5%. Under Level-6, it sustains 68.4% CodeBLEU, 76.2% CCR, and 72.8% HER, outperforming ChatDEOB by large margins in complexity reduction. By anchoring source-level reconstruction to dynamic execution observations rather than static parsing alone, B IN M IRROR avoids many injected fake branches and redundant predicates, producing more compact and readable observed-behavior-consistent code.

6.5. RQ5: Downstream Utility To evaluate whether B IN M IRROR improves downstream security analysis, we conduct a malware detection experiment on heavily obfuscated Linux executables. We use HawkEye-Linux, a HawkEye-style CFG-based detector adapted to Linux ELF artifacts [66]. The detector extracts CFGs from executable artifacts, represents basic blocks with instruction-level features, learns graph-level program

embeddings with a graph neural network, and performs malware/benign classification with a fixed classifier head. It does not directly consume reconstructed source code, pseudocode, ASTs, or manually engineered semantic features. All pipelines are normalized through executable artifacts. The direct binary-analysis condition uses the original obfuscated ELF binary as the detector artifact. For deobfuscationenhanced conditions, each front-end first produces a simplified or reconstructed representation, which is then compiled into a normalized Linux ELF artifact using the same compiler configuration, linker setting, wrapper template, and stripping policy whenever possible. HawkEye-Linux then extracts CFGs and instruction-level features from the resulting executable artifact. If artifact construction fails within the timeout, we fall back to the original obfuscated ELF and record the case as an artifact-construction failure. All pipelines use the same family-aware train/validation/test split, benign-matching policy, graph-extraction procedure, model architecture, hyperparameters, random seed, and threshold-selection rule. Thus, RQ5 measures whether different deobfuscation front-ends produce executable artifacts whose graph representations are more useful for downstream Linux malware detection. The evaluation uses matched malware and benign corpora. We construct a balanced corpus with 500 in-the-wild Linux malware samples from MalBench and 500 benign Linux executables collected from standard Ubuntu repositories. The malware set covers active families such as Mirai, Gafgyt, and ransomware samples, and includes binaries protected by multi-layered anti-analysis transformations. Both malware and benign samples are processed under the same construction and graph-extraction protocol to reduce label leakage. BinMirror improves downstream malware detection. Table 7 reports the detection results across the evaluated pipelines. When HawkEye-Linux analyzes the original obfuscated binaries directly, it achieves only 58.2% accuracy and 54.1% F1-score, indicating that aggressive structural obfuscation weakens CFG-based malware classification.

TABLE 8. I MPACT OF THE ITERATION LIMIT (Nmax ) ON THE S YNTHETIC B ENCHMARK UNDER THE L6 CONFIGURATION .

Iteration Nmax

1

2

3

4

5

6

8

10

Pass@1 (%) Gain (∆ %) Avg. Time (s)

60.5% 5.2

67.8% +7.3% 10.4

71.4% +3.6% 15.7

73.5% +2.1% 21.1

74.5% +1.0% 26.5

74.7% +0.2% 32.1

74.8% +0.1% 43.5

74.8% +0.0% 55.2

TABLE 9. E FFECT OF SLICE LENGTH UNDER L6 OBFUSCATION . L ONGER EXTRACTED SLICES |Lext | ARE ASSOCIATED WITH LOWER SYNTHESIS ACCURACY.

Slice Length (|Lext |)

Proportion of Dataset (%)

Cumulative Pass@1 (Success Rate %)

≤ 50 instructions 51 − 100 instructions 101 − 250 instructions 251 − 500 instructions > 500 instructions

25.4% 34.6% 24.5% 10.5% 5.0%

92.4% 85.1% 71.3% 45.2% 21.6%

Adding deobfuscation front-ends improves performance to different degrees. D810 provides limited gains, increasing accuracy by 4.2 percentage points and F1-score by 5.7 percentage points, while ChatDEOB improves accuracy by 17.6 percentage points and F1-score by 20.4 percentage points. The B IN M IRROR-enhanced pipeline achieves the best result, with 91.5% accuracy and 91.2% F1-score, improving over direct binary analysis by 33.3 and 37.1, respectively. The improvement comes from behavior-consistent artifacts. D810 often produces limited gains because static pattern matching struggles with combinatorial obfuscation and may leave fragmented control-flow artifacts. ChatDEOB can recover some high-level structure, but under heavy obfuscation, it may generate logic that is inconsistent with observed execution behavior, which can mislead the downstream detector. In contrast, B IN M IRROR uses runtime behavior constraints during reconstruction, reducing the impact of injected structural noise and producing normalized executable artifacts that better preserve behaviorally relevant control-flow patterns.

7. Discussion 7.1. Sensitivity and Convergence of the ClosedLoop Iteration (Nmax ) An important hyperparameter in the B IN M IRROR pipeline is the maximum number of iterations (Nmax ) during the test-based behavioral validation stage. This parameter controls how many times the LLM can refine the candidate source code based on differential behavior feedback (∆dif f ). To evaluate the trade-off between test-based recovery effectiveness and computational overhead, we conducted a sensitivity analysis on Nmax using the Synthetic Benchmark under the L6 obfuscation configuration. Table 8 reports the Unit Test Pass Rate (Pass@1), the cumulative

Primary Failure Mode Minor Syntax Errors Variable Type Mismatch Logic Inversion Missing Dependencies Context Truncation

time overhead per slice, and the incremental improvement at each iteration step. Optimal Iteration Threshold. Relying solely on synthesis without refinement (Nmax = 1) yields a Pass@1 of 60.5%. In the second iteration, the success rate increases by 7.3%, indicating that differential feedback helps resolve syntactic errors and local behavioral deviations. As iterations continue, however, the success rate plateaus at 74.5% after Nmax = 5, while the average time overhead continues to grow and reaches 55.2 seconds at Nmax = 10. These results indicate diminishing returns in later iterations. Therefore, we set Nmax = 5 as the default threshold to balance test-based recovery effectiveness and computational efficiency. Analysis of Unresolved Cases. We further analyzed the samples that remained unsuccessful after the 5th iteration and identified two main limiting factors. First, Incomplete Behavior-Relevant Slices: If the initial backward data-flow slice (Lext ) misses implicit dependencies, for example, due to pointer aliasing beyond the monitored memory boundary, the LLM may not infer the missing logic regardless of the provided refinement prompts. Second, Context Window Exceedance: For particularly large slices, repeatedly appending behavioral discrepancy logs (∆dif f ) can exceed the LLM’s effective context capacity. This causes the model to lose track of earlier constraints, sometimes resulting in oscillation between incorrect candidate programs across iterations. Implications for LLM-based Synthesis. These findings highlight the practical role of LLMs in our setting: they are more effective as constraint-guided generators than as standalone deobfuscation solvers. The feedback mechanism provides useful test-based signals, but it still relies on the completeness of the behavior-relevant slice extracted in Phase II and the coverage of observed executions captured in Phase I. Consequently, future work should focus on improving dynamic taint tracking, pointer-alias modeling, and memory-constraint capture, rather than simply increasing the LLM iteration limit.

7.2. Impact of Instruction Slice Length and Context Boundaries To evaluate the boundary of the LLM’s semantic comprehension, we analyzed the synthesis success rate, measured by Pass@1, across different slice-length (|Lext |) intervals using the Synthetic Benchmark under the L6 configuration. Table 9 presents the distribution of slice lengths, the corresponding success rates, and the primary failure modes observed during synthesis. It is worth noting that the 150-LOC threshold in dataset construction refers to the original source-level programs/functions, whereas |Lext | measures the behavior-relevant instruction slice extracted for a specific observed behavior after Phase II. Therefore, a nontrivial source program can still yield a relatively short slice when only a small portion of the program contributes to a monitored interaction. Specifically, B IN M IRROR maintains high Pass@1 values of 92.4% and 85.1% for short-to-medium slices (≤ 100 instructions), which constitute 60% of the dataset. For these lengths, failures primarily involve minor syntactic issues or variable type mismatches that can often be corrected by closed-loop refinement. However, as the slice length exceeds 250 instructions, the success rate drops to 45.2%, and further declines to 21.6% for slices longer than 500 instructions. The empirical results indicate that the model’s ability to maintain low-level data-flow context degrades when processing long, dense assembly sequences. Unlike high-level source code, assembly instructions lack explicit structural boundaries and exhibit tightly coupled register and memory dependencies. As a result, the LLM may omit dependencies, truncate output, or generate inconsistent control/data-flow structures over extended sequences. To process slices exceeding 500 instructions, future extensions of B IN M IRROR should investigate hierarchical chunking strategies. For example, recursively partitioning large dependency graphs into smaller behavior-preserving sub-tasks before LLM inference may help the system maintain higher translation quality for large computational functions.

7.3. Threats to Validity 7.3.1. Internal Validity. Emulation, Instrumentation, and Slicing Accuracy. Our validation relies on execution states captured through CPU emulation and dynamic binary instrumentation. Bugs in QEMU/DBI, missed implicit effects, or architecture-specific memory operations may make the captured state incomplete and cause false positives. Similarly, trace-driven backward slicing may miss behaviorrelevant semantics when syscall memory boundaries, pointer aliases, or dynamic address mappings are imprecise. We mitigate these risks by validating syscall IDs, arguments, and memory payloads at monitored interaction points, conservatively over-approximating memory boundaries according to architecture-specific ABIs [67], and using dynamic address mapping for runtime pointer references. Nevertheless, our validation remains bounded by captured executions and does not prove all-input semantic equivalence.

LLM Non-Determinism. Semantic lifting may be affected by LLM non-determinism, prompt sensitivity, backend updates, and refinement trajectories. We reduce this effect by using fixed prompt templates, low-temperature decoding, bounded feedback budgets, and five independent runs with mean±SD reporting. Held-out inputs are never exposed to prompts, repair messages, or refinement feedback. Sparse Observable Behavior. B IN M IRROR is effective when inputs trigger observable interaction boundaries and behavior-relevant state transitions. CPU-local or dormant computations that do not affect monitored registers, memory regions, return values, or syscall/I/O behavior may provide weak specifications and limit reconstruction. Our pathcoverage reporting makes this scope explicit, but uncovered behavior remains outside the observation-bounded oracle. 7.3.2. External Validity. Architectural and OS Scope. Our implementation targets Linux binaries and evaluates four architectures: x86, x64, ARM, and MIPS. Generalizing B IN M IRROR to Windows, macOS, or bare-metal firmware requires additional engineering because observable interaction boundaries may differ from POSIX syscalls. For example, Windows binaries may require instrumentation at Native API or user-mode library boundaries rather than direct syscall interfaces. Thus, while the behavior-specificationguided synthesis paradigm is not inherently POSIX-specific, the current implementation is Linux-oriented. Benchmark Selection and Contamination. The Synthetic Benchmark is derived from CodeNet, a public dataset that may overlap with LLM pretraining data. We therefore treat benchmark contamination as a validity threat and do not claim complete decontamination. We mitigate this risk by removing duplicate source hashes, assigning train/evaluation partitions at the problem level before architecture and obfuscation expansion, withholding ground-truth source code and held-out tests from prompts and feedback, and evaluating correctness through compiled held-out executions rather than textual similarity alone. The retained programs are also selected for executability, test availability, and obfuscatability, so they should be interpreted as a controlled benchmark rather than a representative sample of all CodeNet programs.

8. Conclusion In this paper, we presented B IN M IRROR, a behaviorspecification-guided synthesis approach for binary deobfuscation. B IN M IRROR uses dynamic execution traces and interaction snapshots to constrain source-level reconstruction. This design helps mitigate semantic loss introduced by compilation and decompilation, and enables the recovered code to be validated against observed runtime behavior. Our evaluation shows that B IN M IRROR improves robustness under heavy obfuscation, produces more analyzable reconstructions, and provides useful executable artifacts for downstream malware analysis. These results suggest that behavior-constrained synthesis offers a practical direction for binary deobfuscation, especially when static structure and decompiler output are unreliable.

References [1]

[2]

B. Mariano, Z. Wang, S. Pailoor, C. Collberg, and I. Dillig, “Controlflow deobfuscation using trace-informed compositional program synthesis,” Proceedings of the ACM on Programming Languages, vol. 8, no. OOPSLA2, pp. 2211–2241, 2024. C. Barría, D. Cordero, C. Cubillos, and R. Osses, “Obfuscation procedure based in dead code insertion into crypter,” in 2016 6th International Conference on Computers Communications and Control (ICCCC). New York, NY, USA: IEEE, 2016, pp. 23–29.

[3]

J.-T. Chan and W. Yang, “Advanced obfuscation techniques for java bytecode,” Journal of systems and software, vol. 71, no. 1-2, pp. 1–10, 2004.

[4]

Y. Zhou, A. Main, Y. X. Gu, and H. Johnson, “Information hiding in software with mixed boolean-arithmetic transforms,” in International Workshop on Information Security Applications. Cham: Springer, 2007, pp. 61–75.

[5]

B. Johansson, P. Lantz, and M. Liljenstam, “Lightweight dispatcher constructions for control flow flattening,” in Proceedings of the 7th Software Security, Protection, and Reverse Engineering/Software Security and Protection Workshop. New York, NY, USA: ACM, 2017, pp. 1–12.

[6]

S. Schrittwieser, S. Katzenbeisser, J. Kinder, G. Merzdovnik, and E. Weippl, “Protecting software through obfuscation: Can it keep pace with progress in code analysis?” Acm computing surveys (csur), vol. 49, no. 1, pp. 1–37, 2016.

[7]

P. Junod, J. Rinaldini, J. Wehrli, and J. Michielin, “ObfuscatorLLVM: Software protection for the masses,” in Proceedings of the 1st IEEE/ACM International Workshop on Software Protection (SPRO). New York, NY, USA: IEEE, 2015, pp. 3–9.

[8]

I. You and K. Yim, “Malware obfuscation techniques: A brief survey,” in 2010 International conference on broadband, wireless computing, communication and applications. New York, NY, USA: IEEE, 2010, pp. 297–300.

[9]

S. Bardin, R. David, and J.-Y. Marion, “Deobfuscation of opaque predicates using value analysis,” in Proceedings of the 2017 IEEE International Symposium on Software Reliability Engineering (ISSRE). New York, NY, USA: IEEE, 2017, pp. 1–12.

[10] W. Dong, J. Lin, R. Chang, and R. Wang, “Cadecff: Compileragnostic deobfuscator of control flow flattening,” in Proceedings of the 13th Asia-Pacific Symposium on Internetware. New York, NY, USA: ACM, 2022, pp. 282–291. [11] Y. Li, B. Wen, and H. Zheng, “Generic o-llvm automatic multiarchitecture deobfuscation framework based on symbolic execution,” in Proceedings of the 4th International Conference on Advanced Information Science and System. New York, NY, USA: ACM, 2022, pp. 1–6. [12] B. Choi, H. Jin, D. H. Lee, and W. Choi, “Chatdeob: An effective deobfuscation method based on large language model,” in International Conference on Information Security Applications. Cham: Springer, 2024, pp. 151–163. [13] G. Chen, X. Jin, and Z. Lin, “Jsdeobsbench: Measuring and benchmarking llms for javascript deobfuscation,” in Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security. New York, NY, USA: ACM, 2025, pp. 36–50. [14] A. Tkachenko, D. Suskevic, and B. Adolphi, “Deconstructing obfuscation: A four-dimensional framework for evaluating large language models assembly code deobfuscation capabilities,” arXiv preprint arXiv:2505.19887, vol. 1, no. 1, pp. 1–15, 2025. [15] J. Liu, J. Jing, J. Lin, H. Sun, and B. Zhu, “Llm-das: An llm-powered deobfuscation system for arm binary code,” in International Conference on Information Security and Cryptology. Cham: Springer, 2025, pp. 312–329.

[16] R. David, L. Coniglio, M. Ceccato et al., “Qsynth-a program synthesis based approach for binary code deobfuscation,” in BAR 2020 workshop. Reston, VA, USA: Internet Society, 2020, pp. 1–10. [17] T. Ye, L. Wu, T. Ma, X. Zhang, Y. Du, P. Liu, S. Ji, and W. Wang, “Cp-bcs: Binary code summarization guided by control flow graph and pseudo code,” in Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing. Stroudsburg, PA, USA: Association for Computational Linguistics, 2023, pp. 14 740– 14 752. [18] A. Jain and Z. Jin, “Indistinguishability obfuscation via mathematical proofs of equivalence,” in 2022 IEEE 63rd Annual Symposium on Foundations of Computer Science (FOCS). New York, NY, USA: IEEE, 2022, pp. 1023–1034. [19] R. Tofighi-Shirazi, M. Christofi, P. Elbaz-Vincent, and T.-H. Le, “Dose: Deobfuscation based on semantic equivalence,” in Proceedings of the 8th Software Security, Protection, and Reverse Engineering Workshop. New York, NY, USA: ACM, 2018, pp. 1–12. [20] S. Schrittwieser, S. Katzenbeisser, P. Kieseberg, M. Huber, M. Leithner, M. Mulazzani, and E. Weippl, “Covert computation: Hiding code in code for obfuscation purposes,” in Proceedings of the 8th ACM SIGSAC symposium on Information, computer and communications security. New York, NY, USA: ACM, 2013, pp. 529–534. [21] S. Banescu, C. Collberg, V. Ganesh, Z. Newsham, and A. Pretschner, “Code obfuscation against symbolic execution attacks,” in Proceedings of the 32nd Annual Conference on Computer Security Applications. New York, NY, USA: ACM, 2016, pp. 189–200. [22] E. Baralis, S. Ceri, and S. Paraboschi, “Compile-time and runtime analysis of active behaviors,” IEEE Transactions on knowledge and data engineering, vol. 10, no. 3, pp. 353–370, 2002. [23] G. Klein, K. Elphinstone, G. Heiser, J. Andronick, D. Cock, P. Derrin, D. Elkaduwe, K. Engelhardt, R. Kolanski, M. Norrish et al., “sel4: Formal verification of an os kernel,” in Proceedings of the ACM SIGOPS 22nd symposium on Operating systems principles. New York, NY, USA: ACM, 2009, pp. 207–220. [24] S. Joel, J. Wu, and F. Fard, “A survey on llm-based code generation for low-resource and domain-specific programming languages,” ACM Transactions on Software Engineering and Methodology, vol. 33, no. 1, pp. 1–25, 2024. [25] J. Wang and Y. Chen, “A review on code generation with llms: Application and evaluation,” in 2023 IEEE International Conference on Medical Artificial Intelligence (MedAI). New York, NY, USA: IEEE, 2023, pp. 284–289. [26] C. Patsakis, F. Casino, and N. Lykousas, “Assessing llms in malicious code deobfuscation of real-world malware campaigns,” Expert Systems with Applications, vol. 256, p. 124912, 2024. [27] M. T. Shirazi, “Analysis of obfuscation transformations on binary code,” Ph.D. dissertation, Université Grenoble Alpes, 2019. [28] Hex-Rays, “IDA Pro,” https://hex-rays.com/ida-pro, 2026, accessed: 2026-01-26. [29] joydo, “D810: An IDA Pro plugin which can be used to deobfuscate code at decompilation time,” https://github.com/joydo/d810, 2021, accessed: 2026-03-05. [30] G. Li, M. Yu, D. Fang, G. Li, X. Meng, J. Jiang, and W. Huang, “X-mba: Towards heterogeneous mixed boolean-arithmetic deobfuscation,” in MILCOM 2024-2024 IEEE Military Communications Conference (MILCOM). New York, NY, USA: IEEE, 2024, pp. 1082– 1087. [31] N. Nethercote and J. Seward, “Valgrind: a framework for heavyweight dynamic binary instrumentation,” ACM Sigplan notices, vol. 42, no. 6, pp. 89–100, 2007. [32] T. Blazytko, M. Contag, C. Aschermann, and T. Holz, “Syntia: Synthesizing the semantics of obfuscated code,” in Proceedings of the 26th USENIX Security Symposium. Berkeley, CA, USA: USENIX Association, 2017, pp. 643–659.

[33] G. Menguy, S. Bardin, R. Bonichon, and C. d. S. Lima, “Search-based local black-box deobfuscation: understand, improve and mitigate,” in Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security. New York, NY, USA: ACM, 2021, pp. 2513–2525. [34] D. Beste, G. Menguy, H. Hajipour, M. Fritz, A. E. Cinà, S. Bardin, T. Holz, T. Eisenhofer, and L. Schönherr, “Exploring the potential of llms for code deobfuscation,” in International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment. Cham: Springer, 2025, pp. 267–286. [35] S. Mohseni, S. Mohammadi, D. Tilwani, Y. Saxena, G. K. Ndawula, S. Vema, E. Raff, and M. Gaur, “Can llms obfuscate code? a systematic analysis of large language models into assembly code obfuscation,” in Proceedings of the AAAI Conference on Artificial Intelligence, vol. 39. Washington, DC, USA: AAAI Press, 2025, pp. 24 893–24 901. [36] M. Zalewski, “American fuzzy lop,” http://lcamtuf.coredump.cx/afl/, 2014, standard baseline for coverage-guided fuzzing. [37] A. Fioraldi, D. C. D’Elia, and E. Coppa, “AFL++: Combining incremental steps of fuzzing research,” in Proceedings of the 14th USENIX Workshop on Offensive Technologies (WOOT). Berkeley, CA, USA: USENIX Association, 2020, pp. 1–10, the advanced standard for modern fuzzing. [38] M. Böhme, V.-T. Pham, and A. Roychoudhury, “Coverage-based greybox fuzzing as markov chain,” in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, 2016, pp. 1032–1043. [39] S. Rawat, V. Jain, A. Kumar, L. Cojocar, C. Giuffrida, and H. Bos, “Vuzzer: Application-aware evolutionary fuzzing,” in 2017 Network and Distributed System Security (NDSS) Symposium:[Proceedings]. Internet Society, 2017, pp. 1–14. [40] M. D. Ernst, J. H. Perkins, P. J. Guo, S. McCamant, C. Pacheco, M. S. Tschantz, and C. Xiao, “The daikon system for dynamic detection of likely invariants,” Science of computer programming, vol. 69, no. 1-3, pp. 35–45, 2007. [41] Z. D. Sisco, J. Balkind, T. Sherwood, and B. Hardekopf, “Loop rerolling for hardware decompilation,” Proceedings of the ACM on Programming Languages, vol. 7, no. PLDI, pp. 420–442, 2023. [42] C. Nandi, M. Willsey, A. Anderson, J. R. Wilcox, E. Darulova, D. Grossman, and Z. Tatlock, “Synthesizing structured cad models with equality saturation and inverse transformations,” in Proceedings of the 41st ACM SIGPLAN Conference on Programming Language Design and Implementation, 2020, pp. 31–44. [43] J. Xiao, P. Jiang, Z. Zhao, R. Huang, J. Liu, and D. Li, “Robust, efficient, and widely available greybox fuzzing for {COTS} binaries with system call pattern feedback,” in 34th USENIX Security Symposium (USENIX Security 25). Berkeley, CA, USA: USENIX Association, 2025, pp. 6239–6258. [44] K. Z. Snow, F. Monrose, L. Davi, A. Dmitrienko, C. Liebchen, and A.-R. Sadeghi, “Just-in-time code reuse: On the effectiveness of fine-grained address space layout randomization,” in 2013 IEEE symposium on security and privacy. New York, NY, USA: IEEE, 2013, pp. 574–588. [45] M. Payer, “Too much pie is bad for performance,” Technical report, vol. 766, no. 1, pp. 1–20, 2012. [46] N. F. Liu, K. Lin, J. Hewitt, A. Paranjape, M. Bevilacqua, F. Petroni, and P. Liang, “Lost in the middle: How language models use long contexts,” Transactions of the Association for Computational Linguistics, vol. 12, pp. 157–173, 2024. [47] V. Rawte, A. Sheth, and A. Das, “A survey of hallucination in large foundation models,” arXiv preprint arXiv:2309.05922, vol. 1, no. 1, pp. 1–10, 2023. [48] A. Q. Nguyen and H. V. Dang, “Unicorn Engine: The ultimate cpu emulator framework,” https://www.unicorn-engine.org/, 2015, accessed: 2026-03-17.

[49] R. Puri, D. S. Kung, G. Janssen, W. Zhang, G. Domeniconi, V. Zolotov, J. Dolby, J. Chen, M. Choudhury, L. Decker et al., “Codenet: A large-scale ai for code dataset for learning a diversity of coding tasks,” arXiv preprint arXiv:2105.12655, vol. 1, no. 1, pp. 1–10, 2021. [50] Y. Yao et al., “Hikari: LLVM based obfuscator,” https://github.com/ HikariObfuscator/Hikari, 2017, accessed: 2026-03-05. [51] C. Collberg, “The Tigress C Obfuscator,” 2023, university of Arizona. Accessed: 2026-03-05. [Online]. Available: https://tigress.wtf [52] weak1337, “Alcatraz: A binary obfuscator that works by modifying the binary,” https://github.com/weak1337/Alcatraz, 2022, accessed: 2026-03-05. [53] J. Williams, “VirusShare.com,” https://virusshare.com/, 2026, accessed: 2026-01-27. [54] abuse.ch, “MalwareBazaar Database,” https://bazaar.abuse.ch/, 2026, accessed: 2026-01-27. [55] E. Raff, J. Barker, J. Sylvester, R. Brandon, B. Catanzaro, and C. Nicholas, “Malware detection by eating a whole exe,” stat, vol. 1050, no. 1, pp. 25–35, 2017. [56] National Security Agency, “Ghidra Software Reverse Engineering Framework,” https://ghidra-sre.org/, 2026, accessed: 2026-01-26. [57] I. Skochinsky, “Deobfuscation with Goomba,” Hex-Rays, 2021, accessed: 2026-03-04. [Online]. Available: https://hex-rays.com/ blog/deobfuscation-with-goomba/ [58] Y. Shoshitaishvili, R. Wang, C. Salls, N. Stephens, M. Polino, A. Dutcher, J. Grosen, S. Feng, C. Hauser, C. Kruegel et al., “Sok:(state of) the art of war: Offensive techniques in binary analysis,” in 2016 IEEE Symposium on Security and Privacy (SP). New York, NY, USA: IEEE, 2016, pp. 138–157. [59] J. Achiam, S. Adler, S. Agarwal, L. Ahmad, I. Akkaya, F. L. Aleman, D. Almeida, J. Altenschmidt, S. Altman, S. Anadkat et al., “Gpt-4 technical report,” arXiv preprint arXiv:2303.08774, vol. 1, no. 1, pp. 1–100, 2023. [60] Anthropic, “The Claude 3 Model Family: Opus, Sonnet, Haiku,” 2024, technical Report. Accessed: 2026-03-05. [Online]. Available: https://www.anthropic.com/news/claude-3-family [61] Meta AI, “Introducing Llama 3.1: Our most capable models to date,” Meta, 2024, accessed: 2026-03-05. [Online]. Available: https://ai.meta.com/blog/meta-llama-3-1/ [62] B. Hui, J. Yang, Z. Cui, J. Yang, D. Liu, L. Zhang, T. Liu, J. Zhang, B. Yu, K. Lu et al., “Qwen2. 5-coder technical report,” arXiv preprint arXiv:2409.12186, vol. 1, no. 1, pp. 1–10, 2024. [63] B. Roziere, J. Gehring, F. Gloeckle, S. Sootla, I. Gat, X. E. Tan, Y. Adi, J. Liu, R. Sauvestre, T. Remez et al., “Code llama: Open foundation models for code,” arXiv preprint arXiv:2308.12950, vol. 1, no. 1, pp. 1–10, 2023. [64] D. Guo, Q. Zhu, D. Yang, Z. Xie, K. Dong, W. Zhang, G. Chen, X. Bi, Y. Wu, Y. Li et al., “Deepseek-coder: When the large language model meets programming–the rise of code intelligence,” arXiv preprint arXiv:2401.14196, vol. 1, no. 1, pp. 1–10, 2024. [65] G. Chen, H. Sun, D. Liu, Z. Wang, Q. Wang, B. Yin, L. Liu, and L. Ying, “Recopilot: Reverse engineering copilot in binary analysis,” arXiv preprint arXiv:2505.16366, vol. 1, no. 1, pp. 1–15, 2025. [66] P. Xu, Y. Zhang, C. Eckert, and A. Zarras, “HawkEye: Cross-platform malware detection with representation learning on graphs,” in Artificial Neural Networks and Machine Learning – ICANN 2021, ser. Lecture Notes in Computer Science, vol. 12893. Cham: Springer, 2021, pp. 127–138. [67] M. Matz, J. Hubicka, A. Jaeger, and M. Mitchell, “System v application binary interface,” AMD64 Architecture Processor Supplement, Draft v0, vol. 99, no. 2013, p. 57, 2013.

Appendix A. Synthetic Benchmark Audit Table 10 reports the exclusion reason for each filtered CodeNet program. Each excluded program is assigned one reason according to the first failed filtering stage, making the categories mutually exclusive. The retained 1,573 programs are executable, testable, and obfuscatable, but are not intended to represent the full CodeNet distribution. TABLE 10. S YNTHETIC B ENCHMARK FILTERING REASON CODES . Filtering outcome

# Programs

Fraction

Initial C/C++ programs

341,069

100.00%

Low complexity or short source Compilation or evaluation-pipeline failure Unavailable or flaky tests Unsupported dependencies or external resources Obfuscator failure Timeout-triggered exclusion Duplicate or leakage-control removal Other filtering failures

238,748 51,165 27,285 10,237 5,114 2,386 1,025 3,536

70% 15% 8% 3% 1.5% 0.7% 0.3% 1.04%

1,573

0.46%

Retained source programs

For each retained program, we record the CodeNet problem ID, source hash, language mode, compiler version, compilation flags, test metadata, random seed, and partition ID. The full obfuscation expansion applies four obfuscators, six transformations, four architectures, and four optimization levels, yielding 1,573 × 63 × 4 × 4 = 1,585,584 binaries.

Appendix B. MalBench and Downstream Detection Details MalBench is handled as sensitive security data. We release hashes and audit metadata sufficient to reproduce the selection and evaluation protocol, but do not redistribute live malware binaries. MalBench contains 500 Linux malware samples collected from VirusShare and MalwareBazaar during 2023–2025. A sample is retained only if it is a Linux executable, is flagged by at least 10 VirusTotal engines, and is not an exact duplicate by SHA-256 hash. Corrupted, nonLinux, non-executable, and duplicate samples are removed. For downstream detection, we construct a matched benign corpus of 500 Linux executables from standard Ubuntu repositories. Benign samples are matched by architecture, executable format, and file-size bucket, using the ranges <100KB, 100KB–1MB, 1–5MB, 5–20MB, and >20MB, to reduce trivial corpus differences. We use a family-aware 70/10/20 train/validation/test split with split seed 42, assigning all samples from the same malware family to the same split. Held-out test samples are never used for prompt construction, refinement, detector training, or threshold selection. All malware executions are isolated in Docker/QEMU with restricted network and filesystem policies. Outbound network traffic is disabled or redirected to a sink, the root filesystem is read-only, writable state is confined to a tmpfs workspace, syscall and I/O logging are enabled, and each

execution is bounded by a 30-minute timeout. For RQ5, all pipelines use the same HawkEye-Linux detector configuration, graph-extraction procedure, model architecture, hyperparameters, training seed, validation split, and thresholdselection rule. The threshold is selected on the validation split and fixed before test evaluation. We compute 95% confidence intervals with 10,000 bootstrap resamples using bootstrap seed 42.

Appendix C. Baseline Information Budgets To avoid conflating method design with available evidence, we assign each baseline an explicit information budget. Static-only tools receive only the raw binary or toolspecific IR, with no LLM prompt, dynamic trace, behavioral snapshot, repair, or feedback. Decompiler+LLM and LLM+SamePrompt receive only IDA/Ghidra pseudocode under the same prompt format, decoding setting, 16K/4K input-output token budget, and at most one compile-error repair round. LLM+Dyn uses the same prompt but additionally receives the bounded syscall-trace summary and monitored snapshot fields ⟨k, SysID, Rinit , Minit ⟩, with a 32K/4K token budget. LLM+Dyn+Fb further receives up to Nmax = 5 compile/test feedback rounds generated only from the refinement split. In contrast, B IN M IRROR receives behaviorrelevant slices, monitored snapshots, behavior-specificationguided constraints, and up to Nmax = 5 refinement rounds. All LLM-based variants use temperature = 0.2 and topp = 1.0. Dynamic evidence, when enabled, is shared in the same serialized format across controlled variants and B IN M IRROR. Feedback rounds are generated only from refinement inputs; held-out inputs are never used for prompt construction, repair, feedback generation, or iterative refinement. Thus, LLM+Dyn and LLM+Dyn+Fb test whether the gains in Table 2 can be explained by stronger runtime evidence or feedback alone, while B IN M IRROR additionally tests the effect of trace-driven slicing and behaviorspecification-guided constraint construction.

Appendix D. Implementation Details D.1. Execution Environment and Baseline Settings All experiments were conducted on a workstation equipped with dual Intel Xeon Gold 6248R processors, 512GB of RAM, and four NVIDIA RTX 4090 GPUs, running Ubuntu 22.04 LTS. Malware execution was isolated using Docker and QEMU. For traditional static deobfuscators, we directly exported their generated pseudocode or recovered IR for evaluation. For dynamic deobfuscators, ANGR [58] used a Depth-First Search SimulationManager with a 30-minute timeout, while Syntia [32] used Monte Carlo Tree Search with 50,000 iterations and 100 input-output samples. For LLM-based baselines, we provided IDA-generated pseudocode with fixed system prompts to standardize the semantic lifting task.

TABLE 11. P ROMPT TEMPLATE USED BY B IN M IRROR . Prompt Part

Template Content

System prompt

You are an expert reverse engineer and systems programmer. Your task is to synthesize readable, compilable C code that is consistent with the provided behavior-relevant binary slice and monitored runtime observations. Do not invent behavior that is not supported by the given slice, register/memory state, syscall boundary, or I/O constraints. Prefer simple and portable C constructs.

Input context

Target: Reconstruct the behavior of the following binary slice as C code. Architecture/ABI: <ARCH_ABI> Required function signature: <FUNC_SIGNATURE> Behavior-relevant instruction sequence Lext : <SLICE_INSTRUCTIONS> Initial runtime state Spre : Registers Rinit : <REGISTER_STATE> Memory Minit : <MEMORY_STATE> Target interaction boundary Spost : Syscall identifier: <SYSID> Syscall arguments / target buffers: <SYSCALL_ARGS_AND_BUFFERS> Expected target memory or I/O effect: <EXPECTED_EFFECT> Compilation constraints: <COMPILATION_CONSTRAINTS>

Instruction body

Perform the following reasoning internally before writing the code. 1. Infer the observed state-transfer relation ΦIO : Spre → Spost from the slice and runtime observations. 2. Abstract low-level register, memory, pointer, arithmetic, and branch operations into high-level C constructs. 3. Construct a self-contained C implementation of <FUNC_SIGNATURE> that preserves the observed behavior at the target interaction boundary. The generated code should compile under <COMPILER_AND_FLAGS> and should not rely on undefined behavior, undeclared external state, or unavailable libraries unless explicitly listed in the constraints.

Output constraint

Output only the candidate C source code for <FUNC_SIGNATURE>. Do not include explanations, markdown fences, comments about the task, confidence scores, or intermediate reasoning. If a helper function is necessary, include it in the same output.

TABLE 12. E VALUATION SCALE AND RESOURCE SUMMARY. Item Unique source programs Expanded synthetic binaries RQ1 evaluated subset RQ2 architecture/optimization sweep MalBench samples Completed non-timeout runs Timeout runs Unsupported runs Median runtime/sample Median LLM calls/sample Total compute

Value 1,573 1,585,584 x64-O0, 100,672 binaries (incl. L0) 1,585,584 binaries 500 94.2% 3.9% 1.9% 8.5 min [4.2,17.6] 3 [2,5] 72K CPU-h / 1.2B LLM tokens

information, seeds, prompt-template hashes, serialized evidence files, and request logs are recorded in the artifact. Held-out inputs are never included in prompts, repair messages, feedback, truncation decisions, or refinement traces. When the context exceeds the input budget, we preserve function signatures, call sites, monitored snapshot fields, and the most recent behavior-relevant trace window, and truncate non-executed decompiler text first. Table 11 shows the fixed prompt template used by B IN M IRROR. Baseline and controlled variants use the same output format and decoding constraints.

D.3. Evaluation Scale and Resource Usage D.2. LLM Protocol and Prompt Template All LLM-based baselines, controlled variants, and B IN M IRROR use fixed prompt templates, temperature = 0.2, top-p = 1.0, and a 4K output-token cap. Pseudocode-only variants use a 16K/4K input-output budget, while evidenceaugmented variants and B IN M IRROR use a 32K/4K budget to accommodate trace and snapshot summaries. Decompiler+LLM and LLM+SamePrompt allow at most one compile-error repair round; LLM+Dyn+Fb and B IN M IRROR allow up to Nmax = 5 refinement rounds using only refinement-split discrepancies. The evaluated models include GPT-4o-2024-08-06, Claude-3.5-Sonnet20241022, Llama-3.1-70B-Instruct, Qwen2.5-Coder-32BInstruct, CodeLlama-34B-Instruct, and DeepSeek-Coder33B-Instruct. Closed models are queried through their official APIs, and open models are evaluated from fixed local checkpoints. Exact model identifiers, provider or checkpoint

Table 12 summarizes the evaluation scale and resource usage. The 1,585,584 synthetic binaries denote the full obfuscated benchmark expansion, rather than the denominator of every experiment: RQ1 evaluates the x64-O0 subset including L0, RQ2 evaluates the architecture/optimization sweep, and MalBench uses 500 malware samples under family-aware splits. All reported rates are computed over the corresponding evaluated denominator, where completed non-timeout runs include both pass and fail validation outcomes, and timeout or unsupported runs are not silently removed. Runtime is reported as median [IQR] per evaluated sample, and LLM calls are counted over synthesis-invoking runs. CPU time includes dataset construction, binary execution, baseline execution, slicing, synthesis orchestration, and validation. LLM tokens include both prompt and generated tokens across LLM-based baselines, controlled variants, and B IN M IRROR.

Related documents

• Behavior Specification-Guided Program Synthesis for Binary Deobfuscation#659190
• Behavior Specification-Guided Program Synthesis for Binary Deobfuscation#657054
• A COMPUTER ARCHITECTURE FOR EXPRESSIVE SECURITY#371223
• Buzz to Boom: Detecting Message Progression Vulnerabilities in Electron Applications via Segmented Directed Fuzzing#394326
• Stepwise refinement of formal specifications based on logical formulae : from CO-OPN/2 specifications to Java programs#445109