嵌入式设备和固件中的自动漏洞检测：综述与分层分类法

阿卜杜拉·卡塞姆，帕里亚·希拉尼，穆拉德·德巴比，和王凌宇，康考迪亚大学， 加拿大伯纳德·勒贝尔，泰雷兹加拿大公司，加拿大巴西勒·L·阿格巴，魁北克水电研 究所，加拿大

在物联网(IoT)时代，支持软件的互联设备至关重要。嵌入式系统经常被用于安全与隐私敏感的应用 程序中。然而，底层软件（即固件）常常存在各种安全漏洞，主要原因是其系统过时或重复使用已 有的易受攻击的库；这一点从针对嵌入式系统的攻击数量惊人增长中可见一斑。因此，为了保护这 些嵌入式系统，在大量嵌入式设备及其固件中检测漏洞的存在显得尤为关键。为此，已有多种方法 用于识别并触发已部署的嵌入式系统固件中的潜在漏洞。在本综述中，我们全面回顾了当前最先进 的提案，这些提案通过采用多种分析技术（包括静态分析、动态分析、符号执行和混合方法）来检 测嵌入式系统及固件镜像中的漏洞。此外，我们对所调研的方法进行了定量与定性比较。同时，我 们基于这些方法的应用、文献中使用的特征以及分析类型构建了分类法。最后，我们指出了该研究 领域尚未解决的挑战，并讨论了可能的未来研究方向。

CCS概念： •安全与隐私→漏洞管理；嵌入式系统安全；软件逆向工程； •计算机系统结构→
固件； •计算方法→机器学习；

附加关键词和短语：二进制代码分析，嵌入式设备安全，固件分析，物联网(IoT)，漏洞检测

1 引言

信息技术发展迅速，其底层软件在能源行业、化工行业、核工业和交通系统等各种领域和 关键基础设施中发挥着至关重要的作用。由于这些领域的广泛采用，软件漏洞带来的新兴 威胁正成为这些关键基础设施最令人担忧的安全问题之一。嵌入式设备上频繁发生的近期 攻击事件证实了这一安全隐忧。例如，Mirai僵尸网络攻陷了数百万个物联网设备，并协 调它们对多个域名系统（DNS）服务器发起分布式拒绝服务（DDoS）攻击，导致全球数 十万个网站无法访问[10]。Reaper恶意软件被认为是Mirai恶意软件的扩展版本，于 2016年发布，其目标是利用物联网设备特有的漏洞，而不仅仅局限于凭据攻击[71]。

2014年，BlackEnergy[114]APT通过控制操作站引发了一次停电事件。类似的威胁也在 其他国家得到验证，例如，入侵者控制50多个发电机组，可能影响9300万美国居民的电力 供应[143]。这些现实世界攻击表明，物联网设备和嵌入式系统在关键基础设施中遭受攻击 可能带来严重后果。

软件漏洞被认为是导致这些攻击的主要原因之一，且新漏洞频繁被发现。例如， 2017年报告的漏洞总数相比2016年已翻倍以上，增幅达120%[58]。当这些漏洞出现在被 广泛集成到各类软件项目、嵌入式系统和固件镜像中的流行库中时，其危险性更大。最近， 多篇出版物强调了进行固件镜像评估的必要性[57, 63, 132, 135]。此外，崔等人[38]指出， 许多固件更新多年来一直包含第三方库中的已知漏洞。他们还表明，80.4%的厂商发布的 固件存在已知漏洞。考虑到嵌入式系统的破坏性影响可能非常严重，因为它们控制着关键 系统，因此攻击此类设备可能导致公共系统的大规模瘫痪以及全国范围甚至全球范围内的 严重安全与安全风险。例如，FoscamIP摄像头被报告存在18个零日漏洞，如不安全的默 认凭据、命令注入和基于栈的缓冲区溢出[59]。

频繁发现软件漏洞主要可能归因于以下任一原因：首先，许多软件设计者使用过时的 系统架构[79],，因此他们的系统更容易受到更多攻击。此外，应用程序可能是通过重用易 受攻击的库而开发的。这些被重用的库很少被分析是否存在漏洞，也很少被更新或打补丁。 其次，嵌入式系统的互联网连接、集成和平台兼容性要求使其更有可能暴露于攻击和滥用 之中。最后，传统的安全工具和现有解决方案（如杀毒软件或防火墙）无法被采用，因为 这些设备在计算能力和可用内存方面资源受限。因此，攻击者利用这些限制，构建专门针 对底层嵌入式系统和物联网设备的恶意软件。

软件漏洞检测可以在源代码和二进制代码上进行。后一类方法（例如参考文献 [68, 80, 83, 87, 151]）依赖源代码进行漏洞识别。然而，这些方法并不总是实用的，因为大 多数商业软件产品并非开源。因此，二进制代码分析变得绝对必要。同时，手动二进制分 析是一项艰巨、容易出错且具有挑战性的任务，特别是面对大量嵌入式设备固件镜像时。 因此，自动且可扩展的漏洞检测变得至关重要；具体而言，能够在合理时间内对大量固件 镜像和二进制文件扫描已知或零日漏洞，并生成安全评估报告，是高度可取的。

与普通二进制分析相比，嵌入式系统上的二进制分析和固件镜像分析更具挑战性，因 为除了普通二进制分析的相关挑战外，嵌入式系统的分析还面临特定的难题。首先，嵌入 式系统针对特定硬件定制，因此在缺乏标准以及存在多种CPU架构的情况下，固件分析变 得更加困难。其次，嵌入式系统为特定任务定制，并且为了最小化成本和功耗而资源受限。 因此，嵌入式系统在运行时存在特定的效率和可扩展性问题，因为在嵌入式系统中使用多 处理或虚拟化等并行技术来加速测试活动相比桌面环境是不实用的。第三，嵌入式系统中 的故障检测能力有限。由于有限的I/O能力、计算能力和成本限制，内存损坏攻击在嵌入式 系统中较难被观察到。只有某些导致内存损坏的特定攻击（例如格式化字符串和基于栈的 溢出）更容易被检测到，因为它们会引起设备崩溃。最后，涉及固件获取、解包和二进制 识别的固件逆向工程是嵌入式系统特有的挑战。

尽管已有一些研究致力于探讨二进制代码中漏洞检测的最先进的方法，但此前尚无综 述专注于嵌入式设备固件及二进制文件中自动检测漏洞的相关文献。Brooks[23]研究了 DARPA网络大挑战（CGC）中提出的两个优胜系统在漏洞检测与利用生成方面的异同， 并为网络推理系统(CRSs)的评估提供了数据集和标准平台。Ji等人[43],研究了现有的用 于漏洞检测、利用与修补的网络推理系统。另一项工作[82]综述了在源代码级别应用机器 学习技术的软件漏洞分析。总之，此前没有综述聚焦于嵌入式设备中固件与二进制文件的 漏洞检测机制，以识别其优势与劣势，并最终提出该领域的重要开放性研究问题。

在本综述中，我们对针对嵌入式设备和固件镜像中漏洞的自动检测所提出的二进制分 析方法进行了全面研究。我们系统地比较了69项与嵌入式系统和固件分析相关的独立工作， 并审查了该领域约200篇论文，包括自2004年1月至2020年1月期间网络安全和软件工程领 域主要会议和期刊中的相关出版物。前者包括ACM计算机与通信安全会议(CCS)、IEEE安 全与隐私研讨会(S&P)、网络与分布式系统安全研讨会(NDSS)、USENIX安全研讨会 (USEC)、攻击、入侵与防御研究研讨会(RAID)、ACM亚洲计算机与通信安全会议 (ASIACCS)，以及入侵与恶意软件检测及漏洞评估会议(DIMVA)。后者包括ACM软件工 程基础国际研讨会(FSE)、IEEE/ACM自动化软件工程国际会议(ASE)、国际软件工程会议 (ICSE)和IEEE软件工程汇刊(TSE)。

