IoT firmware Rehosting overview

Recently, I have taken some time to browse some IoT firmware security papers, tried some tools, and made a brief summary. The article mainlystarting from the paper, onRehosting(Hosting)The list may not be comprehensive, and it is hoped that it can inspire more people. This article is part of the author's summary of the 'Internet of Things Firmware Security Research Manual', and the entire book will be completed and published onGithubpublished.

Rehostingis firmwareDynamic analysisis an important means, this paper will clarifyRehosting山寨版 definition, focusing onSome methods of Rehosting, and briefly mentions firmwareStatic analysisand giveReference papersList.

0x00 Rehosting definition

Rehostingis generally translated asHostingBut it may be related toData center machine hostingThe meaning is ambiguous, whileRe+HostIt is more intuitive, that is, by running the required firmware modules on a new host, the purpose of low-cost dynamic analysis and security research on a large scale has been achieved. The term 'Rehosting' will be used directly in the following text.

[1]The following definitions are given:

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.

andRehostingSimilar concepts includeFirmware portingandFirmware simulation (Emulation)The author believes that the difference lies inFirmware portingRefers to compiling and installing PC software across platforms on a development board, which is often the opposite of rehosting;while withCompared to firmware simulation, rehosting generally only extracts the required functional modules and makes appropriate modifications when necessary to be used forFuzzing and security research.

Of course, this is a matter of personal opinion, and it is not the focus of this article. The papers and tools mentioned in this article focus on functional simulation and dynamic security testing, and will not delve into the distinction between concepts.

0x01 Rehosting method

RehostingThe most intuitive way to relate to the type of firmware, IOT firmware can be roughly divided into two types, one with a clearfile systemdirectory, generally based onLinux,FreeBSDsuch as open-source systems/kernels; one without a file systemRTOS (Real-time operating system)For example, Vxworks, FreeRTOS, and others. Rehosting of firmware based on Linux is relatively simple, while separating RTOS modules is more difficult, and most of the papers collected by the author are focused on RTOS.

Simulation operationis an important means of binary analysis, commonly used ones include QEMU, Unicon, including the rising stars such as Qiling, etc. These frameworks or simulation systems simulate execution instructions, and the code also has intersections. The focus of this article is not on this, and will not discuss the basic simulator in detail.

Firmware based on Linux

Firmadyne [2]

The Firmadyne framework is based on QEMU, aiming to complete the operation of the entire firmware system.

Some Rehosting&Fuzzing frameworks will develop on this basis, and the Firmadyne module is shown in the figure below:

Its operation process is:

1. Obtain the firmware (ARM/MIPS) through network means and unpack the firmware;

2. Use a customized dynamic link library to complete library function hijacking to complete NVRAM device calls;

3. Use a customized kernel to complete system startup, network detection, virtual hardware, and network construction;

4. Call the QEMU simulation system.

Those who are familiar with firmware unpacking simulation through the above description willThe probability of giving up the tool is highbecause there are a large number of uncertain factors in the process, and it is likely to give up the tool on a large scaleThe success rate will be very lowThe test results were also as expected. Among the 23,035 firmware images obtained by Firmadyne, 8,617 were unpackable; after unpacking, 8,591 could boot the system; after booting the system, 2,797 could configure the network; finally, only 1,971 could access the network normally. That is, only22.9%firmware simulation and testing.

FirmadyneThe usage method is omitted here,GithubThe tutorial is also very detailed.

FirmAE [3]

The goal of FirmAE is to create an environment that can be dynamically debugged and analyzed by users, rather than an environment that is exactly the same as the hardware, and its selling point is Large-Scale (Large-Scale).

The opening of the paper directly points to the 'competitor' Firmadyne, proposing its low simulation success rate and other issues, raising the original success rate of Firmadyne from 16.28% to 79.36%, and its underlying technology is still usingQEMU. FirmAE summarizes the causes and general solutions of firmware simulation failure from five aspects: firmware startup, network, NVRAM, kernel, and other five aspects, and integratescheckrunanalyzeanddebugThe 'check' mode performs various simulation tests on the firmware and saves relevant log information in cache files. The 'run' mode simulates based on the various processing information constructed by the 'check' mode.

