A microcontroller firmware grey-box fuzzing method

Abstract

The application discloses a microcontroller unit (MCU) firmware grey box fuzzing test method. The method first establishes a high-fidelity peripheral simulator in a simulation execution environment, the peripheral simulator including peripheral registers, internal states and state machines, and determines the interrupt line enable state by jointly monitoring the global interrupt controller register and the peripheral interrupt control register to realize the controlled triggering of the peripheral interrupt. Secondly, the time when the firmware or DMA reads the peripheral data register is determined as an input consumption point during firmware execution, an incremental snapshot containing the processor register state, the peripheral state and the memory dirty page information is saved at the input consumption point, and only the input data that has not been read is mutated after the snapshot is restored. Finally, the test input is divided into multiple input streams corresponding to different peripherals or data registers, a probability distribution is constructed according to the access frequency of each input stream, and the input stream to be mutated is selected, so that the path exploration efficiency and the vulnerability discovery capability of the fuzzing test are improved.

Description

Technical Field

[0001] This invention belongs to the field of embedded system security testing and software vulnerability mining technology, specifically relating to a gray-box fuzzy testing method for microcontroller firmware. Background Technology

[0002] MCU firmware is widely deployed in IoT terminals, industrial control equipment, automotive electronics, and consumer electronics. Because firmware directly controls the device's operational logic, security vulnerabilities can lead to serious consequences such as denial-of-service attacks and remote code execution. Gray-box fuzzing is an effective automated vulnerability discovery technique. Its workflow involves generating test inputs, collecting code coverage and execution status data during the target program's execution of the test inputs, and using this information to guide subsequent testing.

[0003] Due to the highly heterogeneous hardware and limited computing resources of MCUs, and the tight coupling between MCU firmware and hardware, existing MCU firmware fuzz testers suffer from poor availability, slow execution, high false alarm rates, and low testing efficiency. To enable gray-box fuzz testing of MCU firmware to detect security vulnerabilities early, this invention designs and discloses a gray-box fuzz testing method for microcontroller firmware. This method achieves efficient gray-box fuzz testing of firmware in a high-fidelity simulated execution environment, thereby improving firmware security. Summary of the Invention

[0004] The purpose of this invention is to solve the problems of poor availability, slow execution, high false alarm rate and low testing efficiency of existing firmware fuzz testers. It aims to improve the efficiency of firmware fuzz testing without relying on real hardware, thereby enabling the early detection of security vulnerabilities in firmware and improving firmware security.

[0005] The microcontroller firmware gray box fuzzy testing method of the present invention includes the following steps in sequence:

[0006] (1) Construct a simulated execution environment for executing the firmware of the MCU under test. In the simulated execution environment, a peripheral model is established for the MCU peripherals. The peripheral model includes peripheral registers, peripheral internal states, and a state machine consisting of states, state transition conditions, and state callback functions. During firmware execution, the global interrupt controller register and the interrupt control register in the target peripheral are monitored simultaneously. The enable state of the corresponding interrupt line is determined based on the register values ​​of both, and an interrupt is triggered only for the interrupt line that is in the enabled state. The simulated execution environment also records code coverage information and abnormal termination states during firmware execution.

[0007] (2) During the execution of test inputs by the firmware under test, when a read operation is detected on the target peripheral data register by the firmware or DMA, the corresponding moment is determined as an input consumption point, and incremental snapshots are saved at some input consumption points. The incremental snapshots include at least the CPU register state, peripheral register state, peripheral internal state, and dirty page information of guest memory that has changed relative to the previous snapshot. After the current round of testing ends, a baseline snapshot is selected from the saved snapshots to restore the simulation execution environment, and only the test input data that was not read when the baseline snapshot was created is mutated.

[0008] (3) Organize the test inputs into multiple input streams corresponding to different target peripherals or different data registers, count the frequency of each input stream being accessed during firmware execution, and construct a probability distribution for selecting the input stream to be mutated based on the access frequency. Before each mutation, select one or more input streams according to the probability distribution, and perform mutation on the data corresponding to the selected input streams to generate new test cases for subsequent fuzz testing.

[0009] Furthermore, in step (1), the state transitions of the peripheral state machine include: passive state transitions triggered by firmware access to registers or memory, and autonomous state transitions triggered by the autonomous operation of the peripheral. The autonomous state transitions are scheduled through a task queue, and state transition tasks that meet the conditions are checked and executed between the basic blocks executed by the simulator. For register updates or memory updates generated by the autonomous state transition of the peripheral, the content to be updated is first recorded, and when the firmware subsequently accesses the corresponding register field or memory field, the content to be updated is submitted with a preset probability. The code coverage information includes at least the addresses of the basic blocks that have been executed, or edge coverage information calculated by one or more consecutively executed basic blocks; the abnormal termination state includes at least the firmware crash state and the firmware execution timeout state.