我们首先列举了用于自动化漏洞检测的通用和嵌入式特定的二进制分析挑战与技术， 然后根据其应用领域对这些方法进行分类（第2节）。此外，我们还考察了若干现有的动态 分析与符号执行工作以及静态解决方案，以更深入地了解这些提出的技术及其优势与局限 性（第3和4节）。我们基于现有嵌入式系统方法中采用的三类分析——动态分析、符号执 行和静态解决方案，构建了一种分类法（第3节）。我们还研究并分类了当前在嵌入式系统 二进制分析中所使用的特征（第4节）。此外，我们在相应章节中根据不同标准（即方法论、 实现和评估）对这些方法进行了比较。最后，我们讨论了从本次综述中获得的经验教训， 并提出了未来研究方向（第5节）。

我们观察到，大多数现有研究都是针对特定应用程序和实验设置进行评估的，因此它 们无法直接比较。我们的观察表明，需要一个通用平台（例如DARPACGC）和特定数据 集，以便更方便地比较结果，并对比其他能力（如可扩展性）。此外，我们注意到混合方 法（即结合不同分析技术，例如静态和动态分析）可能更适合嵌入式系统中的漏洞检测。

本文的主要贡献在于：
•我们对固件镜像和嵌入式设备中的动态分析、符号执行以及静态漏洞检测方法进行了全面研究。
我们基于特征和所采用的方法提出了分类法。
我们对所审查的方法进行了定量与定性比较。
我们对已审查的方法进行了安全差距分析，并提出了修补某些已识别间隙的建议。

本综述的其余部分结构如下：第2节介绍嵌入式系统二进制分析的背景。第3节和第4 节分别综述了嵌入式系统的现有动态分析、符号执行和静态方法。第5节重点阐述经验教 训与未来方向。第6节总结全文。

2 预备知识

在本节中，我们总结了针对嵌入式设备固件镜像进行二进制分析的主要挑战。此外，我们 简要介绍了该领域的主要分析方法，并将其与已识别的挑战相关联。然后，我们提出了一 个应用于领域的分类法，最后提供了嵌入式系统的分类。

2.1 挑战

接下来，我们将概述二进制分析过程面临的一般性挑战，并讨论其对嵌入式设备中固件镜像分 析的影响。

• C1-信息丢失：在编译过程中，源代码中存在的一些信息会丢失，这些信息包括语 法特征（如变量名和注释）、缓冲区的特征以及数据结构大小。因此，与源代码分析 相比，对二进制代码的分析将变得更加困难和复杂。此外，在剥离的二进制文件中， 由于缺少调试信息（例如标识符名称），二进制分析任务将更具挑战性。

• C2-编译器影响：随着现代编译器和运行时库的出现，二进制代码分析正变得极具挑战性。大 多数编译器都会应用性能或
内存优化，这会导致不同配置下的二进制表示存在显著差异；例如，寄存器、调用 约定、控制流图以及算术运算可能有所不同。如果使用了不同的编译器或编译设置， 甚至源代码有轻微修改时，这些差异会更加显著。

• C3-二进制反汇编：二进制反汇编仍然是一项具有挑战性的任务，主要原因如下： —入口点和函数边界发现：反汇编器通常使用符号表来识别函数边界并构建控制流图。 然而，当符号表不准确或不可用时，寻找函数边界将变得具有挑战性[157]。此外， 在某些情况下，例如二进制blob固件[135],中，入口点和基地址未知。而且，一些函 数可能具有多个入口点[16],，这些都需要被识别。

—代码发现：为了对齐指令并提高缓存效率，编译器可能会在函数之间或函数内部 插入填充字节。因此，反汇编器可能难以区分填充字节和代码字节，因为填充字节 通常会被转换为有效指令[16]。此外，某些函数可能不是连续的，其间可能存在包 含数据、跳转表或其他函数指令的间隙[16],，这会影响二进制分析方法的准确性。 此外，由于无法找到全部代码、识别非返回函数以及处理依赖于计算值的间接跳转， 控制流图的提取也可能无法准确进行。

—代码变换：合法/良性程序的作者可能出于不同原因保护其程序，例如防止知识产 权侵权或防止其程序被重新打包并作为恶意软件重新分发[1, 149]。类似地，恶意软 件作者也会对其恶意代码应用一些技术以逃避分析，使其更难以处理。混淆、加密 和打包[35, 96, 156],技术[90, 141]即用于此目的，使得二进制分析更加困难和复杂。

• C4-函数内联：出于优化目的，小型函数可能会被内联到其调用者函数中。由于内联 函数与函数其他部分之间缺乏明确界限，使得识别内联函数的任务极具挑战性。当内 联函数的汇编指令因指令对齐和流水线而变得不连续时，该任务变得更加困难。

• C5-硬件架构：软件程序可以在不同的CPU架构上交叉编译或部署，而不同架构之 间的指令集、调用约定、寄存器集、函数偏移以及内存访问策略各不相同[123]。因 此，对同一源代码在不同CPU架构下编译生成的二进制文件进行分析更具挑战性。

• C6-准确性：对于任何漏洞检测技术而言，实现高准确性都是一项关键且非平凡的任 务。例如，在静态分析代码时，通常很难获得较低的误报率[134]。

• C7-结果验证：对于某些技术而言，由于无法充分获取已识别漏洞的相关信息（例如 如何触发），所得到的漏洞检测结果难以被验证。因此，这些技术需要人工努力来验 证结果，容易出错且效率低下。

• C8-效率：许多现有方法计算成本高，这表明需要为任何二进制代码提供高效的漏洞识别技术。

• C9-可扩展性：由于桌面应用程序、物联网设备、嵌入式系统及其之间互联性的急 剧增长，已部署软件的数量正呈指数级增加。因此，大规模的漏洞检测是绝对必要的。

• C10-测试用例生成：一些方法需要与目标应用兼容的初始种子输入才能开始分析。 当目标应用提供了所需的输入文件格式时，测试用例很容易生成。然而，当未提供配 置输入时，测试用例生成就成为一项具有挑战性的任务；因为每个程序都需要提前准 备特定的测试用例，这需要专业知识和额外的工作量。

嵌入式系统特有的挑战。除了C5和C9中详细说明的问题外，嵌入式系统还存在这些挑 战的其他方面，以及以下所述的两个更具体的限制（C11和C12）。

• C5-硬件架构：具体而言，嵌入式系统针对特定任务进行定制，因此其固件也专为运 行在特定硬件上而设计。由于缺乏标准，架构的广泛多样性进一步增加了固件分析的 难度。因此，针对特定CPU架构的解决方案难以轻易推广。

• C9-可扩展性：与普通二进制文件相比，嵌入式系统面临特定的可扩展性问题。具体 而言，在目标设备上或模拟环境中对嵌入式固件进行运行时测试非常缓慢。[109]尽管 在桌面环境中可以使用多处理或虚拟化等并行技术来加速测试活动；但在嵌入式系统 中这并不实用，因为需要访问一批相似的物理设备，而由于财务成本或有限资源（如 电源和空间）的限制，这种做法难以实现。此外，测试嵌入式系统需要频繁重启，以 确保每个新测试用例都处于干净状态。

• C11-故障检测：尽管一些动态方法（例如模糊测试，详见第2.2.2节）在传统计算环 境（如桌面和服务器）中被使用，但由于固件组件上缺少故障检测实现，这些方法在 嵌入式系统上存在局限性。在传统计算环境中，操作系统实现了保护机制（例如栈金 丝雀、故障分段、ASLR（地址空间布局随机化）、堆强化和sanitizer）以防止内存 损坏。由于嵌入式系统具有有限的I/O能力、计算能力和成本限制，通常不会实现此类 保护措施。这使得内存损坏攻击更难以被察觉且风险更高，因为越界内存损坏可能会 写入内存映射外设寄存器（例如闪存擦除= 1），或者如果设备嵌入在运营技术（OT） 中，则后果可能更严重，例如触发车辆的制动执行器。在嵌入式系统中，静默内存损 坏是常态而非例外，与传统的台式机相比尤其如此。[109]在嵌入式领域中唯一可观察 到的攻击是与格式化字符串和基于栈的缓冲区溢出漏洞相关的攻击，因为它们会导致 内存损坏，从而通常引起设备崩溃。

