Fuzz testing input optimization device for IoT device firmware

Abstract

This application belongs to the field of computer information processing technology and specifically discloses a fuzz testing input optimization device for IoT device firmware. The device includes a static analysis module for analyzing firmware through an API interface, identifying input transfer points of bare metal firmware, and realizing automatic identification through a custom script; a dynamic simulation module for identifying input transfer points of real-time operating system firmware, and implementing a length inference mechanism and a final input transfer algorithm; an input routing mapping module for identifying and dynamically monitoring data retrieval points, input processing points, and availability check instructions in the firmware to obtain mapping results; an input transfer point identification module for automatically identifying the firmware's input transfer points based on the mapping results; and a perception module for dynamically determining the minimum and maximum lengths of input data at the input transfer points, optimizing the input transfer points of firmware fuzz testing, and dynamically calculating the retained data length. This application can improve the efficiency of fuzz testing.

Description

Technical Field

[0001] The present application belongs to the field of computer information processing technology, and more specifically, relates to a fuzzy test input optimization device for IoT device firmware. Background Art

[0002] Among existing firmware fuzz testing techniques, researchers typically employ rehosting, executing firmware in an emulated environment to discover potential vulnerabilities. This approach has gained widespread attention and application over the past decade, particularly in detecting security vulnerabilities in microcontroller unit (MCU)-based embedded devices, where fuzz testing has become a proven and effective technique. However, due to the limited hardware resources of MCUs, running fuzz testing directly on real devices is often inefficient and unscalable. Therefore, researchers typically rehost firmware into an emulated environment, resulting in three distinct research directions:

[0003] 1. Improving Simulation Fidelity: To avoid simulation failures or erroneous results during fuzz testing, many researchers are working to enhance simulation fidelity by improving peripheral modeling. These efforts focus on ensuring that the firmware's execution behavior in the simulation environment closely resembles its behavior on real hardware, thereby improving vulnerability detection accuracy. For example, some research utilizes dynamic symbolic execution techniques, which simulates peripheral behavior by inputting learned symbolic values ​​at peripheral access points during program execution.

[0004] 2. Optimizing Fuzz Testing Performance: Because firmware typically runs in resource-constrained environments, fuzz testing performance has been extensively studied. Researchers have employed various techniques to accelerate fuzz testing, covering more code paths within a limited timeframe and improving vulnerability discovery efficiency.

[0005] 3. Fuzz Testing Strategies for Firmware-Specific Features: Unlike traditional software, firmware has certain unique characteristics, such as often receiving input data from multiple peripheral interfaces. To adapt to these characteristics, some researchers have improved traditional fuzz testing strategies. For example, to address the firmware's need to receive multi-byte magic strings, a study has proposed a corresponding multi-stream fuzz testing method to unlock new code blocks.

[0006] However, existing firmware fuzz testing tools often fail to consider the timing and amount of input data actually required by the firmware. Instead, they employ arbitrary delivery mechanisms, resulting in either excessive input leading to data loss or overwriting, or insufficient input leading to inadequate logic testing when processing the received input. For example, traditional software fuzz testing typically relies on a synchronous I / O model, passing input data directly to the firmware through a POSIX API interface. However, firmware typically relies on peripheral-specific asynchronous I / O channels, which typically receive data from multiple sources simultaneously, and the expected data length is not clearly specified. This mismatch prevents existing fuzz testing tools from effectively utilizing test inputs, wastes a significant amount of fuzz testing opportunities, and significantly reduces the efficiency and effectiveness of fuzz testing.

[0007] Therefore, how to solve the defect of low efficiency of fuzz testing in existing firmware fuzz testing technology is a technical problem existing in current technology. Summary of the Invention

[0008] In view of the defects of the existing technology, the purpose of this application is to provide a fuzz testing input optimization device for IoT device firmware, aiming to solve the problem of low efficiency of fuzz testing in existing firmware fuzz testing technology.

[0009] In a first aspect, the present application provides a fuzz testing input optimization device for IoT device firmware, comprising a static analysis module, a dynamic simulation module, a communication module, an input routing mapping module, an input transfer point identification module, and a data length and multi-route input transfer perception module;

[0010] The static analysis module is used to analyze the firmware through the API interface, identify the input transfer points of the bare metal firmware, and realize automatic identification through custom scripts;

[0011] The dynamic simulation module is used to identify the input transfer points of the real-time operating system firmware based on the binary dynamic simulation execution framework, and to implement the length inference mechanism and the final input transfer algorithm;

[0012] The communication module is used to implement data exchange between the static analysis module and the dynamic simulation module based on the target communication protocol;

[0013] The input route mapping module is used to identify and dynamically monitor data retrieval points, input processing points, and availability check instructions in the firmware through a combination of static analysis and dynamic analysis to obtain mapping results;

[0014] The input transfer point identification module is used to automatically identify the input transfer point of the firmware based on the mapping result;

[0015] The data length and multi-route input transfer perception module is used to dynamically determine the minimum length and maximum length of the input data of the input transfer point, optimize the input transfer point of the firmware fuzz test, dynamically calculate the retained data length, monitor the transfer point and update the transfer point set to ensure effective coverage and data update.

[0016] Optionally, the input route mapping module includes a data retrieval identification submodule, an input processing identification submodule, and an availability check identification submodule;

[0017] The data retrieval identification submodule is used to monitor the read operation of the peripheral input through the hook function of the binary dynamic simulation execution framework and capture the value of the current program counter as a data retrieval point;

[0018] The input processing identification submodule is used to mark input data starting from the data retrieval instruction through dynamic taint analysis, and use the hook function of the Unicorn framework to track the memory read operation of the marked data until all the marked data is processed or cleared;

