Vulnerability mining method and device for Internet of Things equipment firmware and electronic equipment

Abstract

The invention discloses a vulnerability mining method and system for Internet of Things equipment firmware, and the system comprises a firmware preprocessing module which is used for extracting a loading base address, a function symbol table, an executable program and the like of to-be-tested firmware; the risk function identification module is used for identifying a risk function according to a priori knowledge design heuristic rule and defining a function specification according to the taint parameter; the program static slicing module is used for extracting a complete dangerous code snippet from a program interprocess control flow diagram by adopting a method of combining forward slicing and backward slicing, and reconstructing a dynamic memory allocation function; and the dynamic fuzz testing module is used for realizing simulation and fuzz testing on the firmware dangerous code snippets by utilizing a fuzz testing framework based on simulation execution, and dynamically monitoring vulnerability characterization at the same time. The system disclosed by the invention can be used for performing efficient fuzzy testing and vulnerability mining on the binary firmware of the Internet of Things equipment.

Description

Technical Field

[0001] The present application relates to the field of network security technology, and in particular, to a vulnerability mining method and device for firmware of an Internet of Things device, and an electronic device. Background Art

[0002] With the continuous evolution and development of information technology, IoT devices represented by routers, brain-computer interfaces, firewalls, etc., cover multiple fields such as smart homes, smart medical care, and industrial control systems. Firmware is the core software component of IoT devices, responsible for managing the hardware and software resources of the device and realizing various functions and tasks such as data collection, processing, and transmission. However, due to the lack of effective security protection mechanisms, IoT device firmware is extremely vulnerable to network attacks.

[0003] Traditional firmware vulnerability detection methods are mainly divided into two categories: static analysis and dynamic testing. Static analysis technology does not require the simulation of firmware execution. For example, symbolic execution technology identifies vulnerabilities in firmware by solving constraints. However, due to the limitation of firmware size and lack of semantic information, static analysis methods often face the problem of path explosion and are difficult to effectively discover vulnerabilities. Dynamic testing technology generally requires the simulation of firmware execution. However, due to the wide variety of peripherals and different interfaces of IoT devices, it is difficult to achieve stable system-level simulation. Summary of the invention

[0004] In view of this, the purpose of the embodiments of the present application is to provide a vulnerability mining method and device, and an electronic device for IoT device firmware, so as to solve the problems of low success rate of simulation execution and inefficient fuzz testing of IoT device firmware.

[0005] According to a first aspect of an embodiment of the present application, a vulnerability mining method for IoT device firmware is provided, comprising: Collect the firmware of the IoT device to be tested of different instruction set architectures, pre-process the firmware of the IoT device to be tested, and extract key information of the firmware, wherein the key information of the firmware includes the instruction set architecture of the firmware, the loading base address, the function symbol table, and the firmware executable program; According to the instruction set architecture, loading base address and function symbol table of the firmware, the function semantic information of the firmware executable program is restored, the entry function, memory copy class function and dynamic memory allocation function receiving external data are identified by using the function semantic information, the tainted parameters of the above functions are determined, and the tainted parameters of the memory copy class function are monitored by using hook technology; The entry function and the memory copy class function are used as the starting point and the end point respectively, and are combined in pairs in the firmware executable program to generate an inter-procedural control flow graph. According to the inter-procedural control flow graph, the program is sliced ​​forward and backward to extract complete dangerous code fragments, and the dynamic memory allocation function that cannot be simulated and executed by the cross-architecture simulation model is reconstructed. The reconstructed dynamic memory allocation function should ensure that the memory allocation operation can be correctly executed in the cross-architecture simulation model to avoid crashes caused by undefined behavior during the simulation process; The cross-architecture simulation model is used to simulate the execution of the dangerous code fragment, and the fuzz testing framework is connected to perform iterative testing to record the test cases and runtime information when the program crashes.

