IoT固件Rehosting综述 - FreeBuf网络安全行业门户

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序把安全装进口袋

终端安全

IoT固件Rehosting综述

2022-06-09 20:40:14

所属地江苏省

本文由创作，已纳入「FreeBuf原创奖励计划」，未授权禁止转载

最近抽空浏览了一些IoT固件安全论文，试用了部分工具，这里作简单总结。文章主要从论文出发，对Rehosting(托管)囊括的不一定全面，希望可以为小伙伴抛砖引玉。本文是笔者正在总结的《物联网固件安全研究手册》部分内容，全册完成后会在Github公布。

Rehosting是固件动态分析的重要手段，本文将澄清Rehosting山寨版定义，重点阐述Rehosting的一些方式，文末简单提及固件静态分析，并给出参考论文列表。

0x00 Rehosting定义

Rehosting一般译为托管，但可能与机房机器托管的意思混淆，而Re+Host较为直观，即通过将所需的固件模块在新的宿主(host)上运行，已达到成规模的低成本动态分析和安全研究目的。下文将直接使用Rehosting。

[1]给出的定义如下:

Definition 1.Virtual Environment (VE): A software environment in which code can be executed transparently.

Definition 2.Hardware Emulation System (HES): A VE designed to accurately recreate the features of one or more selected pieces of hardware. Commonly called an emulator.

Definition 3.Rehosted Embedded System (RES): A combination of a firmware image and VEdesigned to sufficiently recreate the firmware’s hardware dependencies such that analyses produce results representative of the firmware running on its original hardware.

Definition 4.Rehosting: The process of building an RES for a given embedded system to enable a specified analysis task. May include modifications to the firmware.

与Rehosting类似概念有固件移植和固件模拟(Emulation)，笔者认为区别在于，固件移植指将PC软件交叉编译安装至开发板，Rehosting往往相反；而与固件模拟相比，Rehosting一般仅将需要的功能模块提取出，必要时适当修改，以用于Fuzzing和安全性研究。

当然，对此见仁见智，这并非阐述重点，本文提及的论文和工具侧重功能模拟和动态安全测试，在概念上不会深究界限区别。

0x01 Rehosting方式

Rehosting方式最直观的与固件类型相关，IOT固件粗略可分两种，一种是有明确文件系统目录的，一般基于Linux，FreeBSD等开源系统/内核；一种是没有的文件系统的RTOS(Real-time operating system)，比如Vxworks，FreeRTOS等。基于Linux的固件Rehosting相对简单，而RTOS模块较难分离，笔者收集的论文大部分都是针对RTOS展开。

模拟运行是二进制分析的重要手段，常用的有QEMU、Unicon，包括后起之秀Qiling等等，这些框架或模拟系统，或模拟执行指令，代码也都有交集，本文重点并不在此，不会对基础模拟器作过多讨论。

基于Linux的固件

Firmadyne [2]

Firmadyne框架基于QEMU，旨在完成整个固件系统的运行。

一些Rehosting&Fuzzing的框架会在其基础上二次开发，Firmadyne模块如下图所示：

其运行流程是：

1、通过网络途径获取固件(ARM/MIPS)，并对固件解包；

2、利用定制动态链接库完成库函数劫持以完成NVRAM设备调用；

3、利用定制内核完成系统启动、网络探测、虚拟硬件和网络构建；

4、调用QEMU仿真系统。

对固件解包模拟的比较熟悉的小伙伴通过以上描述就会大概率放弃该工具，因为该流程存在大量不确定因素，成规模使用的成功利率会很低，而测试结果也正是如此。在Firmadyne获取的23035个固件中，8617个可解包；解包成功后有8591个可启动系统；启动系统后2797个可配置网络；最后只有1971个可以正常访问网络。也就是仅有22.9%的固件完成模拟并进行测试。

Firmadyne的使用方法这里略过，Github上教程也很详细。

FirmAE [3]

FirmAE目标是创造一个可以供用户动态调试分析的环境，而不是复现和硬件一模一样的环境,，其卖点是大规模(Large-Scale)。

论文开头就直指“友商”Firmadyne，提出其模拟成功率低等问题，其将原本Firmadyne的成功率16.28%提高到79.36%，其底层还是使用了QEMU。FirmAE从固件的启动、网络、NVRAM、内核和其它五个方面，总结了导致固件仿真失败的原因及通用解决方法，并集成check、run、analyze和debug四种模式。check 模式会对固件进行各项仿真检测，并保存相关的日志信息记录在缓存文件中。run模式是根据check模式构建的各种处理信息进行仿真。