[0019] The availability check identification submodule is used to analyze global variables in the interrupt processing process, identify potential comparison instructions based on the cross-reference relationship of the global variables, and perform data flow analysis and control flow analysis on the global variables to determine availability check instructions.

[0020] Optionally, the input transfer point identification module includes a bare metal firmware identification submodule and a real-time operating system firmware identification submodule;

[0021] The bare metal firmware identification submodule is used to determine the most recent common caller function of the input availability check instruction and the most recent input processing instruction through a common ancestor algorithm, analyze the control flow relationship between the input availability check instruction and the most recent input processing instruction, and set the entry point of the most recent common caller function as the input transfer point;

[0022] The real-time operating system firmware identification submodule is used to dynamically monitor firmware execution using a hook function of a binary dynamic simulation execution framework, identify and determine whether an infinite loop switched from an interrupt is a unique basic block, and mark the entry point of the infinite loop that meets the conditions as an input transfer point.

[0023] Optionally, the data length and multi-route input transfer perception module includes a length range determination submodule and a fuzzy testing submodule;

[0024] The length range determination submodule is used to dynamically determine the input data length range of each input transfer point based on a snapshot mechanism; the snapshot mechanism dynamically determines the minimum length by creating a snapshot of the firmware execution state at each transfer point and using multiple parallel instances to increment the input length, while monitoring the write operation of the global input buffer to determine the maximum length.

[0025] Optionally, the fuzz testing submodule is used to:

[0026] Determine the data length based on the total fuzz test input length, the number of current transfer points, and the smallest upper bound among all transfer points;

[0027] Detecting whether the data length is less than 0, and if so, reducing the number of current transfer points until the data length is greater than or equal to 0;

[0028] Using the hook function to monitor the execution of firmware instructions, when encountering an input transfer point, determining whether the remaining input length is sufficient, and calculating the available input length of the current transfer point;

[0029] Determine the transfer length based on the available input length, use the transfer length to slice the fuzz test input and transfer it to the firmware, and update the input position;

[0030] Update the delivery point set according to the new data retrieval point, and recalculate the current delivery point quantity and data length to ensure that the new delivery point is covered.

[0031] Optionally, the fuzz testing submodule is further used to:

[0032] Determine whether the available input length is greater than 0;

[0033] If the available input length is less than 0, it is determined that the input data length of the current transfer point is insufficient to meet the minimum input length required by the current transfer point, and zeros are used to fill the data to meet the minimum length requirement, and the minimum length is used as the determined transfer length;

[0034] If the available input length is greater than or equal to 0, the transfer length is randomly determined.

[0035] Optionally, the firmware analysis of the static analysis module includes: disassembly, control flow analysis and data flow analysis; the length inference mechanism of the dynamic simulation module includes: snapshot creation, recovery and parallel instance management, and the final input transfer algorithm includes dynamic slicing and transfer logic.

[0036] In a second aspect, the present application also provides an IoT firmware fuzz test input transmission optimization method, comprising:

[0037] Use the static analysis module to analyze firmware through the API interface, identify the input transfer points of bare metal firmware, and realize automatic identification through custom scripts;

[0038] Using the dynamic simulation module to identify the input delivery points of the real-time operating system firmware based on the binary dynamic simulation execution framework, and to implement the length inference mechanism and the final input delivery algorithm;

[0039] Using the communication module to implement data exchange between the static analysis module and the dynamic simulation module based on the target communication protocol;

[0040] The input routing mapping module uses a combination of static and dynamic analysis to identify and dynamically monitor data retrieval points, input processing points, and availability check instructions in the firmware to obtain mapping results.

[0041] Automatically identifying the input transfer point of the firmware based on the mapping result using an input transfer point identification module;

[0042] The data length and multi-route input transfer awareness module is used to dynamically determine the minimum and maximum length of the input data of the input transfer point, optimize the input transfer points of firmware fuzz testing, dynamically calculate the retained data length, monitor the transfer points and update the transfer point set to ensure effective coverage and data update.

[0043] In a third aspect, the present application provides an electronic device comprising: at least one memory for storing programs; and at least one processor for executing the programs stored in the memory. When the program stored in the memory is executed, the processor is used to execute the method described in the first aspect or any possible implementation of the first aspect.

[0044] In a fourth aspect, the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method described in the first aspect or any possible implementation of the first aspect.

[0045] In a fifth aspect, the present application provides a computer program product, which, when executed on a processor, enables the processor to execute the method described in the first aspect or any possible implementation of the first aspect.

[0046] It can be understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here.

[0047] In general, the above technical solutions conceived by this application have the following beneficial effects compared with the existing technologies:

[0048] (1) This application makes the entire fuzz testing process more efficient through the automated identification of the static analysis module and the identification of the real-time operating system firmware input transfer points by the dynamic simulation module. By combining static analysis and dynamic analysis, the application can quickly identify the input transfer points, data retrieval points, and input processing points in the firmware, reducing the transfer of invalid inputs and data waste, and significantly improving the efficiency of fuzz testing. In addition, the application dynamically determines the minimum and maximum lengths of the input data through the data length and multi-route input transfer perception module, and adaptively adjusts the input length according to the real-time situation, ensuring that the input data meets the minimum requirements for firmware processing, increasing the proportion of valid inputs, reducing the time wasted in invalid testing, and further improving testing efficiency.

[0049] (2) This application realizes data exchange between the static analysis module and the dynamic simulation module through the communication module, which can ensure the collaborative work of the two, so that the analysis results can be quickly fed back to the execution module, thereby improving the overall test efficiency.

