A new benchmark suggests frontier coding agents can recover the structure of compiled software more accurately than some of the world’s best-known reverse-engineering tools. The result is significant, but “perfect decompilation” does not mean recovering every line of the original source.

For decades, turning compiled software back into intelligible source code has been the domain of specialized reverse-engineering tools. A new experimental benchmark suggests that large language models may now be better at parts of that job.

“We are approaching perfect binary decompilation,” University of Georgia researcher Zion Leonahenahe Basque wrote in a July 23 post introducing DecBench. “LLMs may soon be the best decompilers on the planet.”

The evidence behind that claim is compelling. On DecBench’s approximately 250-function sample set, OpenAI’s Codex finished first, ahead of Anthropic’s Claude Code and established decompilation systems including Hex-Rays, Ghidra, Binary Ninja and angr.

Codex achieved a perfect result on at least one of DecBench’s three measurements for 53.9 per cent of the functions it evaluated. Claude Code reached 46.9 per cent. The highest-ranked conventional system, angr, scored 28.4 per cent.

That does not mean Codex recovered 53.9 per cent of the original source code perfectly. Understanding the distinction is essential to understanding both the importance and the limitations of the result.

The DecBench results

The benchmark tested OpenAI Codex using GPT-5.6 Sol and Claude Code using Claude Opus 4.8 alongside seven traditional or research decompilers. The table below reproduces the results shown on the sample-set leaderboard.

The denominators differ because not every function could be measured on every dimension. Recompilation, for example, was evaluated only where the benchmark had a matching host recompiler. The DecBench leaderboard reports each percentage together with the underlying number of functions.

What decompilation actually does

Software normally moves in one direction:

Human-written source code → compiler → machine-code binary

A decompiler tries to reverse that process:

Machine-code binary → reconstructed human-readable code

The reverse journey is fundamentally difficult because compilation destroys information. Comments, formatting and meaningful variable names disappear. Precise types may be lost. Compiler optimizations can remove variables, combine operations, inline functions and reorganize control flow until the machine code bears little visual resemblance to what the developer originally wrote.

There is also not necessarily one uniquely recoverable original. Several different source programs can produce the same machine code. Even a function that recompiles into an identical binary may not use the original words, names or organization.

Traditional decompilers analyze instructions, registers, memory access and control flow to generate a high-level representation of what a program does. Their output can be indispensable to a skilled reverse engineer while still looking very different from normal developer-written code.

How Codex and Claude were tested

DecBench did not just hand the models output from another decompiler and ask them to clean it up.

For each target function, the coding agent received an anonymized, stripped binary without meaningful function names or debugging symbols. It was given the function’s entry address, architecture and a short disassembly hint. It could inspect the binary with basic tools including objdump, readelf, nm, strings, xxd and file, but it was prohibited from using a conventional decompiler.

The agent was then asked to reconstruct source-faithful C for that function. Each function received a separate agentic run, and the generated C was evaluated using the same measurements applied to the conventional decompilers. The DecBench methodology also records the agent prompts and tool activity to audit compliance with the no-decompiler rule.

This makes the result more meaningful than a test in which an LLM merely rewrites Ghidra or Hex-Rays output. The coding agents were performing the reverse-engineering task themselves, using disassembly and binary inspection as evidence.

What “perfect” means in DecBench

DecBench evaluates three distinct dimensions of reconstruction.

Structural correctness asks whether the decompiled function has the same pattern of branches, loops and execution paths as the source. The benchmark converts both versions into control-flow graphs and calculates the graph edit distance between them. A distance of zero counts as a perfect structural match.

Type correctness asks whether the decompiler recovered every measurable argument and variable type correctly. The output is compared with ground-truth type information retained from the original debug build.

Recompilation correctness asks whether the reconstructed C can be compiled back into matching machine code. DecBench applies a standardized fix-up process for missing declarations and decompiler-specific pseudo-types, then rebuilds the function using the original compiler settings and compares the resulting assembly after normalizing linker-dependent addresses.

