自动化多状态嵌入式固件托管方法

An Automated Multi-state Embedded Device Firmware Rehosting Method

摘要

针对近年来固件托管技术的相关研究成果存在仿真执行效率不高、执行路径单一等问题，提出一种自动化多状态嵌入式设备固件托管方法。该方法基于静态特征自动定位启动完成位置，设计距离优先的选路算法，实现仿真设备的快速启动自检；设计基于异常规避的混合执行方法，生成具有多路径执行能力的动态执行模型，实现执行路径的多样化。通过面向两类平台3类架构下19款固件的实验测试，验证该方法能够成功为所有嵌入式设备固件创建静态启动自检模型和动态混合执行模型，实现设备固件高效多状态的仿真运行。

Abstract

Research findings on firmware rehosting techniques have revealed issues such as low simulation execution efficiency and a single execution path. To alleviate these problems, an automated multi-state embedded device firmware rehosting method is proposed. The startup completion position is automatically located based on static features, a distance-first path selection algorithm is designed, and rapid self-testing of the simulated device during startup is achieved. Additionally, a hybrid execution algorithm based on exception avoidance is devised to generate a dynamic execution model with multi-path execution capabilities, thereby enabling the diversification of execution paths. Through experimental testing involving 19 firmware samples across two types of platforms and three types of architectures, the method successfully generates a static boot model and a dynamic hybrid execution model for all embedded device firmware, facilitating efficient multi-state simulation operations of the device firmware.

Graphical abstract

关键词

嵌入式 / 固件仿真 / 固件托管 / 符号执行 / 混合执行

Key words

embedded / firmware emulation / firmware rehosting / symbolic execution / concolic execution

随着物联网、人工智能、大数据、5G等技术的广泛应用，嵌入式系统已经逐渐成为人、机、物以及各种信息系统互联的重要基石。然而，随着各类嵌入式设备的海量部署，针对其脆弱性开展的各类攻击活动日益频繁，嵌入式设备面临的安全形势正在持续恶化^[1]。因此，围绕嵌入式设备展开的安全分析已成为当前网络安全领域的研究热点之一。

嵌入式系统仿真技术是嵌入式设备动态逆向分析的基础支撑技术，按照对硬件设备依赖程度的不同主要分为全系统仿真^[2-6]、硬件在环（Hardware-in-the-Loop，HIL）^[7]、固件托管3类^[8]。全系统仿真技术通过模拟各类外设逻辑，形成一套贴近真实物理环境的运行交互场景。硬件在环仿真技术将外设操作中继到真实的硬件设备上执行并收集执行结果，随后在软件仿真器中继续执行。

固件托管技术是一种可以脱离硬件环境的仿真技术，通过在软件模拟环境中提供给仿真固件合适的外设输入值替代真实外设，尽可能将嵌入式固件完全运行在软件仿真环境中。相比其他仿真技术，固件托管完全摆脱了对硬件设备的依赖，同时省去外设建模等繁琐步骤，成为近年来的研究热点^[9-12]。现有方法虽能较好解决嵌入式设备固件在无硬件支持的情况下的动态仿真问题，但仍普遍存在仿真执行路径单一、执行效率不高等问题。

为解决上述问题，通过动静结合的方法^[13]，提出一种新的嵌入式固件托管仿真方法。首先通过静态分析得到标志设备启动自检完成的代码位置；其次利用距离优先的引导式符号执行^[14]方法引导设备运行到标志启动自检完成位置，求解路径约束生成设备固件启动自检外设模型；最后以该模型为基础，结合异常引导的符号执行方法创建混合执行模型实现固件代码在QEMU^[15]仿真器下的混合仿真运行。启动自检模型帮助仿真固件快速完成启动自检过程，节省启动自检过程的仿真运行时间；混合执行模型帮助固件在后续执行过程中尽可能保留更多合法执行路径选择，缓解路仿真执行路径单一化问题，同时通过缓存历史结果不断提高执行效率。

1 系统设计

为有效提高固件托管效率和动态执行过程中的路径多样化水平，更好地支撑固件安全性检测，本文提出的固件托管方法主要包含固定路径下的快速启动和随机路径下的动态建模仿真两部分，整体框架如图1所示。

固定路径下的快速启动部分通过距离优先的自动化选路方法生成静态模型，引导设备完成从开机到循环等待状态，缩短仿真启动时间；随机路径下的动态建模仿真部分通过混合执行方法，增量生成多路径模型，支撑设备固件多样化路径仿真运行。