[0050] (3) The coordinated multi-route-aware input delivery algorithm of the present application ensures maximum coverage of all possible input paths within limited fuzz testing inputs, and fully combines the inherent characteristics of the firmware during the fuzz testing process, thereby improving code coverage.

[0051] (4) By optimizing the input delivery process, this application can trigger potential vulnerabilities more quickly, accelerating the vulnerability discovery process. Furthermore, this application plug-in can be integrated with a variety of existing firmware fuzz testing tools, demonstrating good adaptability and compatibility.

[0052] (5) This application proposes a corresponding solution for the multi-peripheral input and interrupt mechanism unique to firmware, effectively solving the limitations of traditional software fuzz testing technology in firmware testing. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1 This is one of the structural diagrams of the fuzzy test input optimization device for IoT device firmware provided by an embodiment of the present application;

[0054] Figure 2 This is the second structural diagram of the fuzzy test input optimization device for IoT device firmware provided by an embodiment of the present application;

[0055] Figure 3 This is one of the flow charts of the method for optimizing the input transmission of IoT firmware fuzz testing provided by the embodiment of the present application;

[0056] Figure 4 This is the second flow chart of the method for optimizing the input transmission of IoT firmware fuzz testing provided by the embodiment of the present application;

[0057] Figure 5 A schematic structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0058] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0059] The term "and / or" as used herein describes an association between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. The symbol " / " as used herein indicates that the related objects are in an "or" relationship, for example, A / B means either A or B.

[0060] The terms "first" and "second" in this specification and claims are used to distinguish different objects rather than to describe a specific order of objects. For example, "first response message" and "second response message" are used to distinguish different response messages rather than to describe a specific order of response messages.

[0061] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0062] In the description of the embodiments of the present application, unless otherwise specified, "multiple" means two or more, for example, multiple processing units means two or more processing units, etc.; multiple elements means two or more elements, etc.

[0063] Next, the technical solutions provided in the embodiments of this application are introduced.

[0064] Reference Figure 1 The present application provides a fuzz testing input optimization device for IoT device firmware, including a static analysis module 110, a dynamic simulation module 120, a communication module 130, an input routing mapping module 140, an input transfer point identification module 150, and a data length and multi-route input transfer perception module 160;

[0065] The static analysis module is used to analyze the firmware through the API interface, identify the input transfer points of the bare metal firmware, and realize automatic identification through custom scripts;

[0066] The dynamic simulation module is used to identify the input transfer points of the real-time operating system firmware based on the binary dynamic simulation execution framework, and to implement the length inference mechanism and the final input transfer algorithm;

[0067] The communication module is used to implement data exchange between the static analysis module and the dynamic simulation module based on the target communication protocol;

[0068] The input route mapping module is used to identify and dynamically monitor data retrieval points, input processing points, and availability check instructions in the firmware through a combination of static analysis and dynamic analysis to obtain mapping results;

[0069] The input transfer point identification module is used to automatically identify the input transfer point of the firmware based on the mapping result;

[0070] The data length and multi-route input transfer perception module is used to dynamically determine the minimum length and maximum length of the input data of the input transfer point, optimize the input transfer point of the firmware fuzz test, dynamically calculate the retained data length, monitor the transfer point and update the transfer point set to ensure effective coverage and data update.

[0071] This application proposes a comprehensive fuzz testing input optimization device for IoT device firmware, aiming to improve the efficiency and effectiveness of firmware testing and ensure product security. The device primarily includes the following key modules, which work together and integrate seamlessly to achieve intelligent fuzz testing.

[0072] The static analysis module conducts in-depth analysis of firmware through APIs, aiming to identify input points within the firmware. Customized scripts enable automation, reducing manual intervention and improving analysis efficiency. This module can quickly and comprehensively analyze firmware code to identify potential vulnerabilities and attack surfaces. The automated scripts can also be flexibly adjusted based on different firmware characteristics to improve identification accuracy.

[0073] The dynamic simulation module, based on a binary dynamic simulation execution framework, identifies input delivery points within the RTOS-Base firmware. This module not only dynamically analyzes the firmware's runtime behavior but also implements an input length inference mechanism and executes the final input delivery algorithm. This length inference mechanism dynamically determines the minimum and maximum length requirements for input data based on input characteristics and actual runtime conditions.

[0074] Furthermore, the firmware analysis of the static analysis module includes: disassembly, control flow analysis and data flow analysis; the length inference mechanism of the dynamic simulation module includes: snapshot creation, recovery and parallel instance management, and the final input transfer algorithm includes dynamic slicing and transfer logic.

[0075] The communication module is responsible for data exchange between the static analysis module and the dynamic simulation module, ensuring efficient and accurate information flow. Designed using the target communication protocol, Socket, it ensures stable data transmission between modules and avoids information loss. It also provides a real-time feedback mechanism for the entire system, ensuring information consistency during analysis and testing.

[0076] It should be noted that the integration with existing tools is as follows: an adaptation layer is implemented for Fuzzware, μEmu, and SEmu to ensure seamless integration of the present embodiment. AFL++ is used as the fuzz testing front end to implement input generation and mutation strategies.

[0077] The input route mapping module uses a combination of static and dynamic analysis to identify and dynamically monitor data retrieval points, input processing points, and availability check instructions within the firmware, ultimately generating clear mapping results. This module dynamically adjusts firmware monitoring strategies to ensure effective capture of critical data paths in complex and changing operating environments. The mapping results provide a basis for subsequent input delivery logic, ensuring the validity and relevance of input data.

