论文学习_UVSCAN: Detecting Third-Party Component Usage Violations in IoT Firmware

1. 引言

研究背景：物联网（IoT）已经无处不在，为我们的日常生活提供了极大的便利。 从路由器、打印机等传统物联网设备，到智能灯、智能插件等智能家居，物联网设备在现代生活中的应用日益广泛。 根据最近的一份报告，Gartner预测，从2020年到2030年，物联网设备的数量将增加两倍。物联网设备的蓬勃发展也不可避免地引发了公众对其安全风险的担忧以及几次现实世界的攻击进一步加剧了这种恐慌。 例如，Mirai 已经危害了数百万个物联网设备，包括 IP 摄像机、DVR 和路由器，形成僵尸网络，并对各种在线服务发起 DDoS 攻击。

固件是在物联网设备中启动的集成软件包，发挥着重要作用。 如今，固件广泛采用 TPC，例如 BusyBox 和 OpenSSL，以加速和简化开发过程。 然而，TPC 的广泛使用是一把双刃剑，因为大量 TPC 存在已知漏洞，这些漏洞将为物联网固件带来许多新的攻击面。 例如，OpenSSL 中的 Heartbleed 漏洞 已经极大地影响了至少数百万台物联网设备。 更糟糕的是，供应商可能会在不同类型的固件中重复使用一组相同的 TPC，这会加速潜在漏洞的传播。 因此，识别固件中使用的易受攻击的 TPC 至关重要。 由TPC引起的单一漏洞可能会在物联网生态系统中造成蝴蝶效应。

现存问题：尽管一系列研究采用了静态或动态方法在评估固件安全性方面，它们仍然受到限制，因为它们较少关注固件中由 TPC 引起的漏洞，缺乏对非基于 Linux 的固件的考虑，和/或在大规模固件安全分析中无法扩展。 具体来说，首先，他们缺乏对TPC引入的 N-day 漏洞的分析，这可能会导致比现实中未知漏洞更严重的问题。 其次，大多数方法仅限于分析基于 Linux 的固件，而缺乏对单片固件的分析，而单片固件广泛应用于新的无处不在的低功耗嵌入式系统，例如智能家居。 最后但并非最不重要的一点是，在进行大规模固件测试时，它们的可扩展性是一个挑战。 例如，多种方法需要真正的物联网设备进行分析或进行大量手动配置工作，这极大地限制了它们的可扩展性。 因此，目前仍然缺乏一种可扩展且实用的方法来全面了解TPC在多种固件中的使用情况及其引入的漏洞。

1.1 研究挑战

固件数据集构建：为了进行研究，第一个挑战是构建一个大规模且全面的固件数据集，涵盖来自不同供应商的不同类型的固件。 从而可以获得关于当前固件安全问题的令人信服的结果。 然而，没有可公开访问的固件数据集用于研究。 此外，越来越多的厂商开始禁止公众下载固件，并对恶意网络爬虫采取反抓取技术，这又大大增加了数据收集的难度。 固件处理。 固件处理存在两个主要挑战。 (1) 从基于 Linux 的固件中提取包含的对象，这些对象具有 TPC 检测的基本信息。 虽然现有的工具（binwalk），可以用于解压固件，但它们在处理采用最新或定制文件系统的固件时存在局限性。 (2)处理单片固件，该固件广泛应用于低功耗嵌入式系统，例如智能家居。 单片固件通常缺乏分析所需的传统操作系统或元数据，例如 RAM/ROM 起始地址。 此外，它的代码、库和数据是高度混合的。 然而，面对这些挑战，现有工具（例如 IDA）无法在没有额外配置的情况下处理单片固件。

TPC 检测和漏洞识别：在 TPC 检测和漏洞识别方面面临两大挑战， （1）在版本级别检测 TPC。 为了准确识别固件中使用的 TPC 对应的漏洞，我们需要在版本级别进行检测，而不仅仅是在 TPC 级别进行检测，因为不同版本的 TPC 的漏洞可能有所不同。 然而，由于不同版本的代码差异可能很小，因此很难在版本级别区分相同的 TPC。 此外，在没有源代码的情况下，只能从固件中获取有限的特征来进行 TPC 识别。 以前的固件分析工作无法满足我们的要求，因为它们不支持在固件的版本级别检测 TPC。（2）构建TPC数据库， 研究需要一个全面且易于使用的 TPC 数据库，以指示固件中可能使用的 TPC 以及每个版本的 TPC 的漏洞。 调研结果表明，之前还没有为物联网固件构建这样的 TPC 数据库的工作。 收集尽可能多的 TPC 并将漏洞映射到 TPC 版本是一项挑战。

