# IoT Firmware Emulation and Its Security Application in Fuzzing: A Critical Revisit
## 5 Emulation Fidelity
### Data/Memory Fidelity  
Data/memory fidelity ordered from coarsest to finest granularity are as follows:  
* **External Function:** Data output from firmware in an emulator leads to similar functions as real hardware.
* **Peripheral:** Data output from an emulator matches that of real hardware.
* **Internal Memory:** Data in the memory for running firmware in an emulator is consistent with real hardware.
* **Register:** Data in memory and registers for running firmware in an emulator is consistent with real hardware.
* **Perfect:** All data input, output, and memory space in the emulator matches real hardware at all times, which is virtually unobtainable.  
_Avatar_ interacts with real peripherals, ensuring high data memory fidelity. However, due to basic block translation, it handles peripheral interrupts only between blocks, not simultaneously with triggers, maintaining internal memory fidelity. In full system emulation, data fidelity relies on peripheral modeling methods. Solutions like \(SEmu\), which use external info for individual peripheral modeling, offer higher fidelity than general firmware-specific models like \(P^{2}IM\) and _Fuzzware_. In partial emulation, fidelity depends on the consistency of emulated module functions. For example, while \(HEAPSTER\) only emulates heap-related functions, resulting in low execution fidelity, it excludes peripheral data and maintains memory consistency with real hardware. _FirmWire_'s function replacement and peripheral emulation specific to baseband firmware also achieve high fidelity but with less automation. Similarly, high-level replacement solutions using functional replacement functions can achieve higher data consistency than peripheral emulation solutions. As shown in Figure 6, higher execution fidelity enhances data and memory fidelity in full system emulation. In addition, partial emulations or HAL replacement solutions bypass driver code and involve fewer peripheral operations, resulting in data and memory consistency that closely resembles the real device.  
**Fidelity VS Automation:** To achieve higher-fidelity peripheral modeling, simply analyzing firmware itself for general peripheral modeling is insufficient. Specific modeling for different peripherals requires hardware information. Extracting this information directly from the device can lead to hardware dependence issues, while obtaining it from hardware reference manuals or driver code is complex and error-prone. This complexity demands more human effort and reduces automation in high-fidelity modeling, as shown in Figure 6. In contrast, when focusing on a specific application domain, achieving high-fidelity peripheral emulation may not be essential. For instance, HAL-based solutions, as discussed in [24], can be utilized for testing application code exclusively. However, these solutions necessitate the manual implementation of replacement functions. Similarly, partial emulation can be employed to identify bugs that are less pertinent to peripheral operations, such as specific heap-related issues [37], which demand higher-fidelity emulation solely in memory. Nonetheless, the removal of peripheral-dependent code often requires manual intervention, which can impede automation due to indistinct boundaries and custom interfaces, as elaborated in Section 2. In summary, high-fidelity firmware emulation results in reduced automation, as illustrated in Figure 6 and Table 2.