CHISEL-ing Back Source Code with AI-enabled Iterative Recovery

arXiv:2608.27981v1 [cs.CR] 28 Aug 2026

Chisel-ing Back Source Code with AI-enabled Iterative Recovery Varun Kohli✉

N Raghava

A*STAR Institute of Advanced Intelligence and Computing Singapore Kohli_Varun@a-star.edu.sg

Coimbatore Institution of Technology Coimbatore, India raghava.research.cs@gmail.com

Biplab Sikdar

Dinil Mon Divakaran

National University of Singapore Singapore bsikdar@nus.edu.sg

A*STAR Institute of Advanced Intelligence and Computing Singapore Dinil_Divakaran@a-star.edu.sg

Abstract

1

Decompilation aims to recover high-level, compilable, and semantically equivalent code from binaries. Traditional decompilers produce pseudo-C that is difficult to read and does not compile, while the recent LLM-assisted approaches generate readable, but semantically incorrect code. LLM-aided iterative recovery is an emerging branch of research, but prior works rely on supplied test suites for semantic recovery. In this work, we present Chisel, a test suite-free framework to iteratively recover source code from Ghidra-derived pseudo-C. Chisel uses simple yet effective feedback from a compiler (static analysis) and a coverage-guided fuzzer (differential analysis), augmented by rich observables for grounded divergence detection and feedback, cross-iteration divergence memory, and best candidate retention. We systematically evaluate Chisel for compilation and semantic recovery, feedback oracle soundness, and iteration overhead on 120 ExeBench functions compiled for the x8664 architecture, across four optimizations (O0-O3), in both stripped and unstripped variants, using the open-weight Gemma4:31b LLM. Chisel, with all recommended features, achieves an average of 96.1% re-compilability and 79.8% re-executability rates at an average of 2.1 iterations. Significantly, Chisel recovers 26% of firstgeneration execution errors. At the same time, Chisel’s feedback oracle falsely accepts only 9.4% candidates. Lastly, Chisel performs significantly better than two recent prior work on LLM-assisted decompilation.

Decompilation, i.e., the recovery of high-level language from compiled code, is valuable for reverse engineering, malware analysis, vulnerability detection and mitigation, analyzing patches and auditing legacy and firmware binaries for which no source is available [5, 17]. The recovery of readable, compilable, and semantically faithful source from machine code is a challenging task, and there has been significant effort in developing faithful decompilers that let an analyst read, recompile, patch, and re-deploy a binary for which no source is available. Traditional decompilers such as Ghidra [1] and IDA Pro [11] reconstruct control flow and data types using hand-built heuristics, which is difficult to read, rarely compilable, and does not guarantee semantic fidelity. The resultant pseudo C is typically obscured by synthetic types, machine-level artifacts and Application Binary Interface (ABI)-level scaffolding. This has led to the development of AI and LLM-based approaches to translate assembly or decompiler output into readable and compilable source code [6, 10, 12, 16, 18], which can be broadly classified into two categories: Non-iterative decompilers use finetuned LLMs to recover source code, relying solely on the LLM’s intrinsic capability to generate top-1 or top-k candidates without providing feedback for improvement after failed generations [4, 8, 13, 18]. Iterative decompilers address these limitations‘ by using feedback derived from in-loop oracles to guide the LLM towards better generation [7, 12, 19, 20]. However, several methods rely on native test suites to identify semantic divergence that is then passed to the LLM as feedback [7, 19]. This cannot be assumed when reversing binaries derived from unknown source code, and is the biggest limitation of prior work. These works also use a sanitizer to fix memory corruption errors which is not faithful when done asymmetrically only to the candidate, since the original source may also showcase such properties. Some works use symbolic execution as part of a finetuning pipeline or for multi-role generation, but consequently suffer from path explosion, making it challenging to generalize across control-flow types [12, 21, 22]. Further, in-loop feedback coverage is typically limited to compiler errors and return value divergence [19, 20]. To address the above limitations, we develop and present Chisel1 , a test suite-free iterative enhancement decompiler. We make the following contributions: (1) A lightweight and test-suite-free iterative decompilation framework whose in-loop signals are derived only from the original binary using a compiler and coverage-guided fuzzer,

CCS Concepts • Security and privacy → Software reverse engineering. ACM Reference Format: Varun Kohli, N Raghava, Biplab Sikdar, and Dinil Mon Divakaran. 2026. Chisel-ing Back Source Code with AI-enabled Iterative Recovery. In Proceedings of Software Understanding and Reverse Engineering (SURE ’26). ACM, New York, NY, USA, 7 pages. https://doi.org/XXXXXXX.XXXXXXX

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. SURE ’26, The Hague, The Netherlands © 2026 Copyright held by the owner/author(s). Publication rights licensed to ACM. https://doi.org/XXXXXXX.XXXXXXX

Introduction

1 Controlled Heuristics for Iterative Semantic Extraction and Lifting

SURE ’26, November 15–19, 2026, The Hague, The Netherlands

Varun Kohli, N Raghava, Biplab Sikdar, and Dinil Mon Divakaran

