Emulation-Based Fuzzing of Encrypted Firmware

Abstract

Internet of Things (IoT) devices are frequent targets of cyber attacks, and firmware emulation is essential for enabling automated techniques like fuzzing to uncover vulnerabilities. However, the growing use of encryption in firmware poses significant challenges for building accurate emulated environments. To overcome this, we present EncryptAFL, the first IoT fuzzer specifically tailored for devices with encrypted firmware. In contrast to existing methods that primarily focus on peripheral emulation, EncryptAFL places greater emphasis on automating the decryption process. We evaluate EncryptAFL using real-world firmware and known vulnerabilities, demonstrating its effectiveness in both emulation and vulnerability detection.

1. Introduction

The IoT ecosystem is a fundamental component of modern society, making it an attractive target for hackers worldwide. The integrity and availability of IoT devices are critical in contemporary cyber warfare, influencing both offensive and defensive operations. A notable example is the sophisticated cyber-attack on Ukraine’s power system in 2015, which not only disrupted services in the vicinity of Kiev but also triggered widespread blackouts across nearly half of the country [1]. As a result, proactively identifying and mitigating vulnerabilities in IoT systems has become essential for nations, spurring significant research efforts in both industry and academia [2].

Detecting security vulnerabilities in IoT devices presents a greater challenge than with traditional devices [2,3]. This difficulty arises not only from the complexity and diversity of IoT devices but also from the intricate integration of their software systems with electrical hardware, which hampers emulation using current automated vulnerability detection methods. For instance, conventional techniques such as static and dynamic program analysis struggle to identify bugs in the firmware of smart IoT nodes due to their complicated execution environments and the interdependent relationships among multiple executable binaries within their file systems. To tackle these challenges, researchers have turned to fuzzing with customized emulators [4,5,6,7] as a promising method for uncovering vulnerabilities in IoT devices. Fuzz testing (fuzzing) is an automated software testing technique that repeatedly executes target systems, monitoring for indicators such as program crashes to reveal potential security flaws [8].

However, current methods fall short in overcoming certain challenges when fuzzing IoT devices. A major hurdle is the difficulty in setting up automated fuzzing environments for many devices, especially due to encrypted firmware. Devices like industrial wireless routers employ additional encryption measures, requiring manual analysis and decryption before automated fuzz testing can proceed. This drives us to develop an efficient fuzzer with built-in auto-decryption capabilities, enabling effective fuzzing of IoT devices that use encrypted firmware. Although encryption methods vary, many devices opt for simpler techniques, such as XOR encryption with a specific key, to balance performance and security. These simpler algorithms leave identifiable traces at the binary level, making heuristic analysis feasible. Consequently, advanced classification strategies can be employed to detect these indicators and identify the underlying encryption method.

In this paper, we present EncryptAFL, the first efficient IoT fuzzer specifically designed for devices with encrypted firmware. First, to emulate executable environments for IoT firmware, EncryptAFL extends the state-of-the-art open-source emulator QEMU by introducing a new machine platform that includes custom peripheral components. This enhancement overcomes the challenges of setting up virtual machines when physical modules, such as serial ports with specific protocols, are absent. Second, to mirror the natural decryption process of physical devices, EncryptAFL modifies QEMU’s startup procedure to support automatic decryption of encrypted firmware and accurately emulate the boot process of real hardware. Finally, EncryptAFL employs heuristic analysis algorithms to identify encryption strategies used in target firmware based on the observation that many IoT devices utilize simple encryption methods with identifiable binary traits to balance performance and security.

We developed a prototype of EncryptAFL and evaluated it on popular industrial devices such as MOXA wireless routers. Our evaluation indicates that EncryptAFL can emulate a wider range of IoT devices compared to existing IoT emulators and fuzzers.

In conclusion, we make the following contributions:

• We systematically review and analyze encryption algorithms used in the firmware of existing IoT devices. Building on this knowledge, we develop heuristic algorithms to automatically identify these encryption methods in firmware.
• We present the design and implementation of EncryptAFL, a full-system emulation fuzzing tool specifically tailored for IoT devices, including electricity meters.
• We evaluate EncryptAFL on popular industrial devices and automatically reproduce 12 previously known vulnerabilities. To the best of our knowledge, this is the first fuzzing tool capable of automated testing on devices with encrypted firmware.