首先自动定位表示嵌入式设备启动完成的代码位置，结合引导式符号执行方法生成启动自检模型，引导设备固件完成启动自检过程，启动后利用基于异常规避的引导式符号执行策略，引导设备固件在混合执行环境下进行多样化执行路径的动态仿真运行。不同于混合执行环境外设模型的动态生成，启动自检模型生成完成后不再发生变化。启动自检完成后，外设模型开始动态生长，同时区分出有依赖关系的控制寄存器和无依赖关系的数据寄存器，控制寄存器模型支撑设备固件实现多样化执行路径尝试，数据寄存器则可作为模糊测试的数据输入，将模糊测试技术引入嵌入式设备安全测试。本文方法综合使用angr^[16]符号执行引擎和Avatar^2[17]框架，分别进行启动自检模型生成、固件外设识别分类以及动态仿真运行。

1.1 自动选路引导固件启动

嵌入式设备通电开机后会首先执行启动自检过程，启动自检过程根据功能领域不同可划分为设备硬件初始化和用户自定义的启动自检操作两部分。其中硬件初始化过程由设备的启动文件定义，该文件通常由硬件厂商或是集成开发环境（Integrated Development Environment，IDE）提供，在设备重启时启动文件会引导设备依次完成屏蔽所有中断、复制.data段内容到RAM、初始化.bss段、初始化栈内存空间和栈寄存器、调用main函数等操作。硬件初始化过程调用main函数后，控制权转移到用户代码，用户进行一些自定义的初始化过程，设置设备外设状态，检查外设可用性等操作。

该过程代码往往不是安全研究人员的关注重点。通过构建合适的引导式符号执行方法，找到一条合理的启动自检执行路径，并记录执行路径上各个外设内存寄存器符号值的约束条件。对上述符号值进行约束求解，同时记录各个符号创建时的程序指针和符号对应的内存位置，形成能引导仿真固件快速完成启动自检过程的静态模型。该模型可大幅缩短仿真环境下固件启动时间，提高整体仿真执行时间效率。下面将分别针对表示启动自检完成位置的自动定位算法和生成启动自检静态模型的距离优先引导式选路算法进行进一步阐述。

1.1.1 启动自检目标地址的自动定位

嵌入式设备完成启动自检后通常会进入“监听”状态，在该状态下嵌入式设备不执行任何有效的代码指令，仅等待外设发出的中断请求，进而调用相应的中断响应代码执行该嵌入式设备主要功能。要定位表示启动自检完成的代码位置，关键在于寻找这个“监听状态”。

监听状态所在函数通常以一个循环体结束，且该循环体不会再调用其他的函数体。定义4次过滤规则依次排除：1）无效函数；2）不是以循环体结束函数；3）循环体内含有外溢节点；4）目标节点从程序入口点不可达等条件。随后再根据程序抽象语法树信息计算函数权重信息，最后返回一个唯一的基本块作为后续引导式符号执行的目标地点，引导生成静态模型帮助设备固件完成启动自检过程。

1.1.2 距离优先的引导式选路算法

为成功引导模拟环境下的设备固件代码执行到代表启动自检完成的位置，需在每次固件代码请求外设寄存器内容时返回合适的值，直至自检完成。文中采用引导式符号执行方法，通过搭配基于静态信息的路径选择策略，能够实现快速准确地执行路径生成。

算法1 距离优先的引导式选路算法

输入：当前函数Fc，当前基本块Nc，目标基本块Nt，固件函数调用图CG，目标基本块所在函数Ft

输出：执行路径P

1. if Fc.have_node（Nt） then

2. P = Fc.graph.shortest_path（Nc,Nt）

3. else

4. call_path = CG.shortest_path（Fc,Ft）

5. if call_path.valid（） then

6. target_addr = [x for x in Fc.get_call_sites（） if Fc.get_call_target（x） == call_path[1]][0]

7. P = Fc.graph.shortest_path（Nc,target_addr）

8. else

9. for ret_site in Fc.ret_sites do

10. P = Fc.graph.shortest_path（Nc,ret_site）

11. if P.valid（） then

12. break

13. end if

14. end for

15. end if

16. end if

17. return P

文中采用距离优先的路径选择策略，分3种不同执行情况进行执行路径决策：1）当目标点与当前执行状态位于相同函数时，使用函数控制流图规划前往目标所在基本块最短路径；2）当目标点不与当前执行状态处于同一函数，且当前函数有前往目标点所在函数的函数调用路径，使用函数控制流图规划前往调用下一跳函数基本块的最短路径；3）当目标点不与当前执行状态处于同一函数，且当前函数没有前往目标点所在函数的函数调用路径，使用函数控制流图规划前往随机一个函数返回点的最短路径。

