AI decompilers: what they recover
and where they stop
An AI decompiler is a tool that uses a large language model to turn machine code, or a classic decompiler’s pseudocode, into readable source-like code. In a 2025 write-up, one developer reported that a model reached a 96% match on its first attempt at a single function, tried in January 2025. A readable, or even matching, result is still not proof that the code behaves like the original.
This guide sorts the tools people call AI decompilers into three kinds. It covers how accurate each kind is, what each one can confirm about its own output, and why obfuscated and VM-protected binaries stop all three. It ends with how a recovered function should be reported so that a person, or an agent, knows how far to trust it.
Three kinds of tool sold as an AI decompiler
The term “AI decompiler” covers three different approaches, and they fail in different ways. Some tools ask a language model to rewrite the output of a classic decompiler such as Ghidra or IDA. Some train a model to produce source code directly from assembly. A third approach, matching decompilation, asks the model for source code and then recompiles it to see whether the result matches the original instructions.
| Approach | What goes in | What comes out | Examples |
|---|---|---|---|
| Language model over classic pseudocode | A classic decompiler’s output for one function | Renamed variables, types, comments and cleaner C | DAILA in Ghidra, IDA Pro, Binary Ninja and angr-management; decai in radare2 |
| Model trained on assembly | Disassembled machine code | Source-like C written by the model | RevEng.AI’s decompilation models |
| Matching decompilation | Assembly, plus the original build settings | C that recompiles to the same instructions, with a “% match” score | decomp.me with a language model |
The examples are DAILA, RevEng.AI’s decompilation models and decomp.me with a language model.
The first kind sits on top of tools analysts already use. NowSecure describes decai as a radare2 plugin focused on decompilation that can use a local model or a hosted one. DAILA puts one AI interface into several disassemblers and works with any model LiteLLM supports. Both depend on what the classic decompiler shows them.
How accurate are AI decompilers?
AI decompilers are accurate enough to speed up reading code, but none of them proves its own output. RevEng.AI, which trains models to decompile assembly, describes its evaluation as simple pass/fail testing and lists semantic correctness feedback as future work. NowSecure’s January 2025 write-up on radare2’s decai plugin warns that hallucinations make human oversight necessary.
Both point at the same problem. An AI decompiler produces text that reads like code a person wrote, and readability is what you notice first. A model can invent a plausible variable name, merge two branches, or drop an edge case, and the result still looks clean. Accuracy has to be measured function by function, on code the model can see.
Practitioners say the same thing. In a Hacker News thread on using language models with decompiler output, several people describe using models to traverse and explain decompiled code rather than to replace the decompiler.
What each approach can confirm about its own output
Each kind of AI decompiler can confirm a different amount, and the difference matters more than the model behind it.
- Language model over classic pseudocode. Confirms nothing by itself. The model rewrites what the decompiler printed. If the decompiler was right, the rewrite is easier to read; if the model guessed a name or a type, nothing in the tool marks the guess.
- Model trained on assembly. Can be tested, but testing is separate from the model. RevEng.AI’s pass/fail testing tells you whether generated code passes a test, not whether every path behaves like the original.
- Matching decompilation. Confirms the most, under strict conditions. The candidate C is recompiled and diffed against the target assembly, and decomp.me reports a “% match” between them. A full match shows the code compiles to the same instructions with the same toolchain. It needs the original compiler and settings, so it suits projects like game decompilation and rarely applies to an arbitrary binary.
None of the three tells you, per function, which parts were checked and which were inferred. That is the gap a recovered result has to close before anyone relies on it.
The same function, before and after
The same function looks very different before and after an AI decompiler cleans it up. The example in the figure is made up. It shows the kind of change a language model makes to classic pseudocode, and what such a change can’t show.
The rewrite is easier to read. Every name in it, from validate_session to retry_count, is a prediction. If the field at offset 8 is not a retry counter, the rewrite now teaches the reader something false about the program. Names are where an AI decompiler adds the most value and the most risk at the same time.
Do AI decompilers work on obfuscated or protected binaries?
AI decompilers do not recover code that a protector such as VMProtect or Themida has virtualized. Code virtualization turns each protected function into bytecode for a private virtual machine. The decompiler, and the language model reading its output, see the dispatcher loop and its handlers instead of the function’s logic. That code has to be devirtualized before an AI decompiler has anything meaningful to explain.
Lighter obfuscation causes a related problem. A function wrapped in extra branches or opaque predicates still decompiles, but a model can end up explaining the obfuscation as if it were part of the program’s intent. Our comparison of devirtualization, deobfuscation and unpacking covers which kind of protection each recovery method removes, and for scripts our JavaScript deobfuscators comparison lists which free tool undoes which technique.
For protected code, the order matters. Recovery comes first: an automated service such as VMProtect devirtualization returns the protected functions as readable code for files you own or are authorized to analyze. Then the AI tool reads that recovered code.
How a recovered function should be reported
A recovered function should be reported with a proof state, not presented as plain code. Devirt places every in-scope function in one of four proof states, and the same labels work for any AI decompiler output.
| Proof state | What it means for a recovered function |
|---|---|
| Proven | The accepted check supports the stated behavior within the declared scope. |
| Runtime-dependent | The result needs runtime evidence before an agent should treat it as settled. |
| Unresolved | The available evidence did not establish the behavior. |
| Permanently bounded | The question is outside the accepted model or artifact boundary. |
A function that was not proven stays in the count in one of the other three states, so a guess can’t pass for a result. Our research explains how the four proof states are decided, and the guide to evaluating a devirtualization result before paying shows how the count is checked.
Where an AI decompiler fits next to devirtualization
An AI decompiler and devirtualization do different jobs, and they work best in that order: recovery and checking first, then explanation. Devirt is not an AI model. It recovers the protected scope, and your chosen model or agent interprets the evidence.
Devirt’s read-only MCP connector lets the same agent read assessments, jobs, results and the structured ledger metadata beside its other tools. Upload, authorization, scope approval and payment stay in your account, not in an agent tool. The reverse engineering MCP guide shows where agents stall on protected code, and the AI reverse engineering page covers the full workflow, including agent-assisted reverse engineering.
Questions about AI decompilers
Is decompiling software legal?
Whether decompiling software is legal depends on the jurisdiction, the software license and the purpose, and using an AI decompiler does not change that question. Security research, malware analysis and interoperability are among the purposes for which people decompile files they own or are authorized to analyze. Devirt accepts only those files, and its acceptable use policy refuses cracking and license bypass. This is general information, not legal advice.
Which free decompilers do AI tools build on?
The free AI decompiler tools in this guide build on Ghidra and radare2, two free and open-source reverse engineering frameworks. DAILA adds one AI interface to Ghidra and angr-management, as well as the commercial IDA Pro and Binary Ninja, and works with any model LiteLLM supports. Decai is a radare2 plugin that sends decompiler output to a local or hosted model. The decompiler is free, but a hosted model may still charge for each request.
Does an AI decompiler recover the original source code?
An AI decompiler does not recover the original source code; it writes new source-like code that it predicts behaves the same way. Compilation removes most comments, local names and layout, and protection can remove more. A model can suggest plausible names and types, but those names are guesses until a check confirms the behavior. That is why a recovered function should carry its proof state.
To see what recovery would cover for your own file, create an account and upload a file you own or are authorized to analyze. Paid work starts only after you accept the offer.