The remainder of this paper is organized as follows. Section 2 provides the necessary technical background. In Section 3, we outline the design and details of EncryptAFL. Section 4 presents our evaluation results, and Section 5 discusses the limitations and potential future work. Finally, Section 6 concludes the paper.

2. Background and Related Work

In this section, we provide essential background on device emulation and the application of fuzzing in this context. We then elaborate on the core challenges addressed in device fuzzing.

2.1. System Platform Emulation

System platform emulation is a virtualization strategy that replicates an entire platform, including specific CPUs and all necessary peripheral components, to support full-system emulation [5,6,7,9,10]. Virtualization techniques [11] provide a set of abstract interfaces that mirror the functionalities of a real-world system at the same abstraction layer, ensuring that the virtualized target behaves as it would in its native environment. In this context, we refer to the provider of abstract resources as the $Host$, and the virtualized target that utilizes these resources as the $Guest$. Based on the types of physical resources being virtualized, these techniques can be categorized into three groups: computing resources (CPU) virtualization, memory resources virtualization, and device resources virtualization [12].

When running a virtual machine with the same instruction set architecture (ISA), most binary code is executed directly [13,14]. However, operations involving sensitive physical resources, such as physical ports or privileged registers, are intercepted and emulated with predetermined values, a technique known as the trap-and-emulate model [13,14]. Most ISAs now offer hardware-assisted virtualization features to accelerate virtual machine performance. However, hardware-assisted device virtualization typically requires specific physical peripheral devices to be present on the $Host$ system. This approach is designed solely to redirect I/O requests to existing hardware and is less effective when emulating non-existent devices [12]. Additionally, hardware-assisted CPU virtualization is limited to virtual machines using the same ISA. Emulating systems with different ISAs still necessitates instruction interpretation.

QEMU (Quick Emulator) is a full-system emulator that leverages techniques such as instruction-by-instruction interpretation and dynamic binary code translation to execute instructions efficiently [13,15]. In addition to CPU and memory emulation, QEMU offers a range of emulated peripheral devices and pre-configured machine platform designs. It also features a custom, software-based Memory Management Unit (MMU) to manage memory accesses, enabling it to emulate a general machine platform for most ISAs. Compared to existed full-system emulation and virtualization solutions like VMWare and VirtualBox, QEMU is a fully open-source project with highly customizable functionalities and various types of emulated devices, which offers comprehensive support for hardware virtualization, precise control over execution, and extensive debugging capabilities. This makes QEMU much easier and more powerful than other projects for developers to build their customizable solutions. Given that many industrial devices operate on different ISA platforms, using emulators like QEMU to create virtual machines has become one of the most practical strategies in dynamic software testing [16]. As a result, several fuzzers, such as EQUAFL [5], have adopted QEMU as the foundation for their testing environments.

2.2. Fuzz Testing

Fuzz testing (fuzzing) is an automated software testing technique that uncovers bugs and vulnerabilities by repeatedly executing the target application with randomly or rule-based generated inputs while monitoring for abnormal behaviors, such as program crashes that often indicate memory violation bugs [8,17,18,19]. Fuzzers can be categorized into three types based on the level of insight they have into the target program:

• White-box fuzzing: These tools have complete knowledge of the target, including source code and runtime execution details. They typically use metrics like code coverage to guide the generation of new inputs [20,21].
• Black-box fuzzing: Operating without any feedback, black-box fuzzers treat the target program as an opaque entity. They generate inputs randomly without using static analysis techniques, such as constructing control-flow graphs [22,23].
• Grey-box fuzzing: Striking a balance between the two, grey-box fuzzers do not have full insight into the target program but collect limited runtime feedback through lightweight monitoring. This information is then used to enhance the input generation process and improve the overall fuzzing effectiveness [6,8,24].