[0010] Furthermore, in step (2), a root snapshot is saved during the initialization phase of the simulated execution environment. This root snapshot includes at least the CPU register state, peripheral register state, guest memory state, interrupt queue state, task queue state, and input manager state. The incremental snapshot saves the CPU register state, peripheral register state, interrupt queue state, task queue state, and input manager state, but only saves guest memory pages that have changed relative to the previous snapshot. An input manager is set up to record the length of data read by the firmware in each input stream. After restoring the baseline snapshot, the range of mutable data is determined based on the input manager records to avoid repeated mutations of input prefixes already read by the firmware.

[0011] Furthermore, in step (3), to prevent input streams with low access frequency from being left unselected for extended periods, a minimum selection frequency threshold or minimum selection probability is set for each input stream. In a single round of fuzz testing iterations, multiple mutations are performed continuously on the same test case, and the input stream to be mutated is reselected before each mutation operation. The mutations performed on the selected input streams include at least one of the following:

[0012] 1) Mutate the current input stream using constants, random numbers, or existing data in the current input stream;

[0013] 2) Mutate the current input stream using data from other input streams in the current test case;

[0014] 3) Use data from other test cases that correspond to the current input stream to mutate the current input stream.

[0015] Beneficial effects: Compared with the prior art, the present invention has the following advantages:

[0016] (1) This invention initiates only enabled interrupts by monitoring the registers of the global interrupt controller and the registers in the peripheral device used to control interrupts, and controls the simulation process of the peripheral device through a state machine, thus enabling accurate simulation of the peripheral device hardware. Compared with existing schemes that treat peripheral devices as black boxes and use random numbers to replace their corresponding simulation execution environment construction schemes, the simulation execution environment construction proposed in this invention can provide more realistic peripheral device hardware functions, thereby enabling the firmware to execute normally and avoiding false alarms.

[0017] (2) The incremental snapshot-based fuzzing mechanism designed in this invention can accelerate the speed at which firmware reads external input from peripherals and improve firmware execution efficiency. Compared with existing firmware fuzzers that do not support incremental snapshots, the incremental snapshot-based fuzzing mechanism proposed in this invention can significantly improve fuzzing throughput.

[0018] (3) The test case mutation mechanism based on peripheral access frequency designed in this invention enables the fuzz tester to prioritize the mutation of more important data, thereby improving mutation efficiency. Compared with existing random mutation mechanisms, the test case mutation mechanism based on peripheral access frequency proposed in this invention can significantly increase the probability that the test input generated by the fuzz tester triggers a new code path. Attached Figure Description

[0019] Figure 1 This is an overall architecture diagram of the microcontroller firmware gray box fuzzy testing method in the embodiment.

[0020] Figure 2 This is a logic framework diagram of the microcontroller firmware gray box fuzzy testing method introduced in this invention. Detailed Implementation

[0021] The technical solution of the present invention will be described in detail below, but the scope of protection of the present invention is not limited to the embodiments described.

[0022] The present invention provides a microcontroller firmware gray box fuzzy testing method, comprising the following steps in sequence:

[0023] (1) Construct a simulated execution environment for executing the firmware of the MCU under test. In the simulated execution environment, a peripheral model is established for the MCU peripherals. The peripheral model includes peripheral registers, peripheral internal states, and a state machine consisting of states, state transition conditions, and state callback functions. During firmware execution, the global interrupt controller register and the interrupt control register in the target peripheral are monitored simultaneously. The enable state of the corresponding interrupt line is determined based on the register values ​​of both, and an interrupt is triggered only for the interrupt line that is in the enabled state. The simulated execution environment also records code coverage information and abnormal termination states during firmware execution.

[0024] (2) During the execution of test inputs by the firmware under test, when a read operation is detected on the target peripheral data register by the firmware or DMA, the corresponding moment is determined as an input consumption point, and incremental snapshots are saved at some input consumption points. The incremental snapshots include at least the CPU register state, peripheral register state, peripheral internal state, and dirty page information of guest memory that has changed relative to the previous snapshot. After the current round of testing ends, a baseline snapshot is selected from the saved snapshots to restore the simulation execution environment, and only the test input data that was not read when the baseline snapshot was created is mutated.

[0025] (3) Organize the test inputs into multiple input streams corresponding to different target peripherals or different data registers, count the frequency of each input stream being accessed during firmware execution, and construct a probability distribution for selecting the input stream to be mutated based on the access frequency. Before each mutation, select one or more input streams according to the probability distribution, and perform mutation on the data corresponding to the selected input streams to generate new test cases for subsequent fuzz testing.

[0026] Example 1:

[0027] The microcontroller firmware gray-box fuzzy testing method in this implementation includes the following steps, such as: Figure 1 As shown:

[0028] I. Building the Simulation Execution Environment:

[0029] Firstly, regarding interrupt management, this embodiment combines peripheral local register configuration and global interrupt control information to determine whether an interrupt line is enabled. Specifically, write operations to the peripheral control register are monitored. When a change in a field related to the interrupt configuration is detected, the configurations of multiple interrupt events mapped to the same interrupt line are comprehensively calculated to obtain the enabling status of that interrupt line. When an interrupt line changes from disabled to enabled, the corresponding interrupt line is added to the interrupt management module; when an interrupt line changes from enabled to disabled, the interrupt to be triggered corresponding to that interrupt line is removed. The interrupt management module can maintain an interrupt scheduling queue and trigger corresponding interrupts according to a predetermined execution cycle, thereby avoiding distorted interrupt triggering and improving the accuracy of peripheral simulation.

[0030] Secondly, regarding the peripheral state machine, this embodiment abstracts the peripheral hardware behavior into a state machine. Different hardware functional stages correspond to different hardware states, and state transitions include passive transitions triggered by firmware access and autonomous transitions triggered by the peripheral's autonomous operation. Passive transitions can be implemented through hooked registers or memory access; autonomous transitions can be achieved through a task queue mechanism to achieve deterministic parallel simulation. Specifically, each peripheral simulator can provide a state transition function and add this function to the task queue. Between the simulator's execution blocks, state transition tasks that meet the conditions are checked and executed to replicate the state changes during peripheral operation. In this way, peripheral state machine simulation can be achieved without introducing multi-threaded uncertainty.

[0031] Furthermore, regarding firmware execution and booting, to reduce the likelihood of the firmware remaining stuck in waiting loops or error handling paths for extended periods, this embodiment employs probability control over the state synchronization process after autonomous state transitions. Specifically, after the peripheral device completes an autonomous state transition, it does not immediately update relevant register or memory fields but instead records the content to be updated. When the firmware subsequently accesses these fields, it performs the state update with a preset probability. By setting a higher synchronization success probability, the firmware can more quickly enter the core logic for processing test inputs; by setting a lower synchronization success probability, waiting paths or error handling paths can be covered. This mechanism improves the execution efficiency and path coverage of fuzz testing while maintaining the fidelity of peripheral device simulation.

[0032] II. Fuzz Testing Based on Incremental Snapshots

[0033] This embodiment provides a firmware fuzzing method based on incremental snapshots to improve the execution efficiency and path exploration capability of firmware fuzzing. During firmware execution, when the peripheral simulator consumes test input, this moment is taken as the input consumption point, and snapshots are saved at some of these input consumption points. The input consumption points include the moments when the firmware or DMA reads data registers. Specifically, during the simulator initialization phase, a root snapshot is first saved to record the initial complete state. This complete state includes at least the CPU register state, peripheral register state, memory data, interrupt queue, task queue, and input manager state. Subsequently, during the execution of test cases, several incremental snapshots are randomly saved at the input consumption points. Compared to the root snapshot, incremental snapshots save the CPU register state, peripheral register state, interrupt queue state, task queue state, and input manager state, but only save the client memory pages that have changed since the last snapshot, thus reducing the storage and recovery overhead of snapshots.

[0034] In each round of fuzzing iteration, a baseline snapshot is randomly selected from the root snapshot and each incremental snapshot. Based on the execution position corresponding to this baseline snapshot, only the data in the test input that has not yet been consumed is mutated. The baseline snapshot is then restored, allowing the firmware to continue running from the corresponding intermediate execution state. If the mutated test input triggers a new coverage path, the test input is added to the corpus. To support the above process, this embodiment also sets up an input manager to track the consumption of the byte stream corresponding to each data register in the test input. The input manager maintains corresponding consumption records for each data register and updates these records when the peripheral simulator reads data. Since the input manager state is saved along with the snapshot, after restoring the snapshot, the system can continue to identify input data that has not yet been consumed, thereby avoiding repeated execution of processed input prefixes and improving fuzzing throughput.

[0035] In this embodiment, the simulator determines whether the firmware has crashed by monitoring whether a system interrupt, representing a firmware crash, is triggered, and determines whether the firmware has timed out by monitoring the firmware's execution time. Furthermore, the simulator in this embodiment also records the addresses of all basic blocks executed by the firmware as code coverage.

[0036] III. Test Case Variation Based on Peripheral Access Frequency