[0078] The input transfer point recognition module automatically identifies various firmware input transfer points based on mapping results, saving manual operation time and improving recognition efficiency and accuracy. Advanced algorithms eliminate redundancy and misidentification, rapidly extracting valid information from large amounts of data. This enhances the system's adaptability, enabling it to operate efficiently across diverse firmware architectures and communication protocols.

[0079] The Data Length and Multi-Route Input Transfer Awareness module dynamically determines the minimum and maximum lengths of input data at each input transfer point and adaptively adjusts the length of the input data, supporting fuzz testing across multiple input transfer points. This module possesses intelligent analysis capabilities and dynamically adjusts input data for different input transfer points, ensuring the effectiveness of each test case. This intelligent optimization of input data significantly improves fuzz testing efficiency and reduces unnecessary redundant testing.

[0080] The fuzz testing input optimization device for IoT device firmware in this application integrates multiple functional modules, including static analysis, dynamic simulation, communication, input mapping, automatic identification, and testing, to create an efficient and intelligent firmware testing system. This device not only accelerates firmware testing and improves testing efficiency, but also helps increase vulnerability discovery rates, thereby enhancing the security of IoT devices.

[0081] Optionally, the input route mapping module includes a data retrieval identification submodule, an input processing identification submodule, and an availability check identification submodule;

[0082] The data retrieval identification submodule is used to monitor the read operation of the peripheral input through the hook function of the binary dynamic simulation execution framework and capture the value of the current program counter as a data retrieval point;

[0083] The input processing identification submodule is used to mark input data starting from the data retrieval instruction through dynamic taint analysis, and use the hook function of the Unicorn framework to track the memory read operation of the marked data until all the marked data is processed or cleared;

[0084] The availability check identification submodule is used to analyze global variables in the interrupt processing process, identify potential comparison instructions based on the cross-reference relationship of the global variables, and perform data flow analysis and control flow analysis on the global variables to determine availability check instructions.

[0085] In this embodiment, the input routing mapping module, as a core component of the fuzz testing input optimization device for IoT device firmware, aims to efficiently identify key input delivery points in the firmware, enabling subsequent fuzz testing to be more accurate and effective. This module consists of three submodules: a data retrieval identification submodule, an input processing identification submodule, and an availability check identification submodule, which are described in detail below:

[0086] Specifically, the data retrieval identification submodule monitors peripheral input read operations within the firmware using the UC_HOOK_MEM_READ hook function in a binary dynamic simulation execution framework, such as the Unicorn framework. By setting a hook at the address to be monitored, the hook is triggered when program execution reaches that address, allowing the module to capture the current program counter (PC) value. Whenever a peripheral input is read, the captured PC value is saved as a data retrieval point in the mapping result.

[0087] For bare-metal firmware, check that the data retrieval operation occurs in an interrupt service routine (ISR); for RTOS firmware, verify that the read operation immediately follows the PendSV interrupt.

[0088] The input processing identification submodule is responsible for marking the input data read from the data retrieval instruction through dynamic taint analysis technology and tracking the subsequent processing of this data in memory.

[0089] Starting from the data retrieval instruction, the input data is marked as "tainted data". The hook function UC_HOOK_MEM_READ of the binary dynamic simulation execution framework is used to monitor all memory read operations involving the marked data until the marked data is processed or cleared.

[0090] The availability check identification submodule analyzes global variables in the firmware to identify potential availability check instructions. Cross-reference analysis of global variables examines the global variables affected and involved during interrupt handling to identify conditions that could affect input validity. Data and control flow analysis, combined with changes in global variables, identifies comparison instructions used to verify input validity.

[0091] The detailed processes of each submodule are as follows:

[0092] Data retrieval identification:

[0093] Utilize the UC_HOOK_MEM_READ_AFTER hook function in a binary dynamic simulation execution framework, such as the Unicorn framework, to monitor peripheral input read addresses, including data registers and DMA memory-mapped addresses. When these hooks are executed, the current program counter value is captured and recorded as a potential data retrieval point. For bare-metal firmware, check whether the data retrieval operation occurs within the interrupt service routine (ISR); for real-time operating system firmware, verify whether the read operation immediately follows the PendSV interrupt.

[0094] Input processing identification:

[0095] Implement dynamic taint analysis, marking input data starting with data retrieval instructions. Use the UC_HOOK_MEM_READ hook in the binary dynamic emulation execution framework to track memory reads of marked data. When a conditional branch instruction (such as CMP) is encountered that involves marked data, it is considered a potential processing operation. Continue tracking the data flow until all marked data encounters a processing operation or is cleared.

[0096] Availability checks identify:

[0097] For the bare-metal model firmware, identify instructions that modify global variables upon interrupt exit. Using Ghidra's static analysis capabilities, perform forward data flow analysis on these global variables. Leveraging Ghidra's getReferencesTo API, find cross-references to these variables and identify potential comparison instructions. Starting from the basic block of the buffer read instruction, perform reverse control flow analysis, ultimately identifying the availability check instruction.

[0098] The input routing mapping module of the present embodiment, through the collaborative work of its three submodules, enables more comprehensive and efficient analysis of firmware input. The data retrieval identification submodule ensures real-time capture of input data points, the input processing identification submodule tracks data flow through dynamic taint analysis, and the availability check identification submodule analyzes the relationship between global variables and comparison instructions. This series of sophisticated operations helps improve the accuracy and efficiency of fuzz testing, making it easier to evaluate and fix potential vulnerabilities in firmware, thereby enhancing the security of IoT devices.