• C12-固件逆向工程：固件逆向工程可能是一项耗时且具有挑战性的任务，需要相关 领域的专业知识。整个过程包括以下步骤： —固件获取：嵌入式系统厂商倾向于避免发布其固件，以保护其知识产权或限制对 固件的访问。因此，可能需要通过不同方式直接从设备芯片内存中提取或转储固件， 例如使用EEPROM编程器、在代码上传过程中进行总线监控以及原理图提取[142]。 然而，硬件锁和组件干扰可能会使此任务变得具有挑战性。这 可以通过物理修改原始硬件或使用探针操纵电路板来解决。

—固件解包与提取：一些厂商使用专有打包工具和文件格式打包其固件，或使用私钥加 密。在实践中，可以利用不同的解包工具，例如Binwalk[74], BAT[76],和FRAK[38] 来提取固件。然而，执行此类任务的成功率有限，因此并非所有嵌入式设备的固件都能 被分析（例如，科斯滕等人[28]从收集的23,035个固件镜像中成功解包了8,617个）。

—固件与二进制识别：一旦提取出固件，就需要进行过滤以获取所有相关信息。这 可能包括二进制文件、配置文件、嵌入式文件以及固件本身。为此，使用不同的工 具（如signsrch[78], file[50],和Binwalk）执行文件签名匹配[74]。存在一些没有 底层操作系统（OS）的固件类型，它们仅由一个直接在硬件上运行的二进制文件组 成。在某些情况下，没有操作系统和库的抽象；而在其他情况下，固件镜像并非标 准格式且未提供文档。因此，初始化运行时环境并加载二进制文件更具挑战性[135]。

2.2 二进制分析方法

二进制分析可以通过静态检查代码、动态执行或提供一些符号值来完成，分别称为静态分 析、动态分析，和符号执行。下文将回顾这些方法及其在嵌入式系统固件镜像分析中的应 用。

2.2.1 静态分析

静态分析通过检查给定二进制程序的代码而非执行它来进行分析。 它通常被设计用于对整个程序进行推理，并具备探索给定代码所有潜在执行路径的能力。 静态分析技术通常受限于C1、C2、C3、C4、C5、C6、C7、C8和C9等局限性。例如，它 会识别出非漏洞问题，导致较高的误报率[134],或者无法找到所有漏洞（例如运行时漏 洞），从而产生更多漏报。此外，由于未提供触发已识别漏洞所需的信息，漏洞检测结果 需要手动验证。与动态分析方法相比，静态分析方法具有可扩展性；然而，由于其自身存 在局限性，研究人员最近倾向于将这两种方法结合起来。

2.2.2 动态分析

动态分析是指在程序运行时检查和监控其行为的过程。现有的动态 分析方法可以分为以下几类：

•模糊测试：模糊测试通过随机生成畸形输入或基于适用于目标软件的特定规则反复生 成输入来执行，这些输入会被错误地处理，从而导致程序触发非预期行为，有助于识 别漏洞的存在。通常，模糊测试方法受限于C10限制。将模糊测试应用于嵌入式系统比 传统计算环境更具挑战性。例如，由于缺乏故障检测技术（C11），内存破坏检测更加 受限。此外，由于模糊测试器无法利用源代码推导内存语义，检测故障状态变得更加 困难。因此，在模糊测试活动中，观察嵌入式系统的故障状态是最后的手段。已有研 究[109]表明活性检查不足以捕捉各种 在源代码缺失且内存损坏的情况下，漏洞类型的识别面临挑战。此外，嵌入式平台 还面临额外的困难：这些设备可能因某些命令而触发硬重置和设备擦除，一旦发生 这种情况，恢复可能无法实现，而在普通的二进制世界中，若出现最坏情况，可以 从虚拟机恢复快照并重新启动新的取证过程。

•插桩：插桩是一种在执行过程中收集和插入执行反馈（例如系统调用、运行时信息和 崩溃测试功能）以分析应用程序行为的技术。如果源代码可用，插桩信息可以在编译 时获取，也可以在运行时获取。由于源代码很少可用，因此可以采用运行时插桩来重 写二进制文件并注入插桩信息。然而，目前运行时插桩仅适用于具有操作系统的嵌入 式系统，并且需与当前仿真环境兼容。这些方法受到C5、C10和C12限制的影响。

•动态污点分析（DTA）：动态污点分析（DTA）是一种用于检查应用程序漏洞和漏洞的程 序分析技术。它主要识别程序输入与其逻辑之间的依赖关系。因此，DTA可以检测由于缺 少对关键输入的清理检查而导致的输入验证漏洞。DTA还可用于分析二进制代码中的信息 流，并辅助自动程序测试用例生成。然而，它受到C9和C12限制的影响。

•基于仿真的技术：基于仿真的技术通过为特定平台构建部分/完全仿真，并在模拟环 境中利用强大且先进的动态分析技术来运行软件。由于厂商限制了文档获取和开发环 境的搭建，部分或完整的嵌入式系统仿真具有挑战性。该领域内的主要研究存在以下 不足：CPU架构支持有限、不支持通用中断处理、外设建模支持数量有限[154],且运 行速度非常慢[109]。因此，仿真方法面临C5、C9和C12挑战。

总之，动态分析技术可以克服静态分析方法的一些局限性（例如C2、C3和C7）。然 而，动态分析技术存在C5、C8、C9、C10、C11和C12等常见局限性。

2.2.3 符号执行

符号执行技术旨在通过生成满足所需路径约束的输入来达到特定的程 序状态。与动态分析中使用具体值不同，符号执行采用符号值作为输入。因此，相比仅探 索与给定具体输入相关的一条路径的具体执行，符号执行能够探索所有潜在路径。然而， 符号执行存在依赖计算成本高的求解器（例如参考文献[17]）以及路径爆炸问题（C8和 C9）。直接在固件镜像上应用符号执行面临以下挑战：（i）符号分析需要基于内存布局和 内存映射硬件位置假设的自定义配置；（ii）固件通过I/O外设频繁与外部环境交互，这 些行为对分析人员未知且难以建模，此外模拟这些行为也是一项艰巨任务，因为某些相关 信息仅厂商掌握；（iii）固件的事件驱动编程模型经常导致无限循环，因此使用启发式方 法避免因中断引发的可能无限循环会降低搜索空间覆盖率，而跟踪所有可能路径则会导致 状态空间爆炸；以及（iv）符号执行还面临与模糊测试类似的问题（C10和C11），如前 所述[109]。在符号执行过程中，状态探索将持续进行，直到检测到崩溃或满足终止条件为 止，否则 执行继续。因此，如果未检测到损坏，符号执行将花费时间在无用的状态上。因此，符号执行 也存在C10和C11限制。

2.3 应用领域分类

在本节中，我们根据现有漏洞检测工作的应用领域对其进行分类。所提出的分类包括三个 嵌入式系统、固件和普通二进制文件领域，如图1所示。嵌入式系统是硬件与足够软件的结 合，以实现所需功能，而固件则是嵌入在硬件中的代码。因此，我们将仅专注于固件分析 的方法归入“固件”类别，而那些还考虑与硬件交互的方法则归类为“嵌入式系统”。我 们还根据这些方法与主题的相关性（即嵌入式设备和固件中的漏洞检测）、发表年份（ 2004年1月至2020年1月）以及发表场所（例如顶级网络安全和软件工程会议及期刊），提 供了这些方法在所选文献中的分布情况，如第1节所述。如图所示，37%的研究工作应用于 嵌入式系统，21%的研究工作应用于固件镜像，这凸显了提出适用于该领域的新颖解决方 案的重要性。

2.4 嵌入式设备分类