[0037] This embodiment employs a multi-stream input structure, where each different peripheral corresponds to a different byte stream in the test input. Therefore, in each round of fuzz testing iteration, at least one input stream needs to be mutated. These input streams can correspond to different data registers. To improve testing efficiency, this embodiment selects the mutation target based on the access frequency of each input stream during firmware execution, prioritizing the mutation of input streams with higher access frequencies. Specifically, this embodiment records the frequency of firmware access for each input stream in the test case and constructs a categorical distribution based on the access frequency of each input stream as the probability distribution of the peripheral. When selecting a mutation target, the input stream to be mutated is randomly sampled according to the probability distribution. To avoid low-frequency input streams being ignored for extended periods, this embodiment also sets a minimum frequency threshold for each input stream, ensuring that low-frequency input streams still have a chance to be selected for mutation. During the mutation process, this embodiment employs a stacked mutation method, meaning that multiple mutation operations are performed continuously on the same test case within a single test iteration. Furthermore, the input stream to be mutated is reselected before each mutation operation so that the mutation process can cover multiple different input streams, further improving the trigger probability of new execution paths and the fuzzing effect.

[0038] It should be noted that the above embodiments are not intended to limit the scope of protection of the present invention. Equivalent transformations or substitutions made based on the above technical solutions all fall within the scope of protection of the claims of the present invention.

Claims

1. A gray-box fuzzy testing method for microcontroller firmware, characterized in that, Includes the following steps: (1) Construct a simulated execution environment for executing the firmware of the MCU under test. In the simulated execution environment, establish a peripheral model for the MCU peripheral. The peripheral model includes peripheral registers, peripheral internal states, and a state machine consisting of states, state transition conditions, and state callback functions. During firmware execution, monitor the global interrupt controller register and the interrupt control register in the target peripheral. Determine the enable state of the corresponding interrupt line based on the register values ​​of both, and trigger interrupts only for interrupt lines that are in the enabled state. The simulated execution environment also records code coverage information and abnormal termination states during firmware execution. (2) During the execution of test inputs by the firmware under test, when a read operation is detected on the target peripheral data register by the firmware or DMA, the corresponding moment is determined as the input consumption point, and incremental snapshots are saved at some input consumption points. The incremental snapshots include at least the CPU register state, peripheral register state, peripheral internal state, and dirty page information of guest memory that has changed relative to the previous snapshot. After the current round of testing is completed, a baseline snapshot is selected from the saved snapshots to restore the simulation execution environment, and only the test input data that has not been read when the baseline snapshot is created is mutated. (3) Organize the test input into multiple input streams corresponding to different target peripherals or different data registers, count the frequency of each input stream being accessed during firmware execution, and construct a probability distribution for selecting the input stream to be mutated based on the access frequency. Before each mutation, select one or more input streams according to the probability distribution and perform mutation on the data corresponding to the selected input stream to generate new test cases for subsequent fuzz testing.

2. The microcontroller firmware gray box fuzzy testing method according to claim 1, characterized in that, In step (1), the state transitions of the peripheral state machine include: passive state transitions triggered by firmware access to registers or memory, and autonomous state transitions triggered by the autonomous operation of the peripheral. Autonomous state transitions are scheduled through a task queue, and state transition tasks that meet the conditions are checked and executed between the basic blocks executed by the simulator. For register updates or memory updates generated by the autonomous state transition of the peripheral, the content to be updated is recorded first. When the firmware accesses the corresponding register field or memory field later, the content to be updated is submitted with a preset probability. The code coverage information includes at least the address of the basic block that has been executed, or the edge coverage information calculated by one or more consecutively executed basic blocks. The abnormal termination state includes at least the firmware crash state and the firmware execution timeout state.

3. The microcontroller firmware gray box fuzzy testing method according to claim 1, characterized in that, In step (2), a root snapshot is saved during the initialization phase of the simulated execution environment. The root snapshot includes at least the CPU register state, peripheral register state, guest memory state, interrupt queue state, task queue state, and input manager state. The incremental snapshot saves the CPU register state, peripheral register state, interrupt queue state, task queue state, and input manager state, but only saves guest memory pages that have changed relative to the previous snapshot. An input manager is set up to record the length of data read by the firmware in each input stream. After restoring the baseline snapshot, the range of mutable data is determined based on the input manager records to avoid repeated mutations of input prefixes that have already been read by the firmware.

4. The microcontroller firmware gray box fuzzy testing method according to claim 1, characterized in that, In step (3), to avoid input streams with low access frequency being left unselected for a long time, a minimum selection frequency threshold or minimum selection probability is set for each input stream. In a single round of fuzz testing iteration, multiple mutations are performed continuously on the same test case, and the input stream to be mutated is reselected before each mutation operation. The mutations performed on the selected input streams include at least one of the following: 1) Mutate the current input stream using constants, random numbers, or existing data in the current input stream; 2) Mutate the current input stream using data from other input streams in the current test case; 3) Use data from other test cases that correspond to the current input stream to mutate the current input stream.

Images