Fuzzy test input optimization device for Internet of Things equipment firmware

Abstract

The invention belongs to the technical field of computer information processing, and particularly discloses an internet of things equipment firmware-oriented fuzz test input optimization device, which comprises a static analysis module used for carrying out firmware analysis through an API interface, identifying an input transmission point of bare computer firmware, and realizing automatic identification through a custom script; the dynamic simulation module is used for identifying an input transfer point of the firmware of the real-time operating system and realizing a length inference mechanism and a final input transfer algorithm; the input routing mapping module is used for identifying and dynamically monitoring a data retrieval point, an input processing point and an availability check instruction in firmware to obtain a mapping result; the input transmission point identification module is used for automatically identifying an input transmission point of the firmware based on the mapping result; and the sensing module is used for dynamically determining the minimum length and the maximum length of the input data of the input transmission point, optimizing the input transmission point of the firmware fuzz test, and dynamically calculating the length of the reserved data. According to the invention, the fuzz testing efficiency can be improved.

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] In existing firmware fuzz testing techniques, researchers usually use rehosting technology, that is, executing firmware in a simulation environment to discover potential vulnerabilities. This method has received widespread attention and application in the past decade, especially when detecting security vulnerabilities in embedded devices based on microcontroller units (MCUs), fuzz testing has become an effective technical means. However, due to the limited hardware resources of MCUs, running fuzz testing directly on real devices is often inefficient and non-scalable. Therefore, researchers usually rehost the firmware to a simulation environment, resulting in three different research directions:

[0003] 1. Improving simulation fidelity: In order to avoid simulation failures or erroneous results during fuzz testing, many researchers are committed to improving simulation fidelity by improving peripheral modeling. These studies focus on ensuring that the execution behavior of the firmware in the simulation environment is as close as possible to its performance on real hardware to improve the accuracy of vulnerability detection. For example, some results use the technology of dynamic symbolic execution to simulate the behavior of peripherals by inputting learned symbolic values ​​at peripheral access points during program execution.

[0004] 2. Fuzz testing performance optimization: Since firmware usually runs in a resource-constrained environment, the performance of fuzz testing has also been studied in depth. Researchers have used a variety of technical means to try to speed up the execution of fuzz testing to cover more code paths within a limited time, thereby improving the efficiency of vulnerability discovery.

[0005] 3. Fuzz testing strategies for firmware-specific features: Unlike traditional software, firmware has some specific features, such as it often receives input data from multiple peripheral interfaces. In order to adapt to these features, some researchers have improved traditional fuzz testing strategies. For example, in response to the need for firmware to receive multi-byte magic strings, a study proposed a corresponding multi-stream fuzz testing method to unlock new code blocks.

[0006] However, existing firmware fuzz testing tools often do not consider the timing and amount of input data actually required by the firmware, but instead adopt an arbitrary delivery mechanism, which results in either excessive input resulting in data loss or overwriting, or insufficient input resulting in insufficient logic testing when the firmware processes the received input. For example, traditional software fuzz testing usually relies on a synchronous I / O model, directly passing input data to the firmware through the POSIX API interface. However, firmware usually relies on peripheral-specific asynchronous I / O channels, which usually receive data from multiple sources at the same time, and the expected data length is not clearly specified. This mismatch results in the inability of existing fuzz testing tools to effectively utilize test inputs, wasting a large number of fuzz testing opportunities, and significantly reducing 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 prior art, the purpose of this application is to provide a fuzzy testing input optimization device for IoT device firmware, aiming to solve the problem of low efficiency of fuzzy testing in existing firmware fuzz testing technology.

[0009] In a first aspect, the present application provides a fuzzy test input optimization device for IoT device firmware, including 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 perform firmware analysis through the API interface, identify the input transfer points of the bare metal firmware, and realize automatic identification through a custom script;

[0011] The dynamic simulation module is used to identify the input transfer point 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 the data retrieval point;

[0018] The input processing identification submodule is used to mark the 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 are processed or cleared;