In terms of vulnerability detection, FirmAE infers four modes based on the firmware file system and kernel logs.Webservice status, which discovered 12 0DAY vulnerabilities in 23 devices.

FirmAEThere are many online tutorials on the usage method oftutorialAlso, one can refer toGithub.

FirmAFL [4]

FirmAFL uses and improves the Firmadyne simulation method and uses AFL to implement high-throughput grey-box Fuzzing on IoT firmware.

The contributions of FirmAFL are as follows:

1. In view of the contradictions of the characteristics of full system simulation (high versatility, low efficiency) and user mode simulation (low versatility, high efficiency), it proposedEnhanced process simulationnew technology;

2. Designed and implemented the first grey-box fuzzer based on code coverage - FirmAFL, supporting three CPU architectures: mipsel, mipseb, and armel, covering 90.2% of the firmware in the Firmadyne database.

The usage of FirmAFL can be referred to Github, the following is a brief summary (see reference link (5)):

# Install dependencies
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

# Compile user mode
cd https://www.freebuf.com/articles/endpoint/FirmAFL/user_mode/
sed -i '40s/static //' util/memfd.c
https://www.freebuf.com/articles/endpoint/configure --target-list=mipsel-linux-user,mips-linux-user,arm-linux-user --static --disable-werror
make

# Compile system mode
cd https://www.freebuf.com/articles/qemu_mode/DECAF_qemu_2.10/
sed -i '40s/static //' util/memfd.c
https://www.freebuf.com/articles/endpoint/configure --target-list=mipsel-softmmu,mips-softmmu,arm-softmmu --disable-werror
make

# Install Firmadyne and set up the database
cd https://www.freebuf.com/
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 https://www.freebuf.com/articles/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 https://www.freebuf.com/articles/endpoint/
xz -d data.xz
mv data schema
chmod +x schema
sudo -u postgres psql -d firmware < https://www.freebuf.com/articles/endpoint/schema

Use Firmadyne to simulate firmware
cd https://www.freebuf.com/articles/
sudo https://www.freebuf.com/articles/endpoint/download.sh
sed -i '4s/#//' firmadyne.config
cp https://www.freebuf.com/articles/firmadyne_modify/makeImage.sh https://www.freebuf.com/articles/endpoint/scripts/
sudo https://www.freebuf.com/articles/endpoint/sources/extractor/extractor.py -b dlink -sql 127.0.0.1 -np -nk "https://www.freebuf.com/articles/firmware/DIR-815_FIRMWARE_1.01.ZIP" images
sudo https://www.freebuf.com/articles/endpoint/scripts/getArch.sh https://www.freebuf.com/articles/endpoint/images/9050.tar.gz
sudo https://www.freebuf.com/articles/endpoint/scripts/makeImage.sh 9050
sudo https://www.freebuf.com/articles/endpoint/scripts/inferNetwork.sh 9050

# Use FirmAFL for Fuzzing
cd https://www.freebuf.com/articles/
python3 FirmAFL_setup.py 9050 mipsel
cp https://www.freebuf.com/articles/endpoint/FirmAFL_config/9050/run.sh https://www.freebuf.com/articles/endpoint/image_9050/  # Replace the run.sh in image_9050 with the run.sh in FirmAFL_config
cd image_9050
sudo https://www.freebuf.com/articles/endpoint/run.sh
# After the firmware is started, execute in a new terminal
python3 test.py
sudo user.sh

FirmFuzz [5]

FirmFuzz detects vulnerabilities by monitoring the logs generated by firmware operation, focusing on command injection, buffer overflow, and null pointer reference, etc. FirmFuzz is based on QEMU in the simulation layer and supports MIPS and ARM architectures.