Coverage-guided fuzzing is the most widely adopted strategy among both white-box and grey-box fuzzers [6,8]. This approach is grounded in the principle that executing a greater proportion of code increases the likelihood of uncovering unknown vulnerabilities. Typically, code coverage is obtained through software-level instrumentation techniques that modify the target program’s source code or binary assembly to insert mechanisms for recording executed code blocks or branches. In white-box fuzzing, static instrumentation is commonly employed, integrating the process into the target program’s compilation. In contrast, grey-box fuzzing favors dynamic instrumentation since it does not require comprehensive insight into the target program. The resulting coverage data then guide the input generator in producing subsequent test cases. Inputs that trigger new execution paths are deemed "interesting" and are retained as seeds for further fuzzing, while those that do not enhance coverage are discarded. However, when fuzzing programs on specific platforms, an emulated environment is essential to correctly execute the binary. Full-system emulation becomes particularly critical for testing applications on IoT devices—such as wireless routers and smart electricity meters—that require specific peripheral components to perform hardware-dependent functions reliably.

2.3. Challenges with Encrypted Firmware from IoT

While full-system emulation-based fuzzing is a practical strategy, significant challenges persist when applying it to smart IoT devices.

Electricity-related Peripheral Components Many smart IoT devices incorporate specialized electrical components that differ from those found in common devices like wireless routers. These components are tightly integrated with physical electrical equipment and are typically not supported by standard emulators such as QEMU [10]. This limitation often prevents the establishment of a fully functional emulated environment required for the corresponding device firmware to operate correctly.

Encrypted Firmware. Smart device firmware in the IoT is frequently designed to be encrypted, with decryption occurring during the boot process via boot code or dedicated hardware components [25,26]. This presents a major challenge for conventional IoT fuzzers, as popular emulators like QEMU lack the capability to automatically identify and decrypt encrypted firmware. Consequently, this shortfall hinders the successful setup of a testing environment for such firmware.

2.4. Motivations

Given the limitations of current research approaches, our goal is to develop an effective grey-box fuzzer for smart IoT devices. Although existing fuzzing methods and emulators for IoT lack strategies tailored to this scenario, we identified potential solutions to overcome these challenges. First, many smart IoT devices operate under proprietary protocols that are typically simple by design, allowing specific peripheral components to function via techniques like packet-replaying that uses tools like Wireshark to capture contents of network packets and forgery the procedure of packet transmission via Python 3.9 scripts. For example, when smart electricity meters transmit electricity usage data over serial ports, the response packets are usually in a fixed format. By leveraging this consistency, we can develop custom peripheral components in QEMU that respond with predefined packets, enabling most functions of these smart devices to operate successfully in an emulated environment. Second, many devices with encrypted firmware utilize basic encryption algorithms, such as simple XOR with a specific key string, to balance performance and security. This result is obtained from our observation in analysis of many different IoT firmware including devices from various manufacturers. For example, wireless AP/bridge/client like AWK-3121 series from MOXA Corp usually adopt a simple XOR encryption on its firmware, whose key is always stored in a specific location in the firmware. This simplicity makes it feasible to apply heuristic analysis to encrypted firmware. Our observation is that such encryption algorithms often leave discernible patterns at the binary level, which can be detected and classified using advanced analysis techniques. Motivated by these insights, our work addresses both challenges to provide a viable solution for fuzzing smart devices with encrypted firmware in the IoT.

3. Design

In this section, we present the design of EncryptAFL along with the rationale behind our design choices.

3.1. Overview

We provide a high-level overview of our encrypted firmware fuzzer design before delving into the implementation details of each component in Section 3. The overall architecture of EncryptAFL is illustrated in Figure 1 and can be divided into three main components: the virtualization infrastructure, the encryption resolver, and the fuzzing engine.

The virtualization infrastructure comprises two main elements: a software system running within the decrypted target firmware on the Guest side and a full-system emulated hardware environment built on a customized QEMU with additional emulated electrical peripherals on the Host side. The encryption resolver operates prior to setting up the emulated environment. It identifies the encryption algorithm used in the target firmware and decrypts it accordingly. Meanwhile, the fuzzing engine maintains a pool of seeds derived from a malicious input database gathered from real-world cyber-attack activities (e.g., data sequences from NIDS and honeypots). Seed scheduling and mutation processes continuously generate new inputs, which are then fed into the binary executables within the target firmware via customized QEMU emulated peripherals or network adapters. An external monitor observes the emulated environment, flagging inputs that trigger notable events such as crashes.

