Towards Fast and Scalable Firmware Fuzzing with Dual-Level Peripheral Modeling

Firmware vulnerabilities raise serious security concerns with the rapid growth in connected embedded devices. Fuzzing is an effective dynamic testing technique to find those vulnerabilities; however, firmware fuzzing is very limited by hardware dependence, such as on-chip and off-chip peripherals. The latest elegant approaches are making substantial progress in hardware-independent firmware fuzzing, but there is room for further improvement. We observe that hardware-independent peripheral modeling is scalable but slow at the register level; in contrast, at the abstract function level, it is fast but has limited scalability. Firmware fuzzing is still challenging in terms of achieving both scalability and efficiency. To address this problem, we present a dual-level approach that leverages register level modeling and selective function level modeling in a hybrid manner. Our method starts firmware fuzzing at the register level and connects peripheral handlers while executing hardware abstraction layer functions. We evaluate our method in terms of efficiency, scalability, and effectiveness with four real-world firmware and demonstrate the possibility of relatively fast and scalable firmware fuzzing that combines the benefits of the two levels.


I. INTRODUCTION
E MBEDDED systems are prevalent in our daily lives, including but not limited to the Internet of Things (IoT), automation systems, and smart cars. In particular, the growth in connected IoT devices is spectacular; for example, the revenue of such devices was approximately 12 billion in 2020 (about 15 times compared to 2010), which is likely to exceed 30 billion in 2025 [1]. This rapid progress has resulted in a significant increase in firmware vulnerabilities, which are listed in the NIST National Vulnerability Database [2]. Firmware vulnerabilities are critical security concerns, leading to not only digital but also physical damage through substantial failures, such as (late) crashes, reboots, and hangs, and even silent faults, in embedded systems [3], [4]. Moreover, these vulnerabilities could allow an attacker to access I/O interfaces such as SPI or UART and cause problems [5]. Unfortunately, it is cumbersome and difficult to test firmware from a security perspective, particularly when running on microcontrollers called MCUs and even worse as closed-source and blob binaries, due to the complex environmental dependencies required at run time [6], [7].
Fuzz testing or fuzzing is an effective and scalable testing method that is widely used to detect vulnerabilities in modern software [8]. Especially, coverage-guided fuzzers such as AFL [9] have successfully discovered many bugs in a variety of software [10]. Thus, the application of coverage-guided fuzzing to MCU firmware is highly desirable; however, this task is challenging [4]. Although on-chip fuzzing is preferable to address hardware dependencies, it is infeasible because of the limited resources in MCUs. Hardware emulation may deal with this problem by running every element on commodity computers, but this task is laborious and impractical because of the notorious heterogeneity in embedded hardware. For example, both on-chip/off-chip peripherals and architectural derivatives are extremely diverse in this domain. Indeed, none of the modern emulators can emulate the whole range of MCU peripherals, entailing that firmware executions are disrupted.
Recently, Muench et al. [4] studied firmware fuzzing and suggested that partial emulation with peripheral modeling might be a reasonable direction to the hardware-independent (peripheral-agnostic) firmware fuzzing. As a quick response to this, two invaluable methods were proposed. Feng et al. [7] presented P 2 IM, which abstracts diverse peripherals at the memory-mapped register level and handles firmware I/O based on automatically generated models for fuzzing. Clements et al. [6] proposed an approach of peripheral modeling at the abstract function level by replacing hardware abstraction layer (HAL) functions with software handlers for fuzzing; they introduced HAL-Fuzz along with a highlevel emulation system called HALucinator. Although both of these approaches realize hardware-independent firmware fuzzing, there remains a scope for further improvement. We observe that P 2 IM is scalable but relatively slow, whereas HAL-Fuzz is fast but less scalable and requires HAL functions and exact matching environments. Thus, it is a challenging task to satisfy both the scalability and efficiency of firmware fuzzing.
In this paper, we address this problem by presenting a duallevel approach that leverages both register level peripheral modeling and selective function level peripheral modeling in a hybrid manner. Our prototype system called hybrid emulation for firmware fuzzing (HEFF), starts firmware fuzzing at the register level and connects peripheral handlers while executing HAL functions. We combine the benefits of the two levels for fast and scalable firmware fuzzing. We implement our system based on P 2 IM and HAL-Fuzz, and perform evaluation in terms of efficiency, scalability, and effectiveness.
Contribution. This paper makes the following contributions.
• Dual-Level Peripheral Modeling. We proposed a novel approach of peripheral modeling in a hybrid manner to improve hardware-independent firmware fuzzing. • Fast and scalable firmware fuzzing. We implement our prototype system and conduct fuzzing experiments. • Effectiveness of bug finding. Our prototype system finds more bugs and finds them faster.
Organization. Section II explains related work. Section III describes backgrounds and problems. Section IV represents our system design. Section V reports our evaluation. Section VI makes a discussion. Section VII concludes this paper.