[0006] According to a second aspect of an embodiment of the present application, a vulnerability mining device for IoT device firmware is provided, comprising: A collection preprocessing module is used to collect the firmware of the IoT device to be tested of different instruction set architectures, preprocess the firmware of the IoT device to be tested, and extract key information of the firmware, wherein the key information of the firmware includes the instruction set architecture of the firmware, the loading base address, the function symbol table, and the firmware executable program; An identification monitoring module is used to restore the function semantic information of the executable program of the firmware according to the instruction set architecture, loading base address and function symbol table of the firmware, and the entry function, memory copy class function and dynamic memory allocation function for receiving external data are identified by using the function semantic information, and the tainted parameters of the above functions are determined, and the tainted parameters of the memory copy class function are monitored by using hook technology; A program static slicing module is used to use the entry function and the memory copy class function as the starting point and the end point respectively, to generate an inter-procedural control flow graph in pairs in the firmware executable program, to perform forward and backward slicing of the program according to the inter-procedural control flow graph to extract complete dangerous code fragments, and to reconstruct the dynamic memory allocation function that cannot be simulated and executed by the cross-architecture simulation model. The reconstructed dynamic memory allocation function should ensure that the memory allocation operation can be correctly executed in the cross-architecture simulation model to avoid crashes caused by undefined behavior during the simulation process; The dynamic fuzz testing module is used to simulate the execution of the dangerous code fragments using a cross-architecture simulation model, and access the fuzz testing framework for iterative testing to record test cases and runtime information when the program crashes.

[0007] According to a third aspect of an embodiment of the present application, there is provided an electronic device, including: one or more processors; A memory for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in the first aspect.

[0008] According to a third aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which computer instructions are stored. When the instructions are executed by a processor, the steps of the method described in the first aspect are implemented.

[0009] The technical solution provided by the embodiments of the present application may have the following beneficial effects: It can be seen from the above embodiments that the present application identifies the firmware executable program of the IoT device firmware to be tested, restores the function semantic information of the firmware executable program, identifies the entry function, memory copy class function and dynamic memory allocation function that receive external data, and can accurately identify the introduction point of security risks as a prerequisite for the subsequent program static slicing method; using the entry function and memory copy class function as the starting point and end point respectively, the inter-process control flow graph is generated by combining the two in the firmware executable program, and the program is forward and backward sliced ​​according to the inter-process control flow graph to extract the complete dangerous code fragment, which can effectively extract the complete closed-source firmware code fragment and improve the success rate of firmware simulation execution; and reconstructs the dynamic memory allocation function that cannot be simulated and executed by the cross-architecture simulation model. The reconstructed dynamic memory allocation function should ensure that the memory allocation operation can be correctly executed in the cross-architecture simulation model, effectively avoiding the simulation exception problem caused by the inability of the dynamic memory allocation function to be simulated and executed by the cross-architecture simulation model, and improving the efficiency of fuzz testing.

[0010] The embodiments of the present invention provide a method and system for discovering vulnerabilities in the firmware of an Internet of Things device, which solve the problems of low simulation execution success rate and inefficient fuzzy testing of the firmware of the Internet of Things device, and can effectively discover vulnerabilities in the firmware of real Internet of Things devices, thus having practicality.

[0011] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0013] Figure 1 The present invention is a flowchart of a vulnerability mining method for IoT device firmware according to an exemplary embodiment.

[0014] Figure 2 The present invention is a block diagram of a vulnerability mining device for IoT device firmware according to an exemplary embodiment.

[0015] Figure 3 The diagram is a schematic structural diagram of an electronic device according to an exemplary embodiment. DETAILED DESCRIPTION

[0016] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0017] The terms used in this application are for the purpose of describing specific embodiments only and are not intended to limit this application. The singular forms of "a", "said" and "the" used in this application and the appended claims are also intended to include plural forms unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0018] It should be understood that although the terms first, second, third, etc. may be used in the present application to describe various information, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the present application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0019] Figure 1 is a flow chart of a vulnerability mining method for IoT device firmware according to an exemplary embodiment. Figure 1 As shown, the method may include the following steps: S1: Collect IoT device firmware of different instruction set architectures, pre-process the IoT device firmware to be tested, and extract firmware key information, wherein the firmware key information includes the firmware instruction set architecture, loading base address, function symbol table, and firmware executable program; this step includes the following sub-steps: S11: using an unpacking tool to unpack the firmware of the IoT device to be tested, identifying the instruction set architecture of the firmware, extracting the function symbol table of the firmware, and after manually analyzing the size and location of the unpacked file, determining and extracting the firmware executable program; Specifically, first, use the binwalk tool to identify the instruction set architecture of the firmware, and combine the IDA reverse tool to manually analyze the firmware to obtain the correct firmware instruction set architecture information. The correct firmware instruction set architecture can ensure that the subsequent base address identification tool correctly understands the binary format of the firmware. Then, use the binwalk tool to unpack the firmware and generate several files of different sizes. Search for the location of the file where the bzero function is located in the generated files. Bzero is a commonly used standard library function that is used to clear the specified memory area. Determining the location containing the bzero function can help find the file containing the function symbol table. The symbol table contains the function names and their addresses in the file, which is the premise of the subsequent program slicing method.