Figure 2 illustrates the sequence of communications and events during a fuzzing procedure. Initially, the encryption resolver examines the target firmware using a heuristic algorithm to detect binary-level indicators that reveal the encryption method. Once identified and successfully decrypted, the firmware is transformed into the appropriate format required by the virtualization infrastructure for booting an emulated environment.

Subsequently, the virtualization infrastructure launches a new virtual machine with the decrypted firmware provided by the encryption resolver. Once the virtual machine has successfully booted—avoiding a recursive rebooting stage that typically occurs when the system fails to initialize—and begins probing peripheral devices to communicate with the expected electrical infrastructure, QEMU on the Host side notifies the fuzzing engine via a local domain socket. The fuzzing engine then begins feeding inputs into corresponding QEMU peripherals, such as serial or network ports, while continuously monitoring the virtual machine’s status.

We modify the error handler subsystem and instruction set architecture emulator in QEMU to hijack the procedure of error handling and runtime state switching to detect the runtime state and exception events. Therefore, we can determine how the virtual machine is running now in real time and handle potential upcoming machine faults and events on our own. If the emulated environment crashes, the incident is recorded, and the input responsible is flagged as an interesting seed for subsequent input generation cycles.

3.2. Design Details

3.2.1. Virtualization Infrastructure

The virtualization infrastructure is primarily built on the open-source emulator QEMU, enhanced with custom components. It allocates all the physical resources necessary to establish an emulated environment for running the target firmware. Additionally, during the boot process, it identifies the peripheral devices probed by the virtual machine, allowing the fuzzing engine to generate targeted input mutations accordingly.

QEMU enables the creation of custom emulated devices and machine architectures, allowing us to replicate full-system environments for nearly any smart IoT device. We designed and implemented dozens of emulated peripheral devices closely associated with the IoT. For instance, emulated electricity cables and equipment that support protocols such as IEC 61850 [27] are essential for electrical infrastructures.

To successfully emulate the firmware of a specific IoT device, the key requirement is that the emulated system can detect and interact with the necessary peripherals. However, these emulated devices do not need to fully replicate the functionality of their real-world counterparts. For example, running the firmware of a smart meter only requires monitoring and recording electricity usage, not a complete emulation of an electricity consumer such as a fully functional air conditioner with temperature adjustment capabilities. Consequently, our peripheral infrastructure implementations focus solely on providing the most essential functions.

3.2.2. Encryption Resolver

Compared to legacy solutions like EQUAFL that boot the firmware directly, our EncryptAFL introduces an additional stage that executes the Encryption Resolver before the beginning stage of booting. This provides us with the power to automatically and efficiently fuzz multiple types of firmware from different manufacturers compared to examples in existing work that need to manually decrypt the firmware before the fuzzing procedure. The encryption resolver is a core component of EncryptAFL that employs several custom heuristic algorithms to automatically identify and decrypt the encryption methods applied to the target firmware. A pre-established database stores identifiable indicators for various encryption algorithms, and a portion of the decryption process is integrated into the virtualization infrastructure to accelerate the booting of virtual machines with encrypted firmware.

The key to identifying encryption algorithms in target firmware is detecting distinct binary-level indicators. For example, XOR encryption typically leaves a recurring string within the firmware, as the results of calculations with zero-padded data can reveal information about the original encryption key. Another notable trait is the magic number $0x184D2204$, which appears in firmware encrypted with the LZ4 algorithm and is commonly associated with devices using u-Boot.

In our encryption resolver, we first scan the firmware for directly observable identifiers, such as magic numbers corresponding to known encryption algorithms. If no clear indicators are found, we then apply a series of heuristic algorithms to detect indirect traits, such as recurring loop strings that may hint at specific encryption methods. Since an encrypted firmware might employ multiple encryption algorithms simultaneously, we initially collect all potential indicators and perform the decryption process after this information is gathered. The complete process of our encryption resolution is detailed in Algorithm 1.

Algorithm 1 Figuring out encryption algorithms

