LLM4Decompile, OGhidra, DAILA: 7 AI decompilers, measured
Every thread about turning a binary back into source ends with the same seven repositories. I pulled stars and last-push dates for all of them this morning, plus the decompilers they sit on top of, because the list gets recommended far more often than it gets checked.
| project | stars | last push | what it is |
|---|---|---|---|
| LLM4Decompile | 7,034 | 216 days | models trained to turn assembly back into C |
| reverser_ai | 1,137 | 119 days | renames Binary Ninja functions using a local model |
| DAILA | 707 | 64 days | one plugin interface across Ghidra, IDA and angr |
| OGhidra | 439 | 2 days | Ghidra talking to Ollama, from a national lab |
| decompai | 227 | 310 days | upload an x86 binary, analyse it by chat |
| sentinel-reverse | 78 | 223 days | autonomous binary analysis CLI, MLX focused |
| GhidraLens | 0 | 17 days | Ghidra views inside an AI client |
Median 439 stars. Five of the seven have not been touched in two months or more, two of them in seven and ten. The only one pushed this week is a bridge to Ollama rather than a decompiler, and the one with the most stars is a research release that has sat still since February.
Now the layer underneath, on the same day:
| tool | stars | last push |
|---|---|---|
| Ghidra | 77,196 | 1 day |
| jadx | 50,480 | 4 days |
| ILSpy | 26,075 | 1 day |
| dnSpyEx | 11,078 | 22 days |
| Il2CppDumper | 9,392 | 759 days |
| RetDec | 8,630 | 113 days |
| AssetRipper | 8,349 | same day |
The whole AI layer adds up to 9,622 stars, less than an eighth of Ghidra on its own, and four of the seven classic tools shipped something this week.
So the honest shape of it: the decompiler does the work, the model reads the output and guesses names. Where to start depends entirely on what you are holding.
| what you have | start with | what a model adds |
|---|---|---|
Windows .exe or .dll |
Ghidra, RetDec | naming functions, guessing structs |
| Android APK | jadx, apktool | explaining obfuscated Java |
| .NET assembly | ILSpy, dnSpyEx | little, the C# is already readable |
Java .jar |
CFR, FernFlower | little, same reason |
| Unity Mono game | AssetRipper, dnSpyEx | recovering intent in generated code |
| Unity IL2CPP | Il2CppDumper plus Ghidra | mapping classes back to methods |
| iOS or macOS binary | Ghidra, Hopper | Swift name demangling, mostly |
| Flutter release build | Ghidra and Dart tooling | very little worth the time |
None of it gives back a project you can build. Comments, local variable names and file layout are gone at compile time and no model recovers them, it invents plausible ones. .NET, Java and Unity Mono come back close to source because the bytecode kept the names. Optimised C and C++, Swift, Flutter AOT and anything obfuscated stay a long manual read.
And the obvious line: your own binaries, or ones you have written permission to pull apart.
@nils_ohm · 3h ago · 2 replies
The renaming is worth more than the summaries, and it is the part people undersell. A stripped binary with 4,000
FUN_0040labels is unreadable because you cannot hold the shape of it. Getting 300 of them renamed to something half right means you can finally see which ones matter. Half right is fine at that stage. It is not fine three hours later when you have built an argument on a name the model guessed.Reply
Report
@wrenfield · 3h ago
That matches what I saw. The useful loop was rename everything, find the twenty functions that matter, then throw away every generated name in those twenty and do them by hand.
Reply
Report