1.2 研究方法

在论文致力于全面了解 TPC 在固件中的使用以及 TPC 带来的潜在安全风险。 为此，作者开发了一个可扩展的自动化框架 FIRMSEC 来对物联网固件进行大规模分析，论文的分析方法如下。

• 步骤 1：为了解决构建固件数据集的挑战，作者从公共来源和私人来源（例如官方网站和私人固件存储库）收集固件映像。
• 步骤 2：作者为现有的工具（例如binwalk和IDA）定制了几个插件，以解决固件处理中的问题。定制工具支持解压和反汇编基于 Linux 的固件（使用流行和不常见的文件系统）和单片固件。
• 步骤 3：作者提出了一种新的检测策略来识别固件中使用的 TPC。论文的主要思想是利用从 TPC 和固件中提取的两种特征：语法特征和控制流图特征。然后论文根据版本检查搜索相应的漏洞，这依赖于论文的TPC数据库。根据结果​​，FIRMSEC 将为每个固件映像生成一份报告，指出其潜在风险。此外，报告还将提供一系列修复漏洞的建议。

为了提供更深入的见解，论文进一步研究从四个方面探讨物联网生态系统的安全现状。 首先，论文评估不同种类、不同供应商的固件的漏洞。 其次，论文调查了不同时期固件中TPC的使用趋势以及它们引起的相应漏洞。 接下来，论文探讨物联网设备安全性的地域差异。 然后，论文探讨了固件中过时的TPC问题。 然后，论文研究固件更新过程中 TPC 的变化。 最后，论文分析了固件中的 TPC GPL/AGPL 许可证违规情况。

1.3 研究贡献

论文构建了迄今为止最大的固件数据集，其中包括 11,086 个可公开访问的固件映像和 23,050 个私有固件映像。 它包含 35 种固件，其中大部分在以前的作品中很少研究。为了方便未来的研究，论文在 https://github.com/BBge/FirmSecDataset 开源了该数据集。

论文提出 FIRMSEC，一个可扩展的自动化框架，用于分析固件中使用的 TPC 并识别相应的漏洞。 FIRMSEC 在识别固件版本级别的 TPC 方面具有 91.03% 的精确度和 92.26% 的召回率，显着优于学术界和工业界商业系统的最新成果，例如 Gemini、BAT、OSSPolice、binare 、360 FirmwareTotal 和阿里巴巴 FSS。

论文对固件中易受攻击的 TPC 问题进行了首次大规模分析。 论文在 34,136 个固件映像中识别出 584 个 TPC，并检测到 429 个 CVE。 根据结果​​，论文揭示了物联网固件中易受攻击和过时的 TPC 的广泛使用。 此外，论文注意到，随着时间的推移，固件中包含越来越多由TPC引起的漏洞，而供应商在固件更新时几乎不更新易受攻击的TPC。 此外，论文确认了物联网设备安全性的地理差异，其中韩国和中国等几个地区的情况比其他地区更为严重。 最后，论文发现 2,478 个固件映像可能违反 GPL/AGPL 许可条款，这可能会导致诉讼。

2. 设计与实施

FIRMSEC 旨在自动识别固件中使用的 TPC 并检测相应的漏洞。 如下图所示，FIRMSEC主要包含三个部分：固件采集、固件预处理和固件分析。 固件采集模块主要用于采集不同来源的固件。 接下来，固件预处理模块将分三步处理收集到的固件，（1）从原始数据集中过滤掉非固件文件； （2）识别固件必要的信息； （3） 解压并拆解固件。最后，固件分析模块将根据从 TPC 和固件中提取的语法特征和控制流图特征来检测固件中版本级别的 TPC。 根据论文的TPC数据库，通过版本检查来识别相应的漏洞。 以下小节将讨论每个组件背后的实现。