在漏洞检测方面，FirmAE根据固件的文件系统和内核日志来推断Web服务状态，其发现了23个设备的12个0DAY。

FirmAE的使用方法网上不乏教程，也可以参考Github。

FirmAFL [4]

FirmAFL使用并改进了Firmdyne模拟方式，并利用AFL对IoT固件实施高通量灰盒Fuzzing。

FirmAFL的贡献在于：

1、针对全系统仿真(高通用性、低效率)和用户模式仿真(低通用性、高效率)的矛盾特点，提出了增强过程仿真的新技术；

2、设计并实现了第一个基于代码覆盖率的灰盒fuzzer—FirmAFL，支持mipsel、mipseb和armel三种CPU架构，涵盖Firmadyne数据库中90.2%的固件。

FirmAFL的使用可参考Github，以下简单梳理(详见参考链接(5))：

# 安装依赖
sudo apt-get install zlib1g-dev libglib2.0-dev automake libtool binwalk
sudo apt-get install python-lzma
sudo -H pip install git+https://github.com/ahupp/python-magic
sudo -H pip install git+https://github.com/sviehb/jefferson
sudo pip3 install python3-magic

# 编译用户模式
cd ./FirmAFL/user_mode/
sed -i '40s/static //' util/memfd.c
./configure --target-list=mipsel-linux-user,mips-linux-user,arm-linux-user --static --disable-werror
make

# 编译系统模式
cd ../qemu_mode/DECAF_qemu_2.10/
sed -i '40s/static //' util/memfd.c
./configure --target-list=mipsel-softmmu,mips-softmmu,arm-softmmu --disable-werror
make

# 安装Firmadyne并设置数据库
cd ../../
sudo apt-get install busybox-static fakeroot git dmsetup kpartx netcat-openbsd nmap python-psycopg2 python3-psycopg2 snmp uml-utilities util-linux vlan
git clone --recursive <https://github.com/firmadyne/firmadyne.git>
cd ../FirmAFL/firmadyne
sudo apt-get install postgresql
sudo apt-get install libpq-dev
dropdb -U firmadyne -h 127.0.0.1 firmware
sudo -u postgres createuser -P firmadyne
sudo -u postgres createdb -O firmadyne firmware
cd database
cp /home/churchkm/Downloads/data.xz ./
xz -d data.xz
mv data schema
chmod +x schema
sudo -u postgres psql -d firmware < ./schema

# 使用Firmadyne仿真固件
cd ../
sudo ./download.sh
sed -i '4s/#//' firmadyne.config
cp ../firmadyne_modify/makeImage.sh ./scripts/
sudo ./sources/extractor/extractor.py -b dlink -sql 127.0.0.1 -np -nk "../firmware/DIR-815_FIRMWARE_1.01.ZIP" images
sudo ./scripts/getArch.sh ./images/9050.tar.gz
sudo ./scripts/makeImage.sh 9050
sudo ./scripts/inferNetwork.sh 9050

# 使用FirmAFL进行Fuzzing
cd ../
python3 FirmAFL_setup.py 9050 mipsel
cp ./FirmAFL_config/9050/run.sh ./image_9050/  #即用FirmAFL_config中的run.sh替换image_9050中的run.sh
cd image_9050
sudo ./run.sh
# 固件启动后，新终端下执行
python3 test.py
sudo user.sh

FirmFuzz [5]

FirmFuzz通过监控固件运行所生成的日志以检测漏洞，侧重挖掘命令注入、缓冲区溢出和空指针引用等。FirmFuzz在模拟层面基于QEMU，支持MIPS和ARM架构。

Firmfuzz论文中将固件可能存在的缺陷归因于三个方面，分别是(Linux)内核、开源软件和厂商自研软件，Firmfuzz重点挖掘厂商自研软件漏洞。其主要贡献点在于：

1、利用这些设备的web应用界面作为入口，生成语法上合法的输入；

2、将运行监控器嵌入固件的运行时环境中，以允许上下文感知的监控；

3、从静态分析中收集信息来指导固件模拟和Fuzzing生成。

输入检测、插庄反馈和静态预分析都是Fuzzing的常规操作，只是框架使用的方案各异。

FirmFuzz的使用侧重Fuzzing，固件解包可单独使用firmadyne extractor或者binwalk，具体可参见Github教程。

可以看到，在上述提及的Linux-based的框架和工具中，大部分都直接或间接基于QEMU模拟，以下探讨一些基于RTOS的固件分析框架。