1.2 混合执行下的动态建模仿真

距离优先的选路方法生成的静态模型能够引导设备快速完成启动自检过程，然而该模型难以提高代码覆盖率并支撑后续用户代码执行。混合执行（Concolic-Execution）阶段将在固件访问外设时将执行状态挂起，同时切换到异常引导符号执行引擎更新混合执行模型。混合执行整体架构如图2所示，仿真固件在请求未知外设寄存器值时，会将执行状态切换到符号执行环境。

下面分别就执行状态切换过程中的状态同步以及后续进行寄存器值求解的异常引导符号执行部分进行简要介绍。

1.2.1 运行过程中的状态同步

由于系统中混合执行阶段的实际仿真执行（Concrete-Execution）部分基于QEMU仿真器完成，符号执行部分则是基于angr符号执行引擎完成，因此需要将QEMU仿真器执行的当前状态信息（寄存器、内存、当前指令位置等）同步到符号执行引擎，以确保符号执行结果的有效性。

混合执行中的状态同步主要依赖Avatar²执行框架。针对该框架现有通道下内存同步效率低的问题，使用共享内存机制进行状态切换时内存同步。通过将被仿真运行的固件内存映射为QEMU仿真器进行固件代码仿真执行过程中，遇到读取内存映射寄存器值操作时将执行状态挂起，同时将该读操作相关指令地址、读内存位置、读内存大小、仿真器当前寄存器值等信息通过已有信道传输到符号执行端。符号执行引擎收集到上述信息并通过共享内存完成内存同步之后，将从该挂起位置开始向后进行符号执行。符号执行结束后QEMU仿真器收到外设值，固件继续在QEMU下仿真运行。

1.2.2 异常引导式符号执行

嵌入式设备固件在硬件设备中执行时，通常能够从设备外设获取到正确的输入值，并不会触发异常状态。反之，当异常状态触发时，则表示固件得到的外设输入值异常。基于此观察，通过符号执行手段将外设输入符号化（设为S_{\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{p}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{l}}），使用异常规避的方法引导符号执行并记录非异常条件下的符号约束，求解S_{\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{p}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{l}}值即可作为合法外设输入，保证嵌入式设备固件正常执行。通过随机选取非异常条件约束并进行求解，能够最大限度保证设备固件执行路径的多样化。

切换到符号执行后，程序将在符号执行框架下进行广度优先的路径探索，按照自定义的异常检测规则对执行分支进行分类，以收集合法路径的符号约束。本文试图通过符号执行判断哪些输入值会导致程序进入异常状态，同时通过收集非异常状态的约束条件求取外设模型值。在此过程中要重点解决以下几个问题：首先，为实现在有限的符号执行过程中收集到有效的外设输入的约束条件，如何正确定义异常和准确识别异常；其次，数据寄存器作为用户数据的输入点，能够作为外部输入的数据入口，进一步获得模糊测试数据接入能力，如何将固件执行过程中用到的数据寄存器识别出来；最后，怎样设计混合执行状态下的外设模型，支撑设备固件执行多样化路径。

1）异常判断标准。一般情况下，当嵌入式设备固件执行过程中遇到异常，执行过程会跳转到死循环体。通过符号执行推断外设输入过程中，遇到死循环则表示执行过程遭遇了异常。需要指出的是，固件启动自检完成后所在位置，也就是论文自动定位的表示启动自检完成的代码位置同样是一个无跳转点的死循环。不同的是该循环位置并非其他常见的异常类型，而是表示固件启动完成进入等待外设中断的就绪状态。为区别该循环位置和其他死循环，异常检测过程中需要将该位置标记为异常检测的白名单位置。

此外，所提方法还提供接口方便用户提供自定义的异常位置。随着对固件的了解不断加深，用户可以根据自身掌握的知识手动添加自定义异常位置。实际执行过程中，这些指定位置将会被视作异常代码位置不会被模拟器执行。

