NotDec：带过程间类型恢复的 WebAssembly 反编译

当天发生了什么

2026-08-04 08:01（UTC），arXiv 收到论文《NotDec: WebAssembly Decompilation With Inter-Procedural Type Recovery》的 v1，备注称发表于 ICSE'26。NotDec 扩展了 WebAssembly 的类型检查算法，把字节码提升为基于 SSA 的中间表示；用过程间类型恢复算法 Retypd，并结合指针与数值区分方法来恢复复杂数据结构；再借助 Memory SSA 和保持语义的结构化控制流分析输出 C 代码。摘要中的数字是：在全部 5,241 个 Juliet 样本和 Howard 数据集程序上重编译成功率 100%，对照的 Ghidra 为 45.95%；在真实程序中恢复了 85.33% 的结构体成员访问，Ghidra 为 9.24%。作者也写明了局限：完整的过程间版本在大型二进制上有可扩展性问题，过程内变体 NotDec_F 更高效，在未优化二进制上内存不到 Ghidra 的一半、耗时最多少 97%。

对保护应用逻辑的人意味着什么

不少团队把计算密集或「不想让人看」的逻辑编译成 WebAssembly，放进网页、Electron 或跨平台前端里，默认它比 JavaScript 更难读。NotDec 这类工作说明，难读的主要原因是类型和数据结构丢失，而这正是研究在补的部分：一旦结构体成员和控制流能被恢复成可重编译的 C，阅读成本会明显下降，再配合大模型做命名和摘要，门槛还会更低。需要诚实看待的是：论文的评测集以测试样本和研究数据集为主，效率数字针对未优化二进制，大型优化过的模块是否同样有效，摘要没有给出结论。但对防守方来说，结论方向已经足够清楚：下发到客户端的 .wasm 应当被视为公开代码，它能提高分析成本，却不是保密边界。

可以落地的检查

第一，盘点所有随客户端分发的 .wasm 文件，列出每个模块里包含的业务逻辑、常量和密钥类数据。第二，检查发布构建是否仍保留名称段（name section）或 DWARF 调试信息，并确认这是有意为之。第三，把许可证判断、定价规则、风控阈值等决定性逻辑放到服务端，客户端 Wasm 只做可以公开的计算。第四，每次升级编译工具链或优化选项后，用公开的反编译工具对自己的构建做一次可读性抽查，并记录结果，作为后续评估的基线。

行动清单

• 盘点客户端分发的全部 .wasm 及其内容
• 检查发布构建是否保留名称段或 DWARF 信息
• 把许可证与定价等决定性逻辑放到服务端
• 工具链升级后对自家构建做可读性抽查并留档