An AI-assisted framework recovered C candidates that matched the original functions on every input in a held-out test suite in 79.8% of benchmark cases, while 96.1% of returned candidates recompiled. The system, called Chisel, is designed to work without a supplied test suite: it repeatedly rewrites Ghidra-derived pseudo-C and uses compiler and differential-fuzzer feedback. For evaluation, the returned code was scored against a held-out ground-truth suite.
Those measures capture different hurdles. Re-compilability means the returned code could be built; re-executability means it matched the original on every input in the held-out suite. The paper scored the single returned candidate, so the reported figures reflect the system's chosen output rather than a later selection from several candidates.
A feedback loop around pseudo-C
Chisel's core is a feedback loop around each rewrite. It combines compiler-based static feedback with coverage-guided differential-fuzzer feedback, then adds richer observables, cross-iteration divergence memory and best-candidate retention. Those pieces let the framework carry information about earlier divergences into later iterations while preserving a best candidate.
To examine those pieces, the study used six staged versions of the system. It began with one-shot LLM generation and added compiler and fuzzer checks, richer observables, cross-iteration memory and best-candidate retention in stages. The comparison describes differences among the versions, but does not by itself prove that a single added feature caused a change.
The evaluation started by giving each function a 1,000-pair ground-truth input-output suite. After filtering for functions with at least 200 functional test cases, it retained 120 ExeBench functions. The selected functions were compiled as x86-64 binaries at optimization levels O0 through O3, in both stripped and unstripped forms.
The experiments used Ollama Gemma4:31b at int-4 quantization on an x86-64 Linux host with four NVIDIA H200 GPUs. Each loop allowed up to five rounds, used temperature 0, relied on a 200-sample corpus and allowed 2,000 mined inputs per round, with a two-CPU-second timeout per input. Feedback was capped at five compiler errors and 10 fuzzer divergences.
Where the numbers land
In the full configuration, the average test-suite pass rate was 82.1%. The reported recovery figures were 64.1% after an initial compilation failure, 15.0% after an initial execution failure and 26.2% overall. False acceptance was 9.4%, false rejection was 45.9% and regression was 0.0%; the mean iteration count was 2.06.
The component comparisons showed different patterns. The +compiler arm reported 96.6% re-compilation and recovered 65.6% of samples that initially failed to compile, but recovered none of the samples that compiled initially and then failed to execute. The +fuzzer arm recovered 7.5% of compiled-but-incorrect first generations and reported 79.3% re-executability. After richer observations were added, false acceptance was 9.4%, compared with 17.6% in the +fuzzer arm.
The hard cases
False acceptance reached 16.4% for stripped binaries, compared with 1.7% for unstripped ones. The authors attribute the residual false acceptance in stripped samples mainly to errors in recovering function signatures.
The reported re-executability also varied across optimization levels. In unstripped cases, it fell from 93.3% at O0 to 80.8% at O3. In stripped cases, it fell from 78.3% at O0 to 68.3% at O3.
Against LLM4Decompile-9B-v2, Chisel's re-executability was 79.8% on the same subset, versus 17.0% for LLM4Decompile-9B-v2. The authors also report better re-executability, false acceptance and overhead than Agent4Decompile under the same LLM and test-suite assumptions.
What the benchmark cannot settle
Even the strongest percentages are operational benchmark results, not proof of exact semantic equivalence. The score depended on a held-out input-output suite and the behavior of the single returned candidate, while input-output sampling remains only an approximation of functional similarity. Ghidra pseudo-C was used as the source representation, so the findings do not establish how the approach would behave with other decompiler outputs.
No confidence intervals, p-values or other inferential uncertainty estimates were reported. The results are therefore descriptive comparisons within the tested setting: 120 functions, x86-64 binaries, the specified optimization and stripping variants and Gemma4:31b at the tested settings. Whether the framework holds up on newer binary datasets, other decompiler outputs or different model settings remains open.
The project was 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.
Paper data and sources
Original title: CHISEL-ing Back Source Code with AI-enabled Iterative Recovery
Authors: Varun Kohli, N Raghava, Biplab Sikdar, Dinil Mon Divakaran
Journal/Repository: arXiv
Status: Preprint, not yet peer-reviewed
First online: 2026-08-28
DOI: Not available
Original paper · Full text