In the Firmfuzz paper, the possible defects in the firmware are attributed to three aspects, namely(Linux) kernelopen source softwareandvendor self-developed software, Firmfuzz focuses onMining vendor self-developed software vulnerabilities. Its main contribution lies in:

1, Utilize the web application interface of these devices as the entry point to generate syntactically valid inputs;

2, Embed the runtime monitor into the runtime environment of the firmware to allow context-aware monitoring;

3, FromCollect information in static analysisto guide firmware simulation and Fuzzing generation.

Input detectionInsert feedbackandStatic pre-analysisThey are all conventional Fuzzing operations, but the frameworks use different schemes.

The use of FirmFuzz focuses on Fuzzing, firmware unpacking can be used separately with firmadyne extractor or binwalk, for details, please refer toGithubTutorial.

It can be seen that most of the Linux-based frameworks and tools mentioned aboveDirectly or indirectly based on QEMUSimulation, the following discusses some firmware analysis frameworks based on RTOS.

Based on RTOS firmware

Avatar [6]

Avatar constructs a software proxy between the physical device and the external simulator, which can execute firmware instructions in the simulator to perform IO operations on the physical device.

The Avatar framework is one of the classic (old) frameworks, which was the first to apply symbolic execution to the field of embedded device firmware analysis. It provides a simulator backend component for controlling S2E (Symbolic Sombolic Exection) and selectively executing binary code. S2E is a selective symbolic execution platform based on QEMU. S2E provides a powerful plugin interface that can intercept simulation events, and by symbolically executing specific code segments, it can detect vulnerabilities existing in the firmware.

Its iterative frameworkAvatar2 [7]It allows analysts to choose different execution environments and execute their analysis tasks on the same execution state together. Its advantage lies in the ability to share analysis states obtained from different analysis tools in multiple analysis environments. The dynamic analysis tools supported by Avatar2 include GDB, OpenOCD, QEMU, angr, and PANDA.

The usage method is omitted here, but can be referred to inAvatar GithubandAvatar2 GithubIt is worth noting that the Avatar2 compiler is relatively simple to use.

Jetset [8]

Jetset comes from a relatively new (2021) paper that uses symbolic execution to infer what operations the firmware expects to receive from the target device, implements the hardware peripheral module function through C simulation, and uses QEMU to boot the firmware.

Jetset tested 13 different firmware, including 3 architectures, 3 application fields (power grid, avionics equipment, and consumer electronics equipment) and 5 different operating systems. At the same time, a 0Day privilege escalation was found in an avionics equipment firmware through Fuzzing.

Ignoring the tedious details, Jetset is still relatively easy to understand overall, that isBy using symbolic execution technology, find the code flow path of the firmware running normally, and then meet through the software module methodto ultimately achieve firmware Rehosting.

For installation and usage of Jetset, please refer toGithub:

# Install 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

# Run 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 utilizes the hardware abstraction layer (HAL: Hardware Abstract Layers) as the foundation for rehosting and analyzing firmware, by providing an advanced substitute for HAL functions (referred to as HLE), it decouples hardware from firmware and uses QEMU to simulate firmware.

Its main contribution lies in:

1. Proposed the HAL library simulation technology, which can simulate binary firmware using emulators such as QEMU without depending on actual hardware;

Improved the existing dependency library matching technology;

2. Proposed the HALucinator simulation system, which can be used for interactive simulation and firmware Fuzzing through the interaction with the abstract processor and peripheral model library;

3. By simulating 16 firmware versions, the practicality of the method has been proven. And two 0days were discovered through Fuzzing.

The disadvantages lie in that, HALucinatorit is only applicable to devices that use the HAL provided by the chip manufacturer in the firmware，andThe compilation environment should be similar to the compilation environment of the firmware，these two points alone greatly limit its scope of use.

HALucinator usage can be referred toGithub.

P²IM [10]