[0019] The availability check identification submodule is used to analyze global variables in the interrupt processing process, identify potential comparison instructions according to the cross-reference relationship of the global variables, and perform data flow analysis and control flow analysis on the global variables to determine the 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 use 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 delivery 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 current number of transfer points, and the smallest upper limit of all transfer points;

[0027] Detect whether the data length is less than 0, and if so, reduce the current transfer point number 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 that the remaining input length is sufficient, and calculating the available input length of the current transfer point;

[0029] Determine a transfer length based on the available input length, use the transfer length to slice the fuzz test input 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 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 and dynamic analysis 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 delivery awareness module is used to dynamically determine the minimum and maximum length of the input data of the input delivery point, optimize the input delivery points of the firmware fuzz testing, dynamically calculate the retained data length, monitor the delivery points and update the delivery 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. When the computer program product runs on a processor, the processor executes 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 prior art:

[0048] (1) This application makes the entire fuzz testing process more efficient through the automatic identification of the static analysis module and the identification of the input transfer point of the real-time operating system firmware by the dynamic simulation module. By combining static analysis and dynamic analysis, the input transfer point, data retrieval point and input processing point in the firmware can be quickly identified, reducing the transmission of invalid input and data waste, and significantly improving the efficiency of fuzz testing. In addition, the minimum and maximum lengths of the input data are dynamically determined through the data length and multi-route input transfer perception module, and the input length is adaptively adjusted according to the real-time situation, which can ensure that the input data meets the minimum requirements of firmware processing, increase the proportion of valid input, reduce the time waste of invalid testing, and further improve the test efficiency.

[0049] (2) The present application realizes data exchange between the static analysis module and the dynamic simulation module through the communication module, which can ensure the coordinated work of the two modules, 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 firmware's own characteristics during the fuzz testing process, thereby improving code coverage.

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

[0052] (5) This application proposes a corresponding solution for the multiple peripheral inputs and interrupt mechanisms unique to firmware, effectively addressing 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 schematic diagrams of the fuzzy test input optimization device for IoT device firmware provided in the 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 in an embodiment of the present application;

[0055] Figure 3 This is one of the flow charts of the IoT firmware fuzzy test input sending optimization method provided in the embodiment of the present application;

[0056] Figure 4 This is the second flow chart of the IoT firmware fuzzy test input transmission optimization method provided in the embodiment of the present application;

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

[0058] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0059] The term "and / or" in this article is a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. The symbol " / " in this article indicates that the associated objects are in an or relationship, for example, A / B means A or B.

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

[0061] In the embodiments of the present 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 the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

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

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

[0064] Reference Figure 1 , the present application provides a fuzzy test 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 perform firmware analysis through the API interface, identify the input transfer points of the bare metal firmware, and realize automatic identification through a custom script;

[0066] The dynamic simulation module is used to identify the input transfer point 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 test input optimization device for IoT device firmware, aiming to improve the efficiency and effectiveness of firmware testing and ensure product security. The device mainly includes the following key modules, which cooperate with each other and are organically integrated to achieve intelligent fuzz testing.

[0072] The static analysis module conducts in-depth analysis of the firmware through the API interface, aiming to identify the input transfer points inside the firmware, and achieves automation through customized scripts to reduce manual intervention, thereby improving analysis efficiency. It can quickly and comprehensively parse the firmware code to find possible vulnerabilities and attack surfaces. The automated script can also be flexibly adjusted according to different firmware features to improve the accuracy of identification.

[0073] The dynamic simulation module is based on the binary dynamic simulation execution framework to identify the input transfer points of the real-time operating system RTOS-Base firmware. It can not only dynamically analyze the running behavior of the firmware, but also implement the input length inference mechanism and execute the final input transfer algorithm. The length inference mechanism is implemented so that the minimum and maximum length requirements of the input data can be dynamically determined according to the input characteristics and actual running 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 the efficiency and accuracy of information flow. The target communication protocol Socket is used for design to ensure the stable transmission of data between modules and avoid information loss. The real-time feedback mechanism provided for the overall system ensures the consistency of information during the analysis and testing process.