[0099] Optionally, the input transfer point identification module includes a bare metal firmware identification submodule and a real-time operating system firmware identification submodule;

[0100] The bare metal firmware identification submodule is used to determine the most recent common caller function of the input availability check instruction and the most recent input processing instruction through a common ancestor algorithm, analyze the control flow relationship between the input availability check instruction and the most recent input processing instruction, and set the entry point of the most recent common caller function as the input transfer point;

[0101] The real-time operating system firmware identification submodule is used to dynamically monitor firmware execution using a hook function of a binary dynamic simulation execution framework, identify and determine whether an infinite loop switched from an interrupt is a unique basic block, and mark the entry point of the infinite loop that meets the conditions as an input transfer point.

[0102] Specifically, in the fuzz testing input optimization apparatus for IoT device firmware, the bare metal firmware identification submodule and the real-time operating system firmware identification submodule are responsible for identifying the input delivery points of different types of firmware. The following is a detailed description of these two submodules.

[0103] Bare-metal firmware identification submodule: The main purpose of this submodule is to determine the control flow relationship between the input availability check instruction and the most recent input processing instruction through the common ancestor algorithm, and mark the entry point of the most recent common caller function as the input transfer point.

[0104] The common ancestor algorithm is used to identify the lowest common parent function between two functions in a control flow graph. For the input availability check instruction and the most recent input processing instruction, their call chains are first analyzed and recorded. Using the call graph query function, the most recent common caller of these two functions is located and analyzed in conjunction with control flow relationships. The common caller's location in the global context and its relationship to the input availability check instruction and input processing instruction are determined. By exploring this path layer by layer, critical path information is extracted.

[0105] Then, the entry point of the nearest public caller function is used as the input transfer point, which ensures that the path through which the input data passes can be effectively captured and analyzed.

[0106] This embodiment uses the common ancestor algorithm to find important input-related connections across multiple call paths, improving understanding of control flow in complex firmware. By analyzing control flow relationships hierarchically, it can identify complex situations such as nested calls, improving the comprehensiveness of input point identification.

[0107] Real-time operating system firmware identification submodule: This submodule dynamically monitors the execution of the real-time operating system firmware through a binary dynamic simulation execution framework such as the hook function UC_HOOK_BLOCK of the Unicorn framework, identifies whether the infinite loop switched to after an interrupt is a unique basic block, and marks the entry point of the infinite loop that meets the conditions as the input transfer point.

[0108] It should be noted that during monitoring, the submodule analyzes the code segment entered after an interrupt switch and evaluates whether it constitutes a unique basic block. If the address of the loop does not change across multiple executions, it is considered an infinite loop. The control flow of the loop body and other code blocks is further analyzed to ensure accurate identification. Infinite loop entry points that meet the unique basic block condition are marked as input transfer points. These points are typically important nodes where firmware receives and processes input.

[0109] The specific implementation method is:

[0110] For bare-metal firmware input routing: Implement the common ancestor algorithm to find the nearest common caller function between the input availability check instruction and the nearest input processing instruction. Analyze the control flow relationship between these instructions to determine their nearest common caller function. Define the entry point of this common caller function as the input transfer point. For real-time operating system firmware input routing: Use a binary dynamic simulation execution framework, such as the UC_HOOK_BLOCK hook in the Unicorn framework, to dynamically monitor firmware execution. Identify infinite loops caused by switching from the PendSV interrupt. Judgment condition: Enter the infinite loop within the only basic block after the PendSV interrupt. Mark the entry point of the infinite loop that meets the condition as the input transfer point.

[0111] The bare-metal firmware identification submodule and the real-time operating system firmware identification submodule of the present embodiment together constitute a key component of the input transfer optimization device for IoT firmware fuzz testing. The former analyzes control flow relationships using a common ancestor algorithm, while the latter identifies infinite loops through dynamic monitoring. The combination of these two submodules enables more accurate and efficient identification of input transfer points in different types of firmware, significantly improving the ability to detect and repair potential firmware vulnerabilities.

[0112] Optionally, the data length and multi-route input transfer perception module includes a length range determination submodule and a fuzzy testing submodule;

[0113] The length range determination submodule is used to dynamically determine the input data length range of each input transfer point based on a snapshot mechanism; the snapshot mechanism dynamically determines the minimum length by creating a snapshot of the firmware execution state at each transfer point and using multiple parallel instances to increment the input length, while monitoring the write operation of the global input buffer to determine the maximum length.

[0114] This embodiment of the application introduces a new snapshot mechanism for dynamically determining the input data length range of each transfer point:

[0115] a) Minimum length determination:

[0116] Implement the UC_SNAPSHOT_TAKE and UC_SNAPSHOT_RESTORE mechanisms to create snapshots of the firmware's execution state at each transfer point. Create multiple parallel instances (32 by default), each with its input length incremented by the least read byte (LRB). Set up a hook for each instance to monitor whether it has reached the nearest input processing instruction. Record the shortest input length that first triggered the input processing instruction as the minimum length. If none of the 32 instances triggers the processing instruction, run N more instances, starting at byte N+1, until the minimum length is found.

[0117] b) Maximum length determination:

[0118] Monitor the write operations to the upper limit address of the global input buffer. Gradually increase the input length and observe the changes in the consecutive write addresses. Determine the maximum length when one of the following conditions is detected:

[0119] 1. The last byte is written to the same address as the second-to-last byte;

[0120] 2. The write address returns the buffer base address;

[0121] 3. Write to non-contiguous address space.

[0122] Optionally, the fuzz testing submodule is used to:

[0123] Determine the data length based on the total fuzz test input length, the number of current transfer points, and the smallest upper bound among all transfer points;

