Evaluating neural decompilation of Dart AOT binaries: what the scores measure

What happened on this date

On 2026-07-07 (10:36 UTC), Raafat Abualazm and co-authors submitted v1 of "Evaluating Neural Decompilation of Dart AOT Binaries" (arXiv 2607.06125); a v2 followed on 2026-10-01, and the details here follow the abstract shown when checked. The paper evaluates neural decompilation of Dart ahead-of-time binaries by execution and audits what the scores mean. Across six adapter comparisons, both Qwen3-8B adapters showed functional regressions at k = 1, 5 and 10. On 141 reference-certified tasks, CodeBLEU had only a modest association with pass@10, and about 21–23% of compiling candidates passed. Removing semantic names and related cues cut task coverage from 42/154 to 7/154, and across five decoding seeds the baseline solved 4.8 tasks on average.

What it means for a Flutter app's threat model

Flutter release builds compile Dart to native machine code, which is often mistaken for unreadable. This paper is a reminder that researchers are systematically trying to recover source from Dart AOT with models. The encouraging part is that, by the authors' numbers, current results are far from reliable: there is a wide gap between compiling and behaving correctly, and common text-similarity metrics overstate quality. What developers should note most is the role of names. Removing semantic names and related cues sharply reduced the tasks that could be handled, which suggests symbol and naming information is a major aid to these methods. It is still a single study, and the authors say some questions remain open, so it supports neither the claim that Flutter apps are automatically decompiled nor the claim that they are safe.

Checks to run on your own builds

First, build releases with Flutter's --obfuscate together with --split-debug-info, and keep the symbol files in a private location for crash symbolication rather than shipping them with the app or in a public repository. Second, run strings on your own libapp.so to see whether class names, method names, endpoint paths or error messages reveal business meaning. Third, review which rules truly must stay on the client, and validate pricing, entitlement and anti-abuse decisions on the server. Fourth, run full regression tests after obfuscation, especially code that depends on type names or reflection-style serialization. Fifth, follow later versions of this research; their methods and metrics can help you judge your own risk objectively rather than by marketing claims.

Your checklist

• Build with --obfuscate and --split-debug-info and keep symbol files private
• Check readable names and paths in your own libapp.so
• Validate pricing and entitlement decisions server-side
• Regression-test code that depends on type names after obfuscation