2）异常检测方法。为准确识别执行过程中的死循环体，首先通过静态程序分析方法得到所有的循环体，然后将循环体内无跳出循环指令的标记为死循环体。符号执行过程中，遇到死循环体直接将其标记为异常状态并终止该执行分支，遇到其他循环体则对其进行进一步观测。当该循环的循环执行次数达到一定阈值R（文中根据实际经验设定值为5），记录当前循环中各个寄存器值。若执行过程进入下一循环，即循环执行次数达到（R+1）时，再次检查当前各个寄存器值，并将上述值同第R次循环的寄存器值进行比对，寄存器值无变化则认定该循环同样为一个死循环，符号执行过程将终止该执行分支，并将该状态标记为异常状态。

3）数据寄存器识别。仿真器执行过程中遇到外设的读取请求会将自身挂起，切换到符号执行状态。其中状态寄存器的值往往会很快影响固件的后续执行路径，异常的输入值还会导致固件执行进入异常状态，而数据寄存器的值则很少会在短期内影响程序的执行分支。基于此观察，本文通过检查符号执行完成后所有正常状态的符号约束条件，若发现所有正常状态均未产生对外设模型S_{\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{p}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{l}}的任何约束条件，表明该外设值在短期内并不会影响程序的执行流程，将上述此类外设寄存器归类为可能的数据寄存器并返回0。后续执行过程中若多次记录到对该寄存器位置的读请求，同时不存在任何约束条件，将该外设寄存器归类为数据寄存器。

4）嵌入式设备外设模型。混合执行过程中每次异常引导符号执行完毕，所有符号执行状态将被分为异常执行状态和正常执行状态两类。依次对所有正常执行状态下的S_{\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{p}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{l}}进行求解，所有正常执行状态下得到的S_{\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{p}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{l}}实际值将构成一个合法值集合，即该执行位置的外设模型。

本文将外设模型定义如式（1）所示：

\begin{array}{l}{M}_{(i,a)}≔\left(A_{\mathrm{1}}.\mathrm{e}\mathrm{v}\mathrm{a}\mathrm{l}\left(S_{\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{p}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{l}}\right),\right.A_{\mathrm{2}}.\mathrm{e}\mathrm{v}\mathrm{a}\mathrm{l}\left(S_{\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{p}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{l}}\right),\cdots ,\\ \left.A_n.\mathrm{e}\mathrm{v}\mathrm{a}\mathrm{l}\left(S_{\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{p}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{l}}\right)\right).\end{array}（1）

式中：i表示模拟器请求外设值时的执行地址；a表示模拟器请求的外设地址；A₁表示符号执行结束后的第1个正常执行状态；n表示所有正常执行状态数。当后续执行过程中发生相同的请求条件时，则从该模型中返回一个随机值。例如，混合执行过程中固件代码运行指令LDR R4, 0x40001000请求外设寄存器地址0x40001000的值，经过异常引导符号执行共得出4个合法运行状态A₁、A₂、A₃、A₄。基于上述4个合法运行状态分别对0x40001000的符号值进行约束求解，分别得出集合Q₁、Q₂、Q₃、Q₄，集合B=\left\{Q_{\mathrm{1}}\bigcap Q_{\mathrm{2}}\bigcap Q_{\mathrm{3}}\bigcap Q_{\mathrm{4}}\right\}即是该位置得到的混合执行模型，后续执行过程中将遇到相同执行条件将从集合B中返回随机值。该模型将固件执行时的执行地址和所请求的外设地址合并作为模型的索引，在提高模型针对性的同时，降低了误匹配情况出现的概率。

2 系统性能分析

为验证所提系统的性能与效果，分别从启动代码完成位置识别准确度测试、启动自检模型有效性检测、混合执行下仿真运行能力测试3个方面进行测试。

2.1 实验环境及对象

系统运行的硬件环境为：AMD Ryzen 7 5800 H @ 3.20 GHz，RAM 8.0 GB，UbuntuServer18.04。软件环境：Python v3.6.9，QEMU v3.0.0，Avatar² v1.4.7。

使用Laelaps中的19款嵌入式设备固件作为实验对象，固件分别取自NXP、ST等不同公司生产的硬件设备，基于FreeRTOS、Mbed OS、ChibiOS/RT 3款实时操作系统，且包含从简单GPIO端口到复杂以太网网卡的多种嵌入式设备外设的应用。

2.2 启动代码完成位置识别测试

通过对比自动搜索算法和人工识别的表示启动代码完成位置，验证自动搜索算法的有效性和准确率如表1所示。首先，通过手工逆向分析依次确定各个实验对象表示启动自检完成代码位置的虚拟地址；其次，使用启动自检定位算法依次对各个实验对象执行计算；最后，对比算法结果和手工逆向分析结果，统计算法命中概率。实验结果显示所有19个实验对象全部成功定位到了正确的表示启动自检完成的代码位置。