II. RELATED WORK
Based on WYCINWYC [4], we classify the work related to this study into three categories.

A. FULL EMULATION
In general-purpose OS-based devices, since hardware interaction occurs in the kernel, it is possible to process these interactions through the emulated kernel without special emulations of the peripherals. Firmadyne [11], Costin et al., [12], and FirmFuzz [13] are some of the reported vulnerability-finding studies targeting Linux-based embedded devices; these are based on a full system emulation of QEMU [14]. Additionally, FIRM-AFL [10] was proposed as an augmented process emulation technique that combines QEMU's two methods of full system-mode as well as usermode emulations to improve the compatibility and fuzzing performance degradation problems reported in previous studies.
Embedded-OS or no-OS abstraction-based devices communicate directly with the peripherals such that firmware emulation requires peripheral emulations. Moreover, all documents are required for full emulation of the board and peripherals of the target device. QEMU_STM32 [15] performs emulations using the STM32 library based on the expanded QEMU. Panda [16] uses the register knowledge of each board through the SDK and performs emulations by implementing all the logic for peripheral operation at the register-level in QEMU.
The accuracy of system-vulnerability detection through full emulation of the firmware is high, however, detailed knowledge of the hardware is often lacking, and even with sufficient information, a significant amount of engineering effort required to implement full emulators [4], [17]. Moreover, there is a disadvantage that such emulations are slow [4]. Therefore, HEFF, which explores vulnerabilities targeting embedded-OS or no-OS abstraction-based devices, uses a partial emulation technique that overcomes this limitation of full emulation.

B. PARTIAL EMULATION (HARDWARE-IN-THE-LOOP)
Hardware-in-the-loop partial emulations require firmware images and physical devices. Avatar [18] solves the hardware resource problem and performs firmware emulation by forwarding the state changes of all the memory and CPU registers of the emulator to the actual device. PROSPECT [19] provides a proxy that and tunnel arbitrary peripheral accesses within the virtual machine to the embedded system under test, while SURROGATES [20] provides an FPGA bridge between the host and target to reduce the operational overheads and enable analyses of complex systems. Further, Avatar 2 [21] is a multi-target orchestration platform that is implemented by extending Avatar. This approach enables state transfer between tools such as GDB, QEMU, angr, OpenOCD, and PANDA; WYCINWYC [4], PRETENDER [22], Unicorefuzz [23], and HALucinator [6] use Avatar 2 's approach between the emulators or analysis tools for firmware operation.
This method overcomes the limitation of full emulation in that it reduces the engineering effort in implementation by emulating physical devices. However, as described in §I, it is not easy to provide physical devices for emulation because there are various peripherals used in the embedded device. HEFF eliminates these peripheral dependencies that exist in hardware-in-the-loop by using the modeled peripheral instead of the physical device during partial emulation. Partial emulations with peripheral modeling require firmware images and peripheral modeling without the firmware source code or hardware. PRETENDER [22] performs peripheral modeling using machine-learning techniques, and P 2 IM [7] processes the peripheral I/O by abstracting them at the register-level. However, HALucinator [6] solves the peripheral device problem of firmware emulation by partial emulation using the processing method as a peripheral abstracted handler at the HAL function-level. HAL-Fuzz [24] performs firmware fuzzing by combining HALucinator and AFL. In addition, a recent study showed that, DICE [25] and Conware [26] can improve the limitations of P 2 IM [7] by modeling DMA or using symbolic execution. Unlike these approaches, HEFF combines register-and function-level modeling; hence, we compared HEFF with P 2 IM and HAL-Fuzz and observed that our dual-level peripheral modeling in emulation was scalable and efficient.