2.1 固件收集

固件采集模块负责采集固件以构建大规模的原始数据集。 为了解决固件资源有限的问题，论文实现了一个网络爬虫从三个来源收集固件：官方网站，一些供应商在其官方网站上提供固件下载链接。FTP站点，论文发现了一个存储旧版本固件的 ftp 站点列表，可以免费下载。社区，论文从社区收集了多家厂商的部分固件镜像，包括相关论坛和GitHub仓库；私有固件存储库，论文获得了访问一家主要专注于智能家居的世界领先公司的私有固件存储库的权限。 在论文使用 TSmart 来代表这家公司。 TSmart 的固件存储库包含数以万计的由数百家供应商（例如飞利浦）制造的智能家居固件映像，并且从未被研究过。 其次，我们基于 Scrapy 实现了一个网络爬虫，它支持从13个供应商的31个站点收集固件，例如TP-Link、DLink、Trendnet等。

2.2 固件预处理

在这一部分中，论文主要通过三个步骤对收集到的固件进行预处理：固件过滤、固件识别、固件提取以及固件反汇编。

固件过滤：第一步是从原始数据集中排除非固件文件。 分析原始数据集中的非固件文件将产生意想不到的结果，从而影响论文最终结果的可信度。 因此，论文需要从收集的固件中排除非固件文件。 首先，论文通过后缀匹配过滤掉明显的非固件文件，例如.txt文件。 其次，论文采用下一代二进制分析（BANG），它支持识别136种文件，以去除其他非固件文件，例如Android Dex。 论文将其应用于其余收集的文件，并根据返回的文件类型删除非固件文件。

固件识别：第二步是识别固件的必要信息，例如操作系统、架构和文件系统，这对于进一步分析至关重要。 尽管非固件文件已从数据集中排除，但仍有大量固件映像的类别仍未知。 此外，论文还缺乏有关他们的操作系统、体系结构、文件系统等信息，这对于进一步分析至关重要。 采用两种方法来识别未知固件的类别。 (1) 论文从固件爬取的元数据文件中提取信息。 元数据文件描述了固件，包括其对应的设备型号、类别等。 元数据文件通常与固件位于同一存档中。 （2）论文实现一个脚本来查询互联网上未知固件的文件名，并爬取返回的前3个站点的内容，其中可能包含相关信息，例如固件的类别。论文最终结合上述两种方法获得的信息来识别未知固件的类别。 其次，论文采用binwalk扫描所有固件镜像，获取其操作系统、架构和文件系统。

固件提取：固件中包含的对象具有许多语法特征，这对于进一步的 TPC 检测至关重要。 此外，从固件中提取的链接库是创建TPC数据库的主要来源。 因此，在进行进一步分析之前，有必要进行固件提取。 然而，现有工具在提取采用最新或定制文件系统的固件时或多或少存在提取不完整等问题。 这里的主要挑战是彻底提取固件中的文件系统，而不递归提取压缩数据。 为了应对这一挑战，论文为 binwalk 配备了一系列插件。 首先，论文分析了收集到的固件中使用的文件系统，发现原始的binwalk主要在处理三种流行的系统上存在问题：SquashFS、JFFS2、YAFFS和UBIFS。 然后，论文利用 sasquatch 和 jefferson 来替换 binwalk 中的 unsquashfs 和 jffsdump。 这些插件支持许多特定于供应商的 SquashFS 和 JFFS2 实现。 接下来，论文为 binwalk 实现一个基于 yaffshiv 的新插件来解压 YAFFS，它支持 YAFFS 构建参数（例如页面大小）的暴力破解，甚至在文件系统运行多轮后也可以提取包含的对象。 最后，论文基于 UBI Reader 为 binwalk 开发了一个插件来解压 UBIFS。

