# IoT Firmware Emulation and Its Security Application in Fuzzing: A Critical Revisit
## 2 Feature of MCU Firmware
### Features of MCU Firmware  
**F1: Diverse hardware dependency environments.** Unlike general software that interacts directly with users or external files, firmware relies on hardware peripherals for external interaction, making it tightly to these components. Figure 2 illustrates the hardware environment of a drone based on ARM Cortex-M4 MCU, showcasing various peripherals. These peripherals are categorized into on-chip (e.g., SPI, I2C, UART) and off-chip (e.g., WiFi, Button). Firmware accesses off-chip peripherals indirectly through on-chip peripherals. Firmware interacts with peripherals in four ways (highlighted with red lines):  
1. **Peripheral Registers R/W:** In most MCUs, such as ARM-based ones, peripheral hardware registers are memory-mapped (MMIO), allowing the processor to access them for status, configuration, and data queries. In a few MCUs, such as Intel 8051, these registers are accessed via port instructions.
2. **IRQ:** Actively verifying peripheral registers reading values wastes CPU cycles when no events occur. Many MCUs support configuring peripherals to trigger interrupts for events like timer completions or new data arrivals, allowing firmware to handle them promptly in interrupt service routines (ISRs).
3. **DMA:** To enhance high-throughput data transfer, some MCUs offer Direct Memory Access (DMA), enabling peripherals to transfer data directly to and from main memory, bypassing peripheral register reading via processor for faster large data transfers.  
Figure 2: Hardware components of a drone based on ARM Cortex-M4 MCU.  
Firmware functionality varies significantly across devices, such as drones and door locks, due to different peripheral controls and methods that can change at runtime. Consequently, peripheral usage by firmware is highly varied, involving numerous methods.  
**F2: Blurring of boundaries and interface among application, library, and driver code.** As illustrated in Figure 3, in general, MCU firmware consists of three layers: the driver layer, the operating system layer, and the application layer. The application layer, developed by programmers, contains the device's functional logic. The system layer includes real-time operating systems like FreeRTOS, Zephyr, and MbedOS for task scheduling and control, along with protocol libraries for external interactions. The driver layer manages hardware peripherals, with most code provided by manufacturers through board support packages (BSP) or open-source hardware abstraction layers (HALs). However, unlike general OSs and software, the layer boundaries in firmware are often blurred, with many components being optional, as shown in Figure 3. For instance, FreeRTOS [9] allows library or application code to interact with hardware directly, bypassing system calls like bare-metal firmware. Moreover, driver code can invoke system calls, such as system queue operations, making it difficult to distinguish driver layers from other code layers.  
**F3: Fragmentation of MCU Firmware Ecosystem.** MCU-based devices are tailored for specific tasks, such as sensors or drones, and their firmware is fragmented, unlike the dominant OSs like Linux or Windows. Over 20 IoT operating systems exist, each with its own compatible libraries, such as RT-Thread [10], which offers over 700 packages with multiple versions. Different MCU vendors provide their own HAL/BSP libraries, like STM32 CubeMX [11], which are specific to their MCUs. These libraries often implement different driver interfaces for peripheral controls, leading to incompatibility across various HAL/BSP functions and OS drivers. Developers can also integrate third-party libraries or create custom driver code for unique peripherals, compounding to the fragmented software stack in the MCU firmware ecosystem.