III. MOTIVATION
This section briefly describes the background of our study and clarifies the research problem through small experiments.

A. BACKGROUND 1) Firmware in Embedded Devices
Firmware is a low-level software that provides hardware controls in various embedded devices. Muench et al. [4] categorized those embedded devices into the following three classes according to the type of an operating system: general purpose OS, embedded OS, and no OS abstraction. At present, approximately 81% of the embedded devices are working with MCU firmware with no or less OS abstraction [27], which is our major concern in this study.

2) Firmware Fuzzing
Fuzzing embedded systems is similar to walking barefoot on a rough gravel road. Instrumentation tools on firmware without emulation is usually not possible. Full emulation of both processor and peripheral devices is impractical because of hardware diversity; furthermore, partial "hardware-in-theloop" emulation also presents poor fuzzing performance due to the bottleneck in communication with actual hardware devices. Such emulation is usually slow and unscalable for firmware fuzzing.
As explored in [4], partial emulation with peripheral modeling is a promising approach to firmware fuzzing, in which a processor is fully emulated while peripherals are only virtually modeled in software. This concept is con- vincing as any firmware can run on an emulator without real or fully emulated peripherals, as long as the emulator can provide acceptable peripheral data to firmware whenever required. Moreover, it is sufficient to consider only on-chip peripherals in fuzzing because firmware cannot access offchip peripherals directly. Recently, we observed two such promising approaches: P 2 IM [7] and HAL-Fuzz [6], [24].

B. PROBLEM DEFINITION
Our fundamental question is whether the partial emulation with peripheral modeling is fast and scalable for fuzzing. Therefore, we conducted two small experiments to clarify the research problem of our study. [7] treats peripherals as a black box by manipulating memory-mapped registers reserved for peripherals, rather than emulating any peripherals, so as to provide the equivalent processor-peripheral interfaces to a generic emulator (such as QEMU) for firmware fuzzing. For example, on ARM Cortex-M MCUs, peripheral registers are mandatorily mapped to the 0x40000000-0x5fffffff memory segment; thus, P 2 IM considers each memory word in this segment as a potential memory-mapped register. To this end, P 2 IM automatically instantiates the interface models for firmware specific information; it also monitors and handles every access to the peripheral registers. Although P 2 IM is highly scalable for firmware fuzzing, we observed that the performance at the register level can be further improved in terms of speed. Table 1 shows the result of our experiment that compares P 2 IM and HAL-Fuzz in terms of fuzzing performance (runs per second) on a firmware (960KB) that includes HAL functions. Although the number of basic blocks executed by P 2 IM is more than HAL-Fuzz which performs fuzzing through an external handler, P 2 IM is about four times slower than HAL-Fuzz for fuzzing. Readers are referred to Table 3 for further comparisons.