[0076] It should be noted that the integration with existing tools is to implement the adaptation layer for Fuzzware, μEmu and SEmu to ensure seamless integration of the embodiments of the present application. 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 in the firmware, and ultimately generates clear mapping results. The module can dynamically adjust the monitoring strategy for the firmware to ensure that key data paths are effectively captured in a complex and changing operating environment. The mapping results provide a basis for subsequent input delivery logic to ensure the validity and relevance of input data.

[0078] The input transfer point recognition module automatically recognizes various input transfer points of the firmware based on the mapping results, saving time for manual operation and improving the efficiency and accuracy of recognition. Through advanced algorithms, redundancy and misidentification can be eliminated, and effective information can be quickly extracted from large amounts of data. The system's adaptive ability is enhanced, allowing it to maintain efficient operation under different firmware architectures and communication protocols.

[0079] The data length and multi-route input delivery awareness module is used to dynamically determine the minimum and maximum length of the input data of the input delivery point, and can adaptively adjust the length of the input data to support fuzz testing of multiple input delivery points. This module has intelligent analysis capabilities and can dynamically adjust the input data for different input delivery points to ensure the effectiveness of each test case. Through intelligent optimization of input data, the efficiency of fuzz testing is significantly improved and unnecessary redundant testing is reduced.

[0080] The fuzzy test input optimization device for IoT device firmware in the embodiment of the present application integrates multiple functional modules such as static analysis, dynamic simulation, communication, input mapping, automatic identification and testing into one, thereby constructing an efficient and intelligent firmware testing system. The device can not only speed up the completion of firmware testing and improve testing efficiency, but also help to increase the vulnerability discovery rate, thereby improving 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 the data retrieval point;

[0083] The input processing identification submodule is used to mark the 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 are processed or cleared;

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

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

[0086] Specifically, the data retrieval identification submodule monitors the read operation of the peripheral input in the firmware through the hook function UC_HOOK_MEM_READ in the binary dynamic simulation execution framework such as the Unicorn framework. By setting a hook on the address to be monitored, when the program executes to the address, the hook will be triggered, allowing the module to capture the current program counter (PC) value. Whenever the peripheral input is read, the captured program counter value will be 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 instructions 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 the global variables in the firmware to identify potential availability check instructions. On the one hand, the cross-reference analysis of global variables looks for a series of conditions that may affect the validity of the input by reviewing the global variables affected and involved in the interrupt processing process. On the other hand, the data flow and control flow analysis combines the changes in global variables to perform data flow and control flow analysis to identify comparison instructions used to verify the validity of the input.

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

[0092] Data retrieval identification:

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

[0094] Input processing identification:

[0095] Implement dynamic taint analysis and mark input data starting from data retrieval instructions. Use the UC_HOOK_MEM_READ hook of the binary dynamic simulation execution framework to track memory read operations of marked data. When a conditional branch instruction (such as CMP) is encountered and involves marked data, it is considered as a potential processing operation. Continue to track the data flow until all marked data encounters processing operations or is cleared.

[0096] Availability checks identify:

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

[0098] The input routing mapping module of the embodiment of the present application makes the analysis of firmware input more comprehensive and efficient through the collaborative work of its three submodules. The data retrieval identification submodule ensures the real-time capture of input data points, the input processing identification submodule tracks the data flow through dynamic taint analysis, and the availability check identification submodule analyzes the relationship between global variables and comparison instructions. Through a series of precise operations, it helps to improve the accuracy and efficiency of fuzz testing, making it easier to evaluate and fix potential vulnerabilities in firmware, thereby improving 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 use 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 test input optimization device 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 delivery point.

[0104] The common ancestor algorithm is used to identify the minimum common parent function of two functions in the control flow graph. For the input availability check instruction and the nearest input processing instruction, their call chains are first analyzed and recorded. The call graph query function is used to locate the nearest common caller of the two and analyze it in combination with the control flow relationship. The position of the common caller in the global context and its relationship with the input availability check instruction and the input processing instruction are determined, and the critical path information is extracted by advancing layer by layer.