Table 1: A comparison of LLM-assisted decompilation methods related to Chisel.

Method

Iterative test suite-free

LLM4Decompile [18] Nova [13] Idioms [8] DeGPT [12] DecLLM [19] PCodeTrans [7] Agent4Decompile [20] Chisel (ours)

✗ ✗ ✗ ✗ ✓ ✓ ✓ ✓

✓ ✓ ✓ ✓ ✗ ✗ ✗ ✓

In-loop Oracle Soundness Signature Type Rich Divergence Best Candidate Compiler Sanitizer Fuzzer Evaluation Extraction Observables Memory Retention ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✓ ✓ ✗ ✗ ✗ ✓ ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓

aided by rich observables for grounded differential analysis, cross-iteration divergence memory, and best-candidate retention. Our code is available on GitHub2 . (2) A systematic six-arm ablation of Chisel’s iteration harness, building up from single-shot LLM generation to our end-toend design, highlighting the incremental impact of each components across three axes of evaluation, namely recovery of source, which covers Re-compilability (RC), Re-executability (RE), regression, and three new recovery metrics that we define in Section 4 to evaluate the effectiveness of an iterative decompiler; soundness of the feedback oracle, which covers the oracle’s False-acceptance (FA) and False-rejection (FR) rates judged against the ground-truth test suite; and overhead, which includes the average number of iterations. (3) A systematic evaluation on 120 ExeBench functions [3] across four optimization levels (O0-O3), with both stripped and unstripped x86-64 binaries, using an off-the-shelf, openweight Gemma4:31b model in all experiments, that reports 96.1% RC, 79.8% RE, 9.4% FA, and 26.2% recovery after firstgeneration failure. We also report better performance than LLM4Decompile [18] and Agent4Decompile [20].

2

Related Work

Table 1 compares related works over methodologies and design. The first family of LLM-assisted decompilers produces candidate source code without behavioral feedback to improve generation. LLM4Decompile [18] and Nova [13] fine-tune LLMs to translate assembly or Ghidra pseudo-C into compilable and re-executable C, and Idioms [8] jointly recovers code and its user-defined types from decompiler output. These methods do not utilize feedback derived from the generated code or differential analysis to improve the quality of generation, relying only on the LLMs inherent capability to recover good-quality source code. DeGPT [12] improves readability with a multi-role pipeline and a static symbolic check that refuses edits that change the function. Iterative decompilation methods overcome the limitations of noniterative approaches through feedback loops. DecLLM [19] repairs compiler errors, identifies semantic divergence using coverageguided AFL++ [9] seeded by a supplied ground-truth test suite, and employs a sanitizer on the generated candidate to fix memory misuse. PCodeTrans [7] validates hot-swapped function using the 2 https://github.com/VarunKohli18/chisel

program’s official test suite, then localizes failures with breakpointmatched differential tracing that compares control flow and variable values against the original. Both works use compilers and sanitizers, while DecLLM also uses a fuzzer for divergence feedback. However, the use of a sanitizer to asymetrically fix the generated code (while not the origin) is unfaithful decompilation. Agent4Decompile [20] proposes a three-tier hierarchical agentic approach covering syntax, compilation, and execution checks that assume the availability of supplied test cases, showcasing the first agentic approach to pseudocode enhancement. The main limitation of the above methods is the reliance on a test suite for in-loop feedback, which may not be possible to access when reversing binaries whose source is unknown. Additionally, with the exception of PCodeTrans [7], prior works typically have limited coverage of observable behaviors for differential analysis, and show limited capability. In contrast, Chisel is an iterative enhancement framework that improves the output of traditional decompilers without supplied test suites. It uses in-loop signals derived solely from the original binary, performing static analysis using a compiler for compilation failures and differential analysis through type-aware coverage-guided fuzzing over a rich observable space that includes return values, output buffer contents, stdout, exit codes, timeouts, and crash signals. Chisel also integrates crossiteration divergence memory and best candidate retention if the feedback oracle doesn’t accept any candidate after the last iteration.

3

Proposed Framework: Chisel

This section presents the design components of Chisel, including the iterative enhancement algorithm, constituent oracles, features, prompts and parameter selection.

3.1

Iterative Enhancement Algorithm

Chisel’s novelty lies in its test-suite-free iterative refinement through compiler and type-aware differential fuzzer feedback, augmented by features for broader observability, divergence memory, and best candidate retention. Fig. 1 provides an overview of Chisel and its iterative procedure is depicted by Algorithm 1. The algorithm takes Ghidra pseudo-C (𝑃) of a single function, the original reference object (𝑜) that needs to be decompiled, iteration budget (𝐾), feedback oracles (O), feedback budgets (𝑑𝑐 , 𝑑 𝑓 ), and features (F ). The algorithm returns one compilable C function func0. The subsequent text explains the algorithm assuming all components are active.

Chisel-ing Back Source Code with AI-enabled Iterative Recovery

SURE ’26, November 15–19, 2026, The Hague, The Netherlands

START!

x86-64 Binary

Task Instructions

Ghidra 1 Prompt

LLM

Divergence summary Feedback

2

Failure Candidate C

Success

Budget exhausted

