1. 引言

研究背景：随着结构设计模式的广泛采用以及缩短上市时间的迫切需要，越来越多的商业现成（COTS）软件产品正在开源软件（OSS）项目之上开发。如此快速的应用程序开发会导致一些不良问题，包括许可证违规和安全问题。在这些问题中，OSS 重用漏洞是最严重的问题之一。

现存问题：当一些易受攻击的 OSS 代码集成到软件中并在该软件中重用时，OSS 漏洞可能会被引入到 COTS 软件中。此类 OSS 漏洞（称为OSS重用漏洞）普遍存在，会对 COTS 软件的安全产生严重影响。例如，Adobe Reader 和 Windows Defender 都被发现存在漏洞，因为它们都使用了开源项目 Libxslt 和 UnRAR 的一些易受攻击的版本。事实上，大多数 OSS 重用漏洞仍然存在于COTS 软件中，即使其易受攻击的 OSS 版本已经被修补。根据 Synopsis 报告，被审计的 COTS产品中有 96% 重复使用了 OSS 项目作为其组件，平均包含六年前发布的 OSS 项目中未修补的OSS 漏洞。

为了检测 OSS 重用漏洞，必须尽可能准确地识别 COTS 软件中包含的 OSS 项目。因此，论文希望解决 COTS 软件的底层 OSS 重用检测问题。尽管移动应用程序的数量不断增加，但运行在桌面计算机和服务器上的传统 COTS 产品仍然被广泛使用。因此，本文重点关注 COTS 软件。COTS产品通常由数十个剥离的二进制文件组成，其中大多数是可移植可执行（PE）格式（适用于Windows）或可执行和可链接格式（ELF）（适用于Linux）。

现有工作：给定目标 COTS 软件产品的二进制文件和一组候选 OSS 项目，存在两种代表性的 OSS 重用检测方法。 其中一种方法为计算目标 COTS 产品的二进制文件与候选 OSS 项目的已编译二进制文件之间的相似性。 虽然之前在二进制相似性检测方面已做了许多工作，但仍然面临两个挑战。 首先，所有候选 OSS 项目的全自动编译并非易事，通常需要手动寻找适当的编译器标志才能成功编译。 在论文对从 Ubuntu Packages 爬取的共计 2189 个 OSS 项目进行的实验中，发现仅约四分之一可以自动编译。 其次，任何二进制相似性分析的成本都可能很高。 对于一个中等的 COTS 软件产品，需要大约数十亿次比较才能从众多候选 OSS 项目中寻找代码重用，这使得分析无法扩展。Function Similarity Based 检测方法实现成本高，可扩展性差

另一种方法是直接比较 COTS 软件产品的目标二进制文件与候选 OSS 项目的源代码。 在缺乏用于生成 COTS 软件二进制文件的编译器标志的情况下，以前关于二进制到源码匹配的工作严重依赖于代码函数，包括函数名称和字符串文字等信息，这些信息通常与使用的编译器标志无关。 因此，代码重用的可能性是通过目标二进制文件和候选 OSS 项目中存在的共同特征实例的数量来衡量的，这些特征实例代表具体的特征对象，如函数名称 jpeg_start_decompress。 虽然该方法可以扩展到数以万计的 OSS 项目，但由于未考虑代码函数，直接将其应用于 OSS 重用检测并不能提供所需的准确性。Constant Features Based 检测方法依赖函数名称和字符串文字，检测精度低

研究挑战：如何选择尽可能多的代码特征，同时确保所有选定的特征在编译的二进制文件中都是可追踪的？ 二进制到源码匹配的关键在于所考虑的代码特征。 例如，BAT 仅考虑字符串文字，因此错过了 39.7% 与字符串文字无关的代码重用。 OSSPolice 不仅考虑字符串文字，还考虑导出的函数名称，在 ELF 格式的库中表现良好。 然而，COTS 软件的 PE 文件通常会剥离这些线索，使得 OSSPolice 无法执行剥离二进制文件中所需的代码匹配。

如何精确计算不同代码特征及其特征实例的匹配分数？ 先前的工作通常通过计算匹配分数来衡量特征匹配程度。 但它们的分数计算不够精确，主要有两个原因：（1）不同类型的特征通常由同一过程匹配，（2）假设同一特征的不同特征实例在特征匹配中贡献相同。

如何利用 OSS 项目的代码结构来增强复用识别度？ 一般来说，较高的匹配分数并不总是代表较高的代码重用可能性，反之亦然。 具体来说，LibPNG 中的每个特征都与 libopenjp2-7.dll 中的特征匹配，导致匹配分数很高。 但实际上，libopenjp2-7.dll 只是重用了 OpenJPEG 而非 LibPNG。 这说明论文需要考虑到 OSS 项目的复杂代码结构，以减少误报的重用标识数量，并增加真实重用标识的发现数量。

研究内容：为了解决上述三个问题，论文提出了一种二进制到源匹配方法 B2SFINDER，用于检测 OSS 重用。 如下图所示，B2SFINDER 分为 "匹配分数计算" 和 "重用类型识别" 两个阶段：

• 匹配分数计算：为了精确计算第一阶段的匹配分数，论文选择了七种稳定的代码特征，其中四种不受编译影响，三种在编译过程中受到轻微影响。通过将七种特征分为字符串型、整数型和控制流型三种类型，论文设计了三种相应的匹配方法：精确匹配、基于搜索的匹配和基于语义的匹配。为了描述不同匹配特征实例的相对重要性，论文引入了两个特征实例属性：特异性和出现频率。 特异性属性表示特殊匹配的特征实例（例如0x6a09e667）比普通的特征实例（例如0x0001）更有助于区分一个 OSS项目与其他项目。 出现频率属性表示所有候选 OSS 项目中匹