Log date · Fri
ReSource paper: recovering decompiled code under optimization and obfuscation
ReSource uses a tiered LLM pipeline against transforms such as control-flow flattening, reporting 83% Top-5 retrieval; well-known transforms deserve reassessment.
What happened on 2026-08-28
On 2026-08-28 at 03:52 UTC, Zhiping Zhou, Xiaohong Li and co-authors submitted v1 of 'Decoupling is a Necessity: Transformation-Agnostic Decompiled Code Recovery under Optimization and Obfuscation' to arXiv. The paper introduces ReSource, a multi-phase LLM framework that separates recovery into lexical, syntactic and semantic tiers: a Semantic Distortion Database grounds the LLM to reduce logic drift, a lightweight predictor rebuilds source-level structure and handles control-flow flattening, and a contextual stage restores readable identifiers. On a benchmark of over 80,000 decompiled-source function pairs spanning three optimization levels and four obfuscation techniques, the abstract reports 83% Top-5 source retrieval accuracy and an average similarity of 0.66, and says baselines including DeGPT, LLM4Decompile and FidelityGPT overfit or degrade under the same conditions.
What it means for protecting app logic
Control-flow flattening is one of the core transforms in many compiler-level obfuscation schemes, and this paper makes it an explicit recovery target. For defenders the conclusion is not that obfuscation has failed, but that the delaying value of public, well-known transforms declines as research targets them, so assessments of a protection scheme should be updated over time. Read the numbers precisely: Top-5 retrieval accuracy measures finding the matching source function among candidates, not line-by-line reconstruction, and an average similarity of 0.66 shows the recovered code still differs noticeably from the original. The evaluation is at function level and says nothing about restoring a complete app.
Checks you can run
List the obfuscation transforms your build relies on and mark which ones are public, common types such as control-flow flattening and identifier renaming. In internal documentation, position those transforms as adding time cost, with a scheduled reassessment cycle. Move the highest-value logic server-side first, leaving the client with only what cannot be moved. For critical functions that remain on the client, consider combining layers instead of relying on a single transform. Re-evaluate on your own builds after every protection tool or compiler upgrade. Avoid describing any single transform to customers as making code unrecoverable.
Your checklist
- List the obfuscation transforms you rely on and how public they are
- Schedule periodic reassessment of common transforms
- Move the highest-value logic server-side first
Primary sources
- arXiv: Decoupling is a Necessity: Transformation-Agnostic Decompiled Code Recovery under Optimization and Obfuscation · Source date 2026-08-28 · Checked 2026-10-12