> For the complete documentation index, see [llms.txt](https://wokough.gitbook.io/iot-firmware-aio/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wokough.gitbook.io/iot-firmware-aio/wiki/fang-zhen-fen-xi.md). # 仿真分析 固件仿真又称固件模拟，或者**Rehosting**(有些差异，可参见笔者[**Rehosting综述**](https://www.freebuf.com/articles/endpoint/335783.html))，模拟是二进制动态分析的重要手段，一般在没有设备或需要成规模研究的情况下使用。 ### 一、基础 固件模拟根据不同需要可能有以下3个场景： (一) 只需模拟某个应用，比如web、upnpd、dnsmasq等，目的是对该应用作调试。此时可以直接用模拟工具运行该程序，只需考虑动态库是否能加载。 (二) 需要模拟固件shell，与整个系统有所交互。这里可以通过chroot改变根路径，并利用模拟工具执行/bin/sh。同时可以挂在/proc，这样在ps查看进程时看上去更加真实。 (三) 需要模拟整个固件启动，并且网卡等也能正常使用。这里要利用可模拟img系统的工具直接加载整个系统，也可以利用“套娃”大法，先模拟该架构的debian.img，再用chroot起设备的roofs。 从模拟方式出发常用的有QEMU、Unicon，包括后起之秀Qiling等等，这些框架或模拟系统，或模拟执行指令，代码也都有交集。 #### 1.1 QEMU [Qemu](https://www.qemu.org/)是最老牌的多架构模拟工具，上述3个使用场景qemu都可以满足。qemu可以下载安装也可以直接利用源安装，这里要注意的是如果模拟应用不仅需要qemu，还需安装qemu-user。 ``` # For ubuntu $ sudo apt-get install qemu $ sudo apt-get install qemu-user qemu-uesr-static ``` * qemu模拟应用 以模拟ARM固件为例，解开固件得到rootfs，下面是利用qemu模拟执行busybox： ``` iot@attifyos ~/Document> cp (which qemu-arm-static) ./rootfs/ iot@attifyos ~/Document> sudo chroot ./rootfs /qemu-arm-static /bin/busybox BusyBox v0.47 (2018.08.30-14:14+0000) multi-call binary -- GPL2 Usage: busybox [function] [arguments]... or: [function] [arguments]... BusyBox is a multi-call binary that combines many common Unix utilities into a single executable. Most people will create a link to busybox for each function they wish to use, and BusyBox will act like whatever it was invoked as. Currently defined functions: busybox, cat, chgrp, chmod, chown, cp, date, dd, df, echo, free, grep, gunzip, gzip, halt, hex, hostname, id, init, kill, killall, ln, ls, mkdir, mknod, more, mount, mv, ping, ps, pwd, reboot, rm, rmdir, sh, sleep, sync, syslogd, tail, tar, touch, tty, umount, uname, zcat ``` * qemu模拟shell 利用qemu模拟sh与上述情况相似，可以先mount proc，使得ps查看进程时显得更加真实： ``` iot@attifyos ~/Document> cd ./rootfs iot@attifyos ~/Document> rm -rf proc iot@attifyos ~/Document> sudo mount -t proc /proc ./proc iot@attifyos ~/Document> cd .. iot@attifyos ~/Document> sudo chroot ./rootfs /qemu-arm-static /bin/sh BusyBox v0.47 (2018.08.30-14:14+0000) Built-in shell Enter 'help' for a list of built-in commands. / # ls bin gm sbin usr dev lib store var etc qemu-arm-static sys / # ps PID PPID Uid Mem CPU St Command 1 0 0 29936 0.0 S init splash 2 0 0 0 0.0 S [kthreadd] 7 2 0 0 0.6 S [ksoftirqd/0] 332 1 0 26776 0.0 S systemd-journald 358 1 0 6568 0.0 S systemd-udevd 378 1 0 28144 0.0 S vmware-vmblock-fuse /run/vmblock-fuse -o rw,su 495 1 100 18500 0.0 S systemd-timesyncd 607 1 0 8244 0.0 S haveged --Foreground --verbose=1 -w 1024 608 1 0 42756 0.0 S VGAuthService 615 1 0 38824 0.0 S vmtoolsd 619 1 0 3740 0.0 S cron -f 621 1 103 6216 0.0 S avahi-daemon: running [attifyos.local] ... ``` * qemu模拟系统 qemu的功能很强大，可以像在vmware、virtualbox中一样安装系统： ``` $ qemu-img create -f qcow2 arm.qcow2 10G $ qemu-system-arm -m 1024M -sd arm.qcow2 -M vexpress-a9 -cpu cortex-a9 -kernel ../Downloads/vmlinuz-3.2.0-4-vexpress -initrd ../Downloads/initrd.gz -append "root=/dev/ram" -no-reboot ``` 利用qemu模拟完整固件最常规的办法就是将rootfs制作成img或qcow2文件，再用相应架构的qemu模拟执行，这里我们介绍一下前面提到的“套娃”大法。 首先下载[Debian官方](https://people.debian.org/~aurel32/qemu/)ARM构架的系统镜像。 挂在qcow2镜像，将rootfs拷贝至qcow2镜像： ``` $ sudo apt-get install libguestfs-tools # 利用guestmount挂在qcow2镜像 $ guestmount -a debian_wheezy_armel_standard.qcow2 -m /dev/sda1 /mnt # 拷贝rootfs $ cp -rf ./rootfs /mnt/root/rootfs $ guestunmount /mnt ``` 然后启动qcow2文件： `qemu-system-arm -M versatilepb -kernel vmlinuz-3.2.0-4-versatile -initrd initrd.img-3.2.0-4-versatile -hda debian_wheezy_armel_standard.qcow2 -append "root=/dev/sda1"` 利用chroot“套娃”系统： ``` $ chroot -u ./rootfs /bin/sh BusyBox v0.47 (2018.08.30-14:14+0000) Built-in shell Enter 'help' for a list of built-in commands. / # ``` 使用debian现成的qcow2镜像可以省去网卡和其他一些配置过程，提高模拟效率。 值得注意的是，qemu在对程序黑盒测试时也经常使用，比如AFL的qemu\_mode，在后面的篇章里我们会探讨，当然AFL同样可以使用unicorn\_mode，使用的就是下面介绍的模拟器unicorn。 #### 1.2 Unicorn [Unicorn](https://www.unicorn-engine.org/)一个基于Qemu的cpu指令模拟框架，也就是可以模拟任何的cpu指令。我们一般可以利用Unicorn指令级模拟特性： 对(IOT)程序作模糊测试，用于gdb插件，或代码模拟执行的插桩，修改代码逻辑，模拟执行一些复杂混淆代码，提高人工逆向效率，关于Unicorn模拟执行修改代码逻辑的教程比较多，这里不再赘述，下面介绍一款基于Unicorn的[IDA pro插件](https://github.com/H4lo/IDA_MIPS_EMU)，该插件可以在IDA pro中模拟执行，并给出执行结果，UnicornFuzz相关内容会在后面的篇章中介绍。 ``` #include int calc(int a,int b){ int sum; sum = a+b; return sum; } int main(){ calc(2,3); } ``` 上面非常简单的计算器C代码是该插件的官方示例，其mipsel IDA pro反汇编代码如下： ``` .text:00400640 .globl calc .text:00400640 calc: # CODE XREF: main+18↓p .text:00400640 .text:00400640 var_10 = -0x10 .text:00400640 var_4 = -4 .text:00400640 arg_0 = 0 .text:00400640 arg_4 = 4 .text:00400640 .text:00400640 addiu $sp, -0x18 .text:00400644 sw $fp, 0x18+var_4($sp) .text:00400648 move $fp, $sp .text:0040064C sw $a0, 0x18+arg_0($fp) .text:00400650 sw $a1, 0x18+arg_4($fp) .text:00400654 lw $v1, 0x18+arg_0($fp) .text:00400658 lw $v0, 0x18+arg_4($fp) .text:0040065C addu $v0, $v1, $v0 .text:00400660 sw $v0, 0x18+var_10($fp) .text:00400664 lw $v0, 0x18+var_10($fp) .text:00400668 move $sp, $fp .text:0040066C lw $fp, 0x18+var_4($sp) .text:00400670 addiu $sp, 0x18 .text:00400674 jr $ra .text:00400678 nop .text:00400678 # End of function calc ``` 创建一个 emu object `Python>a = EmuMips()` 配置模拟地址和参数 ``` Python>a.configEmu(0x00400640,0x00400678,[2,3]) [*] Init registers success... [*] Init code and data segment success! [*] Init Stack success... [*] set args... ``` 开始指令模拟 ``` Python>a.beginEmu() [*] emulating... [*] Done! Emulate result return: 0x5 ``` 通过Unicorn模拟执行得到sum(2+3)的结果为0x5。 **QEMU 提供了一个完整的仿真环境，既可以模拟硬件外设、整个系统，也可以模拟单个二进制程序。而 Unicorn 专注于 CPU 指令的仿真。** #### 1.3 Qiling [Qiling](https://www.qiling.io/)是一款很年轻的基于Unicorn的模拟器，专为IOT研究而生。Qiling可以作为IDA pro插件，也可以利用Qiling Unicornalf进行fuzz，还可以模拟IOT设备固件。Qiling用python3开发，可以直接用`pip3 install qiling`安装，以下是官方模拟ARMj架构路由器固件的部分代码： ``` import os, socket, sys, threading sys.path.append("..") from qiling import * def patcher(ql): ... def nvram_listener(): ... def my_sandbox(path, rootfs): ql = Qiling(path, rootfs, output = "debug") ql.add_fs_mapper("/dev/urandom","/dev/urandom") ql.hook_address(patcher ,ql.loader.elf_entry) ql.run() if __name__ == "__main__": nvram_listener_therad = threading.Thread(target=nvram_listener, daemon=True) nvram_listener_therad.start() my_sandbox(["rootfs/bin/httpd"], "rootfs") ``` 可以看到Qiling框架进一步简化了模拟所需代码，同时提供了指令级插桩功能，还是很强大的。 ### 二、类型模拟 模拟分析从固件类型出发粗略可分两种，一种是有明确**文件系统**目录的，一般基于**Linux**，**FreeBSD**等开源系统/内核；一种是没有的文件系统的**RTOS(Real-time operating system)**，比如Vxworks，FreeRTOS等。基于Linux的固件模拟相对简单，而RTOS模块较难分离。 #### 2.1 **基于Linux的固件** * **Firmadyne \[2]** **Firmadyne框架基于QEMU，旨在完成整个固件系统的运行。** 一些Rehosting\&Fuzzing的框架会在其基础上二次开发，Firmadyne模块如下图所示： ![](/files/tavO210iFvEXsJTgQXgT) 其运行流程是： 1、通过网络途径获取固件(ARM/MIPS)，并对固件解包； 2、利用定制动态链接库完成库函数劫持以完成NVRAM设备调用； 3、利用定制内核完成系统启动、网络探测、虚拟硬件和网络构建； 4、调用QEMU仿真系统。 对固件解包模拟的比较熟悉的小伙伴通过以上描述就会**大概率放弃该工具**，因为该流程存在大量不确定因素，成规模使用的**成功利率会很低**，而测试结果也正是如此。在Firmadyne获取的23035个固件中，8617个可解包；解包成功后有8591个可启动系统；启动系统后2797个可配置网络；最后只有1971个可以正常访问网络。也就是仅有\*\*22.9%\*\*的固件完成模拟并进行测试。 **Firmadyne**的使用方法这里略过，[Github](https://github.com/firmadyne/firmadyne)上教程也很详细。 * **FirmAE \[3]** **FirmAE目标是创造一个可以供用户动态调试分析的环境，而不是复现和硬件一模一样的环境,，其卖点是大规模(Large-Scale)。** 论文开头就直指“友商”Firmadyne，提出其模拟成功率低等问题，其将原本Firmadyne的成功率16.28%提高到79.36%，其底层还是使用了**QEMU**。FirmAE从固件的启动、网络、NVRAM、内核和其它五个方面，总结了导致固件仿真失败的原因及通用解决方法，并集成**check**、**run**、**analyze**和**debug**四种模式。check 模式会对固件进行各项仿真检测，并保存相关的日志信息记录在缓存文件中。run模式是根据check模式构建的各种处理信息进行仿真。 ![](https://image.3001.net/images/20220609/1654777051_62a1e4db79a606523b263.jpg) 在漏洞检测方面，FirmAE根据固件的文件系统和内核日志来推断**Web**服务状态，其发现了23个设备的12个0DAY。 **FirmAE**的使用方法网上不乏[教程](https://www.52pojie.cn/thread-1572565-1-1.html)**，也可以参考**[Github](https://github.com/pr0v3rbs/FirmAE)。 * **FirmAFL \[4]** **FirmAFL使用并改进了Firmdyne模拟方式，并利用AFL对IoT固件实施高通量灰盒Fuzzing。** FirmAFL的贡献在于： 1、针对全系统仿真(高通用性、低效率)和用户模式仿真(低通用性、高效率)的矛盾特点，提出了**增强过程仿真**的新技术； 2、设计并实现了第一个基于代码覆盖率的灰盒fuzzer—FirmAFL，支持mipsel、mipseb和armel三种CPU架构，涵盖Firmadyne数据库中90.2%的固件。 ![](/files/cZryriTpAHieX301SUk7) FirmAFL的使用可参考Github，以下简单梳理： ``` # 安装依赖 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 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 ``` ![](https://image.3001.net/images/20220609/1654777187_62a1e5634824bceaf8cf6.jpg) * **FirmFuzz \[5]** **FirmFuzz通过监控固件运行所生成的日志以检测漏洞，侧重挖掘命令注入、缓冲区溢出和空指针引用等。FirmFuzz在模拟层面基于QEMU，支持MIPS和ARM架构。** ![](https://image.3001.net/images/20220609/1654777227_62a1e58b2ec71417df53d.png) Firmfuzz论文中将固件可能存在的缺陷归因于三个方面，分别是**(Linux)内核**、**开源软件**和**厂商自研软件**，Firmfuzz重点**挖掘厂商自研软件漏洞**。其主要贡献点在于： 1、利用这些设备的web应用界面作为入口，生成语法上合法的输入； 2、将运行监控器嵌入固件的运行时环境中，以允许上下文感知的监控； 3、从**静态分析中收集信息**来指导固件模拟和Fuzzing生成。 **输入检测**、**插庄反馈**和**静态预分析**都是Fuzzing的常规操作，只是框架使用的方案各异。 ![https://image.3001.net/images/20220609/1654777309\_62a1e5dd022b8db39b16a.png](https://image.3001.net/images/20220609/1654777309_62a1e5dd022b8db39b16a.png) FirmFuzz的使用侧重Fuzzing，固件解包可单独使用firmadyne extractor或者binwalk，具体可参见[Github](https://github.com/HexHive/FirmFuzz)教程。 可以看到，在上述提及的Linux-based的框架和工具中，大部分都**直接或间接基于QEMU**模拟，以下探讨一些基于RTOS的固件分析框架。 #### 2.2 **基于RTOS固件** * **Avatar \[6]** **Avatar 在物理设备与外部模拟器之间架构一个软件代理Avatar，可以执行模拟器中的固件指令，来对物理设备进行IO操作。** ![](https://image.3001.net/images/20220609/1654777338_62a1e5fae19a928596d54.jpg) Avatar框架比较经典(老牌)的框架之一，其最早将符号执行应用于嵌入式设备固件分析领域，提供了一个仿真器后端组件，用于控制 S2E(Symbolic Sombolic Exection)，选择性地执行二进制代码。S2E 是一个选择性的符号执行平台，底层基于QEMU之上。S2E 提供了一个功能强大的插件接口，可以通过这些接口拦截仿真事件，通过符号化执行特定代码段可以检测固件中存在的漏洞。 其迭代框架**Avatar2 \[7]**允许分析人员选择不同的执行环境，共同在相同的执行状态上执行其分析任务，其优势在于可以在多个分析环境中共享不同分析工具得到的分析状态。Avatar2 支持的动态分析工具包括GDB、OpenOCD、QEMU、angr 和 PANDA。 使用方法这里略过，可以参见[Avatar Github](https://github.com/avatarone)**和**[Avatar2 Github](https://github.com/avatartwo)，值得注意的是Avatar2编译使用较为简单。 * **Jetset \[8]** **Jetset来自一篇较新(2021)的论文，其使用符号执行来推断固件期望从目标设备得到什么操作，通过C模拟实现硬件外设模块功能，利用QEMU启动固件。** Jetset测试了13个不同的固件，包括3个架构、3个应用领域(电网、航空电子设备和消费电子设备)和5个不同的操作系统。同时Fuzzing了一个航空电子设备固件，挖掘出一个提权0Day。 ![](https://image.3001.net/images/20220609/1654777376_62a1e6201bd03d24e7c98.jpg) 抛开繁琐的细节，Jetset从整体上还是比较好理解的，即**利用符号执行技术找到固件正常运行的代码流路径，再通过软件模块方式满足**，最终实现固件的Rehosting。 Jetset安装和使用可参考[Github](https://github.com/aerosec/jetset)： ``` # 安装 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模拟固件。** ![htt](https://image.3001.net/images/20220609/1654777444_62a1e6644ccec21896c9b.png) 其主要贡献在于： 1、提出HAL库模拟技术，可在无需依赖实际硬件的情况下使用QEMU等模拟器仿真二进制固件， 改进了现有的依赖库匹配技术； 2、提出HALucinator仿真系统，可通过抽象处理程序和外设模型库的方式进行交互式仿真和固件Fuzzing； 3、通过对16个固件的模拟，证明了方法的实用性。并通过Fuzzing的方式发现了两个0day。 其缺点在于，HALucinator**仅适用于固件中使用了芯片厂商提供了HAL的那些设备**，并且**编译环境要跟固件的编译环境类似**，仅这两点就大大限制了其可用范围。 HALucinator使用可参见[Github](https://github.com/embedded-sec/halucinator)。 * **P²IM \[10]** **P²IM(Processor-Peripheral Interface Modeling)针对MCU处理器和外设之间的处理接口，根据处理器设计文档，自动化提供与之等价的接口模型来模拟外部 I/O 操作。** **P²IM**在模拟层面仍然使用**QEMU**，其主要使用**抽象模型定义**(Abstract Model Definition)和**自动模块实例化**(Automatic Model Instantiation)模块。抽象模型定义基于专家经验定义模型，把寄存器分为控制寄存器、状态寄存器、数据寄存器、控制-状态寄存器。自动模块实例化则基于之前的模型定义，基于执行对模型进行填充。主要是查找寄存器的类型、寄存器在内存中的位置、中断等。 ![](https://image.3001.net/images/20220609/1654777495_62a1e697bfe6c08ee5946.png) 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](https://github.com/RiS3-Lab/p2im)。 * **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个位置漏洞。 ![](https://image.3001.net/images/20220609/1654777563_62a1e6db5c5b2f3aa4b38.png) 研究细节这里就不作展开，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](https://github.com/RiS3-Lab/DICE-DMA-Emulation)。 * **Para-rehosting \[12]** **Para-rehosting针对MCU软件的可移植性问题，使用POSIX接口抽象和实现了一个可移植的MCU来降低移植难度，其会对MCU的常见函数建模。** ![](https://image.3001.net/images/20220609/1654777596_62a1e6fcea17ea6fe9e9f.jpg) 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](https://github.com/MCUSec/para-rehosting)。 * **Firmwire \[13]** **Firmwire是一个支持三星和联发科的全系统基带固件分析平台，它支持对基带固件映像进行模糊测试、模拟和调试。** ![https://image.3001.net/images/20220609/1654777641\_62a1e72911752f5a504d3.jpg](https://image.3001.net/images/20220609/1654777641_62a1e72911752f5a504d3.jpg) FIRMWIRE提供基带专用API，可轻松添对供应商、固件映像和安全分析的支持。论文中选择 LTE 和 GSM 协议进行Fuzzing，发现7个可能导致RCE，其中包含 4 个0Day。 使用Firmwire需安装[Panda](https://github.com/panda-re/panda)(基于QEMU的仿真器，分支众多，本文就不在赘述)**，安装使用了参见**[**Firmwire手册**](https://firmwire.github.io/docs/installation.html)，或从[Github](https://github.com/FirmWire/FirmWire)获取更多信息。 ![h](https://image.3001.net/images/20220609/1654777760_62a1e7a0238756fd30865.png) * **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访问处理设计，如下所示 ： ![6.jpg](https://image.3001.net/images/20220609/1654777785_62a1e7b9c16f35af5f876.jpg) Fuzzing引擎生成一个原始输入文件，在MMIO访问时，MMIO访问模型将使用输入文件的块，并将其转换为(可能更大的)硬件生成值，然后将其提供给仿真固件。一旦原始输入耗尽，覆盖反馈将提供给Fuzzing引擎以指导继续Fuzzing操作。 Fuzzware的安装与使用可参见[Github](https://github.com/fuzzware-fuzzer/fuzzware)。 * **Periscope \[15]** **Periscope是用于分析设备与驱动之间交互的动态分析框架，并在此框架扩展提出了专用于该场景下的fuzzing框架PeriFuzz。** ![https://image.3001.net/images/20220609/1654777828\_62a1e7e4144eb6c88fc23.jpg](https://image.3001.net/images/20220609/1654777828_62a1e7e4144eb6c88fc23.jpg) 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](https://github.com/securesystemslab/periscope)。 * **Pretender \[16]** **Pretender通过观测固件与设备之间的交互记录，使用机器学习/模式识别为每一个外设创建模型，再使用QEMU或angr结合生成的外设模型实现固件Rehosting。** ![](https://image.3001.net/images/20220609/1654777883_62a1e81b2c9aeeef47e60.jpg) 值得注意的是，Pretender的使用条件**比较苛刻**，需安装Avatar，OpenOCD及其众多依赖项，在设置和部署时可能出现问题。组件中的任何一个小版本更改都可能导致工具无法运行，或者间歇性地运行，尤其在中断方面。官方建议在**Ubuntu 16.04**环境下，使用mkvirtualenv安装运行Pretender，具体可参见[Github](https://github.com/ucsb-seclab/pretender)。 * **Laelaps \[17]** **Laelaps针对ARM MCU，通过符号执行辅助外设仿真来推断固件的预期行为，从而生成适当的输入以动态地引导具体模拟执行。** ![h](https://image.3001.net/images/20220609/1654777927_62a1e84721dc635fa5dbd.jpg) Laelaps结合了固件常规运行和符号执行，在常规运行因访问未实现的外设卡住时，切换到符号执行，以找到正确的输入，从而引导**QEMU**找到与实际执行最相近的路径。其主要贡献在于： 1、对基于ARM Cortex-M的MCU系统模型进行了抽象，并提取了系统仿真中所缺少的关键部分； 2、通过设计一个符号化引导的模拟器，填补了全系统设备仿真的缺失部分，该模拟器能够运行各种固件的ARM MCU与以前未知的外设； 3、融入了boofuzz、angr和PANDA等工具辅助动态分析，以Fuzzing固件中的漏洞。 Laelpas的安装和使用可参见[Github](https://github.com/dongmu/Laelaps)。 * **μEmu \[18]** **μEmu是一种针对ARM微处理器(MCU)固件task code的动态分析工具，其核心组件是一个设备无关的仿真器，用于仿真未知外设的驱动代码。** ![](https://image.3001.net/images/20220609/1654777977_62a1e879a1cd2e8276642.jpg) 在μ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](https://github.com/MCUSec/uEmu#%CE%BCemu)\*\*。 * **Frankenstein \[19]** **Frankenstein 提供了一个虚拟环境来fuzzing无线设备固件，该工具在固件在运行时转储其当前状态，然后在虚拟环境中重新执行以进fuzzing。** ![](https://image.3001.net/images/20220609/1654778005_62a1e89534a87ef1fd5cb.jpg) Frankenstein使用**QEMU**运行仿真，其特点在于通过转储状态使固件“恢复生机”，并为芯片的虚拟调制解调器提供模糊输入。研究人员利用Frankenstein在Broadcom和Cypress蓝牙堆栈中发现三个0Day，该堆栈广泛应用于Apple、三星、Raspberry Pi等设备。 Frankenstein可使用Web接口配置，功能包括符号管理和内存转储，生成文件和链接器脚本均可自动生成。通过`python3 manage.py runserver`启动服务后，访问本机8000端口完成配置。 ![](https://image.3001.net/images/20220609/1654778033_62a1e8b167ee5a044d677.png) Frankenstein更多安装和使用信息可参见[Github](https://github.com/seemoo-lab/frankenstein)。 模拟的难点在于找到**规模**和**精确**的平衡点，想在效率和规模上有所建树需要提高工具的**通用性**，有些复杂固件难以模拟；而想精确模拟需要提高工具的**专用性**，此时又难以扩大规模。针对某些固件静态分析也不失为较好的方式，动静当然各有优劣，静态分析一般围绕**符号执行**和**污点分析**开展。