[0124] Detecting whether the data length is less than 0, and if so, reducing the number of current transfer points until the data length is greater than or equal to 0;

[0125] Using the hook function to monitor the execution of firmware instructions, when encountering an input transfer point, determining whether the remaining input length is sufficient, and calculating the available input length of the current transfer point;

[0126] Determine the transfer length based on the available input length, use the transfer length to slice the fuzz test input and transfer it to the firmware, and update the input position;

[0127] Update the delivery point set according to the new data retrieval point, and recalculate the current delivery point quantity and data length to ensure that the new delivery point is covered.

[0128] Furthermore, the fuzz testing submodule is also used to:

[0129] Determine whether the available input length is greater than 0;

[0130] If the available input length is less than 0, it is determined that the input data length of the current transfer point is insufficient to meet the minimum input length required by the current transfer point, and zeros are used to fill the data to meet the minimum length requirement, and the minimum length is used as the determined transfer length;

[0131] If the available input length is greater than or equal to 0, the transfer length is randomly determined.

[0132] Specifically, in this embodiment, dynamic adjustment of input length is a key approach to improving testing efficiency and vulnerability discovery during IoT firmware fuzz testing. The following describes a detailed approach to data length management based on input length, the number of transfer points, and the available input length to ensure effective firmware testing.

[0133] First, determine the initial data length. It is necessary to determine the total fuzz test input length, denoted as LenR, the current number of transfer points, denoted as N, and the minimum upper limit of all transfer points, denoted as Min.

[0134] The current data length is determined by the following formula:

[0135] LenR=LenFI-N*Min

[0136] Check whether the calculated data length is less than 0. If the data length is less than 0, it means that there are too many current transfer points, resulting in the data length allocated to each transfer point being insufficient for effective testing. It is necessary to reduce N until the data length is ≥ 0.

[0137] Use the hook function UC_HOOK_CODE to monitor the firmware execution process. When encountering an input transfer point, capture the firmware execution status and verify whether the remaining input length is sufficient to support the current transfer point processing. Use the following formula to calculate the available input length:

[0138] Δ=LenR+Min-Lowp

[0139] Where Δ is the available input length and Lowp is the minimum length requirement;

[0140] If Δ<0, pad with zeros to meet the minimum length requirement. Otherwise, if Δ≥0, the transfer length is randomly determined as shown in the following formula:

[0141] LenSI=Rand(FI[Pos])mod t+Lowp

[0142] t=min(LenR+Min,UPp)-Lowp

[0143] Among them, LenSI represents the length of a single transfer, FI represents the complete fuzz test input data array, Rand(FI[Pos]) represents the random value of the element at position Pos in the input set FI, mod is the modulo operation, UPP represents the maximum length requirement of the current transfer point, and t represents the upper limit of the random length range.

[0144] Furthermore, data of a fixed length is sliced ​​from the fuzz test input and passed to the firmware. The input position is updated so that the next test can start from the input position subsequent to the previous transfer point. Based on the newly identified data retrieval point, the current set of transfer points and the input data requirements for each transfer point are updated. The number of current transfer points and data length are recalculated to ensure that the newly identified transfer points can be covered, providing an accurate input data configuration for subsequent fuzz testing.

[0145] This embodiment aims to improve the accuracy and efficiency of fuzz testing by dynamically adjusting data length, controlling the number of transfer points, and cyclically checking input availability. It utilizes hook functions to monitor firmware instructions in real time and updates input information based on real-time detection results, ensuring that each transfer point receives appropriate input data for effective testing.

[0146] The system framework diagram of this application is as follows Figure 2 As shown. It mainly includes a static analysis module and a dynamic simulation module. The dynamic simulation module is mainly implemented based on the Unicorn simulator and is mainly responsible for the simulation and dynamic execution of the firmware. Its underlying implementation is mainly based on the Unicorn simulator. While implementing instruction simulation, a series of Hook mechanisms are added to the original simulator to achieve more complete firmware analysis functions. The static analysis module is mainly supported by the Ghidra server. After the dynamic simulation module calls the corresponding processing module, it uses a socket to communicate with the static analysis module. The specific process is as follows:

[0147] After the firmware is started in the simulation environment, the fuzz tester takes over its input interface. The dynamic simulation module first calls the input routing mapping module and uses a socket to communicate with the static analysis module. The static analysis module executes the corresponding module script, obtains the firmware's data retrieval point and availability checkpoint, and returns it to the dynamic simulation module. The dynamic module then calculates new dynamic data through the input routing mapping module and sends it to the input transfer point identification module, instructing it to call the static analysis module. The static module identifies the input transfer point through data flow and control flow analysis techniques. After receiving the input transfer point information, the dynamic module calls the data length and multi-route input transfer perception algorithm to calculate the data length. The input transfer perception algorithm then determines the amount of data to be inserted each time, achieving efficient data utilization and improving fuzz testing efficiency.

[0148] Reference Figure 3 , the present application also provides an IoT firmware fuzz test input sending optimization method, comprising:

[0149] S301. Use the static analysis module to perform firmware analysis through the API interface, identify the input transfer point of the bare metal firmware, and realize automated identification through custom scripts;

[0150] S302 using a dynamic simulation module based on the binary dynamic simulation execution framework to identify the real-time operating system firmware input transfer point, and the implementation of the length inference mechanism and the final input transfer algorithm;

[0151] S303. Using the communication module to achieve data exchange between the static analysis module and the dynamic simulation module based on the target communication protocol;

[0152] S304. Using the input routing mapping module through a combination of static and dynamic analysis methods, identify and dynamically monitor the data retrieval points, input processing points and availability check instructions in the firmware to obtain the mapping results;