2) Function-Level Peripheral Modeling
HAL-Fuzz [6], [24] provides high-level replacements for HAL functions located by library matching techniques in firmware. It handles external interactions between the emulated firmware and the corresponding peripheral models for fuzzing without any peripheral emulation. HAL-Fuzz needs a specific tool named LibMatch to locate HAL functions in VOLUME 4, 2016 FIGURE 2. HEFF System Overview. In the emulation, whether the function which is in the function list is hooked in the firmware is expressed as "Yes" or "No". stripped binary firmware, which is highly dependent on the HAL object files that are used to identify HAL functions from arbitrary firmware in LibMatch. Although HAL-Fuzz is fast for firmware fuzzing thanks to the lower granularity at the abstract function level, we observed that rigorous requirements for the library matching environments can be relaxed to further improve the scalability. Figure 1 illustrates the result of our experiment that compares the HAL functions found by LibMatch in the different compilation environments for each firmware.
The HAL object files used in our experiment were compiled using GCC (2018 q4 version) with the-O0 optimization level. For the ideal result of LibMatch, we compiled six bare-metal firmware which are available in [28] (UART_1 [29], UART_2 [30], SPI_1 [31], SPI_2 [32], I2C [33] and GPIO [34]) in the same environment as that of HAL object files. Moreover, to compare the matching results according to the GCC version, we compiled the firmware using the GCC with -O0 (2017 q2 version), respectively. Finally, to confirm the results according to the optimization options, we also used GCC (2018 q4) with other optimization levels ( -O1, -O2, -O3, -Os and -Og).
In the ideal case, 95% (median) HAL functions were successfully identified. However, when the compiler versions were different, the matching result became considerably lower. Furthermore, when the optimization levels were even slightly different, no matching result came out. Since HAL-Fuzz is a function hooking-based approach, the exact identification of HAL functions by LibMatch is mandatory for firmware fuzzing and also for the proper emulation.

C. OUR DIRECTION
To achieve the benefits of peripheral modeling at both levels, we present a dual-level approach for peripheral modeling. We implemented a firmware fuzzer based on P 2 IM and HAL-Fuzz; named HEFF that might enjoy both levels optimistically half and half. In HEFF, the peripheral modeling starts at the register level, as in P 2 IM, because it is automatic and scalable. When a HAL function call is detected, functionlevel peripheral modeling is launched by connecting a peripheral handler, as in HAL-Fuzz. Although constructing the peripheral handler requires an engineering effort, this functionlevel process accelerates fuzzing. Furthermore, HEFF implemented in this way enable fast fuzzing of firmware which calls both HAL and non-HAL functions (e.g., CNC), which was impossible with existing function level processing alone, through dual-level peripheral modeling. In addition, we observed that even with fewer handlers, HEFF is faster than P 2 IM (Table 3) and more scalable than HAL-Fuzz (Table 5). HEFF performs efficient and scalable firmware fuzzing. Figure 2 illustrates an overview of HEFF's system architecture. HEFF takes a target firmware and a function list as inputs; after the preprocessing, it initiates firmware emulation via QEMU. Preprocessing enables independent control of functions to be processed at the function level during emulation via binary rewriting. For peripherals that cannot be emulated using QEMU, HEFF's dual-level peripheral modeling is employed. Dual-level modeling commences at register-level first, when the HAL function is hooked through the function address check in real time, peripheral modeling is performed through a handler at the HAL function-level. When the handler processing of the corresponding function is completed, the process returns to the next address of the instruction at which the HAL function is called, and emulation continues at the register-level. Finally, fuzzing in HEFF is performed by transferring the mutated input generated in the AFL to the part that requires an external input among the peripheral models generated at each level.

B. DUAL-LEVEL PERIPHERAL MODELING 1) Preprocessing
HEFF's dual-level peripheral modeling requires a pre-built QEMU and modified firmware.
Pre-built QEMU is built by inserting the HAL function list and the corresponding handlers into the QEMU implemented by P 2 IM. The HAL function list is composed of the function name and its start address, which can be created through the symbol parsing program or LibMatch analysis of the HALucinator [6]. In addition, the function handlers are implemented in C-code by modeling the external interactions between the emulated firmware and the peripherals of the corresponding target firmware.
Modified firmware is created by rewriting the hex value to the start point of listed functions so that the internal function if pc = Fl addr : 10: Convert to Function-level 11: AFL mutated input → Function Handler 12: return fuzzing output 13: else:

14:
Convert to Register-level 15: AFL mutated input → Peripheral Interface Model 16: return fuzzing output 17: return fuzzing result is not driven. Functions handled at function-level are only run via handlers. However, when the firmware runs in QEMU, it is difficult to control the entire function with only the start address because the translated tiny block of QEMU constantly changes. Therefore, to prevent internal functions from running, as described in lines 1-6 of Algorithm 1 above, HEFF finds the function start addresses in the binary from a given function list check logic and rewrites the first 2 bytes with bx lr (little endian: 70 47). In this manner, the function hooked directly parses the address to return in the function handle and specifies lr (r14). If the function is called, bx lr code is subsequently executed according to the modified lr information, so the function is immediately terminated and the next instruction is executed. Through this process, it is possible to reduce unnecessary internal function operation time during emulation and errors that appear because all basic blocks inside the function cannot be controlled during processing can be prevented.

2) Function address check
Function address check is the core of dual-level emulation, given that the function-level modeling is operated only through this process. The function address check logic monitors the program counter (PC) value, which is changed during firmware operation in real time. At this point, if the PC value matches the address in the function list, that function is hooked and converted to the function-level peripheral modeling.

3) Function-level peripheral modeling
In HEFF, function-level peripheral modeling is executed by connecting the handler corresponding to the hooked HAL function after the function address check. This peripheral abstraction handler was proposed in HALucinator [6], and it is created by converting the HAL function argument into data that the peripheral model can use. This facilitates easy handling of complex interactions between peripherals and processors. In addition, in most cases, because some hardware concepts such as power or clocking do not exist in the emulation, the return values of the handlers do not affect the emulation.

4) Register-level peripheral modeling
Peripheral modeling at the register-level continues as long as the HAL function is not hooked during emulation. In addition, this method uses P 2 IM's peripheral interface modeling. First, it classifies the control register (CR), status register (SR), and data register(DR) via register access patterns, and then defines the peripheral interface to be emulated in the target firmware through model abstraction. Next, by handling peripheral I/O with the peripheral interface defined through model instantiation, the running firmware can emulate without peripheral problems. Using the modeling of P 2 IM, HEFF continuously emulates at the register-level when it does not operate at the function-level.

C. FUZZER
HEFF performs fuzzing by providing a mutated input in two ways (represented on lines 11 and 15 of Algorithm 1) , given that it carries out peripheral modeling at the dual-level. After peripheral modeling at the register-level, HEFF channels the AFL-mutated input into the DR where the data value store. Whereas, after function-level peripheral modeling, the AFL-mutated input is provided to the function handler by parsing the mutated file of the AFL. For example, the HAL function argument of the receive-related function consists of (peripheral handle, data variable to store input, length of input value). The elements of this stored in the r0, r1, and r2 registers, respectively, when the function is called.
Concerning the fuzzing input of the handler a data variable to store the input and the length of the input value are required. The handler parses the r1 and r2 registers, splits the input in the mutated file of the AFL as much as the input value length (r2), and stores it in the data variable (r1) to be saved.

V. IMPLEMENTATION
We implemented HEFF on top of P 2 IM. HEFF takes a function list and firmware binary as the inputs. Using these inputs, function list check, function address check processes, and corresponding HAL function handlers are implemented by inserting 10 lines of C code in the QEMU. In addition, the firmware binary is automatically modified by our python script which based on radare2 [35]. Concerning the function handler, we obtained the function-level handling idea from HAL function hooking and handling in HAL-Fuzz. We   ported the C code function handler to gnu-eclipse-qemu in P 2 IM so that it could be used in HEFF. There are two major function handlers implemented in HEFF: a receive handler, which receives the input from the fuzzer, and a return-zero handler, which bypasses functions that are not specifically needed in the fuzzing and returns zero to the r0 register. Through the return-zero handler, we control the init-and transmit-related functions, because these functions do not require inputs during a firmware execution and consequently are not important for the fuzzing process. Meanwhile, we did not modify P 2 IM for register-level peripheral modeling.