固件反汇编：固件中的控制流图 (CFG) 包含识别固件中 TPC 的基本信息。 为了获得CFG，论文需要先反汇编固件。 然而，现有的反汇编工具无法在没有额外配置的情况下处理单片固件。 例如，原生 IDA 和 GHIDRA 都无法处理许多单片固件映像，因为它们采用不常见的处理器并丢弃一些必要的信息，例如分析所需的 RAM/ROM 起始地址。 这里的主要挑战是根据单片固件的已知有限信息来恢复丢失的信息。 为了解决这一挑战，论文首先分析单片固件中使用的处理器以恢复丢失的信息，然后为 IDA 实现一系列定制插件来加载和反汇编单片固件。 更具体地说，首先，论文分析收集的单片固件中使用的处理器类型，例如 ESP8266 。 其次，论文收集每个处理器相应的参考手册或数据表。 参考手册和数据表可以为我们提供三种有用的信息：处理器的核心、内存映射和中断向量表。 论文可以根据核心找出反汇编固件的确切指令集，并从内存映射中检索用于加载固件的RAM/ROM起始地址。 此外，论文还可以从中断向量表中获取固件起始地址。 最后，论文根据恢复的信息为IDA实现了 7 个插件，对应于单片固件中使用的7种处理器。 这些插件使 IDA 能够自动加载和反汇编单片固件。

2.3 固件分析

通常的做法是使用版本检查来识别TPC的相应漏洞。 在FIRMSEC中，论文也采用这种策略来分析固件。 固件分析模块包括三个子模块：（1）TPC数据集构建，（2）TPC检测，（3）漏洞识别。

TPC 数据集构建：论文的分析策略需要一个 TPC 数据库，其中包含固件中可能使用的 TPC 以及每个 TPC 版本的详细漏洞信息。 然而，与指示 Android 应用程序中使用的 TPC 的 Maven 存储库不同，没有这样一个可公开访问的 IoT 固件数据库。 这里的主要挑战是从可靠来源收集尽可能多的 TPC 并将漏洞映射到 TPC 版本。 为了克服这一挑战，论文首先从四个来源收集物联网固件中可能使用的 TPC：（1）从固件中提取的链接库； （2）开源物联网项目； （3）来自多个物联网平台的SDK，例如AWS IoT； 4）来自 TSmart 的 TPC 候选列表，如下表所示。其次，论文利用专业的CVE搜索工具 cve-search 从CVE数据库中查询TPC，并实现一个脚本 查询 NVD 和 CVE 详细信息以收集 TPC CVE。 通过这两种方法，论文可以获得不同版本 TPC 对应的 CVE。 构建的物联网固件TPC数据库具有以下字段：TPC、许可证、版本、CVE、CVSS分数[49]和CVE描述。 我们最终收集到了 1,261 个 TPC。

TPC 检测：在版本级别精确检测固件中使用的 TPC 对于我们的分析至关重要，因为论文将使用检测到的 TPC 的确切版本来确认其漏洞。 然而，由于论文只能从固件中获取有限的信息，并且不同版本的代码差异可能很小，因此很难在版本级别区分相同的TPC。 为了应对这一挑战，论文实现了一种基于两种特征的新型 TPC 检测方法：语法特征和 CFG 特征，这些特征在源文件和二进制文件之间几乎没有变化。 论文首先从 TPC 和固件中提取上述两个特征。 接下来，论文利用编辑距离这种广泛使用的方法来衡量两个字符串之间的相似度，并使用基于比率的匹配来计算句法特征的相似度，并使用定制的Gemini 来比较 CFG 特征。 根据比较结果，论文最终确认了 TPC 在版本级别的使用。 工作流程如下。