如前所述，嵌入式系统由硬件和软件组成，旨在解决特定任务，这些任务可能涉及通过传 感器和执行器与环境交互。各种设备，例如数码相机、打印机、硬盘控制器、智能手机、 汽车和智能电表，均可被视为嵌入式设备。嵌入式系统可根据不同标准进行分类，例如使 用领域、计算能力、成本和尺寸。为了对现有研究进行比较研究，我们旨在对嵌入式设备 进行分类。由于我们的重点是嵌入式系统中的漏洞检测，因此我们采用参考文献[109],中 基于操作系统类型的分类方法。与上述分类（例如计算能力）相比，这种分类可以提供更 多关于特定嵌入式设备所提供安全机制的信息。根据此分类，嵌入式设备分为三种类型， 定义如下：

• I型：基于通用操作系统的。它通常代表使用经过修改的轻量级Linux操作系统来处 理复杂逻辑的嵌入式设备，例如接入点和路由器。

• II型：基于嵌入式操作系统。II型操作系统专为计算资源较低的嵌入式设备设计，例 如中央处理器、内存或功耗受限的设备。II型操作系统可能没有像III型操作系统中所 具备的内存管理单元（MMU），但应用程序与内核之间的逻辑隔离仍然存在。此类操 作系统通常用于单用途嵌入式设备，例如LTE调制解调器或DVD播放器。

• III型：无操作系统抽象的嵌入式设备。III型设备没有操作系统，而是使用单一的控 制循环和中断处理程序来响应来自外部世界的时间。

3 动态分析与符号执行

在本节中，我们对应用于嵌入式系统的动态分析与符号执行方法进行了详细回顾。我们的 回顾围绕图2所示的分类法展开。我们进一步总结了已应用于嵌入式系统环境中的普通二 进制文件的传统方法。此外，我们对现有应用于嵌入式系统的各种方法以及可能被用于嵌入式系统的传统方法进行了比较研究。

3.1 嵌入式系统中的动态分析

在本节中，我们回顾了在嵌入式系统上采用重新托管和模糊测试的动态分析方法。我们还 简要介绍了可用于嵌入式系统的普通二进制文件上的现有方法。

3.1.1 重新托管

与常规平台相比，嵌入式系统面临特定的可扩展性问题。在传统计算 环境中，可以使用多处理或虚拟化等并行技术来加速测试活动。然而，在嵌入式系统中这 并不实用，因为需要访问一批相似的物理设备，而这由于财务成本或有限资源（如电源和 空间）而难以实现。此外，测试嵌入式系统需要频繁重启，以确保每个新测试用例都处于 干净状态。为解决这些问题，提出了重新托管技术，即将固件提取并迁移到不同于原始环 境的其他环境中执行。在本节中，我们概述了通过重新托管实现部分/完全仿真以及 Web界面提取的现有研究成果。

部分仿真 。在虚拟且可扩展的环境中分析嵌入式系统是一项具有挑战性的任务，因为运行 固件通常需要访问其相关的外设，而这些外设可能并不存在。此外，由于缺乏文档或建模 复杂性，对外设进行仿真也十分困难。为解决这些问题，提出了部分仿真方法，即提取固 件并对其进行修改，使其可在模拟器内执行，同时转发命令 根据需要连接到外设。部分仿真提供了对目标嵌入式系统及其所有外设进行完全仿真的印 象。然而，由于频繁与连接的外设（C9）交互，其可扩展性受到影响。此外，在多个设备 上同时进行多项测试时，扩展性可能存在问题。

重新托管的嵌入式系统固件通常需要访问其外设以完成测试。因此，为了促进在重新 托管的嵌入式设备上应用动态二进制分析方法，卡默斯特特等人[89]提出了一种名为 PROSPECT的部分模拟器。PROSPECT实现了一个代理，用于将QEMU虚拟机内运行的 固件发起的每个外设硬件访问通过隧道传输到被测嵌入式设备。1[54]为了评估该方案，通 过在搭建的环境上运行商用火灾报警系统对PROSPECT进行了评估，然后使用捕获的网络 流量数据包原始流进行广泛的基于变异的模糊测试。因此，无需事先提供网络协议规范。 模糊测试通过每次随机频繁修改一个字节来执行。结果，在目标设备上发现了一个零日漏 洞。然而，PROSPECT无法应用于没有网络连接接口的设备。

类似于PROSPECT[89]但更具可扩展性，提出了一种名为Avatar的动态分析框架， 用于将实际硬件与通用处理器模拟器集成。首先，Avatar从目标设备中提取固件镜像，然 后在提取的固件中注入软件代理。因此，它可以在模拟器内部运行提取的指令，同时拦截 所有I/O操作并将其转发到物理设备。Avatar在三个安全场景中进行了评估：逆向工程、 后门检测以及在三种不同设备（GSM设备、硬盘和无线传感器节点）上的漏洞发现。然而， 该框架仅在基于ARM的嵌入式系统上进行了评估，要适配多种CPU架构还需更多努力。

除了对嵌入式系统进行部分仿真以及协调其与外设的执行外，Avatar2[108]（avatar的后 续工作）还可以协调与其他物理设备、调试器和流行的二进制分析框架（如angr3[136]（见第 3.3节））、QEMU、PANDA4[125],和OpenOCD的交互[53]。目前，Avatar2支持x86、 x86‐64和ARM硬件架构，然而，其模块化特性使其能够适应支持其他架构，甚至可以实现中 间表示。

由于仿真过程较慢，通用仿真解决方案不适用于需要近实时响应的嵌入式设备。为解 决此问题，提出了一种名为SURROGATES的部分模拟器，用于任意基于ARM的嵌入式系 统，以促进高级动态分析。SURROGATES能够处理[94]时钟变化、直接内存访问和中断， 并可实现嵌入式设备的近实时仿真。SURROGATES利用定制的FPGA低延迟硬件将嵌入式 系统与主机的PCIExpress总线连接，使其比avatar[154]更快，并更适合测试对时间敏感 且复杂的系统，如医疗设备。

与上述仿真方法相比，卡默斯特特等人[88]提出了在虚拟机内运行的固件与目标嵌 入式设备之间进行程序状态近似和外围设备通信缓存的方法。首先，系统通过连接设备进 行充分训练，学习被访问外设的行为。然后，在重复测试中不再需要物理设备。由于该方 法提供了快照功能 并行化，可以采用高级动态分析。然而，作者已经表明，他们的外设缓存方法仅适用于小 型复杂固件。他们还指出，所提出的方法与符号执行类似，存在状态爆炸问题。

完全仿真 。为了以比传统计算设备更具可扩展性的方式在嵌入式设备上进行动态分析，需 要将目标嵌入式系统固件重新托管到其设备之外。这可以通过仿真或虚拟化环境实现，而 无需访问任何外设。此过程称为完全仿真，相比部分仿真更具可扩展性。此外，它不需要 目标嵌入式系统的硬件实际存在。然而，只有在目标系统的外设能够被成功仿真的情况下， 完全仿真才适用。当嵌入式系统是基于Linux的且其固件已成功提取时，完全仿真具有实 用性[37]（C12），或者当目标嵌入式系统硬件具备完整文档时也可行。完全仿真为将可 扩展的动态分析方法引入嵌入式系统领域打开了大门。

为了实现这一目标，陈等人[28]提出了一种名为FIRMADYNE的全仿真动态分析 框架5,，该框架专用于基于Linux的固件嵌入式系统。FIRMADYNE被设计为独立于物理 硬件和硬件特定外设。此外，它提供了写入非易失性内存和动态生成文件的能力。它利用 QEMU这一完整的系统模拟器，运行一个通用的插桩Linux内核，并加载从目标固件镜 像中提取的文件系统。为了评估FIRMADYNE，作者收集了一个包含23,035个固件镜像 的大型数据集，并成功从其中9,486个固件镜像中提取了文件系统。FIRMADYNE在 69个固件镜像中发现了14个未知漏洞。