The leaderboard’s “Union” score—the 53.9 per cent figure for Codex—is the percentage of functions on which the system achieved perfection on at least one of those dimensions.

That is a generous definition of “perfect.” Codex can recover a function’s control-flow structure exactly while getting its types and machine-level implementation wrong, and the function will still count toward the Union result. Conversely, code can compile into matching machine instructions without reproducing the original variable names, comments or literal source text.

The most defensible interpretation is therefore not that Codex perfectly recovered more than half of the original source. It is that Codex exactly recovered at least one important property of more than half the sampled functions.

Even under that narrower interpretation, its performance is remarkable. Codex produced an exact control-flow match for 118 of 239 measurable functions, compared with 61 for Hex-Rays and 49 for Ghidra. It generated C that recompiled into matching machine code for 31 of 154 measurable functions, compared with five for Hex-Rays and four for Ghidra.

Why an LLM may outperform a specialized decompiler

Conventional decompilers are built around deterministic program analysis. They translate instructions into intermediate representations, track data through registers and memory, reconstruct control-flow graphs and infer higher-level structures.

A frontier coding model can combine that evidence with learned knowledge of how programmers usually express common operations. Faced with a complicated sequence of assembly instructions, it may recognize the larger pattern as a bounds-checking loop, string operation, parser, state machine or familiar library idiom.

In other words, a traditional decompiler is exceptionally good at analyzing what the processor does. An LLM may also infer what kind of source code a human was likely trying to write.

That explanation remains an inference, not something DecBench directly proves. It is nevertheless consistent with previous research showing that LLM-generated decompilations can be easier for humans to understand. A separate 2025 benchmark based on 23,400 functions from 130 real-world programs found that LLM approaches surpassed conventional tools in understandability while remaining substantially worse in functional correctness. The peer-reviewed DecompileBench study reported a 52.2 per cent functionality deficit for the LLM-based methods it evaluated.

The new DecBench result suggests that frontier coding agents may be beginning to close that gap, although the two benchmarks use different systems, datasets and measurements and cannot be compared directly.

Why this matters beyond a leaderboard

More capable decompilation could change several areas of software and cybersecurity.

Malware analysts could move more quickly from suspicious binaries to intelligible descriptions of malicious behaviour. Security researchers could identify vulnerable logic in software for which they do not possess the source. Organizations could recover knowledge from abandoned legacy applications, undocumented firmware or systems whose original developers and code repositories are no longer available.

It also reduces the practical opacity of proprietary software distributed to customers. Compilation has never been a reliable security boundary: skilled reverse engineers have always been able to inspect binaries. LLMs could dramatically reduce the time, cost and specialized expertise required to do it.

That has implications for intellectual property, software licensing and product security. Secrets, credentials and cryptographic keys should never be treated as safe merely because they have been compiled into an application. Obfuscation may raise the cost of analysis, but increasingly capable AI systems could erode some of the protection it provides.

The same capability can serve both defenders and attackers. Faster reverse engineering may accelerate vulnerability discovery and remediation, while also helping adversaries understand proprietary systems, locate weaknesses and adapt malware.

This is not the end of decompilation

DecBench is new, experimental and not yet an independently replicated standard. Its complete corpus contains more than 94,000 functions, but the coding agents were evaluated on only about 250 because one agentic run per function is expensive. An expanded LLM evaluation is planned when the researchers can secure the necessary credits.

The test also evaluates isolated functions rather than the reconstruction of an entire complex application. Each function can consume minutes of agent time, while conventional tools are designed to process large binaries systematically. Training-data familiarity remains another possible confounding factor because the ground truth comes from open-source software, although the benchmark strips symbols and anonymizes binary filenames to make direct recognition more difficult.

Most importantly, some information removed by compilation cannot be recovered with certainty. A model may infer plausible names, intent and source structure, but plausible is not identical to historically authentic.

The benchmark does not demonstrate universal recovery of original source code. It demonstrates something narrower and still consequential: frontier coding agents can already reconstruct important properties of individual compiled functions more successfully than several leading dedicated decompilers on this sample.