基于RTOS固件

Avatar [6]

Avatar 在物理设备与外部模拟器之间架构一个软件代理Avatar，可以执行模拟器中的固件指令，来对物理设备进行IO操作。

Avatar框架比较经典(老牌)的框架之一，其最早将符号执行应用于嵌入式设备固件分析领域，提供了一个仿真器后端组件，用于控制 S2E(Symbolic Sombolic Exection)，选择性地执行二进制代码。S2E 是一个选择性的符号执行平台，底层基于QEMU之上。S2E 提供了一个功能强大的插件接口，可以通过这些接口拦截仿真事件，通过符号化执行特定代码段可以检测固件中存在的漏洞。

其迭代框架Avatar2 [7]允许分析人员选择不同的执行环境，共同在相同的执行状态上执行其分析任务，其优势在于可以在多个分析环境中共享不同分析工具得到的分析状态。Avatar2 支持的动态分析工具包括GDB、OpenOCD、QEMU、angr 和 PANDA。

使用方法这里略过，可以参见Avatar Github和Avatar2 Github，值得注意的是Avatar2编译使用较为简单。

Jetset [8]

Jetset来自一篇较新(2021)的论文，其使用符号执行来推断固件期望从目标设备得到什么操作，通过C模拟实现硬件外设模块功能，利用QEMU启动固件。

Jetset测试了13个不同的固件，包括3个架构、3个应用领域(电网、航空电子设备和消费电子设备)和5个不同的操作系统。同时Fuzzing了一个航空电子设备固件，挖掘出一个提权0Day。

抛开繁琐的细节，Jetset从整体上还是比较好理解的，即利用符号执行技术找到固件正常运行的代码流路径，再通过软件模块方式满足，最终实现固件的Rehosting。

Jetset安装和使用可参考Github：

# 安装 Jetset
apt-get install git make build-essential zlib1g-dev pkg-config libglib2.0-dev binutils-dev libboost-all-dev autoconf libtool libssl-dev libpixman-1-dev virtualenv xterm
Once you have these, you can build Jetset:

make clone
make config_qemu
make build_qemu
make virtualenv
make build_jetset_engine

# 运行 Jetset
The top-level script that coordinates symbolic execution and generates peripheral devices is in jetset_engine/execution/jetset_server.py.

Usage:

usage: jetset_server.py [-h] [--useFunctionPrologues] [--useSlicer]
                        [--useFinalizer] [--verbose] [--noAutoDetectLoops]
                        [--port PORT] [--soc SOCNAME] [-o OUTFILE]
                        [--cmdfile CMDFILE]

Run Symbolic Execution engine for Jetset

optional arguments:
  -h, --help            show this help message and exit
  --useFunctionPrologues
                        Try to infer the start of functions (for CFG) using
                        architecture specific function prologues
  --useSlicer           Use constraint slicer to improve performance of
                        constraint solving
  --useFinalizer        After making a certain decision n times, finalize and
                        make that always the solution
  --verbose             Print out all log messages and other warnings
  --noAutoDetectLoops   Omit auto loop detection
  --port PORT           Port number to communicate with Qemu (over localhost)
  --soc SOCNAME         Type of soc (console | heat_press | steering_control |
                        robot | gateway | drone | reflow_oven | cnc | stm32f4
                        | rpi | beagle)
  -o OUTFILE            output file
  --cmdfile CMDFILE     path to script to invoke qemu instance. If window
                        doesn't open, make sure that the qemu run script is
                        executable

HALucinator [9]

HALucinator利用硬件抽象层(HAL: Hardware Abstract Layers)作为Rehosting和分析固件的基础，通过提供HAL功能的高级替代品(称为HLE)，使硬件与固件脱钩，并利用QEMU模拟固件。

其主要贡献在于：

1、提出HAL库模拟技术，可在无需依赖实际硬件的情况下使用QEMU等模拟器仿真二进制固件，

改进了现有的依赖库匹配技术；

2、提出HALucinator仿真系统，可通过抽象处理程序和外设模型库的方式进行交互式仿真和固件Fuzzing；

3、通过对16个固件的模拟，证明了方法的实用性。并通过Fuzzing的方式发现了两个0day。

其缺点在于，HALucinator仅适用于固件中使用了芯片厂商提供了HAL的那些设备，并且编译环境要跟固件的编译环境类似，仅这两点就大大限制了其可用范围。

HALucinator使用可参见Github。

P²IM [10]

