STILL 论文：从剥离符号的 C++ 中恢复 STL 语义

当天发生了什么

2026-08-26 21:20（UTC），Xiaohan Wang 与 Kevin Leach 在 arXiv 提交了论文《STILL: Recovering Lowered STL Semantics for LLM-assisted C++ Decompilation》v1。摘要指出，LLM 辅助反编译虽然改善了可读性和可重新执行性，但在使用标准模板库（STL）且剥离了符号的 C++ 函数上仍表现不佳，因为编译、优化和剥离会掩盖容器类型和库调用结构。STILL 从剥离后的控制流图预测函数级的 STL 容器语义，再转换成紧凑提示供 LLM 改写。在剥离符号的 HumanEval 反编译上，DeepSeek-chat 配合提示的可执行率为 28.4%，无提示改写为 17.4%，原始 Ghidra 输出为 8.9%。摘要还提到，提示的效果取决于下游模型。

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

很多 iOS、Android 和桌面应用把核心算法放进 C++ 原生库，并认为剥离符号后就「看不出是什么」。这篇论文说明，即使名字没了，库的使用方式仍会在控制流结构上留下可识别的痕迹，而这些痕迹可以被学习并用来提升 LLM 反编译质量。也要准确看待数字：28.4% 的可执行率意味着大多数函数仍未被恢复为可运行代码，而且评估对象是 HumanEval 这类较小的函数，不代表完整原生库可以被自动还原。它说明的是趋势和方向，而非现成能力。

可以做的检查

把「已剥离符号」从保护清单里降级为卫生措施，而不是保护手段。盘点原生库中真正承载核心价值的函数，评估它们是否必须在客户端运行。对自己的 release 原生库用常见反编译器看一遍，了解容器、字符串处理等结构在输出中是否容易辨认，作为内部基线。密钥和授权判断不应放在原生库里依赖「难以阅读」来保护。随着工具进步，定期重复这项自查。

行动清单

• 把剥离符号视为卫生措施而非保护
• 盘点原生库中承载核心价值的函数
• 对自有原生库做反编译自查并定期复测