[0020] Among the generated files, the first file is usually a few hundred bytes in size, which is related to the firmware instruction set architecture and may contain the firmware header information, loader or other code related to the firmware startup process. The second file is usually tens of thousands of bytes in size and is usually the executable program of the firmware, which contains most of the firmware's functional code and logic.

[0021] S12: identifying a loading base address of the firmware executable program using a base address identification tool according to the instruction set architecture of the firmware; Specifically, the base address identification tool findbase is used to set the target architecture type according to the instruction set architecture of the firmware, ensuring that the base address identification tool findbase can correctly understand the binary format of the firmware, thereby retrieving the loading base address of the firmware executable program. The correct base address ensures that the disassembly tool can accurately map the location of the firmware in the memory, thereby correctly parsing instructions and data.

[0022] S2: according to the instruction set architecture, loading base address and function symbol table of the firmware, restore the function semantic information of the firmware executable program, identify the entry function, memory copy class function and dynamic memory allocation function that receive external data, determine the tainted parameters of the above functions, and use hook technology to monitor the tainted parameters of the memory copy class function; this step includes the following sub-steps: S21: using a reverse tool to disassemble the firmware executable program, and recovering the function semantic information of the firmware executable program according to the instruction set architecture, loading base address and function symbol table of the firmware.

[0023] Specifically, the reverse engineering tool IDA is used to load the firmware executable program, and the target architecture type and base address are set according to the firmware instruction set architecture and the loading base address. IDA starts to automatically analyze and disassemble the firmware executable program; an IDA plug-in script is written in Python to automatically restore the function semantic information of the firmware executable program according to the function symbol table. The function symbol table provides meaningful function names, which helps to read and understand the functions and logic of the firmware code. S22: Design a heuristic method based on prior knowledge to identify the entry function, memory copy class function and dynamic memory allocation function in the firmware executable program;

[0024] Specifically, in an embodiment of the present invention, a function name matching method based on regularization is designed: by manually analyzing the function names in the program, functions related to network data reception, file operations and environment variables, such as recv(), read(), getenv(), etc., are identified as potential entry functions; since the recovered function semantic information often contains specific prefixes and suffixes, in order to increase the search range of the vulnerability path, a regularized method is used to match all functions containing the entry function name, and the results are added to the entry function list.

[0025] Memory copy functions are the end points of program execution. Common memory copy functions include memcpy, strcpy, strncpy, memmove, etc. These functions are often the key points of program vulnerabilities and have standardized function names. Therefore, the function names in the firmware executable program are compared one by one with the memory operation function names in the standard library, and the results are added to the list of memory copy functions. Dynamic memory allocation functions are key functions in the program execution process. Common dynamic memory allocation functions include malloc, calloc, etc. These functions are often the key factors affecting memory management issues, but their names in the firmware executable program are not always standardized and may have interference information such as prefixes and suffixes. Therefore, a method for partial matching of function names is designed to identify substrings in function names, and a regular expression method is designed to match possible prefixes or suffixes to identify dynamic memory allocation functions in firmware executable programs.

[0026] S23: identifying tainted parameters by analyzing the return values ​​of the entry function, the memory copy class function, and the dynamic memory allocation function and the roles of the parameters in the function; Specifically, according to the function declarations of the entry function, memory copy class function and dynamic memory allocation function, the types and uses of the function return values ​​and parameters are analyzed to determine whether they contain tainted data, and the return values ​​and parameters containing tainted data are marked as tainted parameters. Through careful analysis and marking, it is helpful to perform forward and backward slicing of the program based on data flow analysis in the inter-procedural control flow graph, determine the taint propagation path, and discover possible vulnerability exploitation paths.