• TPC 特征提取：首先，论文实现一个解析器来从 TPC 的 C/C++ 源文件中提取语法特征。 语法特征包括字符串文字（例如，唯一字符串）、函数信息（例如，函数名称和函数参数类型）。 对于每种TPC，论文总结了其所有版本中共同的句法特征，将其视为共享句法特征。 然后，论文识别每个版本的 TPC 中的特定语法特征，这些特征被视为独特的语法特征。 其次，我们从每个版本的 TPC 中提取属性控制流图（ACFG）。 ACFG 中的每个顶点都是一个标有一组属性的基本块。 除了Gemini 中使用的块级属性外，论文还使用了三个函数级属性，如表2所示。函数级属性提供了有关CFG结构的更详细信息，而Gemini忽略了这些信息。
• 固件特征提取：首先，论文从固件中提取与上一步相同类型的语法特征。 虽然论文成功反汇编了基于 Linux 的固件和单片固件，但许多函数名称是 IDA 无法识别的，特别是在单片固件中。 为了解决这个问题，我们为 IDA 配备了大量 TPC 的签名文件，以识别反汇编文件中的函数名称。 签名文件主要是从互联网上收集的，例如 GitHub 项目，论文也手动生成了一部分签名文件。 其次，论文从反汇编的固件中提取 ACFG，其属性与从 TPC 中提取的属性相同。 然而，Gemini 使用的原始提取工具无法从单片固件中提取 ACFG，因为它无法反汇编单片固件。 因此，论文通过集成论文的固件反汇编模块来定制提取工具。
• 语法特征匹配：在此步骤中，论文进行句法特征匹配来识别 TPC。 不幸的是，直接的特征匹配，例如正则表达式，会导致精度和召回率较低。 设计一种新的高精度和召回率匹配方法是这一步的主要挑战。 为了应对这一挑战，论文利用编辑距离和基于比率的匹配来测量 TPC 和固件之间的相似性。
• CFG 特征匹配：论文利用定制的 Gemini 来进行 CFG 特征匹配。 最初的 Gemini 旨在检测固件中的特定漏洞，例如 OpenSSL Heartbleed 漏洞。 它首先分别从漏洞和固件中提取CFG。 然后，Gemini 将所有 CFG 转换为 ACFG，记为 VulACFG 和 FirmACFG。ACFG 表示为七维向量，由七个块级属性组成。接下来，它使用嵌入基于 struct2vec 的网络来计算这些 ACFG 之间的余弦相似度，记为 Cosine(VulACFG, FirmACFG)。 最后根据Cosine(V ulACF G, F irmACF G)列出了固件中前K个相似函数。尽管如此，最初的 Gemini 并不能直接应用于TPC检测。 论文想要确认 TPC 和固件之间的相似性，而不是单个功能的相似性。 由于每个TPC 有许多 ACFG，单个 ACFG 的相似性不能确定TPC和固件之间的相似性。 这里的主要挑战是设计一种方法来聚合 TPC 中每个 ACFG 的相似度，以表示TPC和固件之间的最终相似度。

漏洞识别：在此步骤中，论文利用版本检查来根据论文的 TPC 数据库识别固件中检测到的 TPC 的漏洞。 该数据库包含与不同版本的 TPC 对应的 CVE。 因此，论文实现一个脚本来自动查询数据库中的TPC和相应的版本（例如OpenSSL 0.9.8），并记录返回的漏洞信息。 论文需要澄清的是，某些漏洞可能无法被利用，因为由于其他补救措施（例如禁用某些配置选项或执行某些检查以防止其使用），可能无法访问某些易受攻击的代码。 因此，论文将已识别的漏洞视为潜在漏洞。 论文最终为测试的固件生成一份报告，该报告指出了其潜在的风险，并提供了一系列修复漏洞的建议。

3. 系统评估

在本节中，论文首先介绍数据集的组成。 接下来，论文评估 FIRMSEC 的性能，并将其与来自学术界和工业界商业系统的三个最先进的作品进行比较：Gemini、BAT、OSSPolice、binare、360 FirmwareTotal 和阿里巴巴 FSS。

3.1 数据集组成