A. EXPERIMENTAL SETUP
Experiment Data. In the experiments, we used four real firmware provided by P 2 IM [36]. The real firmware are CNC, PLC, Robot and Drone, which use HAL functions. CNC is a grbl milling controller firmware used in 3D printers and laser cutters, PLC (Programmable Logic Controller) is a firmware that controls important processes as part of the sterilizer, Robot is a motion controller firmware used in personal transport devices, and Drone is an autopilot controller firmware for quad-copters. The experiment was conducted by applying a total of 9 handlers, 4 handlers each including duplicates, to CNC, PLC, Robot, and Drone.
Seeds. The executable seed input values are different for each firmware. In the case of P 2 IM and HEFF, a random seed value is used, whereas HAL-Fuzz requires an input of a specific length for each firmware. Therefore, the input used in HAL-Fuzz was used in P 2 IM and HEFF only for the same firmware.  Platform and configuration. We conducted the experiments on a virtual machine with Intel® Xeon(R) Gold 6134 CPU and 16GB RAM, running 64-bit Ubuntu 18.04 system. In the experiment, we performed real-world firmware fuzzing 10 times [8] for 5h each.

B. RQ.1: EFFICIENCY OF HEFF
To answer RQ1, we compared the fuzzing execution speed with P 2 IM and HAL-Fuzz to confirm that the function handlers perform fuzzing efficiently. Table 3 represents P 2 IM is emulation at the register-level which makes fuzzing slow, so the number of executions is the lowest compared to the other two fuzzers. On the other hand, emulation in HAL-Fuzz is performed at the function-level, so faster fuzzing is possible, and as a result, the firmware is executed the most. At this time, CNC is not executed because there is no handler corresponding to the specific function ( §VII). Finally, HEFF, a combination of P 2 IM and HAL-Fuzz, shows approximately 0.9 times less execution result of P 2 IM and approximately 2 to 4 times more execution than HAL-Fuzz. Moreover, Figure 3 shows that HEFF executed at least 2.7% and at most 9.6% over P 2 IM. This may be seen as a small speed increase, but each handler is at least 2 times and up to approximately 400 times faster than P 2 IM when processing the same function (Table 4).In particular, handling HAL_Init at the function level can significantly reduce the time required. Nevertheless, because each handled HAL function is not called more often than other functions when the firmware is executed, the fuzzing speedup is not significantly affected. However, this result means that using more handlers in HEFF, achieves acceleration ( §VII). Furthermore, comparing otherwise, Table 6 shows that HEFF's firmware rewriting process reduces the   model instantiation time up to 21 seconds at register level except for one ( §VII). Therefore, HEFF is efficient because it can improve the speed even with a small number of handlers, and can also reduce the model instantiation time.

C. RQ.2: SCALABILITY OF HEFF
To answer RQ2, we compared the basic block coverage with HAL-Fuzz and P 2 IM. Table 5 shows the number of basic blocks of each fuzzer. Compared to HEFF, P 2 IM shows a small difference from a minimum of 0.94 times to a maxi-mum of 1.36 times, while HAL-Fuzz shows a big difference from a minimum of 3.58 times up to 6.05 times; during emulation, P 2 IM shows the highest basic block coverage, and HAL-Fuzz shows the lowest basic block coverage. In addition, HEFF covers a large number of basic blocks compared to that in the case of HAL-Fuzz, despite handling approximately 10% of HAL functions for each firmware. Figure 4, which compares HEFF's basic blocks with HAL-Fuzz, shows significant differences, thus, it means that HEFF is more scalable that HAL-Fuzz. In particular, in CNC, given that the "USART_putc" function, which is the transmitrelated function, does not exist in the function list. Therefore, the subsequent operation is stuck and cannot be executed, and further fuzzer execution is impossible in HAL-Fuzz. By contrast, in HEFF, even if there is no function called in the function list for handler processing, because processing is possible at the register-level, it could operate firmware and perform fuzzing. Therefore, it was confirmed that a more scalable fuzzing was possible through HEFF.