[0027] S24: For each memory copy class function, the tainted parameters of the function are monitored through the hook technology, and the error handling code is executed if a memory leak occurs.

[0028] Specifically, the hook technology is used to intercept the calls of memory copy functions, record and monitor the parameters passed to these functions, and determine whether a memory leak occurs by detecting whether there is a memory access beyond the expected range. Once it is detected that the memory copy operation exceeds the target buffer range, it is determined that a memory leak has occurred, and the predefined error handling code is immediately executed, an exception is thrown, and a log is recorded.

[0029] S3: Taking the entry function and the memory copy class function as the starting point and the end point respectively, the two functions are combined in pairs in the firmware executable program to generate an inter-procedural control flow graph, and the program is sliced ​​forward and backward according to the data flow analysis in the inter-procedural control flow graph to extract the complete dangerous code fragment, and the dynamic memory allocation function that cannot be simulated and executed by the cross-architecture simulation model is reconstructed; this step includes the following sub-steps: S31: combining predefined entry functions and memory copy class functions in pairs as the starting point and end point of the function call relationship, and extracting the inter-procedural control flow graph in the firmware executable program; Specifically, first, the disassembly tool IDA is used to recursively extract all the calling functions of each memory copy class function until one of the calling functions contains the entry function, thereby generating a function call graph from the entry function to the memory copy class function. Then, a control flow graph is constructed for each function in the function call graph, where nodes represent basic blocks and edges represent control flow transfers. Finally, the control flow graphs of each function are merged to generate a complete code path from the entry function to the memory copy class function, that is, the inter-procedural control flow graph is constructed.

[0030] S32: taking the tainted parameter of the entry function as the starting point of the data flow analysis, performing forward slicing and backward slicing of the program in the inter-procedural control flow graph according to the data flow analysis, and extracting a complete dangerous code fragment from each of the inter-procedural control flow graphs; Specifically, starting from the tainted parameters of the entry function, along the path of forward data flow analysis, all code snippets related to the tainted data are extracted; starting from sensitive functions such as memory copy functions, along the path of backward data flow analysis, all code snippets related to sensitive operations are extracted. Finally, the results of forward slicing and backward slicing are combined to generate a complete set of dangerous code snippets to ensure that the propagation path and impact range of the tainted data are fully covered.

[0031] Existing program slicing tools only use forward slicing technology for program slicing, which will miss some code related to the tainted parameters of memory copy functions, resulting in incomplete dangerous code snippets and failure to discover vulnerabilities. In order to overcome the shortcomings caused by only using forward slicing technology, we introduced backward slicing technology, combining forward and backward data flow analysis to ensure that all code snippets related to tainted data are identified and analyzed. Through the complete program slicing technology, the code snippets related to the tainted parameters of memory copy functions are accurately located, ensuring the integrity and accuracy of program slicing, allowing the cross-architecture simulation model to simulate the execution of complete dangerous code snippets, thereby more effectively discovering vulnerabilities.

[0032] S33: For the dynamic memory allocation functions such as malloc function that exist in the dangerous code fragment and cannot be simulated by the cross-architecture simulation model, a function reconstruction method is used to implement similar function functions outside the cross-architecture simulation model.

[0033] Specifically, a custom memory allocation function similar to the malloc function is implemented. These functions will manage memory allocation outside the simulation environment and replace the original dynamic memory allocation function. During the simulation process, the original dynamic memory allocation function is intercepted by hook technology, and the call is redirected to the custom memory allocation function. This technology allows more flexible management and debugging of memory allocation operations during the simulation process, solves the problem that the simulation model cannot simulate the execution of the dynamic memory allocation function and exits abnormally, enhances the controllability and stability of the simulation environment, and improves the success rate of firmware simulation execution.

[0034] S4: simulating and executing the dangerous code snippet using a cross-architecture simulation model, and connecting to a fuzz testing framework for iterative testing, and recording test cases and runtime information when the program crashes; this step includes the following sub-steps: S41: simulating the execution of the dangerous code snippet using a cross-architecture simulation model, and dynamically monitoring program crashes; Specifically, we develop an exploit framework for the cross-architecture simulation model Unicorn. First, we initialize the simulation environment, allocate and map memory areas, and load dangerous code snippets and test cases into the simulation memory. Then, we set callback functions for events such as instructions, memory access, and exceptions to monitor during the simulation process. Finally, we start the simulation, execute the code snippet starting from the specified address, and capture crashes or errors through the exception handling callback function, and throw a signal to notify the subsequent fuzz testing framework to perform corresponding processing. Through real-time monitoring and detailed log output, we can capture and handle exceptions in a timely manner, enhancing the ability of vulnerability detection and security analysis.