基于固件采集模块，论文初步采集了来自 13 家厂商的共计 35 个、978 个固件镜像，涉及 35 种设备。具体来说，从互联网爬取 12,913 个固件镜像，从 TSmart 获取 23,065 个固件镜像。论文的数据集实际上涉及数百家供应商，因为 TSmart 的私有固件映像是由数百家供应商制造的。 TSmart提供了一个平台，可以使不同厂商的设备成为智能产品。为了方便起见，论文使用 TSmart 作为私有固件的供应商。论文列出了数据集的详细组成。经过数据过滤，论文去除了 1,842 个非固件文件，最终获得了 13 个供应商的 34,136 个有效固件映像，其中包括 11,086 个可公开访问的固件映像和 23,050 个来自 TSmart 的私有固件镜像。论文的数据集包括 35 种已知的物联网设备和部分未知的物联网设备。 2,694 (7.9%) 个固件映像用于相机，7,293 (21.3%) 个固件映像属于路由器，1,191 (3.5%) 个固件映像部署在交换机上，23,050 (67.5%) 个固件映像 TSmart 已装备智能家居，未知的有 255 个（0.7%）。除了上面提到的供应商和设备之外，论文的数据集还涵盖了多种指令集，其中 ARM（23.9%）占据多数，MIPS 紧随其后（4.9%）。SquashFS、CramFS 和 JFFS2 是数据集中包含的三种流行文件系统。根据论文的进一步分析，大多数未知文件系统实际上都属于上述三个文件系统。 供应商在固件中定制了上述文件系统，这也改变了用于识别的原始文件系统的幻数。 此外，12,342 个 (36.2%) 固件映像是基于 Linux 的，21,794 个 (63.8%) 固件映像是非基于 Linux 的。

3.2 评估

数据集构建：论文首先构建四个数据集，数据集 I 用于训练定制的 Gemini 并评估模型的准确性； 数据集 II 用于选择 FIRMSEC 的阈值；数据集 III 用于评估 FIRMSEC 检测固件中 TPC 级和版本级 TPC 的准确性；数据集 IV 用于比较 FIRMSEC 与业界三个商业系统的性能；数据集 V 用于评估FIRMSEC识别固件中TPC引起的漏洞的精度。

数据集 I 包括论文从 TPC 数据库中的 1,192 个 TPC 中提取的 ACFG。 数据集 II 和数据集 III 具有固件到 TPC 使用情况的标记映射，以获取真实数据。 根据前期调研，以前的作品中没有这样的数据集。 鉴于很难知道商业固件中使用的具体 TPC，我们最终使用 Tomato-shibby 和 OpenWrt 固件映像来构建论文的数据集，因为它们有源代码，并且在配置文件中清楚地表明了所采用的 TPC 的确切版本。 对于数据集 II，我们从数据集中随机收集 200 个 Tomato-shibby 固件映像，其中包括 17, 918 个 TPC 版本对（73 个不同的 TPC，211 个不同版本）。 对于数据集 III，我们从数据集中随机选择 300 个 OpenWrt 固件映像，其中包括 19,645 个 TPC 版本对（92 个不同的 TPC，194 个不同版本）。 论文使用两个数据集分别进行阈值选择和评估以避免偏差。 对于数据集 IV，论文随机选择 24 个固件映像，其中包括 19 个基于 Linux 的固件映像和 5 个单片固件映像。 对于数据集 V，我们随机选择 35 个固件映像，其中有 FIRMSEC 识别的 382 个漏洞。

模型精确度：论文按照 6:2:2 的比例将数据集 I 分为三个子集，分别用于训练、验证和测试。 论文根据原始 Gemini 的训练流程对定制的 Gemini 进行 100 个 epoch 的训练。 保存在 100 个 epoch 期间验证集上实现最佳 AUC（曲线下面积）的模型。 论文最终在测试集上测试了模型，AUC 为 0.953。 论文也用同样的过程重新训练原始的 Gemini，AUC 只有 0.912。

阈值选择：论文的最终结果是句法特征和CFG特征匹配的结果的并集。当各自的方法达到最佳性能时，论文不直接使用阈值，因为此时并集结果可能无法达到最佳。论文将三个阈值作为一个整体，并利用版本级别的真阳性率（TPR）作为衡量标准来选择合适的阈值。论文将三个阈值及其对应的 TPR 组合为一个四维向量：[α, β, γ, TPR]。每个阈值的范围是 0.01 到 1.00。我们选择 TPR 达到最高时的阈值。

评估结果：论文使用两个评估指标来评估 FIRMSEC 在数据集 III 上 TPC 级别和版本级别的检测准确性，精度和召回率。 误报代表论文错误识别的 TPC 和版本，漏报代表论文没有找到的 TPC 和版本。FIRMSEC 在 TPC 级别上实现了 92.09% 的准确率、95.24% 的召回率，在版本级别上实现了 91.03% 的准确率、92.26% 的召回率。