D. RQ.3: EFFECTIVENESS OF HEFF
To validate the effectiveness of HEFF in finding bugs, we performed 10 fuzzings of each fuzzer on 4 real firmwares and compared them against P 2 IM and HAL-Fuzz. As a result, HEFF, P 2 IM, and HAL-Fuzz all detected bugs in PLC only among the 4 firmwares (CNC, PLC, Robot, Drone). Figure 5 shows the number of crashes resulting from 5(h) fuzzing on the PLC. The number of crashes was counted based on the last basic block of the test case that crashed during fuzzing, HAL-Fuzz found only one crash, while HEFF found a total of 49 crashes, which is six more than P 2 IM. In addition, HEFF found the same number of crashes faster. Therefore, HEFF is effective because it can quickly detect more crashes.

VII. DISCUSSION
Remark that 19 out of 31 HAL function handlers (61%) are return-zero handlers [24]. This means that approximately 60% of the HAL functions do not affect the fuzzing performance. Accordingly, unlike HAL-Fuzz, HEFF does not implement function handlers that require complex logic but implements a return-zero handler for acceleration by connecting functions that do not affect firmware operation (Table 4). In addition, we implemented a receive handler for fuzzing. The HAL function handled by each experimental firmware is only approximately 10% of the total HAL functions called, and the frequency of the HAL functions called by each firmware is only approximately 0.24% 3% of the total function calls. However, despite the low frequency of calls, the fuzzing speed of the HEFF is improved (Table 3). That is, even a small effort of HEFF can affect the overall fuzzing speed. However, using many handlers, as implemented in HAL-Fuzz, faster speed improvement is expected. Moreover, Table 4 shows that Init functions require more time to process than other functions. Therefore, as more handlers are processed for Init-related functions, a greater speed improvement can be expected. Table 6 shows the model instantiation times of HEFF and P 2 IM which does not use modified firmware. By running the modified firmware, HEFF can reduce the model instantiation time in contrast to P 2 IM by not creating models for functions that are unnecessary for fuzzing. Therefore, the model instantiation times of the PLC, Robot, and Drone are faster than HEFF by 6.5% to 60% with respect to P 2 IM. However, for CNC, HEFF is approximately 2% slower than P 2 IM. This slight slowdown occurs because the HEFF's function address check logic makes it slower than the speed increased through the modified firmware. In other words, given that the function address check logic in HEFF monitors the changed PC value in real time, a tiny block overhead occurs. However, although the model instantiation time of HEFF is slower than P 2 IM in CNC, its difference is the smallest in terms of model instantiation time difference with respect to other firmware. Moreover, despite this slowdown, the overall fuzzing speed increased ( §VI-B).

VIII. CONCLUSION
To achieve fast and scalable firmware fuzzing, we proposed the new approach of dual-level peripheral modeling and implemented our prototype system called HEFF on top of P 2 IM. We demonstrated its efficiency, scalability, and effectiveness by performing the experiments with P 2 IM and HAL-Fuzz. In our prototype implementation, we adopted LibMatch and function handlers of HAL-Fuzz to deal with the abstract function level. Although HEFF was more efficient than P 2 IM and more scalable than HAL-Fuzz in our experiments, there remain limitations. We expect the following future study for further improvement.
As we adopted LibMatch, we were able to handle only HAL functions at the abstract function level. The basic idea of HAL-Fuzz is splendid but limits scalability. We plan to develop a more general function matching mechanism to deal with more functions at the abstract function level and to relax the prerequisite of the exact environmental match, entailing even faster fuzzing than now. We also expect that this approach could address the miscategorization problem at the register level; and in addition, it could handle the "write" functions, unnecessary for fuzzing, with a return-zero handler regardless of which register they access, for further improvement of fuzzing speed.