P²IM (Processor-Peripheral Interface Modeling) is designed for the processing interface between MCU processors and peripherals, providing equivalent interface models for simulation of external I/O operations based on the processor design documentation.

P²IMis still used at the simulation levelQEMU，its main useabstract model definition(Abstract Model Definition) andAutomatic module instantiation(Automatic Model Instantiation) module. The abstract model definition is based on expert experience to define models, dividing registers into control registers, status registers, data registers, and control-status registers. Automatic module instantiation is based on the previous model definition, filling the model based on execution. It is mainly to find the type of the register, the location of the register in memory, and interrupts.

P²IM only implements registers and interrupts, without implementing DMA (Direct Memory Access). The DICE mentioned below is constructed for this issue. The directory structure is as follows:

.
├── 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

Installation and usage informationGithub.

DICE [11]

DICE is a dynamic analysis method for simulating and generating DMA (Direct Memory Access) inputs, with its core idea being the identification and simulation of an abstract DMA input channel (an abstract concept defined by the author, which can be regarded as a bridge for firmware and peripherals to exchange data through DMA), rather than simulating a variety of peripherals and controllers.

Currently, dynamic analysis for firmware generally cannot handle DMA operations in firmware, such as P²IM mentioned above, which limits the types of devices supported by the analysis and the code coverage. The authors have used DICE for P²IM on ARM Cortex-M and for PIC32 simulator on MIPS M4K/M-class. Tests were conducted on 83 benchmarks, detecting 9 different DMA controllers from 5 different manufacturers. Analysis of 7 fuzz-tested real-world firmware resulted in execution paths that were 79 times higher than before, and an additional 5 location vulnerabilities were discovered.

The research details are not expanded here, the main contribution of DICE is: in view of the universality and diversity of DMA on MCU-based devices, by integrating into existing analysis solutions, it has achieved DMA input simulation that is independent of hardware, and can automatically infer the location and size of DMA buffers.

DICE structure is as follows:

.
├── 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

Installation and usage informationGithub.

Para-rehosting [12]

Para-rehosting addresses the portability issues of MCU software by using POSIX interface abstraction and implementing a portable MCU to reduce the difficulty of porting, which models common MCU functions.

Para-rehosting is similar to the HALucinator introduced earlier, which also operates on HAL. It uses secondary function substitution based on HAL, that is, replacing advanced hardware functions with equivalent backend drivers on the host, which are called by the para-api and can be reused in many MCU operating systems. Para-rehosting successfully rehosted 9 MCU operating systems, including widely deployed Amazon FreeRTOS, ARM Mbed, Zephyr, and LiteOS, and used dynamic analysis tools (AFL and ASAN) to discover 28 unknown bugs, of which five obtained CVE, and 19 were recognized by manufacturers.

Officially recommended Para-rehosting for compilation and use on Ubuntu 18.04, for more details, please refer toGithub.

Firmwire [13]

Firmwire is a full-system baseband firmware analysis platform that supports Samsung and MediaTek, supporting fuzz testing, simulation, and debugging of baseband firmware images.

FIRMWIRE provides dedicated API for baseband, which can easily add support for suppliers, firmware images, and security analysis. The paper selects LTE and GSM protocols for Fuzzing, and finds 7 potential RCE causes, including 4 0Days.

Firmwire needs to be installedPanda(Based on QEMU emulator, with many branches, this paper will not elaborate on it)),Installation and usage, please refer toFirmwire manual, or fromGithubFor more information.

Fuzzware [14]

Fuzzware is a dedicated system for fuzz testing original single-chip firmware in an scalable way, which proposes a fine-grained access modeling method, using precise MMIO modeling, which can save all paths through firmware logic, helping Fuzzing transformation to focus on changing important inputs, thereby increasing code coverage and Fuzzing efficiency.

The paper summarizes some previous Rehosting methods and their drawbacks:

1、High-level emulation: ByhookAnd solving the problem of missing peripherals by deploying known libraries, thus avoiding hardware access errors, which would lead to a large amount of manual work in the early stage;