Best Candidate Retention

Best available C

7 8 9

Divergence

Sampling

prev ← 𝑐; 𝑓𝑏 ← ∅; accept ← true; if O.compiler and ¬ Compile(𝑐) then 𝑓𝑏 ← Diagnostics(𝑐); continue;

6

3

Compiler 4

Cross-iteration Divergence Memory

Divergence

Algorithm 1: Chisel’s iterative enhancement loop. Input: pseudo-C 𝑃, reference object 𝑜, round budget 𝐾, feedback budgets 𝑑𝑐 , 𝑑 𝑓 , oracles O, features F Output: a C function func0 1 prev, 𝑓𝑏 , 𝑀, C ← ∅; 2 for 𝑘 ← 1 to 𝐾 do 3 𝑐 ← LLM(𝑃, prev, 𝑓𝑏 ); 4 if O = ∅ then 5 return 𝑐 ; // Single-shot generation

Differential Fuzzer and Observables

10

if O.differential then 𝜎 ← ParseSignature(𝑐); if F .observe then 𝑋 ← libFuzzer(𝑐, 𝑜, 𝜎, 𝐵, TypeSeeds(𝜎)); else 𝑋 ← libFuzzer(𝑐, 𝑜, 𝜎, 𝐵, RandomSeeds(𝜎));

11

5

Accepted

12

END!

13

Recovered C

Cache candidate and outcome

14 15 16

𝐸 ← Diff(𝑐, 𝑜, 𝑋 ∪ 𝑀); if F .memory then 𝑀 ←𝑀 ∪𝐸 ; // Memory accumulation

17 18

Figure 1: Overview of Chisel. The overall sequence of steps is marked with numbers.

19

if 𝐸 ≠ ∅ then 𝑓𝑏 ← Sample(𝐸); accept ← false ;

20 21

Each round samples a single candidate 𝑐 from the LLM at zero temperature, using a self-contained prompt assembled from 𝑃, the previous candidate (prev), and the current feedback (𝑓𝑏 ) derived from oracles (line 2-22): O·compiler is a static feedback oracle that compiles the generated C, parses observed failures, and shares them as 𝑓𝑏 ← Diagnostics(c) (lines 8-9), nudging the LLM towards generating compilable C in the next iteration. If 𝑐 compiles, O.differential searches for inputs that expose divergence of 𝑐 relative to 𝑜 through coverage-guided entropic libFuzzer mining of 𝐵 samples from a type-aware seed corpus (TypeSeeds) derived from the parsed signature (𝜎) for a better starting point than random (lines 11-16). Discriminating inputs are sampled from the accumulated set (E) and passed as feedback 𝑓𝑏 ← Sample(𝐸) (lines 17-21). Only a maximum of 𝑑𝑐 compilation errors and 𝑑 𝑓 fuzzer divergences are passed as feedback and the remaining are appended as a count instead to stay within token budgets. If neither oracle flags an issue, 𝑐 is returned as the recovered source (lines 23-24). Beyond the oracles, Chisel is equipped with three key features to improve recovery of failed generations and oracle soundness. (1) F ·observe (lines 13-17) makes the differential analysis type-aware and extends observation to return values, output buffer contents, stdout, timeouts, exit codes, and crash signals, and compares pointer results by content rather than raw address, providing a richer differential feedback to the LLM for improvement. (2) F .memory (lines 18-19) grows 𝑀 with the deduplicated divergence-inducing inputs across iterations and replays them under the same sampling budget to ensure that the generation maintains performance on prior divergences and converges. Finally, to handle no accepted generation or the regression of code quality

22

24

if accept then return 𝑐 ;

25

C ← C ∪ {𝑐};

23

// Accepted candidate

27

if F .retain_best then return arg min Divergence(C) ; // Best candidate

28

return 𝑐

26

through iterations, (3) F .retain_best (lines 23-24) returns the best-performing candidate from the loop as the recovered source code. Overall, Chisel provides a novel iterative harness that nudges generation towards compilable and functionally similar code.

3.2

Prompts and Parameters

Every round is driven by one self-contained prompt which is depicted in Table 2. It consists of a fixed task instruction that guides the LLM to rewrite the pseudo C as compilable C named func0 that reproduces the original’s behavior exactly, preserving the control flow and the order of operations while dropping decompiler scaffolding that reflects the machine and the ABI rather than the program. The first round shows only this instruction and the pseudo C. Later rounds append 𝑝𝑟𝑒𝑣 and 𝑓𝑏 as per availability. We set 𝐾 = 5, the LLM is set at temperature 0 for reproducibility, and reasoning is turned off. Candidates are compiled at O0 optimization by default for static and differential analysis. Each round tests 𝑐 against 𝑜 on a 200-sample corpus of type-aware seeds and

SURE ’26, November 15–19, 2026, The Hague, The Netherlands

Varun Kohli, N Raghava, Biplab Sikdar, and Dinil Mon Divakaran

Table 2: Prompt components and descriptive samples. Component Task instruction