P²IM(Processor-Peripheral Interface Modeling)针对MCU处理器和外设之间的处理接口，根据处理器设计文档，自动化提供与之等价的接口模型来模拟外部 I/O 操作。

P²IM在模拟层面仍然使用QEMU，其主要使用抽象模型定义(Abstract Model Definition)和自动模块实例化(Automatic Model Instantiation)模块。抽象模型定义基于专家经验定义模型，把寄存器分为控制寄存器、状态寄存器、数据寄存器、控制-状态寄存器。自动模块实例化则基于之前的模型定义，基于执行对模型进行填充。主要是查找寄存器的类型、寄存器在内存中的位置、中断等。

P²IM只实现了寄存器和中断，没有实现DMA(Direct Memory Access)的情况，下文的DICE正为此问题而构建。其目录结构如下：

.
├── afl                           # fuzzer source code
├── docs                          # more documentation
├── externals                     # git submodules referencing external git repos for unit tests, real firmware, and ground truth
├── fuzzing
│   └── templates                 # "random" seeds and configuration file template to bootstrap fuzzing
├── LICENSE
├── model_instantiation           # scripts for instantiating processor-peripheral interface model and fuzzing the firmware
├── qemu
│   ├── build_scripts             # scripts for building QEMU from source code
│   ├── precompiled_bin           # pre-compiled QEMU binary for a quick start
│   └── src                       # QEMU source code. AFL and QEMU system mode emulation integration is based on TriforceAFL.
├── README.md
└── utilities
    ├── coverage                  # scripts for counting fuzzing coverage
    └── model_stat                # scripts for calculating statistics of the processor-peripheral interface model instantiated

安装与使用可参见Github。

DICE [11]

DICE是一种模拟并生成DMA(Direct Memory Access)输入的动态分析方法，其核心思想是识别和模拟抽象的DMA input channel(作者定义的一个抽象概念，可以视为固件与外设通过DMA交换数据的桥梁)，而不是模拟种类繁多的外设及控制器。

目前的针对于固件的动态分析一般无法处理固件中的DMA操作，比如上文的P²IM，从而限制分析所支持的设备种类以及代码覆盖率。作者在针对ARM Cortex-M的P²IM以及针对于MIPS M4K/M-class的PIC32模拟器上使用了DICE。在83个benchmarks上进行测试，检测到了来自5个不同厂商的9种不同的DMA 控制器。对7个fuzz-tested的真实世界的固件进行分析，执行路径比之前的高79倍，并额外发现了5个位置漏洞。

研究细节这里就不作展开，DICE主要贡献在于：针对DMA在基于MCU设备上的普遍性和多样性，通过集成到现有分析方案，实现了与硬件无关的DMA输入模拟，并能够自动化的推断出DMA缓冲区的位置和大小。

DICE结构如下：

.
├── DICE-Evaluation
│   ├── ARM
│   │   ├── DICE-P2IM-Utilities     # DICE-P2IM scripts for model instantiation 
│   │   ├── Fuzzing                 # Firmware binaries, source code and scripts for fuzz testing with DICE-P2IM
│   │   └── Unit-Test               # Firmware binaries, source code and scripts for unit test with DICE-P2IM
│   └── MIPS
│       └── Unit-Test               # Firmware binaries, source code and scripts for unit test with DICE-MIPS-emulator 
├── DICE-Patches                    # DICE patches (Add-ons) for P2IM and MIPS-emulator
├── DICE-precompiled
│   ├── ARM_bin                     # Precompiled QEMU-DICE-P2IM binaries with DMA input channels identification and emulation for the ARM Cortex-M
│   ├── ARM_bin_Disabled            # Precompiled QEMU-DICE-P2IM binaries with DMA input channels identification for the ARM Cortex-M
│   └── MIPS_bin                    # Precompiled QEMU-DICE-MIPS-emulator with DMA input channels identification for the MIPS M4K/M-class
├── mips-emulator                   # Vanilla MIPS emulator submodule
└── p2im                            # Vanilla P2IM framework submodule

安装与使用可参见Github。

Para-rehosting [12]

Para-rehosting针对MCU软件的可移植性问题，使用POSIX接口抽象和实现了一个可移植的MCU来降低移植难度，其会对MCU的常见函数建模。

Para-rehosting与前文介绍的HALucinator类似，也在HAL上做文章，其使用基于HAL的次要函数替换，即用主机上的等效后端驱动程序替换高级硬件功能，这些后端驱动程序由para- api调用，可以在许多MCU操作系统中重用。Para-rehosting成功地重新rehost了9个MCU操作系统，包括广泛部署的Amazon FreeRTOS、ARM Mbed、Zephyr和LiteOS，并使用动态分析工具（AFL和ASAN）发现了28个未知的bug，其中五个获得了CVE，19个被厂商承认。