2、Pattern-based modeling: By matching the access patternMatchingModeling peripheral registers to common static hardware register types, the drawback is that overhead elimination is incomplete (can eliminate full input overhead, but cannot eliminate partial input overhead);

3、Guided symbolic execution-based modeling: Treat hardware registers asSymbolicInput source, and then solve the symbolic values to the most likely running path of the firmware, the drawback of course is that path elimination needs to be solved.

Many accesses to hardware peripherals are short-lived, and the reasons for these accesses are unrelated to the overall behavior of the firmware (for example: checking the status of peripherals or setting their configurations). For accesses that indeed affect the behavior of the firmware, the firmware usually does not use all the inputs. (For example: directly: extracting several bits from 32-bit data; indirectly: distinguishing a few state values) Therefore, Fuzzware provides its solution, due to the limited space, only the MMIO access processing design is explained as follows:

The Fuzzing engine generates an original input file. When MMIO access occurs, the MMIO access model will use the blocks of the input file and convert them into (possibly larger) hardware-generated values, and then provide them to the simulated firmware. Once the original input is exhausted, the coverage feedback will be provided to the Fuzzing engine to guide the continuation of the Fuzzing operation.

For the installation and usage of Fuzzware, please refer toGithub.

Periscope [15]

Periscope is a dynamic analysis framework for analyzing the interaction between devices and drivers, and proposes a specialized fuzzing framework PeriFuzz for this scenario.

Periscope's contribution lies in proposing an analysis framework and fuzz framework for the interaction between hardware and drivers, and technically mainly through hooking the page fault handler to analyze the read and write operations for the shared memory between the driver and the device, PeriFuzz found 15 different vulnerabilities on two WiFi drivers, including 9 0Days. The core contribution of this article lies in.

The interaction methods between hardware and drivers can be divided intoDevice interruptMMIO (Memory mapping IO)andDMA (Direct Memory Access)3 types, and the commonly used methods for analyzing devices and drivers currently include the following 3 types:

1. By adding additional capabilities to the device toAnalyze the interaction processAdvantages are that it does not depend on the operating system, but disadvantages are that it requires the programmability of the device or the analysis personnel, i.e., the device developer.

2. Analyze the interaction between the driver and the virtual device inVirtual operationinteraction, but the requirements are very strict, and the analysis of each device requires corresponding support from the virtualization device.

3. Treat all the data transmitted from the device to the driver as symbolic values, and thusSymbolic ExecutionAlthough it does not require support from virtualization devices and programmable devices, it may cause path explosion.

Periscope marks the shared memory region by hooking the allocate function under MMIO or DMA, and further records the read and write operations for these memory regions by hooking the page fault handler, thus achieving the effect of analysis.

PeriFuzz uses AFL as the Fuzzing tool. For the installation and usage of Periscope and PeriFuzz, please refer toGitHub.

Pretender [16]

Pretender observes the interaction records between firmware and devices, creates a model for each peripheral using machine learning/pattern recognition, and then uses QEMU or angr combined with the generated peripheral model to implement firmware Rehosting.

It is worth noting the usage conditions of PretenderVery strict, it is necessary to install Avatar, OpenOCD and its many dependencies, and there may be problems in setting and deployment. Any small version change in the component may cause the tool to fail to run or to run intermittently, especially in terms of interruptions. The official recommendation is inUbuntu 16.04environment, usemkvirtualenvInstall and run Pretender, the specific information can be seen inGithub.

Laelaps [17]

Laelaps for ARM MCU, through symbolic execution to assist in peripheral simulation to infer the expected behavior of the firmware, thereby generating appropriate inputs to dynamically guide the specific simulation execution.

Laelaps combines firmware regular operation and symbolic execution, switching to symbolic execution when the regular operation is stuck due to accessing an unimplemented peripheral card, to find the correct input and guideQEMUFind the path closest to the actual execution. Its main contribution lies in:

1. Abstracted the MCU system model based on ARM Cortex-M and extracted the key parts missing in system simulation;

2. By designing a symbolic guided simulator, it fills the missing part of full system device simulation, which can run various firmware ARM MCU and previously unknown peripherals;

3. Integrated with boofuzz, angr, and PANDA and other tools to assist in dynamic analysis, to fuzz vulnerabilities in firmware.

The installation and use of Laelpas can be seen inGithub.

μEmu [18]

μEmu is a dynamic analysis tool for firmware task code of ARM microprocessors (MCU), with its core component being a device-independent emulator used to simulate the driver code of unknown peripherals.

In the μEmu paper, researchers summarize the previous Rehosting approach and disadvantages roughly:

1. Approach:Forward unsupported peripherals to real hardware.

Disadvantages: need real hardware, cannot be operated on a large scale.

2. Approach:Simulation abstraction layer, firmware depends on the operation of the abstraction layer.

Disadvantages: need ecological support, do not support custom SOC; it is not easy to decouple the security test of firmware and drivers; there is no test for peripheral logic.

3. Approach:Full system simulation can achieve high-fidelity simulation when hardware is unknown.

Disadvantages: cannot simulate complex systems;P²IMIt is necessary to guess the response of the status register blindly, and the search range is too large;Laelapscan only find short-term good choices;P²IMandLaelapsmay cause crashes or system crashes.

μEmu does not create a general model for each peripheral device like existing work, μEmuFocusing on correctly simulating each independent access point of the peripheral devices. To implement this measure, it is necessary to solve the input of peripheral devicesObtainandJudgmentTwo difficulties. μEmu usesSymbolic ExecutionObtain the required information for simulating firmware images, and when the firmware receives an incorrect response, the execution phase should reflect the error and enter a failure state, with the failed execution state directly reflecting a failed path.

μEmu 的结构如下：

.
├── LICENSE
├── README.md
├── docs                     # 关于实现和配置的更多文档
├── uEmu-helper.py           # 基于配置文件（例如，μEmu.cfg）配置 μEmu 的辅助脚本
├── launch-uEmu-template.sh  # 启动 μEmu 的模板脚本
├── launch-AFL-template.sh   # 启动 AFL 模糊测试器的模板脚本
├── uEmu-config-template.lua # μEmu 和 S2E 插件的模板配置文件
├── library.lua              # 包含方便的函数，用于 uEmu-config.lua 文件。
├── uEmu-unit_tests          # uEmu 单元测试样本和配置文件
├── uEmu-fuzzing_tests       # uEmu 模糊测试样本（真实世界 MCU 固件）和配置文件
├── ptracearm.h
├── totalbbrange.py          # IDA 插件，用于基本块范围计算
├── vagrant-bootstrap.sh     # vagrant 虚拟机的引导文件
└── Vagrantfile              # 配置文件用于 vagrant 虚拟机

Installation and usage informationGithub.

Installation and usage can be seen

Frankenstein [19]

Frankenstein provides a virtual environment for fuzzing wireless device firmware. This tool dumps the current state of the firmware while it is running and then re-executes it in a virtual environment for fuzzing.QEMUFrankenstein uses

Frankenstein can be configured using a Web interface, including symbolic management and memory dump. File and linker scripts can be automatically generated. By running simulation, its characteristic is to 'revive' the firmware through dumps of the state and provide fuzzy input for the virtual modem of the chip. Researchers have used Frankenstein to discover three 0Day vulnerabilities in Broadcom and Cypress Bluetooth stacks, which are widely used in devices such as Apple, Samsung, Raspberry Pi, etc.python3 manage.py runserverAfter starting the service, access the local 8000 port to complete the configuration.

For more installation and usage information about Frankenstein, please refer toGithub.