Input: Encrypted Firmware as $EF$, Identifiers Set $Is$, Traits Set $Ts$ Output: Decrypted Firmware as $DF$, Encryption Algorithm Set $EAs$   1: $EAs\leftarrow \varnothing$   2: $ni\leftarrow \mathrm{number}\mathrm{of}\mathrm{Identifiers}\mathrm{in}Is$   3: $nt\leftarrow \mathrm{number}\mathrm{of}\mathrm{Traits}\mathrm{in}Ts$   4: for i to  $ni$  do   5:    if $Is\left[i\right].ident\in EF$ then   6:      $EAs\leftarrow EAs\cup \{$Is[i]$.algo\}$   7:    end if   8: end for   9: for i to  $nt$ do 10:    if $Ts\left[i\right].ident\in EF$ then 11:      $EAs\leftarrow EAs\cup \{$Ts[i]$.algo\}$ 12:    end if 13: end for 14: $ne\leftarrow \mathrm{number}\mathrm{of}\mathrm{Algorithms}\mathrm{in}EAs$ 15: $DE\leftarrow \varnothing$ 16: for i to  $ne$  do 17:    $DF\leftarrow EAs\left[i\right].decrypt(DF,EF)$ 18: end for

3.2.3. Fuzzing Engine

The fuzzing engine orchestrates the entire fuzzing process, managing tasks such as seed mutation and VM scheduling. Rather than using traditional binary inputs, it employs operation sequences—actions like reading from or writing to specific ports—to simulate potential malicious behavior. Additionally, some components of the fuzzing engine are integrated into the virtualization infrastructure, enabling rapid transmission of inputs from emulated peripheral devices to the system within the virtual machine.

We developed a complex instruction set interpreter, called NORNIR, which serves as the core of our fuzzing engine. NORNIR defines a set of specific opcodes to represent common interactions with emulated devices and continuously reads a bytecode stream—sourced either from existing databases or from pseudo-random number generators—to generate operation sequences for the target environment.

When a bytecode stream is read from a database, it is first decoded into operation sequences used by the fuzzer to interact with the virtual machine. If no external stream is available, the system falls back on inputs generated by a pseudo-random number generator. By modifying the internal state of the PRNG, we can produce deterministic bytecode streams for the fuzzing process. If a particular bytecode stream triggers a crash, the fuzzer repeatedly executes the same input to reproduce the issue, then minimizes the input to its simplest form. This minimal input is stored in the database as a seed for further mutation. The architecture of this process is illustrated in Figure 3.

4. Evaluation

We evaluate the availability and performance of our design using our prototype implementation of EncryptAFL, aiming to address the following research questions:

• RQ 1: How does EncryptAFL’s availability compare to state-of-the-art firmware emulation approaches such as legacy QEMU and Firmadyne?
• RQ 2: Can we emulate malicious actions to effectively attack IoT devices?
• RQ 3: Can we rediscover previously known vulnerabilities, such as CVE-2021-22714 [28] in Schneider’s smart meters?

To evaluate whether EncryptAFL can successfully emulate encrypted firmware (RQ 1), we tested it on encrypted firmware from 15 different smart devices. EncryptAFL successfully ran all the firmware in an emulated environment, whereas existing IoT emulators failed to achieve comparable success rates.

For RQ 2, we manually crafted exploit scripts and converted them into the bytecode format for the NORNIR interpreter, using these as initial inputs to simulate real-world cyber attacks. We selected 12 previously known vulnerabilities and successfully induced crashes on devices using variations of the original inputs.

To address RQ 3, we assembled a set of firmware images with known vulnerabilities and tested whether EncryptAFL could rediscover these flaws within a reasonable timeframe. Overall, our experiments demonstrate that EncryptAFL can effectively rediscover all the targeted vulnerabilities.

4.1. Experiment Setup

All experiments were conducted on a server equipped with an Intel Xeon Gold processor (40 cores, 80 threads) and 256 GB of RAM. The host system runs Debian 12.6 (Bookworm) with the latest software packages.

4.2. Emulating Encrypted Firmware

To demonstrate that EncryptAFL can successfully create emulated environments for encrypted firmware, we evaluated a set of firmware images from various common IoT devices. The success of emulation in this context is defined as the ability to establish an execution environment for the target firmware to finish the booting stage and initiate the first userland process like the $/sbin/init$ for general Linux environment. We compared our implementation against several state-of-the-art emulation and virtualization tools. The emulation results are presented in