[0153] S305. Using the input transfer point identification module based on the mapping results, automatically identify the firmware input transfer point;

[0154] S306. Utilize the data length and multi-route input transfer perception module to dynamically determine the minimum length and maximum length of the input data of the input transfer point, and optimize the input transfer point of the firmware fuzz test, dynamically calculate the retained data length, monitor the transfer point and update the transfer point set to ensure effective coverage and data update.

[0155] Reference Figure 4 , Figure 4 It is the firmware fuzz testing flow chart.

[0156] Perform static analysis and dynamic simulation on target firmware;

[0157] Determine whether the input transfer point is obtained;

[0158] If yes, calculate the upper and lower limits of the transfer point length;

[0159] Otherwise return to static analysis;

[0160] Multi-route aware algorithm slicing;

[0161] Determine whether the data has been consumed;

[0162] If yes, this round of testing ends;

[0163] Otherwise, return to dynamic simulation.

[0164] Furthermore, the complete process of the IoT firmware fuzz test input transmission optimization method provided by the embodiment of the present application is as follows:

[0165] Step 1: First, statically analyze the firmware and disassemble the firmware binary file using Ghidra. By analyzing the instruction sequence, identify instructions related to peripheral data reading, such as the LDR (load) instruction for specific memory-mapped I / O addresses. These instructions are marked as potential data retrieval points. Then, start the dynamic analysis module. Run the firmware in the Unicorn simulation environment and set memory read hooks at the previously identified data retrieval points. When these hooks are executed, the present invention records the current program counter (PC) value and starts tracking the data read from that point.

[0166] Through dynamic taint analysis, the propagation of tagged data is tracked. When an instruction that compares or operates on this data is encountered, it is marked as an input processing point. Simultaneously, the present invention identifies interrupt service routines (ISRs) that affect global variables and, through static analysis, finds conditional branch instructions that check these global variables.

[0167] Step 2: Use a graph algorithm to find the lowest common ancestor function between the availability checkpoint and the input processing point. The entry point of this function is identified as the input transfer point. During dynamic analysis, the firmware execution flow is monitored. When a simple loop (typically the idle task) is detected after returning from the PendSV interrupt, the entry point of this loop is marked as the input transfer point.

[0168] Step 3: At each identified input transfer point, the present invention creates a snapshot of the firmware execution state. It then derives multiple parallel instances, each of which executes the firmware with a different input length. The present invention starts with the minimum possible length (such as 1 byte) and gradually increases the input length until the minimum length that can trigger the input processing point is found, and records it as the minimum input length of the transfer point. To determine the maximum input length, the dynamic module monitors the write operation of the global input buffer. It continues to increase the input length until a buffer overflow (such as the write address exceeds the predefined range) or a circular write (such as the write address returns to the starting position of the buffer) is detected. The last input length that does not cause these situations is recorded as the maximum input length.

[0169] Step 4: During fuzz testing, when an input transfer point is reached, the algorithm dynamically calculates the length of the input slice to be transferred based on the length requirement of the current transfer point and the total remaining input length. The algorithm maintains a global counter N, which represents the expected number of transfer points. Initially, N is set to the number of unique transfer points identified. If fewer than N transfer points are encountered in a fuzzing round, the algorithm decreases N in the next round to ensure that each transfer point receives sufficient input data.

[0170] Step 5: When the fuzz tester generates a new test case, the input transfer algorithm will split the test case into multiple slices based on the previously identified transfer point information. During the firmware execution process, when a transfer point is encountered, the present invention transfers the corresponding input slice instead of transferring the entire input at once.

[0171] Step 6: After the fuzz tester is finished, check whether there is a new crash in the crash queue, and perform log checking, crash analysis, and other operations on the generated crash.

[0172] Reference Figure 5 Based on the method in the above embodiment, an embodiment of the present application provides an electronic device, which may include: a processor (processor) 510, a communication interface (Communications Interface) 520, a memory (memory) 530 and a communication bus 540, wherein the processor 510, the communication interface 520, and the memory 530 communicate with each other via the communication bus 540. The processor 510 can call the logic instructions in the memory 530 to execute the method in the above embodiment.

[0173] In addition, the logic instructions in the above-mentioned memory 530 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when sold or used as an independent product. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application.

[0174] Based on the method in the above embodiment, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method in the above embodiment.

[0175] Based on the method in the above embodiment, an embodiment of the present application provides a computer program product. When the computer program product runs on a processor, the processor executes the method in the above embodiment.

[0176] It is understood that the processor in the embodiments of the present application may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0177] The method steps in the embodiments of the present application can be implemented by hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC.

[0178] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted via the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state drive (SSD)).

[0179] It will be understood that the various numerical numbers involved in the embodiments of the present application are merely distinctions for the convenience of description and are not intended to limit the scope of the embodiments of the present application.

[0180] It is easy for those skilled in the art to understand that the above is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present application should be included in the scope of protection of the present application.

Claims