官方推荐Para-rehosting在Ubuntu 18.04环境下编译使用，具体可参见Github。

Firmwire [13]

Firmwire是一个支持三星和联发科的全系统基带固件分析平台，它支持对基带固件映像进行模糊测试、模拟和调试。

FIRMWIRE提供基带专用API，可轻松添对供应商、固件映像和安全分析的支持。论文中选择 LTE 和 GSM 协议进行Fuzzing，发现7个可能导致RCE，其中包含 4 个0Day。

使用Firmwire需安装Panda(基于QEMU的仿真器，分支众多，本文就不在赘述)，安装使用了参见Firmwire手册，或从Github获取更多信息。

Fuzzware [14]

Fuzzware是一个以可扩展方式对原始单片机固件进行模糊测试的专用系统，其提出了一种细粒度的access modeling 方法，使用精准的MMIO建模，可以通过固件逻辑保存所有路径，帮助Fuzzing变换集中在改变重要的输入上，从而增加了代码覆盖率和Fuzzing效率。

论文中总结了之前一些Rehosting的方法和弊端：

1、High-level emulation：通过hook和从新部署已知库来解决缺少外设的问题，从而避免硬件访问抱错，这样会导致前期手动工作量很大；

2、Pattern-based modeling：通过将访问模式匹配到常见的静态硬件寄存器类型来建模外设寄存器，弊端是开销消除不完整(可以消除 full input overhead，无法消除partial input overhead)；

3、Guided symbolic execution-based modeling：将硬件寄存器视为符号输入源，然后将得到的符号值求解到固件最可能运行的路径，缺点当然是需要解决路径消除。

而对硬件外设的许多访问是short-lived，且这些访问的原因是与固件的整体行为无关的(例如：检查外设的状态或设置其配置)。对于确实影响固件行为的访问，固件通常不会使用所有的输入。(例如：directly：从32位数据中提取几位；indirectly：区分少数几个状态值) 因此Fuzzware给出了其解决方案，由于篇幅有限，仅阐释其MMIO访问处理设计，如下所示：

Fuzzing引擎生成一个原始输入文件，在MMIO访问时，MMIO访问模型将使用输入文件的块，并将其转换为(可能更大的)硬件生成值，然后将其提供给仿真固件。一旦原始输入耗尽，覆盖反馈将提供给Fuzzing引擎以指导继续Fuzzing操作。

Fuzzware的安装与使用可参见Github。

Periscope [15]

Periscope是用于分析设备与驱动之间交互的动态分析框架，并在此框架扩展提出了专用于该场景下的fuzzing框架PeriFuzz。

Periscope贡献在于提出了分析硬件和驱动之间交互的分析框架和fuzz框架，在技术上主要通过hook page fault handler来分析针对驱动与设备共享内存的读写操作，PeriFuzz在两种WiFi的驱动上发现了15个不同的漏洞，其中包括9个0Day。本文的核心贡献在于。

硬件和驱动之间的交互方式可以分为设备中断、MMIO(Memory mapping IO)和DMA(Direct Memory Access)3类，目前常用的分析设备和驱动间的方法主要包括以下3种：

1、通过为设备加入额外的能力来分析交互流程，好处是不依赖于操作系统，缺点是要求设备的可编程性或者分析人员即设备开发者。

2、分析驱动与虚拟设备在虚拟运行环境下的交互，但要求比较苛刻，对每款设备的分析都需要与之对应的虚拟化设备支持。

3、将设备向驱动传输的数据都认为是符号化的值，从而进行符号执行。虽然不需要虚拟化设备和可编程设备的支持，但可能会产生路径爆炸。

Periscope则通过hook MMIO或DMA下的allocate函数来标记共享的memory region，进一步通过hook page fault handler，将针对这些memory region的读写都记录下来，从而达到分析的效果。

PeriFuzz使用AFL作为Fuzzing工具，关于Periscope和PeriFuzz安装与使用可参见GitHub。

Pretender [16]

Pretender通过观测固件与设备之间的交互记录，使用机器学习/模式识别为每一个外设创建模型，再使用QEMU或angr结合生成的外设模型实现固件Rehosting。