[0035] S42: Perform iterative testing using a fuzz testing framework. If a program crash occurs, record information about the current test sample and runtime information.

[0036] Specifically, an efficient fuzz testing framework AFLplusplus is selected for testing, which automatically generates and inputs a large number of fuzz test cases into the target program. The execution of the target program is monitored in real time through the Unicorn simulation framework. When the test case generated by the fuzz testing framework causes the target program to crash, key information such as the input data of the current test case, the register state at runtime, and the memory state are recorded, and this information is saved in a log file for subsequent analysis and debugging.

[0037] S43: If no new program crash occurs within the preset time, the fuzz testing process is exited, and the crash log is analyzed to identify vulnerabilities in the firmware to be tested.

[0038] Specifically, when starting the fuzz test, a 60-minute time limit is set in advance to ensure that the fuzz test does not run indefinitely. The exit condition is that no new program crashes occur within 15 minutes of fuzz testing, saving computing resources and time costs. At the end of the fuzz test, the crash log is analyzed to discover and locate potential vulnerabilities, and the type and impact of the vulnerability are confirmed, including security issues such as stack overflow, formatted string, and integer overflow. The identified vulnerabilities and related information are organized into a vulnerability report, including vulnerability description, affected version, reproduction steps, and recommended repair measures to ensure that security issues are effectively handled and tracked.

[0039] It can be seen from the above embodiments that the present application identifies the firmware executable program of the IoT device firmware to be tested, restores the function semantic information of the firmware executable program, identifies the entry function, memory copy class function and dynamic memory allocation function that receive external data, and can accurately identify the introduction point of security risks as a prerequisite for the subsequent program static slicing method; using the entry function and memory copy class function as the starting point and end point respectively, the inter-process control flow graph is generated by combining the two in the firmware executable program, and the program is forward and backward sliced ​​according to the inter-process control flow graph to extract the complete dangerous code fragment, which can effectively extract the complete closed-source firmware code fragment and improve the success rate of firmware simulation execution; and reconstructs the dynamic memory allocation function that cannot be simulated and executed by the cross-architecture simulation model. The reconstructed dynamic memory allocation function should ensure that the memory allocation operation can be correctly executed in the cross-architecture simulation model, effectively avoiding the simulation exception problem caused by the inability of the dynamic memory allocation function to be simulated and executed by the cross-architecture simulation model, and improving the efficiency of fuzz testing.

[0040] The embodiments of the present invention provide a method and system for discovering vulnerabilities in the firmware of an Internet of Things device, which solve the problems of low simulation execution success rate and inefficient fuzzy testing of the firmware of the Internet of Things device, and can effectively discover vulnerabilities in the firmware of real Internet of Things devices, thus having practicality.

[0041] Corresponding to the aforementioned embodiment of the vulnerability mining method for IoT device firmware, the present application also provides an embodiment of a vulnerability mining device for IoT device firmware.

[0042] Figure 2 1 is a block diagram of a vulnerability mining device for IoT device firmware according to an exemplary embodiment. Figure 2 , the device comprises:

[0043] A collection preprocessing module 1 is used to collect the firmware of the IoT device to be tested of different instruction set architectures, preprocess the firmware of the IoT device to be tested, and extract key firmware information, wherein the key firmware information includes the firmware's instruction set architecture, loading base address, function symbol table, and firmware executable program; Identify and monitor module 2, restore the function semantic information of the firmware executable program according to the instruction set architecture, loading base address and function symbol table of the firmware, use the function semantic information to identify the entry function, memory copy class function and dynamic memory allocation function that receive external data, determine the taint parameters of the above functions, and use hook technology to monitor the taint parameters of the memory copy class function; The program static slicing module 3 is used to use the entry function and the memory copy class function as the starting point and the end point respectively, to generate an inter-process control flow graph in pairs in the firmware executable program, to perform forward and backward slicing of the program according to the inter-process control flow graph to extract complete dangerous code fragments, and to reconstruct the dynamic memory allocation function that cannot be simulated and executed by the cross-architecture simulation model. The reconstructed dynamic memory allocation function should ensure that the memory allocation operation can be correctly executed in the cross-architecture simulation model to avoid crashes caused by undefined behavior during the simulation process; The dynamic fuzz testing module 4 is used to simulate the execution of the dangerous code fragment using a cross-architecture simulation model, and access the fuzz testing framework for iterative testing, recording the test cases and runtime information when the program crashes.