为了使动态分析（例如模糊测试和符号执行）在全仿真或虚拟环境中运行的嵌入式系
统固件上更具可扩展性和适用性，古斯塔夫森等人[73]提出了PRETENDER框架，该框 架自动化了将各种嵌入式系统固件重新托管到虚拟环境中的过程。通过自动化的重新托管， 动态分析方案可以像传统的桌面计算环境一样并行执行。PRETENDER的工作方式如下： 首先，它反复运行目标固件并记录其与相关硬件的真实交互。然后，利用机器学习和模式 识别技术，基于这些记录为每个已检测到的外设构建模型。之后，所生成的模型会被集成 到一个知名的全模拟器（例如QEMU）或分析框架（例如angr[136]）中，以对其相关固 件进行可扩展的交互式精确分析。PRETENDER在三个不同平台上共六个不同的“blob” 镜像上进行了评估，每个目标均包含合成安全漏洞。此外，每个目标都通过使用朴素模糊 测试和代码覆盖率来测试，以尽可能覆盖目标固件功能。PRETENDER的目标并不是在目 标嵌入式系统中发现新的漏洞；相反，它旨在实现一种先进的动态分析方法来发现已知漏 洞。

Web接口分析 。为方便起见，嵌入式设备（如路由器和交换机）提供了一个Web界面， 用于配置或与外部环境进行交互。然而，这些Web界面容易受到各种安全威胁。Costin等 人[37]提出了一种可扩展的自动化动态分析框架，用于发现使用Web管理界面的固件中的 漏洞。该系统在评估Web界面安全性时，不受设备厂商的影响。为此，它首先提取嵌入式 Web服务器 从固件中提取PHPWeb界面，然后使用RIPS进行静态分析6[41]以发现目标嵌入式系统 PHPWeb界面中的潜在漏洞。此外，该系统在模拟环境中运行Web界面。最后，使用开 源的Web渗透测试工具Arachni7, Zed攻击代理（ZAP）8,和w3af9对正在运行的Web界 面进行测试。结果共发现并验证了225个严重漏洞。所提出的系统[37]是首个针对嵌入式 系统中PHP安全性的系统。

此外，先前提到的工作FIRMADYNE[28]收集基于Linux的固件并在QEMU模拟器中运 行它们。如果被模拟的固件具有Web访问接口，则会在本地网络上对可访问的Web界面进行 Web渗透测试，以检查是否存在众所周知的漏洞（例如，命令注入、缓冲区溢出和信息泄露）。

与上述方法不同，Bojinov等人[19]手动研究了嵌入式系统的Web界面。作者证明， 所调查的21个嵌入式系统设备均包含严重的Web漏洞，例如跨通道脚本（XCS）。XCS利 用现代嵌入式设备中包含的多种特征，例如网络附加存储（NAS）上Web界面与FTP服务 器之间的跨通道交互，或Web服务器与SIP电话服务之间的交互，从而危害嵌入式设备的 Web界面。作者成功报告了来自16家不同厂商的大约50个漏洞。

3.1.2 模糊测试

将固件重新托管到其原始环境之外存在若干挑战（C5，C9，C12）。 为了应对这些挑战，在无法实现重新托管时，仍可通过通信接口应用模糊测试方法。为此， 可通过通信接口对目标嵌入式系统进行模糊测试。模糊测试方法可分为三类：基于变异、 基于生成、和混合型。根据模糊测试方法对目标程序代码的依赖程度，这些技术可进一步 分为三类[104]：（i）黑盒模糊测试器，其生成输入种子时无需访问目标程序的内部状态。 （ii）白盒模糊测试器，通过结合输入覆盖率和目标程序的内部分析来生成输入种子。 （iii）灰盒模糊测试器（也称为基于覆盖率的模糊测试器），其根据插桩反馈对生成的输 入种子进行变异，该反馈用于监控每个输入种子所引发的代码覆盖率。灰盒模糊测试器介 于黑盒与白盒之间，旨在提高模糊测试过程的速度。此外，模糊测试器还可分为定向模糊 测试和基于覆盖率的模糊测试类别。前者的目的是在执行快速测试的同时，生成覆盖目标 程序代码和路径的测试用例；而后者的目的是尽可能广泛地覆盖目标软件/固件，以实现更 全面的测试，发现尽可能多的漏洞[98]。接下来，我们将概述已应用于嵌入式设备的这些 解决方案。

基于变异的模糊测试工具 。基于变异的模糊测试工具易于实现和使用，因此已被多种最先 进的模糊测试器所采用。在此方案中，测试用例通过随机变异技术生成，其本质是首先准 备一个初始样本或种子，然后以重复的方式对输入样本的部分/位进行随机或概率性变异。 接着，将生成的样本输入到被测程序/系统中，同时监控其行为，等待由某个变异后的输入 触发的错误或崩溃。基于变异的模糊测试工具可以以黑盒方式或基于覆盖率的方式应用。

陈等人[29]提出了一种名为IoTFuzzer的物联网模糊测试框架，用于定位内存损坏。 首先，IoTFuzzer利用与嵌入式系统相关的移动应用（这些应用用于远程控制设备）。 IoTFuzzer对目标固件的移动应用进行动态分析，以推导出命令消息的逻辑，从而识别命 令格式、发送的URL以及使用的加密方案。然后，通过数据流分析指导应用程序通过修改 已学习消息的内容来生成有意义的测试用例。生成的测试用例对目标设备固件进行模糊测 试，以发现内存损坏漏洞。这实现了无需特定协议规范的基于协议的引导式黑盒模糊测试， 即使在专有协议上也能运行。IoTFuzzer在17个真实世界的物联网设备上进行了评估，共 发现15个漏洞，其中8个此前从未被报告过。然而，IoTFuzzer无法提供漏洞的具体位置， 仅能报告触发漏洞的输入。

尽管IoTFuzzer在物联网固件模糊测试方面表现出良好效果，但在处理复杂的有状态消息 协议（例如SNMP、FTP、SSL、BGP和SMB）时可能不适用，因为这些协议对几乎每个接收 到的消息都采用严格的验证机制（例如校验和和消息长度）。因此，畸形输入会偏离当前协议 状态，从而错失发现深层漏洞的机会。为应对有状态网络协议问题，Yu等人[152]提出了 IoTHunter，该工具采用多阶段消息生成的新技术，并集成了美国模糊测试工具（AFL）[155] （本节后文将解释）、Boofuzz[20],和avatar2。除了能够对已知状态进行模糊测试外，它还可 以从给定的状态序列中探索未知状态。为了实现基于反馈的状态探索并执行覆盖率引导的灰盒 模糊测试，它会根据给定的状态序列切换到另一个协议状态。IoTHunter在来自家用路由器 MikroTik的八个真实物联网程序上进行了评估，发现了五个新漏洞。与黑盒模糊测试器 Boofuzz相比，在边覆盖、块覆盖和函数覆盖方面均取得了更好的结果。

Zheng等人[158]提出了Firm‐AFL，用于在嵌入式系统上进行灰盒模糊测试，以改进灰 盒模糊测试器（如AFL），后者由于兼容性问题无法适用于多种嵌入式设备。Firm‐AFL基于 Firmadyne构建[28],，因为与Avatar等其他模拟器相比，Firmadyne已经解决了许多硬件 兼容性问题[154]。当不需要系统模式仿真时，Firm‐AFL还通过在用户模式而非系统模式下对 目标固件程序进行模糊测试，解决了全仿真环境中模糊测试吞吐量的问题。

Alimi等人[3]提出了一种基于变异的模糊测试方法，使用遗传算法生成测试输入， 以检测万事达卡中的漏洞或异常行为。此外，作者还提出了一种评估生成输入结果的方法， 以优化搜索过程，找出导致万事达卡规范中非预期行为的命令。作者观察到，由于高强度 的模糊测试，被测卡片可能会损坏；因此，他们在仿真环境中对目标部分进行了检查。最 终，他们成功触发了对禁止交易的接受，并能够识别导致这些非法交易的情境。