[0105] Then, the entry point of the nearest common 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 can find important input-related connections from multiple call paths through the common ancestor algorithm, improving the understanding of control flow in complex firmware. By analyzing the control flow relationship at a hierarchical level, 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 the 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 in monitoring, the submodule analyzes the code segment that jumps in after the interrupt switch and evaluates whether the code segment constitutes a unique basic block. If the address of the loop does not change in multiple executions, it is considered an infinite loop. The control flow of the loop body and other code blocks is further analyzed to ensure the accuracy of identification. The infinite loop entry points that meet the unique basic block condition are marked as input transfer points, which are usually important nodes for the firmware to receive input and process it.

[0109] The specific implementation method is:

[0110] For the input routing of bare metal firmware: implement the common ancestor algorithm to find the nearest common caller function of the input availability check instruction and the nearest input processing instruction. Analyze the control flow relationship of these instructions and determine their nearest common caller function. Define the entry point of the common caller function as the input transfer point; For the input routing of real-time operating system firmware: use a binary dynamic simulation execution framework such as the UC_HOOK_BLOCK hook of the Unicorn framework to dynamically monitor firmware execution. Identify the infinite loop switched from the PendSV interrupt. Judgment condition: enter the infinite loop in 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 embodiment of the present application together constitute an important part of the IoT firmware fuzz test input transfer optimization device. The former analyzes the control flow relationship through the common ancestor algorithm, and the latter identifies infinite loops through dynamic monitoring. The combination of the two submodules makes the identification of input transfer points in different types of firmware more accurate and efficient, significantly improving the ability to detect and repair potential firmware vulnerabilities.

[0112] Optionally, the data length and multi-route input delivery 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] The embodiment of the present 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 UC_SNAPSHOT_TAKE and UC_SNAPSHOT_RESTORE mechanisms to create snapshots of the firmware execution state at each transfer point. Create multiple parallel instances (32 by default), each of which increments the input length by the minimum read byte (LRB). Set a hook for each instance to monitor whether the nearest input processing instruction has been reached. 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, start from byte N+1 and run N more instances until the minimum length is found.

[0117] b) Maximum length determination:

[0118] Monitor the write operation of the upper boundary address of the global input buffer. Gradually increase the input length and observe the changes of 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 current number of transfer points, and the smallest upper limit of all transfer points;

[0124] Detect whether the data length is less than 0, and if so, reduce the current transfer point number 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 that the remaining input length is sufficient, and calculating the available input length of the current transfer point;

[0126] Determine a transfer length based on the available input length, use the transfer length to slice the fuzz test input 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 for:

[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, during the IoT firmware fuzz testing process, dynamic adjustment of input length is an important means to improve testing efficiency and discover vulnerabilities. The following is a detailed description of the scheme for managing data length based on input length, number of transfer points, and available input length to ensure the effectiveness of firmware testing.

[0133] First, determine the initial data length. You need 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] Among them, Δ is the available input length, and Lowp is the minimum length requirement;

[0140] If Δ<0, fill with zeros to meet the minimum length requirement, otherwise if Δ≥0, randomly determine the transfer length, 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 modulus 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 certain length is sliced ​​out from the fuzz test input and passed to the firmware; the input position is updated so that the next test can start from the subsequent input position of the previous transfer point. According to the newly identified data retrieval point, the current set of transfer points and the input data requirements of 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 accurate input data configuration for subsequent fuzz testing.

[0145] The embodiment of the present application aims to improve the accuracy and efficiency of fuzz testing by dynamically adjusting the data length, controlling the number of transfer points, and cyclically checking the input availability. The hook function is used to monitor the firmware instructions in real time, and the input information is updated based on the real-time detection results to ensure that each transfer point can obtain appropriate input data for effective testing.