Table 1. Result of emulating firmware of different devices.

	Emulator	Encrypted Firmware	EncryptAFL	QEMU	VirtualBox	Firmadyne [29]	FIRM-AFL [30]	FirmAE [10]
Devices
D-Link DIR-882		Y	✔	✘	✘	✘	✘	✘
D-Link DIR-3040		Y	✔	✘	✘	✘	✘	✘
D-Link DIR-3060		Y	✔	✘	✘	✘	✘	✘
DrayTek Vigor2962		Y	✔	✘	✘	✘	✘	✘
MOXA AWK-3131A		Y	✔	✘	✘	✘	✘	✘
MOXA AWK-3121		Y	✔	✘	✘	✘	✘	✘
Tenda AC8 v5.0		Y	✔	✘	✘	✘	✘	✘
TB WR1800K MT7621		Y	✔	✘	✘	✘	✘	✘
Siemems 9410 PAC meters		N	✔	✘	✘	✘	✘	✘
Cisco RV34X		N	✔	✔	✘	✔	✔	✔
TOTOLINK NR1800XP		N	✔	✔	✘	✔	✔	✔
Trendnet TEW-632BRP		N	✔	✘	✘	✔	✔	✔
D-Link DIR-825		N	✔	✘	✘	✘	✔	✔
TPLink WR940N		N	✔	✘	✘	✘	✔	✔
Schneider NOE 771		N	✔	✘	✘	✘	✘	✘

.

The results indicate that none of the existing state-of-the-art tools could successfully emulate any of the encrypted firmware, whereas EncryptAFL succeeded in all cases. For unencrypted firmware, FIRM-AFL [30] and FirmAE [10] failed to emulate the Schneider NOE 771 controller, Firmadyne [29] could not run firmware from two additional routers, QEMU only succeeded on two devices, and VirtualBox [31] could not emulate any firmware directly. In contrast, EncryptAFL successfully emulated all tested firmware, demonstrating its robust capability in handling the firmware of widely used IoT devices.

4.3. Reproduction of Known Vulnerabilities

To validate our fuzzer’s capability in uncovering bugs and vulnerabilities, we selected a set of firmware images with known vulnerabilities as targets to see whether our approach could rediscover them. Given that related work typically identifies CVEs as their benchmarks, we chose several well-known CVEs for this experiment. We compared our approach to the state-of-the-art IoT fuzzer, FIRM-AFL, setting a 24 h time limit for each vulnerability discovery test. The results are presented in

Table 2. Result of simulating malicious attacks.

CVE Number	Device	EncryptAFL Found	EncryptAFL Time to Crash	FIRM-AFL Found	FIRM-AFL Time to Crash
CVE-2013-0230	Trendnet TEW-632BRP	✔	10 h 21 min	✔	9 h 13 min
CVE-2016-1558	D-Link DAP-2695	✔	1 h 48 min	✔	2 h 53 min
CVE-2017-3193	D-Link DIR-850L	✔	2 h 16 min	✔	1 h 29 min
CVE-2017-5164	BINOM3 Electric Power Quality Meter	✔	6 h 4 min	✘	N/A
CVE-2017-5166	BINOM3 Electric Power Quality Meter	✔	15 h 31 min	✘	N/A
CVE-2018-8941	D-Link DSL-3782	✔	1 h10 min	✔	24 min 37 s
CVE-2018-19241	Trendnet TV-IP110WN	✔	3 h 26 min	✔	4 h 45 min
CVE-2021-44165	Simen SICAM Q100	✔	5 h 24 min	✘	N/A
CVE-2022-43439	Simen SICAM Q100	✔	8 h 46 min	✘	N/A
CVE-2022-43545	Simen SICAM Q100	✔	12 h 7 min	✘	N/A
CVE-2023-30901	Simen SICAM Q100	✔	4 h 33 min	✘	N/A
CVE-2023-31238	Simen SICAM Q100	✔	7 h 21 min	✘	N/A

.

The results demonstrate that AFL-Engird was able to identify more known vulnerabilities than FIRM-AFL, highlighting EncryptAFL’s superior effectiveness in discovering security issues. However, since we do not collect metrics such as code coverage like FIRM-AFL does, our approach does not show a significant advantage in terms of fuzzing time efficiency.

