Echo (arXiv 2609.18706): matching decompilation with recompilation as trusted feedback

What happened on 2026-09-16

At 14:14 UTC on 2026-09-16, Jun Bi and five co-authors submitted v1 of 'Echo' (arXiv 2609.18706), filed under cs.CR and cs.AI. The paper starts from a known weakness: neural decompilers can already produce readable, recompilable code, but it is hard to tell whether that code is faithful to the original. Matching decompilation sets a stricter goal, namely source code whose recompiled assembly is identical to the target binary. That is especially hard when the optimization level and compiler flags are unknown. Echo has a domain-specific model propose candidate programs together with compiler configurations. It recompiles them, scores assembly-level similarity as trusted feedback, and iterates. Any remaining mismatches go through rule-based rewriting, neural refinement and reasoning-based refinement. The abstract reports that on function-level benchmarks Echo produced on average 2.43 times as many exact matches as the strongest baseline. On the Mirai malware binary it matched 2.75 times as many functions as GPT-5.6 and 7.4 times as many as Codex.

What it means for protecting app logic

For developers protecting their own app logic, the specific multipliers matter less than the method. Echo treats the compiler as a referee and lets a model keep trying until the recompiled output matches the original binary function by function. Until now, decompiled code that looks plausible but cannot be trusted has acted as a natural buffer. Once that output can be checked mechanically, recovered code gets much closer to something an attacker could reuse directly. The limits deserve equal honesty. The paper evaluates function-level benchmarks and one malware sample. The abstract does not say how the approach performs on binaries transformed by control-flow flattening, instruction substitution or other obfuscation, and exact matching depends on reproducing the original build configuration. Compile-time transformations probably make an identical recompilation harder to reach. That does not show they stop this class of technique, and it does not show that obfuscation has stopped working either.

Checks to run on your own builds

First, list the functions in your shipped binary that actually carry core rules, such as pricing, entitlement decisions or risk thresholds, and decide one by one whether each can move server-side. Logic that stays on the client should be assumed recoverable. Second, if you use compile-time obfuscation, keep an unobfuscated build and an obfuscated build of the same version. Periodically open both in a public decompiler and compare how readable the key functions are, and write down what you see rather than relying on impressions. Third, check whether release artifacts leak symbols, debug information or compiler version strings, because these make the build configuration easier to guess. Fourth, add this line of research to your threat-model review and confirm each quarter whether the assumption that client code is hard to reconstruct accurately still holds.

Your checklist

• List client functions that carry core rules and assess moving them server-side
• Keep unobfuscated and obfuscated builds and periodically compare key functions
• Check release artifacts for symbols, debug info and compiler version strings