模糊测试已被用于研究现代汽车系统中的潜在漏洞。现代汽车由各种计算机化和网络 化系统控制。科舍尔等人[93]在受控实验室和实际道路上对两辆2009款汽车进行了全面调 查。他们实现了一个系统，用于嗅探和模糊测试发送到车辆CAN总线的数据包，并成功生 成数据包以执行多种功能，包括解锁车门、触发喇叭、关闭车灯等。此外，他们还展示了 能够危及驾驶员和乘客的构造攻击（例如，在行驶过程中突然解除刹车）。类似地，李等 人[97]提出了一种随机 生成可在不同CPU架构上应用的CAN数据包片段。他们观察到目标汽车的仪表盘出现明显变化。

基于生成的模糊器 。基于生成的模糊器需要目标程序的输入格式来生成测试用例。通过传 统随机变异技术生成的测试用例更有可能在程序执行的初始阶段被拒绝，因为它们不符合 所需的输入格式。语法表示技术通过将生成的输入限制为特定的数据结构或语法，解决了 随机变异技术的这一局限性，以确保能够到达程序的深层级别。

与IoTFuzzer类似，WMIFuzzer[144]在无需预定义数据模型的情况下测试正在运行 的物联网固件。WMIFuzzer对商用现成（COTS）物联网设备的Web管理界面进行模糊 测试，以实现管理或用户交互。然而，在设计此类界面时并无统一规范可循。为解决此问 题，WMIFuzzer首先通过用户界面自动化并穷举所有可能的图形用户界面，生成初始的 合法消息种子（与目标商用现成物联网设备兼容）。然后，由所用代理捕获的有效图形用 户界面将被用作种子。其次，捕获的消息被转换为抽象语法树，其中树节点包含消息字段 的内容。因此，仅对树节点进行修改，以确保生成有效的消息。最后一步是对修改后的消 息执行模糊测试。通过网络监控技术来检测是否触发了漏洞。由于并非所有被触发的漏洞 都会导致目标设备崩溃，因此修改后的消息中将注入重启命令和接口泄漏，并通过观察网 络来监控这些副作用——即修改后的消息。WMIFuzzer在七款流行的商用现成物联网设备 上进行了评估，共发现10个漏洞，其中6个为零日漏洞。WMIFuzzer的局限性在于，它仅 适用于通过HTTP或HTTPS访问Web管理界面的物联网设备。

RPFuzzer[147]引入了一个为通信协议量身定制的预定义专家数学模型，用于生成初始消 息（种子），这些种子将在后续的模糊测试活动中作为起点使用。然后，对生成的种子应用基 于变异的模糊测试器以进行测试用例生成。为了检测是否触发了漏洞，采用了三种监控方法： 发送正常数据包、监控CPU利用率以及检查系统日志。RPFuzzer在思科路由器上进行了评估， 测试通过SNMP协议运行。RPFuzzer发现了八个漏洞，其中五个为零日漏洞。

存在一些智能卡实现了Web技术，以促进与其他网络的通信。Kamel等人[86]实现 了一种基于黑盒的模糊测试工具，用于研究嵌入在智能卡中的Web服务器的潜在漏洞。作 者进一步测试了所实现的HTTP服务器是否符合设计规范。评估结果表明，某些智能卡 HTTP服务器接受了本应仅对发卡机构可用的管理命令。此外，还发现了多个不符合规范 的行为。

模糊测试也被用于测试可编程逻辑控制器和智能电表中的潜在漏洞。阿尔姆格伦等人 [4]实现了变异和随机模糊器来检测可编程逻辑控制器和智能电表。他们的实验表明，生 成的输入数据包可以发现潜在的拒绝服务漏洞，在某些情况下还可以破坏可编程逻辑控制 器执行。为了测试智能手机对GSM规范的符合性，穆利纳等人[110]和范等人[143]设计 了基于生成的模糊器，能够触发重启、内存耗尽和拒绝服务。

然而，为了评估连接到互联网的嵌入式设备的安全性，崔等人[39]进行了全球网络扫描。作者 利用Nmap 10并扫描Telnet和HTTP 端口，以检测可通过厂商提供的默认密码访问的固件设备。为期四个月的扫描结果表明， 大约有54万台设备可以使用其默认密码进行访问。类似地，Heninger等人[77]对TLS和 SSH协议进行网络扫描。作者证明，大多数嵌入式系统设备使用的RSA密钥生成算法较弱， 且熵值较低。此外，还发现一些嵌入式系统使用了可预测的DSA私钥。

普通二进制文件中的模糊测试方法 。在传统计算环境中，模糊测试技术已被更广泛地使用， 有时会结合静态与动态分析。然而，这些方法尚未应用于嵌入式系统。我们简要介绍以下 用于普通二进制文件的一些模糊测试方法： 一些研究采用随机变异来对普通二进制文件进行模糊测试。其中包括AFL[155],，它是 一种简单高效的灰盒模糊测试器，用于检测漏洞；Rebert等人[26,130],提出了数学方法， 以在有限的时间和计算资源下高效选择适用于各类模糊测试器的种子，从而提高发现的缺 陷数量；以及SYMFUZZ[26],，它能够在黑盒模糊测试中最大化缺陷发现。此外， T‐Fuzz并未通过变异输入种子来覆盖目标程序中的更多执行路径，[122]而是通过移除或禁 用完整性检查来转换目标程序，使其能够接受提供的种子，否则这些种子将无法在各种执 行路径上继续推进。

在基于语法的模糊测试器领域，Godefroid等人[70]利用神经网络从样本中学习程 序的结构化输入，以生成结构良好、多样化且高覆盖率的输入文件种子，用于对目标程序 进行模糊测试。随后，通过模糊测试修改生成种子的结构，以增加触及不可预测代码路径 的可能性，从而发现漏洞或漏洞。类似地，SmartSeed[103]利用生成对抗网络（ WGAN）[12]从选定的样本中训练模型，以生成多种格式（例如mp3、bmp和flv）的种 子。此外，它还能学习生成可引发更多崩溃的损坏种子文件。SmartSeed已被设计并测试 为可与其他模糊测试器（如AFL）兼容。

为了克服模糊测试方法的局限性，并提高发现更多潜在漏洞和漏洞的概率，模糊测试 方法已与其他二进制分析方法相结合，以帮助绕过条件分支检查，无论是针对具体值还是 魔术值。例如，Driller[139]结合了混合执行和模糊测试，并以重复且交替的方式运行。 它首先对目标二进制文件进行模糊测试，直到由于复杂的条件路径检查（例如与具体值或 魔术值的比较）而在指定时间内停滞。为了绕过条件路径障碍，Driller利用混合执行的约 束求解引擎来确定通过条件路径检查所需输入。因此，Driller使用新输入更新模糊测试器 以继续探索，并重复此过程，直到目标应用发生崩溃。与Driller类似，DeepFuzz[21]将 混合执行与受限模糊测试相结合，但它为符号执行求解器生成的每条路径分配概率。然后， 模糊测试器将进一步探索最有可能的路径。此外，SAFL[145]使用了与Driller类似的组件， 但避免了模糊测试与符号执行之间的频繁切换，因为这种切换成本较高。SAFL仅使用一次 符号执行来生成良好的初始种子，然后通过高效的变异算法引导模糊测试继续执行。然而， VUzzer[128]将模糊测试与动态污点分析（DTA）相结合。为了引导模糊测试器深入探 索路径并最大化覆盖率，结合静态分析使用动态污点分析来提取数据流和控制流特征。类 似于VUzzer[128] 和Driller[139], Steelix[99]通过执行静态分析和二进制插桩来利用轻量级程序分析。

3.2 嵌入式系统中的符号执行

符号执行是另一种用于应对嵌入式系统硬件兼容性挑战（C5）以及外设建模困难的方法。 因此，无需将固件导出并在模拟器或虚拟机中执行，而是将固件在符号执行引擎中进行符 号化执行，并将外设访问的结果视为符号数据。使用符号执行可提高可扩展性，并有助于 探索更多的代码路径。然而，它也有自身的局限性（见第2节），例如路径爆炸问题，当固 件需要访问其外设时，该问题可能被放大（例如，外设产生的中断频繁地生成更多状态 [15]）。