[0146] The system framework diagram of this application is as follows Figure 2 As shown. It mainly includes static analysis module and dynamic simulation module. The dynamic simulation module is mainly implemented based on the Unicorn simulator, which 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 on the basis of 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 the 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 the socket to communicate with the static analysis module. The static analysis module executes the corresponding module script, obtains the data retrieval point and availability checkpoint of the firmware, and returns it to the dynamic simulation module. Then the dynamic module calculates the new dynamic data through the input routing mapping module and sends it to the input transfer point identification module to call the static analysis module. The static module identifies the input transfer point through data flow and control flow analysis technology. 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, and determines the amount of data to be put in each time through the input transfer perception algorithm, so as to achieve efficient use of data and improve the efficiency of fuzz testing.

[0148] Reference Figure 3 The present application also provides an IoT firmware fuzz test input transmission 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 automatic identification through a custom script;

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

[0151] S303. Using the communication module to implement 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 analysis 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. Automatically identify the firmware input transfer point based on the mapping result using the input transfer point identification module;

[0154] S306. Use 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 fuzzy test input transmission optimization method provided by the embodiment of the present application is as follows:

[0165] Step 1: First, perform static analysis on the firmware and use Ghidra to disassemble the firmware binary file. By analyzing the instruction sequence, identify instructions related to peripheral data reading, such as the operation of LDR (load) instructions 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 marked data is tracked. When an instruction that compares or operates on these data is encountered, it is marked as an input processing point. At the same time, the present invention identifies interrupt service routines (ISRs) that affect global variables, and finds conditional branch instructions that check these global variables through static analysis.

[0167] Step 2: Use graph algorithms to find the nearest common ancestor function of the availability checkpoint and the input processing point. The entry of this function is determined as the input transfer point. The firmware execution flow is monitored during dynamic analysis. When a simple loop (usually an idle task) is detected after returning from the PendSV interrupt, the entry of the 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. Then, it derives multiple parallel instances, each of which executes the firmware with a different input length. The present invention starts from 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 the fuzz testing process, when a certain input transfer point is executed, the algorithm dynamically calculates the length of the input slice that should be transferred based on the length requirement of the current transfer point and the remaining total 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 different transfer points that have been identified. If the number of transfer points encountered in a round of fuzz testing is less than N, the algorithm will reduce the value of N in the next round to ensure that each transfer point can get enough input data.

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

[0171] Step 6: After the fuzz tester is executed, 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, the embodiment of the present application provides an electronic device, which may include: a processor (processor) 510, a communication interface (CommunicationsInterface) 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 through 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 software functional units 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, which is stored in a storage medium and includes a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform 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 understandable that the processor in the embodiment of the present application can be a central processing unit (CPU), or 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 can 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, and the software modules 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 a 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 may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions may be transmitted from a website site, a computer, a server or a data center to another website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or a data center that includes one or more available media integrated. The available medium may 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 disk (SSD)), etc.

[0179] It should be understood that the various numerical numbers involved in the embodiments of the present application are only used for the convenience of description and are not used to limit the scope of the embodiments of the present application.

[0180] It will be easily understood by those skilled in the art that the above description 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 shall 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 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; The static analysis module is used to perform firmware analysis through the API interface, identify the input transfer points of the bare metal firmware, and realize automatic identification through a custom script; The dynamic simulation module is used to identify the input transfer point 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 routing 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 the data retrieval point; The input processing identification submodule is used to mark the 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 are processed or cleared; The availability check identification submodule is used to analyze global variables in the interrupt processing process, identify potential comparison instructions according to the cross-reference relationship of the global variables, and perform data flow analysis and control flow analysis on the global variables to determine the 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 use 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 test 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 current number of transfer points, and the smallest upper limit of all transfer points; Detect whether the data length is less than 0, and if so, reduce the current transfer point number 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 that the remaining input length is sufficient, and calculating the available input length of the current transfer point; Determine a transfer length based on the available input length, use the transfer length to slice the fuzz test input 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 also used for: 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 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 and dynamic analysis 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 delivery awareness module is used to dynamically determine the minimum and maximum length of the input data of the input delivery point, optimize the input delivery points of the firmware fuzz testing, dynamically calculate the retained data length, monitor the delivery points and update the delivery 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 used to execute the program stored in the memory, and when the program stored in the memory is executed, the processor is used 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 execute the method as claimed in claim 8.

Images