Content “Below is Ghidra pseudo C for one function. Rewrite it as compilable C named func0 that reproduces the original’s behavior exactly, the same return value and the same writes through its pointer arguments. Keep the computation and control flow as written: preserve the order of operations and do not restructure or simplify loops, reorder side effects, or add or remove returns. But omit the decompiler scaffolding that reflects the machine and the ABI rather than the program, such as stack-protector canary checks, the placeholders the decompiler invents for values it could not recover, and register or stack spill temporaries, and rewrite synthetic types and raw memory addressing as ordinary C. The guiding rule: keep every statement that affects the return value or bytes written through the pointer arguments, and drop every statement that does not. Output only the C source of func0, no prose and no comments, and include every header and type it needs.”

Ghidra pseudo-C Previous generation Compiler feedback

“Ghidra pseudo C: {PSEUDO_C}” E.g.“Previous attempt: {PREVIOUS}” E.g. 1.“Compilation failed: {ERRORS}. Fix it.” E.g. 2.“Compilation timed out. Simplify the control flow and try again.”

Fuzzer feedback

E.g. 1.“On func0(...): outputs agree on the first {COUNT} value(s), then differ at index {INDEX}: original {ORIGINAL_VALUES}.” E.g. 2.“On func0(...): original printed {OUTPUT}, candidate crashed with signal {S}.” E.g. 3.“On func0(...): original printed {OUTPUT}, candidate timed out.” E.g. 4.“On func0(...): original printed {OUTPUT}, candidate printed {OUTPUT’}.”

𝐵 = 2000 libFuzzer-mined inputs, with a per-input timeout of 2 CPU seconds to catch runaway loops. We set 𝑑𝑐 = 5 and 𝑑 𝑓 = 10.

4

Experimental Setup

This sections provides details of the experimental setup including hardware, software, dataset, experiments, evaluation metrics, and baselines compared.

4.1

Hardware, Software, and Dataset

We run all experiments on a x86-64 Linux host with 4 NVIDIA H200 GPUs. We use the Ollama-provisioned Gemma4:31b3 at int-4 quantization for our experiments. The input input and output context limits set to 24,576 and 8,192 tokens respectively. The harness uses Ghidra for lifting assembly to pseudo-C, gcc -c for compiler feedback, and libFuzzer for divergence feedback. We draw the 150 longest real-world functions from ExeBench’s real and val-real splits [3], covering applications including and not limited to, digital signal processing, cryptography, geometry, linear algebra, and data structure. The functions are given a ground truth test suite of 1000 input-output pairs using a generator and further filtered to 120 functions based on the availability of at least 200 functional test cases. The selected functions have 46-265 lines-of-code, and are compiled on x86-64 at O0-O3 optimizations in stripped and unstripped variants. The cached dataset is available on our GitHub.

4.2

Experiments and Evaluation Metrics

We evaluate Chisel through a systematic, six-arm incremental ablation of its harness starting from a one-shot LLM, and adding oracles (compiler, fuzzer) and features (observables, cross-iteration memory, best candidate retention), where each arm retains the prior features and the final arm corresponds to the complete Chisel framework. The ablation enables us to evaluate the value of each component along three key axes, i.e., recovery which measures how much correct source C the loop produces, soundness measures 3 https://ollama.com/library/gemma4:31b

whether the feedback oracle’s accept and reject decisions agree with the test suite, and overhead which measures the cost of the added complexity. All percentage metrics are computed on the single candidate the loop finally returns, scored against the held-out suite, ¯ while overhead is measured in average number of iterations (𝑘). A candidate compiles if it builds, and re-executes if it matches the original on every suite input. The metrics, including our newly defined 𝑅𝑐𝑜𝑚𝑝 , 𝑅𝑒𝑥𝑒𝑐 , 𝑅𝑡𝑜𝑡 , are as follows: • 𝑅𝐶 and 𝑅𝐸: the fractions of returned candidates that compile and that re-execute (pass all test cases), respectively. • 𝑃𝑎𝑠𝑠: the average fraction of test cases passed across samples. • 𝑅𝑐𝑜𝑚𝑝 : of the samples whose first generation did not compile, the fraction whose returned candidate compiles. • 𝑅𝑒𝑥𝑒𝑐 : of the samples whose first generation compiled but did not re-execute, the fraction whose returned candidate re-executes. • 𝑅𝑡𝑜𝑡 : of all samples whose first generation did not re-execute, the fraction whose returned candidate re-executes, i.e. the loop’s overall recovery from first-generation failure. • 𝐹𝐴: of the candidates the oracle accepted, the fraction that stopped on an incorrect candidate. • 𝐹𝑅: of the candidates the oracle did not accept, the fraction that were labeled as correct by the evaluation test suite. • 𝑅𝑒𝑔: of all samples whose first generation already re-executed, the fraction whose returned candidates did not re-execute (regressed). ¯ the mean number of iterations the decompiler runs across • 𝑘: all samples in the dataset. Beyond 𝑅𝐶, 𝑅𝐸, and 𝑃𝑎𝑠𝑠, a good iterative decompiler is also defined by its 𝑅𝑐𝑜𝑚𝑝 , 𝑅𝑒𝑥𝑒𝑐 , 𝑅𝑡𝑜𝑡 , and 𝑅𝑒𝑔. The feedback oracle should (ideally) only accept good-quality candidates and reject incorrect ones. Thus, the design of an oracle should report low 𝐹𝐴 and 𝐹 𝑅. ¯ Over-rejection (high 𝐹𝑅) leads to longer iterative loops and higher 𝑘. However, unless the iteration budget and overhead constraints are tight, this means the oracle is strict, making it a less serious concern since the LLM is then triggered to generate “better” code. However,