从加载固件开始到得出唯一的推断地址值，算法最快运行时间0.86 s，最慢运行时间5.14 s，算法执行时间和分析固件代码的体量呈正相关性。对于自动推断出错的情况，算法在给出唯一值的同时也会输出若干最有潜力的可能地址，用户通过查找其他潜力地址能够快速手动确定真正的目标地址。

2.3 启动自检过程有效性测试

自动定位表示启动自检代码完成位置后，需要通过引导式符号执行方法引导设备快速执行到目标位置，并最终在此基础上生成引导设备固件完成启动自检的启动自检模型。实验如表2所示，将分别测试距离优先的引导式选路模型在所有19个实验对象下的实际表现，验证该模型的有效性并测试该模型的执行效率。

通过应用距离优先的引导式选路方法，同时收集选路过程中经历的选路决策、回滚、外设寄存器符号生成以及执行总时间等信息，能够对启动自检过程的有效性和选路算法执行效率有更加直观的认识。

实验结果显示所有19个实验对象都成功完成了启动自检模型的自动生成过程，且都成功在模型引导下执行到表示启动自检完成代码位置。19个实验对象中共10款设备固件在模型生成过程中未发生任何回滚操作，剩下9款设备固件平均回滚比例7.29%，反映了文中使用距离优先的选路算法能够较好实现快速高效选路的设计需求，较少发生选路出错的情况。使用启动自检模型的启动时间相比符号执行下的模型生成时间平均减少92.12 s，缩短约93%的启动自检执行时间，显著提高启动自检过程的仿真运行效率。

实验中多数实验对象生成启动自检模型的执行时间在20 s左右，但有5个实验对象的执行时间显著高于其他。以上5个实验对象中有3款固件代码中出现了循环次数多达30 000次的循环延迟操作，导致30 000余次重复的基本块执行。另外2款固件代码部分执行基本块中涉及到大量有关外设符号输入的约束操作，同样限制了符号执行的运行效率。

2.4 混合执行下仿真运行能力测试

混合执行模式下设备固件完成启动自检后启动自检模型将停止介入，取而代之的是后续外设访问请求将转交异常引导符号执行引擎执行。异常引导符号执行引擎求解外设访问请求后，会依据符号执行过程对外设的依赖关系将该外设寄存器分为有依赖关系的状态寄存器和无依赖关系的数据寄存器两大类，其中状态寄存器将返回约束条件内的随机值，数据寄存器将返回请求数据宽度内的任意值。分别将19款设备固件代码在混合执行模式下运行3 min，统计该运行区间内混合执行模型的创建、分类以及访问等情况，对混合执行模式下异常引导符号执行算法的有效性进行检测，对混合执行模型引导仿真设备进行多样化动态仿真运行的能力进行评估。

表3统计了此次实验中各个设备固件产生的状态寄存器、数据寄存器个数，混合执行模型的访问次数，执行的基本块个数和去重后的基本块个数，以及混合执行引擎对启动自检完成后的代码覆盖率。

表3中执行翻译块总数指的是QEMU仿真运行过程中执行的无链接的翻译块数量；启动自检代码完成后的代码覆盖率不包含异常处理代码。实验结果显示所有19款设备固件均能够正常在混合执行模型下运行，平均每个模型包含2.1个状态寄存器和1个数据寄存器，模型访问5 060次。混合执行模式下成功对状态寄存器建立模型，并标记若干数据寄存器位置，验证了符号执行方法对于寄存器类型识别建模的有效性，模型访问数体现了混合执行模型在实际执行过程中的广泛应用。

启动自检完成后的代码覆盖率统计了混合执行模式下固件启动自检完成后代码覆盖率情况，记录了多样化路径的仿真执行能力。需要指出的是，由于被测固件功能较为单一，完成启动自检后对外设的交互动作较少，有些固件甚至完全没有读取外设操作，因而混合执行下新建模型数量较低。同时部分被仿真设备在启动自检完成后无任何外设读取操作，因而试验证表现为启动自检完成后代码覆盖率较低。此外，固件仿真执行过程中，中断消息通过QEMU的QMP消息通道传输，而QEMU仿真系统绝大部分时间都处于挂起状态。这导致仿真执行过程中成功插入系统中断的频次较低，中断处理例程被调用的比例也相对较低，对最终的覆盖率统计同样产生了一定影响。

3 结束语