值得注意的是，Pretender的使用条件比较苛刻，需安装Avatar，OpenOCD及其众多依赖项，在设置和部署时可能出现问题。组件中的任何一个小版本更改都可能导致工具无法运行，或者间歇性地运行，尤其在中断方面。官方建议在Ubuntu 16.04环境下，使用mkvirtualenv安装运行Pretender，具体可参见Github。

Laelaps [17]

Laelaps针对ARM MCU，通过符号执行辅助外设仿真来推断固件的预期行为，从而生成适当的输入以动态地引导具体模拟执行。

Laelaps结合了固件常规运行和符号执行，在常规运行因访问未实现的外设卡住时，切换到符号执行，以找到正确的输入，从而引导QEMU找到与实际执行最相近的路径。其主要贡献在于：

1、对基于ARM Cortex-M的MCU系统模型进行了抽象，并提取了系统仿真中所缺少的关键部分；

2、通过设计一个符号化引导的模拟器，填补了全系统设备仿真的缺失部分，该模拟器能够运行各种固件的ARM MCU与以前未知的外设；

3、融入了boofuzz、angr和PANDA等工具辅助动态分析，以Fuzzing固件中的漏洞。

Laelpas的安装和使用可参见Github。

μEmu [18]

μEmu是一种针对ARM微处理器(MCU)固件task code的动态分析工具，其核心组件是一个设备无关的仿真器，用于仿真未知外设的驱动代码。

在μEmu论文中，研究人员将以往Rehosting思路和弊端大致总结：

1、思路：将不支持的外设转发给真实的硬件。

弊端：需要真是硬件，无法大规模操作。

2、思路：模拟抽象层，固件依赖抽象层运行。

弊端：需要生态支持，不支持定制SOC；不好解耦固件和驱动的安全测试；没有对外设逻辑的测试。

3、思路：全系统模拟，可在硬件不可知时实现高保真模拟。

弊端：不能模拟复杂系统；P²IM需要盲猜状态寄存器的反应，搜索范围过大；Laelaps只能找到短期好的选择；P²IM和Laelaps都可能造成崩溃或死机。

μEmu不像现存的工作为每个外设建立一个通用的模型，μEmu着眼于正确模拟外设的每一个独立的存取点。要实现这一举措需解决外设输入获取和判断两个难点。μEmu使用符号执行获取模拟固件映像所需信息，固件收到的反应不正确时，执行阶段应该反射出错误，并进入一种失效状态，而失效的执行状态直接反应为一条失效的路径。

μEmu的结构如下：

.
├── LICENSE
├── README.md
├── docs                     # more documentation about implementation and configuration
├── uEmu-helper.py           # helper scripts to configurate μEmu based on configration file (e.g., μEmu.cfg)
├── launch-uEmu-template.sh  # template scripts to launch μEmu
├── launch-AFL-template.sh   # template scripts to launch AFL fuzzer
├── uEmu-config-template.lua # template config file of μEmu and S2E plugins
├── library.lua              # contains convenience functions for the uEmu-config.lua file.
├── uEmu-unit_tests          # uEmu unit test samples and config files
├── uEmu-fuzzing_tests       # uEmu fuzzing test samples (real-world MCU firmware) and config files
├── ptracearm.h
├── totalbbrange.py          # IDA plugin for basic block range calculation
├── vagrant-bootstrap.sh     # bootstrap file for vagrant box
└── Vagrantfile              # configuration file for vagrant box

安装与使用可参见Github。

Frankenstein [19]

Frankenstein 提供了一个虚拟环境来fuzzing无线设备固件，该工具在固件在运行时转储其当前状态，然后在虚拟环境中重新执行以进fuzzing。

Frankenstein使用QEMU运行仿真，其特点在于通过转储状态使固件“恢复生机”，并为芯片的虚拟调制解调器提供模糊输入。研究人员利用Frankenstein在Broadcom和Cypress蓝牙堆栈中发现三个0Day，该堆栈广泛应用于Apple、三星、Raspberry Pi等设备。

Frankenstein可使用Web接口配置，功能包括符号管理和内存转储，生成文件和链接器脚本均可自动生成。通过python3 manage.py runserver启动服务后，访问本机8000端口完成配置。

Frankenstein更多安装和使用信息可参见Github。

Rehosting的难点在于找到规模和精确的平衡点，想在效率和规模上有所建树需要提高工具的通用性，有些复杂固件难以模拟；而想精确模拟需要提高工具的专用性，此时又难以扩大规模。针对某些固件静态分析也不失为较好的方式，动静当然各有优劣，静态分析一般围绕符号执行和污点分析开展，下文提及部分静态分析工具。