论文发现并集结果的精度与各自方法非常接近，但召回率要高得多。 论文探讨了联合结果比单独方法具有更好性能的原因。 首先，两种方法的真阳性部分不重叠，从而减少了并集结果的假阴性。 例如，基于语法的方法很难检测到具有有限语法特征（例如，没有唯一字符串文字）的TPC，但可以通过CFG特征来识别它们。 其次，它们的误报有重叠部分，不会大幅增加并集结果的误报。 论文进一步分析误报和漏报。 首先，误报主要由两个原因造成：（1）一些 TPC 会重复使用其他 TPC 的代码，并进行微小的更改。 在这种情况下，FIRMSEC 将报告所有匹配的 TPC。（2）不同版本之间相似度高， 同一TPC的某些版本其代码差异不大甚至没有差异。漏报主要由两个原因造成：（1）固件中使用的 TPC 不常见， FIRMSEC 无法检测到未包含在我们数据库中的 TPC。 （2）特征不足，某些固件仅使用部分构建的 TPC，其可用于识别的功能有限。

与学术著作的比较分析：论文将 FIRMSEC 与三种最先进的技术进行比较：Gemini、BAT 以及 OSSSPolice。 最初的 Gemini 使用 8 个块级属性来进行代码相似度比较。 论文使用基于 CFG 权重的方法来增强它来检测固件中的 TPC。 BAT 利用字符串文字来识别二进制文件中的 TPC，但无法检测确切的版本。 OSSPolice 最初旨在检测 Android 应用程序中版本级别的开源软件使用情况。 鉴于它支持在 C/C++ 本机库中查找 TPC，我们成功地将其应用到 IoT 固件上，并将其与 FIRMSEC 进行比较。 在进行对比之前，论文根据 BAT 和 OSSPolice 的指令分别生成对应的TPC数据库。论文不报告版本级别的 BAT 结果，因为它不支持版本级别识别。 对于TPC级别的识别，FIRMSEC 远远优于其他工具。 FIRMSEC 以更高的精确度和召回率报告更多的 TPC。 对于版本级别识别，FIRMSEC 在两个指标上都优于 Gemini 和 OSSPolice。 论文进一步探讨 FIRMSEC 优于其他工具的原因。 首先，Gemini 忽略了函数级属性，这些属性提供了有关 CFG 结构的许多有用信息。 其次，BAT主要利用字符串文字来识别TPC。 它使用直接特征匹配来比较从TPC和固件中提取的字符串文字，这导致精度和召回率较低。 最后，OSSPolice采用分层匹配策略，依赖于TPC的包结构来识别TPC。 然而，同一TPC在不同版本中的封装结构可以很容易地改变。 此外，其特征提取工具在物联网固件上表现不佳，因为它没有针对固件进行优化。

与行业系统对比分析：我们将 FIRMSEC 与三个行业系统进行比较，binare、360 FirmwareTotal  以及阿里巴巴 FSS。 binare 实际上是根据最先进的工作开发的，该工作中提出的原型系统不支持查找 TPC 和固件中相应的漏洞，而其工业版本支持此功能。 360 和阿里巴巴是全球两家知名公司，在物联网安全方面都有丰富的经验。 他们是少数提供可公开访问的系统来检测固件中 TPC 引起的漏洞的公司。 binare 和 FirmwareTotal 提供免费试用，FSS 每次使用费用为 300 美元。

由于两个原因，论文不对数据集 III 进行与行业系统的比较分析。 首先，两个行业制度限制了免费试用的数量。 论文不允许在数百个固件映像上执行它们。 其次，在论文的分析过程中，我们发现有两个行业系统直接分析 OpenWrt 固件中的配置文件来识别 TPC，阻碍了实验的公平性。 因此，我们最终对数据集 IV 进行了对比分析，包括 24 个闭源固件镜像。