符号执行 。一种早期提出的方法，称为FIE[48],将符号执行引入嵌入式系统领域。该方法 通过分析在MSP430微控制器系列上运行的固件的内存安全来识别漏洞，而MSP430被 广泛应用于许多关键安全应用程序中。FIE基于修改版的KLEE[24]（详见第3.3节）构 建，旨在覆盖所有可能的执行路径，并通过引入状态剪枝和内存模糊化来处理循环覆盖问 题。FIE使用符号执行对外设进行符号化建模与描述。该方法成功识别了21个漏洞，并通 过基于亚马逊EC2[9]的系统对其可扩展性进行了测试。

一种名为Firmalice的跨架构框架[135]研究了复杂嵌入式系统固件中普遍存在的各 种认证绕过漏洞（通常称为后门）的存在，而无论认证机制是如何实现的。为了推断后门 是否存在，Firmalice基于输入确定性概念构建了一个模型。该模型声明，任何从固件入 口点到特权操作的执行路径都应经过严格的输入验证过程。因此，攻击者无法通过从固件 镜像本身检索信息的方式来绕过验证。为此，Firmalice首先利用静态分析提取程序数据 依赖图，然后提取由安全分析师确定的从入口点到特权操作位置的程序切片。接着，它采 用其受KLEE[24], MAYHEM[25],和FuzzBALL[13]启发的符号执行引擎（详见第3.3节）， 以寻找可能成功到达目标特权位置的路径。如果前述阶段成功，它将终止并输出触发该漏 洞所需的输入。Firmalice报告称，在两款商用固件设备中发现了后门的存在。

另一种为测试嵌入式系统固件而提出的符号执行框架是Inception[36]。它基于KLEE [24],构建，而KLEE需要访问源代码。Inception利用KLEE[24]以通过紧密同步的方式将 外设交互产生的中断发送到符号执行引擎中，从而解决中断问题。为了确保内存访问与真实硬 件之间的实时转发，Inception引入了JTAG调试器。此外，它还包含一个使用LLVM将提升 的源代码进行翻译的组件，并将其与开发人员可能手动编写的汇编指令合并。Inception已在 合成系统和真实世界系统上进行了评估，成功发现了八次崩溃和两个未知漏洞。

混合执行 。混合执行技术将符号执行与具体执行相结合。在嵌入式系统上应用混合执行是 一个具有挑战性的问题，因为它在中央处理器和内存方面都需要强大的计算资源，而这些 资源在嵌入式系统中通常受限。此外，符号执行依赖于插桩工具和定理证明器，而目标嵌 入式系统可能不支持这些工具。为了 解决这些问题，陈等人[30]提出在目标嵌入式系统上进行具体执行，同时在功能强大的远 程主机（如个人计算机、工作站等）上执行重量级的符号执行。为了实现这种协调，利用 了嵌入式系统供应商（即VxWorks）提供的交叉调试功能，这使得该工作仅限于 VxWorks。此外，所提出的工具在符号执行引擎与目标嵌入式设备之间建立了一对一的关 系，影响了其可扩展性。

类似于参考文献[30],艾等人[2]将混合执行引入嵌入式系统测试中，采用与参考文 献[30]相同的方法论，同时支持多种架构，例如x86、ARM和PPC。为实现其目标，作 者使用了一种可移植的插桩方案。他们将固件和状态信息提升到VEX中间表示，以便符 号引擎能够轻松处理多种CPU架构中的约束。

普通二进制文件中的符号执行与污点分析 。在普通二进制计算中，符号执行已与其他技术 （如静态分析和污点分析）相结合。例如，MACKE[120]结合静态分析与符号执行来发 现缓冲区溢出漏洞，并报告其严重性评分。类似地，费斯特等人[60]结合静态分析与符号 执行来挖掘并验证二进制代码中释放后使用漏洞（UAF）的存在。另一个例子是 TaintScop[146],，它通过将符号执行与污点分析相结合来绕过校验和检查。此外，动态 污点分析（DTA）也被单独用于识别普通二进制文件中的漏洞。例如，切斯等人[32]应 用DTA通过利用功能测试相关的计算来定位输入验证漏洞。DYTAN[34]对源代码或可 能已去符号化的二进制文件执行数据流和控制流污点分析。此外，为了自动检测覆盖攻击 并生成相应的签名，TaintCheck[117]识别受污染的数据。然而，苏等人[140]利用 DTA在操作系统级别保护程序免受恶意输入的影响。

3.3 嵌入式系统中复用的传统方法

不同的二进制分析方法已在传统计算系统（如台式机）上得到了广泛评估。尽管这些方法 的主要关注点并非嵌入式系统设备，但其中一些方法已经被引入或应用于嵌入式系统（如 第3.1.1节所述）。例如，仿真框架已成功集成到知名的二进制分析框架中，如angr[136] （黑盒变异模糊器和白盒模糊器）以及AFL[158]（灰盒模糊测试器）。此外，陈等人 [30]和艾等人[2]将符号执行与混合执行结合引入嵌入式系统测试中。这些组合方法显著 提升了动态分析在嵌入式系统设备上的可用性。本节中，我们总结了已在嵌入式系统领域 复用的现有方法。

一种流行的符号执行工具KLEE[24]能够为简单和复杂软件程序自动生成具有高执行 路径覆盖率的测试用例。KLEE旨在覆盖每一条可执行指令，并检查可能被攻击者利用的 关键操作。因此，KLEE实现了不同的约束求解优化（例如，表达式重写），以提高效率、 缩短求解时间并减少内存使用。为此，KLEE通过在对象级别实现copy-on-write并将堆内存 设计为不可变映射，来维护紧凑的程序状态。这样可以表示和探索更多的状态。为了避免 潜在的路径爆炸，KLEE停止分叉 在每个分支处；相反，它采用不可变的状态表示以节省内存空间。KLEE在GNU核心工具 集上进行了评估，成功在452个测试应用程序中报告了56个严重漏洞，并实现了平均 90%的代码覆盖率。KLEE被多种基于可用固件源代码的方法所采用，如第3.2节所述。具 体而言，FIE[48], Firmalice[135],和Inception[36]利用它来广泛覆盖各种可能的执行 路径。

为了便于集成各种二进制分析方法，引入了一个系统化的开源二进制分析框架angr [136]11。该框架在一个统一且连贯的框架中重现了一系列最先进的二进制分析方法实现。 此外，angr还重新实现了某些攻击性二进制分析技术，例如自动漏洞利用生成、ROP shellcode、漏洞利用重放等。该框架提供了直接比较不同已实现方法的能力。同时，它 还具备将两种或多种方法组合使用的能力，以发挥每种方法的优势并弥补各自的局限性。 angr将二进制程序提升为VEX‐IR，以支持多种CPU架构。angr已与一些用于嵌入式系 统的动态方法集成，例如第3.1.1节中介绍的Avatar[154] 和PRETENDER[73],。

Babic等人[13]提出了一种三阶段流程方法，以自动化测试用例生成，覆盖给定二进 制程序中的更多执行路径。第一阶段结合静态分析和动态分析来生成过程间控制流图（ inter‐proceduralCFG），该图由函数的控制流图及其调用图组成，并使用可见性下推自 动机（VPA）表示[8]。第二阶段利用静态分析消除第一阶段产生的误报。最后，基于前两 个阶段提供的建议（例如VPA中的加权最短路径长度），使用符号执行自动生成用于触 发潜在漏洞的测试用例。该方法的实现已作为原型工具FuzzBALL提供12。FuzzBALL的 思想已被应用于Firmalice，这是一种针对固件和嵌入式设备的符号执行方法[135],a symbolicexecutionapproachforfirmwareandembeddeddevices。