[0044] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0045] For the device embodiment, since it basically corresponds to the method embodiment, the relevant parts can refer to the partial description of the method embodiment. The device embodiment described above is only schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present application scheme. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0046] Accordingly, the present application also provides an electronic device, comprising: one or more processors; a memory for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors implement the vulnerability mining method for IoT device firmware as described above. Figure 3 As shown, a hardware structure diagram of a device with data processing capability in which a vulnerability mining device for IoT device firmware provided by an embodiment of the present invention is located, except Figure 3 In addition to the processor, memory, DMA controller, disk, and non-volatile memory shown, any device with data processing capabilities in which the apparatus in the embodiment is located may also include other hardware, which will not be described in detail, generally based on the actual functions of the device with data processing capabilities.

[0047] Accordingly, the present application also provides a computer-readable storage medium on which computer instructions are stored, and when the instructions are executed by a processor, the vulnerability mining method for IoT device firmware as described above is implemented. The computer-readable storage medium can be an internal storage unit of any device with data processing capabilities described in any of the aforementioned embodiments, such as a hard disk or a memory. The computer-readable storage medium can also be an external storage device, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), an SD card, a flash card (Flash Card), etc. equipped on the device. Furthermore, the computer-readable storage medium can also include both an internal storage unit and an external storage device of any device with data processing capabilities. The computer-readable storage medium is used to store the computer program and other programs and data required by any device with data processing capabilities, and can also be used to temporarily store data that has been output or is to be output.

[0048] Those skilled in the art will readily appreciate other embodiments of the present application after considering the description and practicing the contents disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The description and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the claims.

[0049] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A vulnerability mining method for IoT device firmware, characterized in that: include: Collect the firmware of the IoT device to be tested of different instruction set architectures, pre-process the firmware of the IoT device to be tested, and extract key information of the firmware, wherein the key information of the firmware includes the instruction set architecture of the firmware, the loading base address, the function symbol table, and the firmware executable program; According to the instruction set architecture, loading base address and function symbol table of the firmware, the function semantic information of the firmware executable program is restored, the entry function, memory copy class function and dynamic memory allocation function receiving external data are identified by using the function semantic information, the tainted parameters of the above functions are determined, and the tainted parameters of the memory copy class function are monitored by using hook technology; The entry function and the memory copy class function are used as the starting point and the end point respectively, and are combined in pairs in the firmware executable program to generate an inter-procedural control flow graph. According to the inter-procedural control flow graph, the program is sliced ​​forward and backward to extract complete dangerous code fragments, and the dynamic memory allocation function that cannot be simulated and executed by the cross-architecture simulation model is reconstructed. The reconstructed dynamic memory allocation function should ensure that the memory allocation operation can be correctly executed in the cross-architecture simulation model to avoid crashes caused by undefined behavior during the simulation process; The cross-architecture simulation model is used to simulate the execution of the dangerous code fragment, and the fuzz testing framework is connected to perform iterative testing to record the test cases and runtime information when the program crashes.

2. The vulnerability mining method for IoT device firmware according to claim 1, characterized in that: Preprocess the firmware of the IoT device to be tested and extract key firmware information, including: Use the unpacking tool to unpack the firmware of the IoT device to be tested, identify the instruction set architecture of the firmware, extract the function symbol table of the firmware, and determine and extract the firmware executable program after the unpacked file size and location; According to the instruction set architecture of the firmware, a base address identification tool is used to identify the loading base address of the firmware executable program.