首先，FIRMSEC 可以分析所有测试固件镜像，并且是唯一支持分析单片固件的。 对于 19 个基于 Linux 的固件映像，binare 无法处理 1 个固件映像，FirmwareTotal 无法处理 2 个固件映像，FSS 无法分析 7 个固件映像。 其次，FIRMSEC 在每个测试用例中检测到最多的 TPC。 FIRMSEC发现的TPC已经覆盖了binare、FirmwareTotal、FSS的全部结果。论文发现，binare、FirmwareTotal 以及 FSS 的结果主要包含几种流行的 TPC，例如 BusyBox 和 OpenSSL，而 FIRMSEC 可以检测到一些不常见的 TPC，例如 libogg。 第三，与其他三个系统相比，FIRMSEC 在 19 个基于 Linux 的固件映像中的 12 个中发现了更多的 N 天漏洞。 论文总结了 FIRMSEC 在其他 7 个测试用例中检测到的漏洞少于其他系统的两个原因。 (1) binare、FirmwareTotal、FSS错误报告不属于对应固件的 N-day 漏洞。 (2) 对于一些案例，他们报告了相同 TPC 的多个版本。 例如，FSS在tl-ipc423(p).bin 中报告了两个不同版本的 OpenSSL，并根据这两个版本计算了漏洞。 论文在这 7 个测试案例中进一步去除了上述其他系统的误报，发现 FIRMSEC 在所有情况下都能比它们检测到更多的 N 天漏洞。 最后，FIRMSEC 在分析固件时花费的时间更少。 我们在配备 i7-9700K CPU、RTX 2080 GPU 和 32 GB 内存的 Ubuntu 服务器上实现 FIRMSEC。 FIRMSEC 在不到 10 秒的时间内分析每个固件映像，这在所有测试用例中都比其他系统快得多。

总的来说，我们的结果表明 FIRMSEC 的性能比学术界最先进的工具和工业界的商业工具要好得多。 FIRMSEC 在 TPC 级别和版本级别上均比 Gemini、BAT、OSSPolice 具有更高的精度和召回率。 与 binar ́ e、FirmwareTotal 和 FSS 相比，FIRMSEC 在分析固件时的成功率更高，花费的时间更少，并且可以检测更多的 TPC，以及识别更多的漏洞。

3.3 漏洞识别精度评估

实验设置：在论文的评估中，论文采用三种方法来验证漏洞，源代码审计、静态分析、基于仿真的动态分析。 我们选择这些方法有三个原因。 首先，OpenWrt 的部分固件有源代码。 因此，论文可以检查其源代码来验证漏洞。 其次，由于大量固件镜像没有源代码，因此静态分析是验证这种情况下漏洞的可接受方法。 第三，静态分析可能无法检查一些未公开相应不安全代码的漏洞。 在这种情况下，可以采用动态分析来弥补静态分析的缺点。 论文这里使用 FIRMADYNE 对固件进行动态分析。 FIRMADYNE 支持在桌面上模拟基于 Linux 的固件。 它克服了模拟固件的一般挑战，例如特定于硬件的外设的存在。 论文的评估方法可以确认结果的真阳性和假阳性，但很难区分假阴性，因为我们没有固件中所有与 TPC 相关的漏洞的基本事实。

考虑到我们的大规模数据集，评估 FIRMSEC 在所有固件映像上的精度是不现实的。 因此，论文根据两个标准来选择一些有代表性的固件：（1）每个识别出的固件漏洞都有实用的验证方法，无论是通过源代码审计、静态分析还是动态分析； （2）包括尽可能多的供应商和类别。 论文最终对数据集V进行评估，包括 35 个随机选择的固件映像，其中 FIRMSEC 识别出总共 382 个漏洞。

漏洞验证：首先，由于 OpenWrt 的5个固件镜像都有源代码，论文采用源代码审计来验证漏洞。 其次，论文结合静态分析和动态分析来评估剩余的 30 个固件映像。 论文手动审核其中 335 个漏洞的披露报告，以确定每个漏洞合适的验证方法。 然后，论文根据相应的验证方法将这335个漏洞分为两部分。 第一部分中的192个漏洞可以通过静态分析来验证，第二部分中的143个漏洞可以通过动态分析来验证。

综上所述，论文最终确认了 382 个漏洞中的 368 个确实存在。 论文未能验证四个固件映像中的 14 个漏洞，其中一个来自 TP-Link，另外三个来自 TSmart。 总体而言，FIRMSEC 在识别固件中由 TPC 引起的漏洞方面平均达到 96.3% 的准确率。