# IoT Firmware Emulation and Its Security Application in Fuzzing: A Critical Revisit
## 5 Emulation Fidelity
### Execution Fidelity  
Execution fidelity can be categorized into black-box, module-level, function-level, basic-block, instruction-level, cycle-level, and perfect. As illustrated in Figure 5, firmware emulators use _QEMU_[12], _Unicorn_[13], and _Ghiatra_[18] for instruction set translation. They convert instructions from a target set to a host set at the basic block level, using an intermediate representation (IR) for translation. This approach provides execution fidelity at most the basic block and instruction levels, even without considering peripheral emulation. Consequently, no firmware emulator can achieve cycle-level fidelity, which accurately replicates the CPU instruction cycle as real hardware does, or perfect fidelity, where the emulator's internal execution mirrors that of the actual machine.  
_Avatar_ achieves the highest execution fidelity by forwarding all peripheral access to real hardware. Full system emulation solutions emulate all peripherals to execute entire firmware code, thus their execution fidelity relies on the accuracy of peripheral modeling. Solutions like _AutoMap_, _SEmu_ and _Perry_, employ real hardware, hardware descriptions, or driver source code to construct individual models for each peripheral, offering higher fidelity compared to _QEMU_'s manually crafted peripheral emulation. Firmware-specific modeling solutions such as _Jetset_, _P\({}^{2}\)IM_, and _Fuzzware_, while more automated, depend on general assumptions without detailed hardware information, leading to lower fidelity. _Conware_, which does not model peripherals but instead uses fuzzing input, results in even lower fidelity. Partial emulation solutions such as _SFuzz_, _Gerbil_, and _HEAPSTER_ support only specific firmware functions, achieving module-level execution fidelity. For instance, _HEAPSTER_ concentrates on heap operations using heuristic methods, with many functions returning constraint-solved values without actual execution. High-level function replacement solutions fall in the middle; they bypass all peripheral emulation by hooking and replacing the original driver function with a manually crafted function on the host. This approach misses the execution of peripheral-related instructions, thereby ensuring function-level execution consistency. Generally, firmware emulation based solely on the firmware itself tends to have lower execution fidelity. Achieving higher fidelity necessitates additional hardware information and the development of specific peripheral models for various peripherals.  
\begin{table}
\begin{tabular}{c c c c} \hline \hline
**Firmware Feature** &
\begin{tabular}{c} **Enhanced** \\ **Component** \\ \end{tabular} & **Years** & **Tools** \\ \hline Random Peripheral & Coverage Feedback & 2023 & _Ember-IO_[34] \\ Interrupt & & 2023 & _Hoodur_[44] \\ \hline Multi-stream Input & & 2023 & _Hoodur_[44] \\ Magic Value Check & Input Generation \& Mutation & 2023 & _SpillTS_[43] \\ Multi-stream Input & & 2024 & _MultiFuzz_[45] \\ \hline Silent Bug & Bug Detection & 2018 & _WYCINWYC_[16] \\  & & 2020 & \(\mu\)_SBS_[46] \\ \hline \hline \end{tabular}
\end{table}
Table 3: Summary of fuzzing application enhancement solution.