Chisel-ing Back Source Code with AI-enabled Iterative Recovery

SURE ’26, November 15–19, 2026, The Hague, The Netherlands

Table 3: Metrics derived from one run of a six-arm ablation, averaged over all variants.

Harness Arm

𝑅𝐶

𝑅𝐸

𝑃𝑎𝑠𝑠

𝑅𝑐𝑜𝑚𝑝

𝑅𝑒𝑥𝑒𝑐

𝑅𝑡𝑜𝑡

𝐹𝐴

𝐹𝑅

𝑅𝑒𝑔

#𝑘¯

Remarks

LLM (one-shot) + compiler + fuzzer + observe + memory + best (full Chisel)

90.0 96.6 96.6 96.7 96.1 96.1

73.0 77.1 79.3 79.9 79.6 79.8

75.1 79.2 81.7 82.0 81.8 82.1

– 65.6 67.3 66.7 64.1 64.1

– 0.0 7.5 13.0 14.4 15.0

– 15.1 23.5 26.0 25.9 26.2

– 20.2 17.6 9.4 9.4 9.4

– 0.0 45.0 45.4 45.1 45.9

– 0.0 0.0 0.3 0.1 0.0

1.00 1.18 1.43 2.05 2.06 2.06

LLM-only, no feedback gcc oracle Differential libFuzzer oracle Type aware and rich observables Divergence memory and replay Best-candidate retention

5

77

79

80

80

80

2.1

2

73

2.1

2.1

1.4

k̄

70

1

1.0

1.2

60 50

0

M ler er ve ll) ry LL pi uzz ser mo (fu e st m +f ob o m c + + +be +

23

20

26

26

26

15

10 0

M ler er ve ll) ry LL pi uzz ser mo (fu e st m +f ob o m c + + +be +

Rexec (%)

30

0

30 20 10 0

15

13

10

0

0

M ler er ve ll) ry LL pi uzz ser mo (fu e st m +f ob o m e c + + +b + 45

18 9

9

9

M ler er ve ll) ry LL pi uzz ser mo (fu f t e m b s + o m co + + +be +

15

8

27 20

14

5 0

M ler er ve ll) ry LL pi uzz ser mo (fu e st m +f ob o m e c + + +b +

Results

We evaluate Chisel’s performance using metrics that capture recovery, soundness, and overhead, shown first as a six-arm ablation of its harness, then performance across optimizations for unstripped and stripped cases, and finally compare against recent work. As Table 3 and Fig 2 show, the raw one-shot model compiles 90.0% and re-executes 73.0% of functions. Adding the compiler oracle lifts re-compilation to 96.6% with 𝑅𝑐𝑜𝑚𝑝 = 65.6%, but is unable to repair semantic behavior after first generation (𝑅𝑒𝑥𝑒𝑐 = 0), since it accepts the first candidate that builds without discriminating over behavioral correctness. The differential fuzzer adds the required behavioral signal to improve 𝑅𝐸 and 𝑅𝑒𝑥𝑒𝑐 , recovers 7.5% of compiled-but-incorrect first generations, raises 𝑅𝐸 to 79.3%, and lowers 𝐹𝐴 from 27% for the LLM arm and 20.2% for the compiler arm, to 17.6%. The decisive soundness gain comes at the observe arm, which halves 𝐹𝐴 from 17.6% to 9.4% at equal 𝑅𝐸 and 𝐹𝑅, highlighting the value of rich observation that in turn leads to rich feedback and recovery. The memory and best-candidate retention arms show an improvement in 𝑅𝑒𝑥𝑒𝑐 and reduction in regression. Samples derived from best-candidate retention report mean suite pass-rate increase from 50.9% to 52% compared to the previous arm. Fig. 3 (left) further highlights the importance of cross-iteration divergence memory. 𝑃𝑎𝑠𝑠 is higher for the +memory arm compared to +observe. Fig. 3 (right) shows the distribution of feedback oracle acceptance per iteration. Based on our inspection of the dataset, Ghidra pseudo C, and the LLM’s generation through Chisel, the residual 9.4% 𝐹𝐴 is dominated by signature recovery errors predominantly in the stripped samples. The differential oracle tests each candidate against its own

80

FR (%)

We evaluate two prior works on our dataset and evaluation harness: i) LLM4Decompile-9B-v2 from [18] and available on HuggingFace [15], and ii) Agent4Decompile [20] (code available at [2]). We replace the LLM in Agent4Decompile with Gemma4:31 for a fair comparison of the harness. Further, to align with our test-suite-free setting , no method has access to the ground truth test suite during iterations. Both methods use Ghidra for binary to pseudo-C lifting, and are run using their specified prompts and input formats. We do not compare with other iterative methods such as DecLLM [19] and PCodeTrans [7] since their code is not public.