3. The vulnerability mining method for IoT device firmware according to claim 1, characterized in that: According to the instruction set architecture, loading base address and function symbol table of the firmware, the function semantic information of the firmware executable program is restored, the entry function, memory copy class function and dynamic memory allocation function of external data are received, the tainted parameters of the above functions are determined, and the tainted parameters of the memory copy class function are monitored by using hook technology, including: Disassembling the firmware executable program using a reverse tool, and restoring function semantic information of the firmware executable program according to the firmware's instruction set architecture, loading base address, and function symbol table; Designing a heuristic method based on prior knowledge to identify an entry function, a memory copy class function, and a dynamic memory allocation function in the firmware executable program that receives external data; By analyzing the return values ​​and parameters of the entry function, memory copy class function and dynamic memory allocation function and their roles in the corresponding functions, the tainted parameters are identified; For each memory copy class function, the tainted parameters of the memory copy class function are monitored through hook technology, and the error handling code is executed if a memory leak occurs.

4. The vulnerability mining method for IoT device firmware according to claim 1, characterized in that: Taking the entry function for receiving external data and the memory copy class function as the starting point and the end point respectively, the two functions are combined in pairs in the firmware executable program to generate an inter-procedural control flow graph, and in the inter-procedural control flow graph, the program is sliced ​​forward and backward according to the data flow analysis to extract the complete dangerous code fragment, and the dynamic memory allocation function that cannot be simulated and executed by the cross-architecture simulation model is reconstructed, including: The entry function for receiving external data and the memory copy class function are combined in pairs, respectively as the starting point and end point of the function call relationship, and the inter-process control flow graph of the firmware executable program is extracted; Taking the tainted parameter of the entry function as the starting point of data flow analysis, performing forward slicing and backward slicing of the program in the inter-procedural control flow graph according to the data flow analysis, and extracting a complete dangerous code fragment from each of the inter-procedural control flow graphs; For the dynamic memory allocation function in the dangerous code snippet that cannot be simulated by the cross-architecture simulation model, a function reconstruction method is used to implement similar function functions outside the cross-architecture simulation model.

5. The vulnerability mining method for IoT device firmware according to claim 1, characterized in that: The cross-architecture simulation model is used to simulate and execute the dangerous code snippet, and the fuzz testing framework is connected to perform iterative testing to record the test cases and runtime information when the program crashes, including: Using a cross-architecture simulation model to simulate the execution of the dangerous code snippet and dynamically monitor program crashes; Use the fuzz testing framework to iteratively test. If a program crash occurs, the current test sample and the information of the IoT device firmware under test are recorded. If no new program crash occurs within the preset time, the fuzz testing process is exited and the crash log is analyzed to identify vulnerabilities in the firmware under test.

6. A vulnerability mining device for IoT device firmware, characterized in that: include: A collection preprocessing module is used to collect the firmware of the IoT device to be tested of different instruction set architectures, preprocess the firmware of the IoT device to be tested, and extract key information of the firmware, wherein the key information of the firmware includes the instruction set architecture of the firmware, the loading base address, the function symbol table, and the firmware executable program; An identification monitoring module is used to restore the function semantic information of the executable program of the firmware according to the instruction set architecture, loading base address and function symbol table of the firmware, and the entry function, memory copy class function and dynamic memory allocation function for receiving external data are identified by using the function semantic information, and the tainted parameters of the above functions are determined, and the tainted parameters of the memory copy class function are monitored by using hook technology; A program static slicing module is used to use the entry function and the memory copy class function as the starting point and the end point respectively, to generate an inter-procedural control flow graph in pairs in the firmware executable program, to perform forward and backward slicing of the program according to the inter-procedural control flow graph to extract complete dangerous code fragments, and to reconstruct the dynamic memory allocation function that cannot be simulated and executed by the cross-architecture simulation model. The reconstructed dynamic memory allocation function should ensure that the memory allocation operation can be correctly executed in the cross-architecture simulation model to avoid crashes caused by undefined behavior during the simulation process; The dynamic fuzz testing module is used to simulate the execution of the dangerous code fragments using a cross-architecture simulation model, and access the fuzz testing framework for iterative testing to record test cases and runtime information when the program crashes.

7. An electronic device, characterized in that: include: one or more processors; A memory for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 5.

8. A computer-readable storage medium having computer instructions stored thereon, characterized in that: When the instruction is executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

Images