RehostingThe difficulty lies in findingScaleandPrecisionbalance point. To make a mark in efficiency and scale, it is necessary to improve the tools'GeneralitySome complex firmware is difficult to simulate; while precise simulation requires improving the tools'SpecializationIt is difficult to scale up at this point. Static analysis of some firmware is also a good approach. Static and dynamic analysis each have their own advantages and disadvantages. Static analysis generally revolves aroundSymbolic ExecutionandTaint AnalysisThis section will introduce some static analysis tools.

0x02 Static Analysis Tools

PATCHECKO [20]

PATCHECKO is a framework for detecting executable file vulnerabilities and the existence of patches, known as PATCHECKO. It combines static and dynamic detection methods and can perform vulnerability detection on binary code for X86 and arm architectures.

KARONTE [21] Github

KARONTE is a static analysis method that can analyze embedded device firmware by modeling and tracking multi-binary interactions. This method is based on taint information analysis to detect insecure interactions and identify vulnerabilities.

SaTC [22] Github

SaTC can focus on data introduction points strongly related to front-end inputs in the back-end execution body by utilizing shared keywords between front-end and back-end as input for taint analysis, thus starting taint analysis from there, reducing the complexity of symbolic execution, and being able to discover various types of security vulnerabilities more accurately and efficiently.

Firmalice [23]

Firmalice is a binary static analysis framework that can automatically detect authentication bypass vulnerabilities in firmware programs. Firmalice is built on a symbolic execution engine and combines program slicing techniques to improve its extensibility.

FIE [24]

For some firmware, a complete analysis is difficult to handle, and various imprecise sources in the analysis may lead to false positives or false negatives. FIE uses symbolic execution to describe peripherals, improves symbolic execution technology to adapt to the specific functions of firmware, and is committed to discovering memory errors in firmware.

PASAN [25]

PASAN is the first static analysis tool used to detect intrinsic problems in concurrent peripheral access of embedded systems. PASAn automatically searches for the MMIO address range of each peripheral using the memory layout prepared by the parser, extracts the internal state machine of the peripheral using the corresponding device driver, and automatically detects concurrent bugs in peripheral access.

Basespec [26] Github

BaseSpec is a method for comparative analysis of software and settings in baseband firmware. By utilizing standard message structures, BaseSpec can systematically check the information structure in the baseband software.

LightBlue [27] Github

LightBlue is a BLE firmware analysis trimming tool that can automatically sense the framework of the Bluetooth stack configuration files, allowing users to automatically reduce their Bluetooth attack surface by deleting unnecessary Bluetooth features.

FirmXRay [28] Github

FirmXRay is a static disassembly plugin for Ghidra BLE firmware, which directly analyzes link layer vulnerabilities in firmware.

0x03 Summary

1. Ifrom the papers I have read recentlystarting frommade a comprehensive review of IoT firmware Rehosting, although the general purpose of Rehosting is usually Fuzzing and other dynamic analysis, but since Fuzzing can be discussed separately, the article did not dwell too much on it.

2. In the summary, I found that most Rehosting frameworks still preferQEMU, involving little in the simulation of Unicon and other instruction sets; frameworks or symbolic execution find simulationpath, or study MCU and peripheralsrelationship, or forHALand other MCU features, the ultimate goal isallowing the firmware Rehosting to complete more and longer sequential execution.

3. My theoretical foundation is shallow, and I read papers mainly to make up for my own deficiencies. While browsing these papers, I found that the focus of academia and practice is different. Academia focuses on theory and research process, and the achievements of predecessors are both references and have to be avoided, so some papers give people the illusion of exerting great effort to solve minor problems. Compared with these, papers inSummarizing the problems in the fieldandSolution approachwhich is more attractive to me.

4. Due to my limited ability, some papers (tools) in this field may be omitted, and what is mentioned in the text can only be touched upon superficially. Those who are interested can read the original papers listed in the following list. Simply speaking, when it comes to firmware analysis tools, from the perspective of ease of use or secondary development, I am more inclined toOpen-source frameworks or commercial software in the laboratoryOf course, many frameworks and software also have top conference papers as support.