SoK paper asks how reliable LLMs are at recovering source code from binaries

What happened on 2026-10-08

At 09:20 UTC on 2026-10-08, arXiv received v1 of "SoK: Are LLMs Reliable at Source Code Recovery? A Taxonomy and Empirical Evaluation" (2610.11556, by Varun Kohli and five co-authors). According to the abstract, it is a systematization-of-knowledge paper on using large language models to recover source code from binaries, with assembly and decompiler-derived pseudo-C as inputs. The authors propose a design-centric taxonomy and evaluate methods across seven metrics and six dimensions. The test set has 45,000 samples covering four standard and five embedded architectures, five optimization levels and symbol stripping. They also study the effect of input representation, contextual enrichment, model scale, iteration and review roles, and they assess recovery within the same language and across languages (four mature and two legacy). This entry relies only on the abstract and quotes no specific results from the paper body.

What it means for a defender's threat model

The paper's value is that it turns "can AI turn my binary back into source code?" from anecdote into a measurable question. The variables it studies, such as optimization level, symbol stripping and target architecture, are exactly the factors developers control at build time. That suggests defenders can evaluate their own products the same way instead of relying on vendor claims or one-off demos. Cross-language recovery deserves particular attention: rewriting logic in another language is closer to cloning than to decompiling, so business rules may be reproduced even when the recovered code looks nothing like the original. The honest boundary is that any logic that runs on the client should be assumed understandable and re-implementable. Protection aims to raise cost and buy time; core value belongs on the server, or in the data and the service itself.

Checks on your own builds

You can run a small, repeatable evaluation on your own product. Pick a few functions that represent your core value, build them with your actual release settings, including optimization level and symbol stripping, and have your team try to understand them with AI-assisted tools. Then use your existing unit tests to check whether the recovered result is functionally equivalent, so you measure the risk instead of guessing. If core rules turn out to be easy to reproduce, prioritize moving them to the server or splitting them into a flow the client cannot complete alone. After any obfuscation or hardening step, rerun functional tests on the transformed build. Run this evaluation only on code you own, and record the method and conclusions so you can compare future releases.

Your checklist

• Build core functions with real release settings and run an internal AI-assisted comprehension test
• Measure functional equivalence of recovered code with unit tests instead of guessing
• Move easily reproduced core rules to the server