符号执行可用于动态构造利用已发现漏洞所需的输入。为了实现这一目标， MAYHEM[25]以交替方式结合符号执行和具体执行，从而在速度和内存利用率方面产生 协同效应。MAYHEM引入了一种基于内存的索引模型，用于在二进制级别处理符号内存 索引，有助于发现更多漏洞。该方法已应用于29个应用程序，成功自动报告并生成了29个 漏洞利用。然而，MAYHEM仅支持有限数量的系统调用，适用于Windows和Linux平 台，并且只能分析单次执行，而与之相比，S2E[33],支持多线程执行，并且能够检查用户 和内核程序。此外，MAYHEM能够定位标准漏洞（例如栈溢出）；但不支持查找复杂漏 洞，例如基于堆的溢出和UAF。MAYHEM的思想已被应用于Firmalice[135]。

有关不同二进制分析技术的更多细节，我们引导读者参考关于模糊测试的其他综述 [98, 104]和符号执行[15]。

3.4 比较研究

在本节中，我们比较了针对嵌入式系统的现有方法以及可能适用于嵌入式系统的传统方法。 我们进一步讨论了从该比较研究中得出的关键观察结果。

3.4.1 比较针对嵌入式系统的现有方法

由于缺乏相似的设置环境、嵌入式系统和固件 镜像，对现有解决方案进行全面评估是不可行的。然而，我们基于每种方案所提供的有关 方法、实现和评估的信息，进行了定性和定量比较，如下所示：

表1的第一列和第二列按日期顺序列出了提案及其对应的发表场所。接下来的八列展示了 它们提出的主要方法论。“目标” 列指明了所述目标是运行嵌入式设备、重新托管的固件，还是两者兼有。“设备类型”列 指定了各提案所测试的嵌入式设备类别。接下来的三列中，我们标注了这些方法支持的 CPU架构。下一列表明这些方法使用了哪些框架。最后两列表明哪些工具是开源的，以及 哪些工具可作为服务向公众开放以供审查其代码。此外，我们在表格的最后一行提供了这 些特征在选定的动态分析与符号执行研究中的分布情况，该分布基于这些研究与主题的相 关性（即嵌入式设备和固件中的漏洞检测）、发表年份（2004年1月至2020年1月）以及发 表场所（例如顶级网络安全和软件工程会议及期刊），如第1节所述。

此外，表2中提供了有关这些方法的更多细节。表2的第一列指定了提案。“克服的挑战” 列概述了各提案所应对的挑战类型。“目标（领域）”列报告了被测嵌入式设备的领域范围 设备。接下来的两列分别指定某项提案是否需要访问嵌入式设备固件的源代码以及物理设 备本身。最后一列概述了该提案用于测试目标嵌入式设备所使用的通信协议类型。

我们比较的关键观察结果。我们从表1、表2和表3中得出的关键观察结果如下：对嵌入式系 统进行各种二进制分析的主要目标之一是克服可扩展性问题、硬件兼容性问题，以及将传 统环境中已知的动态分析方法应用于嵌入式系统领域。进一步细化这些观察结果可知，大 多数选定的方法均在ARM和MIPSCPU架构上进行了评估。此外，与针对I型和II型嵌入式 设备的方法相比，所提出的方法较少针对III型嵌入式设备。此外，大多数方法不需要访问 固件源代码，仅有两个例外，因为这两项工作基于KLEE[24],，而KLEE作用于源代码。 此外，完全仿真方法或集成了完全仿真的方法更具可扩展性，因为它们无需访问任何硬件。 此外，重新托管方法试图克服多种CPU架构（C5）和可扩展性（C9）方面的挑战。 模糊测试方法则还致力于解决测试用例生成（C10）和故障检测（C11）的难题。可以看出， 大多数报告的缺陷、已知漏洞和零日漏洞都是通过采用模糊测试方法发现的。此外，结合 表2和表3中列出的特征，通过对嵌入式系统提供的网络连接接口进行模糊测试，相比其他 方法能够以更少的投入发现更多的漏洞和缺陷，表现出更好的性能。然而，难以检查在模 糊测试活动中触发的漏洞的具体位置。另一个缺点是模糊测试方法需要大量时间；与其他 方法相比，通常需要数天才能报告出有意义的结果。最后，将AFL和混合执行引入嵌入式 系统测试领域，为将在通用计算环境中提出的各种最先进的方法（如Driller[139], TaintScop[146],和SmartSeed[103]）应用于嵌入式系统测试打开了大门。

3.4.2 嵌入式系统中重用的传统方法与潜在传统方法的比较

类似地，在本节中，我 们对在嵌入式系统分析中被重用的传统方法及其可能引入的竞争性提案进行定性比较。该 比较基于每种方案在方法、实现和评估方面的可用信息，如表4所示。表4 的前两列指定 了提案及相应发表场所，并按日期排序。接下来的七列展示了它们提出的主要方法论。在 接下来的三列中，我们标记

这些方法支持哪些CPU架构。下一列表明了这些方法所使用的框架。如果没有使用任何框 架，则留空。最后两列显示了哪些工具是开源的，以及哪些工具可以作为服务供公众访问 以检查其代码。此外，我们还提供了这些特征在根据主题相关性、发表年份和 发表场所1。例如，大多数解决方案（48%）采用模糊测试，而只有5%的方案进行网络扫描。 我们比较的关键观察结果。本研究对动态分析与符号执行提出的各种方法进行比较研究， 其关键观察结果如下：首先，从表4可以看出，大多数提出的方法都是在运行于传统CPU 架构（x86‐64）的二进制代码上进行评估的。尽管许多方法声称其工作可被适配以支持多 种CPU架构，但几乎没有任何工作是专门为此可移植性而设计的。其次，如前文关于表3 的关键观察结果所述，大多数报告的漏洞、漏洞和零日漏洞是通过采用模糊测试方法发现 的；然而，模糊测试方法需要大量时间。此外，这些方法无法在合理时间内应用于大规模 且复杂的软件（例如Web浏览器），或用于检查大规模的软件语料库。第三，使用机器学 习生成智能种子仅能略微提升模糊测试的效果。例如，SmartSeed[103],利用对抗性神经 网络生成智能种子，能够发现最多数量的漏洞和崩溃。最后，结合两种或多种二进制分析 方法展现出具有前景的可扩展性和准确的结果。例如，将模糊测试与符号执行或污点分析 相结合，使得Driller[139]及其他受此工作启发的类似方法（例如deepFuzz[21]）能够发 现更多漏洞。

3.4.3 讨论

接下来，我们将讨论动态分析与符号执行方法的局限性。

非平凡的基准测试 。为了对最先进的方法进行基准测试，需要代表性数据集和统一评估指 标。大多数现有工作都在其自行收集的数据集上进行实验，并使用不同的指标评估其系统 的准确性。目前存在DARPACGC数据集[43], LAVA[52],以及LAVA‐M数据集[138],然 而，这些数据集尚不全面，无法覆盖所有使用场景。因此，为了评估目的，需要两个大规 模数据集：（i）固件数据集，包含从多个厂商收集的大量公开可用的固件镜像和嵌入式设 备；（ii）漏洞数据集，由大量跨架构和交叉编译的二进制文件（例如免费开源库）组成， 包含带有调试信息的易受攻击的函数。因此，可将现有方法应用于这些数据集，并通过采 用统一评估指标，评估所提出方法的准确性和可扩展性。最后，可以对最先进的方法进行 全面的定量和定性比较研究。

有限的代码覆盖率 。代码覆盖率对于完整且鲁棒的漏洞发现至关重要。动态分析技术可能 会遇到路径探索问题，从而导致剩余代码的分析过程停止。此外，除非由用户交互触发， 否则某些路径可能不会被执行。再者，如果未满足特定条件，在运行时加载的代码可能会 逃避动态分析和静态分析（即逻辑炸弹）。

非平凡测试用例生成 。为了进行可扩展的动态分析，首先应为目标程序提供合适的输入样 本。根据文献综述，测试用例由专家手动生成[147],使用符号执行[146],或通过训练的机 器学习模型生成[103]。手动测试用例生成过程耗时长、不可扩展且成本高。然而，符号执 行同样不可扩展，无法为复杂软件提供高覆盖率，并且计算成本高。此外，所提出的[139] 结合符号执行与模糊测试以解决此问题的方案并不适用