调用图上下文能否改进二进制函数嵌入？一篇实证研究

当天发生了什么

2026-08-03 11:44（UTC），arXiv 收到论文《Pretraining on Call Graphs: When Binary Analysis Tasks Profit From Context》的 v1，主分类 cs.SE。背景是：二进制函数嵌入模型把编译后代码的语义编码成向量，用于二进制代码搜索、漏洞检测、恶意软件分类等逆向任务；一些工作尝试引入调用图信息来增强嵌入。作者在两个当前先进的嵌入模型输出上，试验了一系列基于图的模型。摘要给出的结论有几条：在二进制代码相似度检测（BCSD）上的改进，不一定能推广到语义或语法类的下游任务；为语义相似度优化，往往与语法任务表现变差相关；调用图增强明显提高了嵌入的鲁棒性，尤其在原始模型表现吃力的场景；而且这种上下文对命名空间相关的函数帮助更大，对实现独立逻辑的函数帮助较小。

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

二进制相似度技术是双刃剑：分析者用它把你二进制里的函数和已知代码对上号，从而跳过大量阅读；你也可以用它在别人的产品里寻找被复用的自家代码。这篇论文提醒两点。其一，函数并不是孤立的，调用关系本身就携带信息，即使符号被剥离，邻居函数和调用结构仍可能帮助模型认出它，尤其是与库、命名空间相关的函数。其二，基准分数不能直接外推：在相似度检测上表现好的方法，换到别的任务可能变差。所以无论你是评估「自己的代码有多容易被认出」，还是选工具去发现克隆，都应该在具体任务上实测，而不是只看论文或厂商给出的单一指标。这是研究层面的结论，不代表任何具体商业工具的能力。

可以落地的检查

第一，确认发布构建确实剥离了调试符号和不必要的导出符号，并把这一点纳入发布检查清单。第二，默认假设第三方库代码会被快速识别，真正需要保护的不是「用了哪个库」，而是你自己的业务规则和数据，能放到服务端的尽量放到服务端。第三，如果打算用相似度工具监测克隆，先用自己不同版本、不同编译选项的构建做一次内部测试，记录召回和误报，再决定是否依赖它。第四，混淆或变换后，重新测一次相似度结果，确认变化是可测量的，而不是想当然。

行动清单

• 确认发布构建已剥离调试符号与多余导出
• 默认第三方库会被识别，把核心规则移到服务端
• 用自家多版本构建测试相似度工具的召回与误报
• 变换后重新测量相似度，而不是假设有效