4.4. Simulating Malicious Actions

To evaluate EncryptAFL’s capability to simulate malicious attacks on IoT devices, we first manually crafted exploit scripts for several previously known vulnerabilities. These scripts served as initial inputs for the NORNIR interpreter, which generated mutated operation sequences. We then observed whether these mutated inputs could cause faults or trigger reboots in the emulated environment. For each exploit script, the NORNIR interpreter was configured to produce 100 variants. The results are presented in

Table 3. Result of simulating malicious attacks.

CVE Number	Device	Success	Successful Input Variants
CVE-2013-0230	Trendnet TEW-632BRP	✔	23
CVE-2016-1558	D-Link DAP-2695	✔	45
CVE-2017-3193	D-Link DIR-850L	✔	16
CVE-2017-5164	BINOM3 Electric Power Quality Meter	✔	37
CVE-2017-5166	BINOM3 Electric Power Quality Meter	✔	21
CVE-2018-8941	D-Link DSL-3782	✔	86
CVE-2018-19241	Trendnet TV-IP110WN	✔	92
CVE-2021-44165	Simen SICAM Q100	✔	65
CVE-2022-43439	Simen SICAM Q100	✔	47
CVE-2022-43545	Simen SICAM Q100	✔	52
CVE-2023-30901	Simen SICAM Q100	✔	71
CVE-2023-31238	Simen SICAM Q100	✔	33

.

The findings indicate that the NORNIR interpreter within EncryptAFL can successfully generate exploit variants that effectively attack target devices, demonstrating the tool’s ability to simulate malicious actions reflective of real-world cyber attacks.

5. Limitations and Future Work

In this section, we discuss the limitations of our current design and outline future work to further improve our system.

Feedback Mechanism. Our current implementation of EncryptAFL does not incorporate common feedback mechanisms such as code coverage monitoring to guide the fuzzing process. This omission may reduce both effectiveness and efficiency [32]. In future work, we plan to integrate these techniques to optimize the fuzzing process.

Supported Devices. Although we developed several emulated peripheral components in QEMU to facilitate a functioning emulated environment, many devices possess unique characteristics that our tool cannot currently emulate. Given the vast diversity of device-specific peripherals, manually creating a comprehensive set of emulated components is not feasible. A promising approach would be to automatically generate the required emulated peripherals by running the firmware iteratively and analyzing its interactions with physical devices.

Real-time systems. Currently, our prototype is implemented on QEMU that does not provide real-time guarantees by default, which means that out approach might not be applicable to real-time systems. However, although we do not have native support for the real-time systems, as our emulation system is based on the QEMU, we can easily adopt open-source solutions like RT-QEMU from communities to integrate such features into our approach.

Hardware-assisted virtualization acceleration. Though we did not employ hardware-assisted virtualization techniques in our prototype yet, they are not difficult to integrate into our approach. As our system is built on QEMU, a state-of-the-art full-system emulation approach designed to be able to integrate firmly with KVM, our prototype is eligible to employ existing hardware-assisted virtualization solutions like using real physical peripherals to accelerate peripheral emulation with techniques including IOMMU and Virt-IO.

Complex Encryption Strategies. Our heuristic algorithms have enabled us to automatically decrypt many encrypted firmware images. However, some newer devices employ more complex encryption schemes, such as multi-stage encryption chains, that remain challenging to decrypt with our current methods. Addressing these cases often requires significant manual effort and deep expertise. We believe that advanced artificial intelligence techniques, such as large language models, may offer valuable assistance in overcoming these challenges.

6. Conclusions

In this paper, we present a comprehensive design for emulating the firmware of smart IoT devices and discovering their vulnerabilities. Compared to existed IoT-fuzzing approaches, we introduce an additional encryption solver to automatically detect the encryption algorithm in firmware with heuristic strategies which grant us with the power to emulate encrypted IoT firmware without manual decryption work. We evaluate both the effectiveness and efficiency of our approach on a set of selected firmware images and known bugs. Compared to state-of-the-art emulators, EncryptAFL successfully emulates a broader range of firmware in diverse scenarios and rediscovers more vulnerabilities than leading IoT fuzzers. Despite these advances, our current implementation has limitations that warrant further improvement, which we outline as future work for continued optimization.