RE (%)

Baselines

FA (%)

4.3

90

Rtot (%)

high 𝐹𝐴 implies the system produces low-quality candidates, which is undesirable for any decompiler.

45

45

46

40 20 0

0

0

M ler er ve ll) ry LL pi uzz ser mo (fu f t e m b s + o m co + + +be +

Figure 2: Key metric trends across the six-arm ablation highlighting their value in driving recovery and oracle soundness.

recovered signature, so a candidate that mis-recovers an argument is self-consistent under the oracle yet fails the ground-truth suite that is built on the original signatures. This is visible in the strip split shown in Tables 4 and 5, where 𝐹𝐴 = 16.4% on stripped binaries but only 1.7% on unstripped, as stripping removes the type information needed by the decompiler (Ghidra) to recover the signature, which subsequently passes the error to the signature extractor used in our work (see ParseSignature at line 12 of Algorithm 1). 𝐹𝑅 rises to nearly 45% once a behavioral oracle is integrated into the system, suggesting that the oracle is stricter than the LLM-only and compiler arms. 𝐹𝑅 falls monotonically with optimization regardless of stripped or unstripped symbols. We also observe that our reported 𝐹𝑅 is inflated partly by the limitation of the test suite. The differential oracle outpaces the test suite due to a wider input

SURE ’26, November 15–19, 2026, The Hague, The Netherlands

+observe +memory

80

637

600

# samples

Pass@k (%)

85

75 70 65

Varun Kohli, N Raghava, Biplab Sikdar, and Dinil Mon Divakaran

400 233

200 77

60

0 1

2

3

4

5

1

Iteration (k)

2

7

5

1

3

4

5 none

Comparison with baselines. Table 6 presents the results of Chisel and two SOTA decompilers on the same 120 functions and test suite. The specialized one-shot decompiler, LLM4Decompile [19] (LLM4Decompile-9B-v2), achieves only 17% RE, which is below our LLM-only one-shot Gemma arm that achieves 73.0% and highlights the significance of LLM capabilities for decompilation. We also evaluate Agent4Dedcompile (A4D) [20] in a test-suite free setting. Chisel achieves performs better at a lower iteration cost.

Accepted at iteration

6 Figure 3: Per-iteration evaluation.

Table 4: Chisel’s recovery and soundness on 480 unstripped x86-64 binaries (120 functions), by optimization level. Optimization

𝑅𝐶 (%)

𝑅𝐸 (%)

𝑅𝑒𝑥𝑒𝑐 (%)

𝑅𝑡𝑜𝑡 (%)

𝐹𝐴 (%)

𝐹𝑅 (%)

O0 O1 O2 O3

99.2 97.5 96.7 95.8

93.3 90.0 82.5 80.8

14.3 10.0 28.6 11.1

33.3 42.9 38.2 32.4

0.0 2.1 2.4 2.4

75.8 58.3 45.7 44.7

Average

97.3

86.7

17.9

36.6

1.7

55.4

Table 5: Chisel’s recovery and soundness on 480 stripped x86-64 binaries (120 functions), by optimization level. Optimization

𝑅𝐶 (%)

𝑅𝐸 (%)

𝑅𝑒𝑥𝑒𝑐 (%)

𝑅𝑡𝑜𝑡 (%)

𝐹𝐴 (%)

𝐹𝑅 (%)

O0 O1 O2 O3

97.5 96.7 95.0 90.8

78.3 75.8 69.2 68.3

8.3 13.0 13.3 18.5

18.8 19.4 21.3 19.1

16.3 17.0 17.6 14.8

54.5 40.0 27.6 21.9

Average

95.0

72.9

13.5

19.8

16.4

34.0

Table 6: Comparison with prior work. Method

𝑅𝐶 (%)

𝑅𝐸 (%)

𝑅𝑡𝑜𝑡 (%)

𝐹𝐴 (%)

Iterations

Ghidra pseudo-C LLM4Decompile-9B-v2 [18] Gemma4:31b + compiler + fuzzer A4D-Gemma4:31b [20] Chisel (full)

35.0 63.2 90.0 96.6 96.6 87.3 96.1

28.1 17.0 73.0 77.1 79.3 77.7 79.8

– – – 15.1 23.5 15.7 26.2

– – – 20.2 17.6 11.0 9.4

– – – 1.18 1.43 2.68 2.06

domain (2000 samples per-iteration not considering cross-iteration memory samples). Its coverage includes divergences that were not included in the test suite. Chisel re-executes 86.7% of unstripped and 72.9% of stripped functions on average. Within each variant re-execution falls as optimization rises, as seen in both unstripped and stripped cases where 𝑅𝐸 falls from 93.3% at O0 to 80.8% at O3, and 78.3% at O0 to 68.3% at O3, respectively. Meanwhile recovery rates 𝑅𝑒𝑥𝑒𝑐 and 𝑅𝑡𝑜𝑡 confirm that a growing share of that gap is repaired by the loop.

Limitations, Risks and Ethics

Signature recovery from stripped binaries continues to be a limitation for decompilers. In addition, our experiments were conducted at 0 temperature for determinism and non-reasoning settings reduced overhead. Higher temperatures and LLM reasoning may help improve recovery through more creative and better generation, critical thinking, and response to feedback. Further, we use Ghidra pseudo-C of the original binary as the source of truth and further evaluation into decompiler resilience is required [23]. Additionally, I/O sampling, both as an in-loop oracle and evaluation instrument, is an approximation of functional similarity and does not indicate semantic equivalence. Lastly, while ExeBench is popularly used in decompilation research, future works may consider using newly released datasets, e.g., [14], to avoid the risk of testing LLMs on their training data. On the ethical front, this research was conducted to push the frontier of reverse engineering. However, our work uses openweight models, and our ideas could potentially be adopted by threat actors for unauthorized activities. We urge ethical use of this work.

7

Conclusion

We presented Chisel, a test suite-free iterative decompiler that integrates static and differential analysis using compilers and coverageguided fuzzers for compilation and execution recovery, augmented by rich observables, cross-iteration divergence memory, and bestcandidate recovery. On a 120 function subset of ExeBench functions compiled to four optimizations on x86-64 with stripped and unstripped variants, Chisel showed 96.1% RC and 79.8% RE, and repairs 26.2% of first-generation failures, while halving the in-loop oracle’s FA from 17.6% to 9.4% relative to a return-only differential fuzzer. The decisive gain comes from richer observation rather than from more search. On the same subset Chisel far exceeds the specialized one-shot LLM4Decompile-9B-v2 model (79.8% vs 17.0% RE) and outperforms Agent4Decompile in terms of RE, FA, and overhead using the same LLM and test-suite assumptions. Our results highlight that, in addition to the LLM, the feedback harness is an important lever to improve decompilation performance.

Acknowledgement This research/project is supported by the National Research Foundation, Singapore, and the Cyber Security Agency of Singapore under the National Cybersecurity R&D Programme and the CyberSG R&D Programme Office (Award CRPO-GC2-ASTAR-001). Any opinions, findings, conclusions, or recommendations expressed in these materials are those of the author(s) and do not reflect the views of the National Research Foundation, Singapore, the Cyber Security Agency of Singapore, or the CyberSG R&D Programme Office.

Chisel-ing Back Source Code with AI-enabled Iterative Recovery

References [1] National Security Agency. 2026. ghidra. https://github.com/ NationalSecurityAgency/ghidra [2] Anonymous. 2026. Agent4Decompile Artifacts. https://anonymous.4open.science/ r/agent4decompile-artifacts-0F69/ [3] Jordi Armengol-Estapé, Jackson Woodruff, Alexander Brauckmann, José Wesley de Souza Magalhaes, and Michael FP O’Boyle. 2022. ExeBench: an ML-scale dataset of executable C functions. In Proceedings of the 6th ACM SIGPLAN International Symposium on Machine Programming. 50–59. [4] Jordi Armengol-Estapé, Jackson Woodruff, Chris Cummins, and Michael FP O’Boyle. 2024. Slade: A portable small language model decompiler for optimized assembly. In 2024 IEEE/ACM International Symposium on Code Generation and Optimization (CGO). IEEE, 67–80. [5] Zion Leonahenahe Basque, Ati Priya Bajaj, Wil Gibbs, Jude O’Kain, Derron Miao, Tiffany Bao, Adam Doupé, Yan Shoshitaishvili, and Ruoyu Wang. 2024. Ahoy SAILR! There is No Need to DREAM of C: A Compiler-Aware Structuring Algorithm for Binary Decompilation. In 33rd USENIX Security Symposium (USENIX Security 24). 361–378. [6] Zion Leonahenahe Basque, Samuele Doria, Ananta Soneji, Wil Gibbs, Adam Doupé, Yan Shoshitaishvili, Eleonora Losiouk, Ruoyu Wang, Simone Aonzo, et al. 2026. Decompiling the Synergy: An Empirical Study of Human-LLM Teaming in Software Reverse Engineering. In Proc. NDSS. [7] Yuxin Cui, Zeyu Gao, Shuxian He, Siliang Qin, and Chao Zhang. 2026. PCodeTrans: Translate Decompiled Pseudocode to Compilable and Executable Equivalent. arXiv preprint arXiv:2603.14855 (2026). [8] Luke Dramko, Claire Le Goues, and Edward J Schwartz. 2026. Idioms: A Simple and Effective Framework for Turbo-Charging Local Neural Decompilation with Well-Defined Types.. In NDSS. [9] Andrea Fioraldi, Dominik Maier, Heiko Eißfeldt, and Marc Heuse. 2020. AFL++ : Combining Incremental Steps of Fuzzing Research. In 14th USENIX Workshop on Offensive Technologies (WOOT 20). [10] Zeyu Gao, Yuxin Cui, Hao Wang, Siliang Qin, Yuanda Wang, Zhang Bolun, and Chao Zhang. 2025. DecompileBench: A comprehensive benchmark for evaluating decompilers in real-world scenarios. In Findings of the Association for Computational Linguistics: ACL 2025. 23250–23267. [11] Hex-Rays. 2026. IDA Pro: Power Disassembler, Decompiler & Debugger. https: //hex-rays.com/ida-pro [12] Peiwei Hu, Ruigang Liang, and Kai Chen. 2024. DeGPT: Optimizing Decompiler Output with LLM.. In NDSS. [13] Nan Jiang, Chengxiao Wang, Kevin Liu, Xiangzhe Xu, Lin Tan, Xiangyu Zhang, and Petr Babkin. 2025. Nova: Generative language models for assembly code with hierarchical attention and contrastive learning. In International Conference on Learning Representations, Vol. 2025. 95905–95926. [14] Chang Liu, Noah Fleischmann, Nicolò Altamura, Edward Raff, James Holt, and Kristopher Micinski. 2026. ASSEMBLAGE-DEEPHISTORY: A Cross-Build Binary Dataset with Temporal Coverage. arXiv:2605.21615 [cs.CR] https://arxiv.org/ abs/2605.21615 https://huggingface.co/ [15] LLM4Decompile. [n. d.]. LLM4Decompile-9B-v2. LLM4Binary/llm4decompile-9b-v2 [16] Kuntal Kumar Pal, Ati Priya Bajaj, Pratyay Banerjee, Audrey Dutcher, Mutsumi Nakamura, Zion Leonahenahe Basque, Himanshu Gupta, Saurabh Arjun Sawant, Ujjwala Anantheswaran, Yan Shoshitaishvili, Adam Doupé, Chitta Baral, and Ruoyu Wang. 2024. "Len or index or count, anything but v1": Predicting Variable Names in Decompilation Output with Transfer Learning. In 2024 IEEE Symposium on Security and Privacy (SP). 4069–4087. [17] Yan Shoshitaishvili, Ruoyu Wang, Christopher Salls, Nick Stephens, Mario Polino, Andrew Dutcher, John Grosen, Siji Feng, Christophe Hauser, Christopher Kruegel, and Giovanni Vigna. 2016. SOK: (State of) The Art of War: Offensive Techniques in Binary Analysis. In 2016 IEEE Symposium on Security and Privacy (SP). [18] Hanzhuo Tan, Qi Luo, Jing Li, and Yuqun Zhang. 2024. Llm4decompile: Decompiling binary code with large language models. In Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing. 3473–3487. [19] Wai Kin Wong, Daoyuan Wu, Huaijin Wang, Zongjie Li, Zhibo Liu, Shuai Wang, Qiyi Tang, Sen Nie, and Shi Wu. 2025. Decllm: Llm-augmented recompilable decompilation for enabling programmatic use of decompiled code. Proceedings of the ACM on Software Engineering 2, ISSTA (2025), 1841–1864. [20] Yifan Zhang, Xiaohan Wang, Yueke Zhang, Yu Huang, and Kevin Leach. 2026. Constraint-Guided Multi-Agent Decompilation for Executable Binary Recovery. arXiv preprint arXiv:2604.23940 (2026). [21] Shunfan Zhou, Zhemin Yang, Dan Qiao, Peng Liu, Min Yang, Zhe Wang, and Chenggang Wu. 2022. Ferry: State-Aware Symbolic Execution for Exploring State-Dependent Program Paths. In 31st USENIX Security Symposium (USENIX Security 22). 4365–4382. [22] Muqi Zou, Hongyu Cai, Hongwei Wu, Zion Leonahenahe Basque, Arslan Khan, Berkay Celik, Antonio Bianchi, Dongyan Xu, et al. 2025. D-lift: Improving llmbased decompiler backend via code quality-driven fine-tuning. arXiv preprint arXiv:2506.10125 (2025).

SURE ’26, November 15–19, 2026, The Hague, The Netherlands

[23] Muqi Zou, Arslan Khan, Ruoyu Wu, Han Gao, Antonio Bianchi, and Dave (Jing) Tian. 2024. D-Helix: A Generic Decompiler Testing Framework Using Symbolic Differentiation. In 33rd USENIX Security Symposium (USENIX Security 24). 397– 414.

A

Generative AI Usage

We used generative AI tools, include Claude and Gemini, to (i) improve the language of the manuscript, (ii) generate the plotting code (verified) that renders figures from our experimental outputs, and (iii) writing the code for our prototype. All experiments, datasets, and numerical results were produced by our own pipeline, every figure and table was regenerated directly from the raw experimental outputs and checked against the underlying data. The authors reviewed all AI-assisted code, and take full responsibility for the accuracy, originality, and integrity of this work. Received 30 June 2026; revised 28 August 2026; accepted 28 August 2026

Related documents

• CHISEL-ing Back Source Code with AI-enabled Iterative Recovery#784756
• CHISEL-ing Back Source Code with AI-enabled Iterative Recovery#783166
• Code Summaries as Diagnostic Context for LLM-Based Program Repair#677449
• Code Summaries as Diagnostic Context for LLM-Based Program Repair#674252
• A Memorization Floor for LLM Refinement of Decompiled Code#1123615