设计了一款新的嵌入式设备固件托管仿真方法，该方法通过将嵌入式设备固件托管切分为启动自检阶段和启动自检后功能运行阶段两部分，使用静态启动自检模型引导设备固件快速完成启动自检过程，提高了整体的仿真执行效率。通过使用基于异常引导的外设模型计算方法，在确保后续执行过程稳定可靠的同时，实现了执行路径的多样化。为验证所提方法有效性分别对19款设备固件进行了实验检测。实验结果表明，所提方法能够有效完成仿真固件的快速启动，以及混合执行模式下的多样化运行。然而系统在实际仿真执行过程中仍然存在中断插入效率不高、面对部分复杂指令时不能有效完成符号执行过程等问题。在未来工作中，将重点改善系统中断插入效率，解决符号执行引擎对异常、未知指令的绕过问题，扩大符号执行引擎兼容性，进一步提升仿真效果和适用范围。

参考文献

[1] The 2023 IOT Security Landscape Report［EB/OL］. （2023-12-11）［2024-10-11］.

[2] BELLARD F. QEMU， a fast and portable dynamic translator［C］∥Proceedings of the USENIX annual technical conference. Berkeley， USA： USENIX Association， 2005：41-46.

[3] CHEN D D， EGELE M， WOO M， et al. Towards automated dynamic analysis for linux-based embedded firmware［C］∥Proceedings of the 2016 Network and Distributed System Security Symposium. San Diego， USA： Internet Society， 2016. DOI：10.14722/ndss.2016.23415 .

[4] SHAH S. EMUX firmware emulation framework［EB/OL］. （2022-08-01）［2024-10-11］.

[5] Qemu STM32［EB/OL］. （2015-10-03）［2024-10-11］.

[6] LuaQEMU［EB/OL］. （2017-09-03）［2024-10-11］.

[7] CLEMENTS A A， GUSTAFSON E， SCHARNOWSKI T， et al. HALucinator： firmware re-hosting through abstraction layer emulation［C］∥Proceedings of the 29th USENIX Security Symposium. Berkeley， USA： USENIX， 2020：1201-1218.

[8] 于颖超，陈左宁，甘水滔，嵌入式设备固件安全分析技术研究［J］.计算机学报，2021，44（5）：859-881.

[9] GUSTAFSON E， MUENCH M， SPENSKY C， et al. Toward the analysis of embedded firmware through automated re-hosting［C］∥Proceedings of the RAID 2019. Chaoyang District. Berkeley， USA： USENIX， 2019：135-150.

[10] FENG B， MERA A， LU L. P2IM： scalable and hardware-independent firmware testing via automatic peripheral interface modeling［C］∥Proceedings of the 29th USENIX Security Symposium. Berkeley， USA： USENIX， 2020：1237-1254.

[11] CAO C， GUAN L， MING J， et al. Device-agnostic firmware execution is possible： a concolic execution approach for peripheral emulation［C］∥Proceedings of the Annual Computer Security Applications Conference. New York， USA： ACM， 2020：746-759.

[12] JOHNSON E， BLAND M， ZHU Y F， et al. Jetset： targeted firmware rehosting for embedded systems［C］∥Proceedings of the 30th USENIX Security Symposium. Berkeley， USA： USENIX， 2021：321-338.

[13] 井靖，何红旗，司彬彬，嵌入式软件逆向分析中的动静态分析交互机制［J］.信息工程大学学报，2015，16（5）：613-618.

[14] MA K K， PHANG K YIT， FOSTER J S， et al. Directed symbolic execution［C］∥Proceedings of the 18th International Coference on Static Analysis. Berlin， Germany： Springer， 2011：95-111.

[15] ZADDACH J， BRUNO L， FRANCILLON A， et al. Avatar： a framework to support dynamic security analysis of embedded systems’ firmwares［C］∥Proceedings of the 2014 Network and Distributed System Security Symposium. San Diego，USA： Internet Society， 2014：1-16.

[16] SHOSHITAISHVILI Y， WANG R Y， SALLS C， et al. SOK：（state of） the art of war： offensive techniques in binary analysis［C］∥Proceedings of the 2016 IEEE Symposium on Security and Privacy. Piscataway， USA： IEEE， 2016：138-157.

[17] MUENCH M， NISI D， FRANCILLON A， et al. Avatar²： a multi-target orchestration platform［C］∥Proceedings of the 2018 Workshop on Binary Analysis Research. San Diego， USA： Internet Society， 2018：1-11.