1. A fuzzy test input optimization device for IoT device firmware, characterized in that: It includes static analysis module, dynamic simulation module, communication module, input route mapping module, input transfer point identification module and data length and multi-route input transfer perception module; The static analysis module is used to analyze the firmware through the API interface, identify the input transfer points of the bare metal firmware, and realize automatic identification through custom scripts; The dynamic simulation module is used to identify the input transfer points of the real-time operating system firmware based on the binary dynamic simulation execution framework, and to implement the length inference mechanism and the final input transfer algorithm; The communication module is used to implement data exchange between the static analysis module and the dynamic simulation module based on the target communication protocol; The input route mapping module is used to identify and dynamically monitor data retrieval points, input processing points, and availability check instructions in the firmware through a combination of static analysis and dynamic analysis to obtain mapping results; The input transfer point identification module is used to automatically identify the input transfer point of the firmware based on the mapping result; The data length and multi-route input transfer perception module is used to dynamically determine the minimum length and maximum length of the input data of the input transfer point, optimize the input transfer point of the firmware fuzz test, dynamically calculate the retained data length, monitor the transfer point and update the transfer point set to ensure effective coverage and data update.

2. The fuzzy test input optimization device for IoT device firmware according to claim 1, characterized in that: The input route mapping module includes a data retrieval identification submodule, an input processing identification submodule, and an availability check identification submodule; The data retrieval identification submodule is used to monitor the read operation of the peripheral input through the hook function of the binary dynamic simulation execution framework and capture the value of the current program counter as a data retrieval point; The input processing identification submodule is used to mark input data starting from the data retrieval instruction through dynamic taint analysis, and use the hook function of the Unicorn framework to track the memory read operation of the marked data until all the marked data is processed or cleared; The availability check identification submodule is used to analyze global variables in the interrupt processing process, identify potential comparison instructions based on the cross-reference relationship of the global variables, and perform data flow analysis and control flow analysis on the global variables to determine availability check instructions.

3. The fuzzy test input optimization device for IoT device firmware according to claim 1, characterized in that: The input transfer point identification module includes a bare metal firmware identification submodule and a real-time operating system firmware identification submodule; The bare metal firmware identification submodule is used to determine the most recent common caller function of the input availability check instruction and the most recent input processing instruction through a common ancestor algorithm, analyze the control flow relationship between the input availability check instruction and the most recent input processing instruction, and set the entry point of the most recent common caller function as the input transfer point; The real-time operating system firmware identification submodule is used to dynamically monitor firmware execution using a hook function of a binary dynamic simulation execution framework, identify and determine whether an infinite loop switched from an interrupt is a unique basic block, and mark the entry point of the infinite loop that meets the conditions as an input transfer point.

4. The fuzzy test input optimization device for IoT device firmware according to claim 1, characterized in that: The data length and multi-route input transfer perception module includes a length range determination submodule and a fuzzy testing submodule; The length range determination submodule is used to dynamically determine the input data length range of each input transfer point based on a snapshot mechanism; The snapshot mechanism creates a snapshot of the firmware execution state at each transfer point and dynamically determines the minimum length by increasing the input length using multiple parallel instances, while monitoring the write operation of the global input buffer to determine the maximum length.

5. The fuzzy test input optimization device for IoT device firmware according to claim 4, characterized in that: The fuzz testing submodule is used to: Determine the data length based on the total fuzz test input length, the number of current transfer points, and the smallest upper bound among all transfer points; Detecting whether the data length is less than 0, and if so, reducing the number of current transfer points until the data length is greater than or equal to 0; Using the hook function to monitor the execution of firmware instructions, when encountering an input transfer point, determining whether the remaining input length is sufficient, and calculating the available input length of the current transfer point; Determine the transfer length based on the available input length, use the transfer length to slice the fuzz test input and transfer it to the firmware, and update the input position; Update the delivery point set according to the new data retrieval point, and recalculate the current delivery point quantity and data length to ensure that the new delivery point is covered.

6. The fuzzy test input optimization device for IoT device firmware according to claim 5, characterized in that: The fuzz testing submodule is further used to: Determine whether the available input length is greater than 0; If the available input length is less than 0, it is determined that the input data length of the current transfer point is insufficient to meet the minimum input length required by the current transfer point, and zeros are used to fill the data to meet the minimum length requirement, and the minimum length is used as the determined transfer length; If the available input length is greater than or equal to 0, the transfer length is randomly determined.

7. The fuzzy test input optimization device for IoT device firmware according to claim 1, characterized in that: The firmware analysis of the static analysis module includes: disassembly, control flow analysis and data flow analysis; the length inference mechanism of the dynamic simulation module includes: snapshot creation, recovery and parallel instance management, and the final input transfer algorithm includes dynamic slicing and transfer logic.

8. A method for optimizing the sending of fuzzy test input for IoT firmware implemented by a fuzzy test input optimization device for IoT device firmware according to any one of claims 1 to 7, characterized in that: include: Use the static analysis module to analyze firmware through the API interface, identify the input transfer points of bare metal firmware, and realize automatic identification through custom scripts; Using the dynamic simulation module to identify the input delivery points of the real-time operating system firmware based on the binary dynamic simulation execution framework, and to implement the length inference mechanism and the final input delivery algorithm; Using the communication module to implement data exchange between the static analysis module and the dynamic simulation module based on the target communication protocol; The input routing mapping module uses a combination of static and dynamic analysis to identify and dynamically monitor data retrieval points, input processing points, and availability check instructions in the firmware to obtain mapping results. Automatically identifying the input transfer point of the firmware based on the mapping result using an input transfer point identification module; The data length and multi-route input transfer awareness module is used to dynamically determine the minimum and maximum length of the input data of the input transfer point, optimize the input transfer points of firmware fuzz testing, dynamically calculate the retained data length, monitor the transfer points and update the transfer point set to ensure effective coverage and data update.

9. An electronic device, characterized in that: include: at least one memory for storing a computer program; At least one processor is configured to execute the program stored in the memory, and when the program stored in the memory is executed, the processor is configured to execute the method according to claim 8.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is run on a processor, the processor is caused to perform the method according to claim 8 .

Images