Internet of Things device firmware-oriented vulnerability mining method and device, and electronic device

Abstract

This invention discloses a method and system for vulnerability discovery in IoT device firmware. The system includes: a firmware preprocessing module, which extracts the load base address, function symbol table, and executable program of the firmware under test; a risk function identification module, which designs heuristic rules based on prior knowledge to identify risk functions and defines function specifications based on taint parameters; a program static slicing module, which uses a combination of forward and backward slicing to extract complete dangerous code fragments from the program's inter-process control flow graph and reconstructs dynamic memory allocation functions; and a dynamic fuzzing module, which uses a simulation-based fuzzing framework to simulate and fuzz test dangerous code fragments in the firmware, while dynamically monitoring vulnerability characteristics. This invention's system can efficiently perform fuzzing and vulnerability discovery on the binary firmware of IoT devices.

Description

Technical Field

[0001] This application relates to the field of network security technology, specifically to a method and apparatus for vulnerability discovery in IoT device firmware, and an electronic device. Background Technology

[0002] With the continuous evolution and development of information technology, Internet of Things (IoT) devices, represented by routers, brain-computer interfaces, and firewalls, cover multiple fields such as smart homes, smart healthcare, and industrial control systems. Firmware is the core software component of IoT devices, responsible for managing the device's hardware and software resources and realizing various functions and tasks such as data acquisition, processing, and transmission. However, due to the lack of effective security mechanisms, IoT device firmware is highly vulnerable to cyberattacks.

[0003] Traditional firmware vulnerability detection methods are mainly divided into two categories: static analysis and dynamic testing. Static analysis techniques do not require simulated execution of the firmware; for example, symbolic execution techniques identify vulnerabilities in firmware through constraint solving. However, due to firmware size constraints and a lack of semantic information, static analysis methods often face the path explosion problem, making it difficult to effectively discover vulnerabilities. Dynamic testing techniques generally require simulated execution of the firmware. However, due to the diverse peripherals and interfaces of IoT devices, it is difficult to achieve stable system-level simulation. Summary of the Invention

[0004] Therefore, the purpose of this application is to provide a method, apparatus, and electronic device for vulnerability mining of IoT device firmware, in order to solve the problems of low success rate of IoT device firmware simulation execution and inefficient fuzzing.

[0005] According to a first aspect of the embodiments of this application, a method for vulnerability discovery in IoT device firmware is provided, comprising:

[0006] The firmware of IoT devices under test with different instruction set architectures is collected, and the firmware of the IoT devices under test is preprocessed to extract key firmware information, including the instruction set architecture, load base address, function symbol table, and firmware executable program.

[0007] Based on the instruction set architecture, load base address, and function symbol table of the firmware, the function semantic information of the executable program of the firmware is recovered. The function semantic information is used to identify the entry function that receives external data, the memory copying function, and the dynamic memory allocation function. The tainted parameters of the above functions are determined, and the tainted parameters of the memory copying function are monitored using hook technology.

[0008] Using the entry function and memory copying function as the starting and ending points respectively, an inter-process control flow graph is generated by combining them in pairs in the firmware executable program. Based on the inter-process control flow graph, the program is sliced ​​forward and backward to extract complete dangerous code fragments. Dynamic memory allocation functions that cannot be simulated by the cross-architecture simulation model are reconstructed. The reconstructed dynamic memory allocation functions should ensure that memory allocation operations can be correctly executed in the cross-architecture simulation model to avoid crashes due to undefined behavior during the simulation process.

[0009] The dangerous code fragment was simulated using a cross-architecture simulation model and iteratively tested using a fuzz testing framework, recording test cases and runtime information when the program crashed.

[0010] According to a second aspect of the embodiments of this application, a vulnerability discovery apparatus for IoT device firmware is provided, comprising:

[0011] The preprocessing module is used to collect firmware of IoT devices under test with different instruction set architectures, preprocess the firmware of the IoT devices under test, and extract key firmware information, including the instruction set architecture, load base address, function symbol table, and firmware executable program.

[0012] The identification and monitoring module recovers the function semantic information of the firmware executable program based on the instruction set architecture, load base address, and function symbol table of the firmware. It uses the function semantic information to identify the entry function that receives external data, the memory copying function, and the dynamic memory allocation function, determines the tainted parameters of the above functions, and uses hook technology to monitor the tainted parameters of the memory copying function.

[0013] The program static slicing module is used to generate an inter-process control flow graph by combining the entry function and the memory copying function as the starting and ending points, respectively, in the firmware executable program. Based on the inter-process control flow graph, the module performs forward and backward slicing to extract complete dangerous code fragments. It also reconstructs dynamic memory allocation functions that cannot be simulated in the cross-architecture simulation model. The reconstructed dynamic memory allocation functions should ensure that memory allocation operations can be correctly executed in the cross-architecture simulation model to avoid crashes due to undefined behavior during simulation.

[0014] The dynamic fuzzing module is used to simulate the execution of the dangerous code fragment using a cross-architecture simulation model, and connect to the fuzzing framework for iterative testing, recording test cases and runtime information when the program crashes.

[0015] According to a third aspect of the embodiments of this application, an electronic device is provided, comprising:

[0016] One or more processors;

[0017] Memory, used to store one or more programs;

[0018] When the one or more programs are executed by the one or more processors, the one or more processors perform the method as described in the first aspect.

[0019] According to a third aspect of the embodiments of this application, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in the first aspect.

[0020] The technical solutions provided by the embodiments of this application may include the following beneficial effects:

[0021] As can be seen from the above embodiments, this application identifies the firmware executable program of the IoT device under test, recovers the function semantic information of the firmware executable program, and identifies the entry function for receiving external data, memory copying function, and dynamic memory allocation function. This can accurately identify the points where security risks are introduced, serving as a prerequisite for subsequent static slicing methods. Using the entry function and memory copying function as the starting and ending points respectively, a process control flow graph is generated by combining them in pairs in the firmware executable program. Based on the process control flow graph, forward and backward slicing is performed to extract complete dangerous code fragments, which can effectively extract complete closed-source firmware code fragments and improve the success rate of firmware simulation execution. Furthermore, dynamic memory allocation functions that cannot be simulated by the cross-architecture simulation model are reconstructed. The reconstructed dynamic memory allocation functions should ensure that memory allocation operations can be correctly executed in the cross-architecture simulation model, effectively avoiding simulation anomalies caused by the inability of dynamic memory allocation functions to be simulated by the cross-architecture simulation model, and improving the efficiency of fuzz testing.

[0022] The present invention provides a method and system for vulnerability discovery in IoT device firmware, which solves the problems of low success rate of simulated execution and inefficient fuzzing of IoT device firmware. It can effectively discover vulnerabilities in real IoT device firmware and has practicality.

[0023] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

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

[0025] Figure 1 This is a flowchart illustrating a vulnerability discovery method for IoT device firmware according to an exemplary embodiment.

[0026] Figure 2 This is a block diagram illustrating a vulnerability discovery apparatus for IoT device firmware according to an exemplary embodiment.

[0027] Figure 3 This is a schematic diagram of the structure of an electronic device according to an exemplary embodiment. Detailed Implementation

[0028] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0029] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

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

[0031] Figure 1 This is a flowchart illustrating a vulnerability discovery method for IoT device firmware according to an exemplary embodiment, such as... Figure 1 As shown, the method may include the following steps:

[0032] S1: Collect firmware of IoT devices with different instruction set architectures, preprocess the firmware of the IoT device under test, and extract key firmware information, including the firmware's instruction set architecture, load base address, function symbol table, and executable program; this step includes the following sub-steps:

[0033] S11: Use unpacking tools to unpack the firmware of the IoT device under test, identify the firmware's instruction set architecture, extract the firmware's function symbol table, and after manually analyzing the size and location of the unpacked files, determine and extract the firmware's executable program.

[0034] Specifically, first, the binwalk tool is used to identify the firmware's instruction set architecture, and this is combined with manual analysis using IDA reverse engineering tools to obtain the correct firmware instruction set architecture information. A correct firmware instruction set architecture ensures that subsequent base address identification tools correctly understand the firmware's binary format. Then, the binwalk tool is used to unpack the firmware, generating several files of different sizes. The location of the bzero function is searched within these generated files. bzero is a commonly used standard library function used to zero a specified memory region. Determining the location containing the bzero function helps locate the file containing the function symbol table. The symbol table contains function names and their addresses in the file, which is a prerequisite for subsequent program slicing methods.

[0035] The first file generated is typically a few hundred bytes in size and depends on the firmware instruction set architecture. It may contain firmware header information, a loader, or other code related to the firmware boot process. The second file is generally tens of thousands of bytes in size and is usually the firmware executable program, containing most of the firmware's functional code and logic.

[0036] S12: Based on the instruction set architecture of the firmware, use a base address identification tool to identify the loading base address of the firmware executable program;

[0037] Specifically, the base address identification tool findbase is used to set the target architecture type according to the firmware's instruction set architecture. This ensures that findbase can correctly understand the firmware's binary format, thereby retrieving the load base address of the firmware executable program. A correct base address ensures that the disassembler can accurately map the firmware's location in memory, thus correctly parsing instructions and data.

[0038] S2: Based on the firmware's instruction set architecture, load base address, and function symbol table, recover the function semantic information of the firmware executable program, identify the entry functions that receive external data, memory copying functions, and dynamic memory allocation functions, determine the tainted parameters of the above functions, and use hook technology to monitor the tainted parameters of memory copying functions; this step includes the following sub-steps:

[0039] S21: Use reverse engineering tools to disassemble the firmware executable program, and recover the function semantic information of the firmware executable program based on the instruction set architecture, load base address and function symbol table of the firmware.

[0040] Specifically, the reverse engineering tool IDA is used to load the firmware executable program. Based on the firmware instruction set architecture and load base address, the target architecture type and base address are set. IDA then automatically analyzes and disassembles the firmware executable program. A Python plugin script is used to automatically recover the function semantics information of the firmware executable program based on the function symbol table. The function symbol table provides meaningful function names, which helps in reading and understanding the functionality and logic of the firmware code. S22: Based on prior knowledge, a heuristic method is designed to identify entry functions, memory copying functions, and dynamic memory allocation functions in the firmware executable program.

[0041] Specifically, in this embodiment of the 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(), and getenv(), are identified as potential entry functions; since the recovered function semantic information often contains specific prefixes and suffixes, in order to improve the search range of vulnerability paths, all functions containing entry function names are matched using regularization, and the results are added to the entry function list.

[0042] Memory copy functions are the endpoints of program execution. Common memory copy functions include memcpy, strcpy, strncpy, and memmove. These functions are often key points of program vulnerabilities and have standardized function names. Therefore, the function names in the firmware executable 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 critical functions in the program execution process. Common dynamic memory allocation functions include malloc and calloc. These functions are often key factors affecting memory management problems, but their names in the firmware executable are not always standardized and may contain prefixes, suffixes, and other interfering information. Therefore, a method for partial matching of function names is designed to identify substrings in function names, and a regular expression method is used to match possible prefixes or suffixes to identify dynamic memory allocation functions in the firmware executable.

[0043] S23: By analyzing the return values ​​and parameters of the entry function, memory copying function, and dynamic memory allocation function, tainted parameters are identified.

[0044] Specifically, based on the function declarations of the entry function, memory copying functions, and dynamic memory allocation functions, the return values ​​and parameter types and uses of the functions are analyzed to determine whether they contain tainted data. Return values ​​and parameters containing tainted data are marked as tainted parameters. This detailed analysis and marking helps in subsequent forward and backward slicing of the program in the inter-process control flow graph based on data flow analysis, determining taint propagation paths, and discovering possible vulnerability exploitation paths.

[0045] S24: For each memory copy function, tainted parameters of the function are monitored using hook technology. If a memory leak occurs, error handling code is executed.

[0046] Specifically, hooking techniques are used to intercept calls to memory copy functions, record and monitor the parameters passed to these functions, and detect memory accesses outside the expected range to determine if a memory leak has occurred. Once a memory copy operation is detected to exceed the target buffer range, a memory leak is identified, predefined error handling code is immediately executed, an exception is thrown, and a log is logged.

[0047] S3: Using the entry function and memory copying function as the starting and ending points respectively, generate an inter-process control flow graph by combining them in pairs in the firmware executable program. Based on data flow analysis, perform forward and backward slicing of the program in the inter-process control flow graph to extract complete dangerous code fragments, and reconstruct the dynamic memory allocation function that cannot be simulated by the cross-architecture simulation model. This step includes the following sub-steps:

[0048] S31: Combine the predefined entry function and memory copy function in pairs as the starting and ending points of the function call relationship to extract the inter-process control flow graph in the firmware executable program;

[0049] Specifically, first, the disassembler IDA is used to recursively extract all calling functions of each memory copy function until an entry function is found among them, thus generating a function call graph from the entry function to the memory copy function. Then, a control flow graph is constructed for each function in the function call graph, with nodes representing basic blocks and edges representing control flow transfers. Finally, the control flow graphs of all functions are merged to generate the complete code path from the entry function to the memory copy function, thus completing the inter-process control flow graph.

[0050] S32: Using the tainted parameters of the entry function as the starting point of data flow analysis, perform forward and backward slicing of the program in the inter-process control flow graph based on data flow analysis, and extract complete dangerous code fragments from each of the inter-process control flow graphs.

[0051] Specifically, starting from the tainted parameters of the entry function, all code snippets related to tainted data are extracted along the forward data flow analysis path. Then, starting from sensitive functions such as memory copy functions, all code snippets related to sensitive operations are extracted along the backward data flow analysis path. Finally, the results of the forward and backward slices are merged to generate a complete set of dangerous code snippets, ensuring full coverage of the propagation path and impact scope of tainted data.

[0052] Existing program slicing tools only use forward slicing techniques, which can miss code related to tainted parameters in memory copy functions, resulting in incomplete dangerous code segments and hindering vulnerability discovery. To overcome the shortcomings of forward slicing alone, we introduce backward slicing, combining forward and backward data flow analysis to ensure that all code segments related to tainted data are identified and analyzed. Through comprehensive program slicing, we accurately locate code segments related to tainted parameters in memory copy functions, ensuring the completeness and accuracy of program slicing. This allows cross-architecture simulation models to simulate and execute complete dangerous code segments, thereby more effectively discovering vulnerabilities.

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

[0054] Specifically, a custom memory allocation function, similar in function to `malloc`, is implemented. This function manages memory allocation outside the simulation environment, replacing the original dynamic memory allocation function. During simulation, the original dynamic memory allocation function is intercepted using hooking technology, and its calls are redirected to the custom memory allocation function. This technique allows for more flexible management and debugging of memory allocation operations during simulation, resolving the issue of the simulation model failing to simulate the execution of dynamic memory allocation functions and thus exiting abnormally. This enhances the controllability and stability of the simulation environment and improves the success rate of firmware simulation execution.

[0055] S4: Simulate the execution of the dangerous code snippet using a cross-architecture simulation model, and perform iterative testing using a fuzz testing framework, recording test cases and runtime information when the program crashes; this step includes the following sub-steps:

[0056] S41: Simulate the execution of the dangerous code fragment using a cross-architecture simulation model and dynamically monitor program crashes;

[0057] Specifically, the framework for developing the Unicorn cross-architecture simulation model involves several steps. First, the simulation environment is initialized, memory regions are allocated and mapped, and dangerous code snippets and test cases are loaded into the simulation memory. Then, callback functions for events such as instructions, memory accesses, and exceptions are set up for monitoring during the simulation. Finally, the simulation is started, executing the code snippet beginning at a specified address. Crashes or errors are caught through exception handling callback functions, and signals are thrown to notify the subsequent fuzzing framework for appropriate processing. Real-time monitoring and detailed log output enable timely capture and handling of anomalies, enhancing vulnerability detection and security analysis capabilities.

[0058] S42: Use a fuzz testing framework for iterative testing. If a program crash occurs, record the information of the current test case and runtime information.

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

[0060] S43: If no new program crash occurs within a preset time, exit the fuzzing process and analyze the crash log to identify vulnerabilities in the firmware under test.

[0061] Specifically, when initiating fuzzing, a 60-minute time limit is pre-set to ensure the fuzzing does not run indefinitely. The exit condition is set if no new program crashes occur within 15 minutes, conserving computing resources and time. At the end of the fuzzing, crash logs are analyzed to identify and locate potential vulnerabilities, confirming their type and impact, including security issues such as stack overflows, format string vulnerabilities, and integer overflows. Identified vulnerabilities and related information are compiled into a vulnerability report, including vulnerability descriptions, affected versions, reproduction steps, and recommended remediation measures, ensuring that security issues are effectively addressed and tracked.

[0062] As can be seen from the above embodiments, this application identifies the firmware executable program of the IoT device under test, recovers the function semantic information of the firmware executable program, and identifies the entry function for receiving external data, memory copying function, and dynamic memory allocation function. This can accurately identify the points where security risks are introduced, serving as a prerequisite for subsequent static slicing methods. Using the entry function and memory copying function as the starting and ending points respectively, a process control flow graph is generated by combining them in pairs in the firmware executable program. Based on the process control flow graph, forward and backward slicing is performed to extract complete dangerous code fragments, which can effectively extract complete closed-source firmware code fragments and improve the success rate of firmware simulation execution. Furthermore, dynamic memory allocation functions that cannot be simulated by the cross-architecture simulation model are reconstructed. The reconstructed dynamic memory allocation functions should ensure that memory allocation operations can be correctly executed in the cross-architecture simulation model, effectively avoiding simulation anomalies caused by the inability of dynamic memory allocation functions to be simulated by the cross-architecture simulation model, and improving the efficiency of fuzz testing.

[0063] The present invention provides a method and system for vulnerability discovery in IoT device firmware, which solves the problems of low success rate of simulated execution and inefficient fuzzing of IoT device firmware. It can effectively discover vulnerabilities in real IoT device firmware and has practicality.

[0064] Corresponding to the aforementioned embodiments of the vulnerability discovery method for IoT device firmware, this application also provides embodiments of the vulnerability discovery apparatus for IoT device firmware.

[0065] Figure 2 This is a block diagram illustrating a vulnerability discovery apparatus for IoT device firmware according to an exemplary embodiment. (Refer to...) Figure 2 The device includes:

[0066] The preprocessing module 1 is used to collect firmware of IoT devices under test with different instruction set architectures, preprocess the firmware of IoT devices under test, and extract key firmware information, including the instruction set architecture, load base address, function symbol table, and firmware executable program of the firmware.

[0067] The identification and monitoring module 2 recovers the function semantic information of the firmware executable program based on the instruction set architecture, load base address and function symbol table of the firmware. It uses the function semantic information to identify the entry function that receives external data, the memory copying function and the dynamic memory allocation function, determines the tainted parameters of the above functions, and uses hook technology to monitor the tainted parameters of the memory copying function.

[0068] The program static slicing module 3 is used to generate an inter-process control flow graph by combining the entry function and the memory copying function in pairs in the firmware executable program, respectively, and to extract complete dangerous code fragments by performing forward and backward slicing of the program based on the inter-process control flow graph. It also reconstructs the dynamic memory allocation function that cannot be simulated by the cross-architecture simulation model. The reconstructed dynamic memory allocation function should ensure that memory allocation operations can be correctly executed in the cross-architecture simulation model to avoid crashes due to undefined behavior during the simulation process.

[0069] The dynamic fuzzing module 4 is used to simulate the execution of the dangerous code fragment using a cross-architecture simulation model, and connect to the fuzzing framework for iterative testing, recording test cases and runtime information when the program crashes.

[0070] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0071] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0072] Accordingly, this application also provides an electronic device, including: one or more processors; a memory for storing one or more programs; and when the one or more programs are executed by the one or more processors, causing the one or more processors to implement the vulnerability discovery method for IoT device firmware as described above. Figure 3 The diagram shown is a hardware structure diagram of any data processing-capable device, including a vulnerability discovery device for IoT device firmware provided in an embodiment of the present invention. (Except for...) Figure 3 In addition to the processor, memory, DMA controller, disk, and non-volatile memory shown, any data processing device in the embodiment may also include other hardware depending on the actual function of the data processing device, which will not be described in detail here.

[0073] Accordingly, this application also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the vulnerability discovery method for IoT device firmware described above. The computer-readable storage medium can be an internal storage unit of any data-processing device as described in any of the foregoing embodiments, such as a hard disk or memory. The computer-readable storage medium can also be an external storage device, such as a plug-in hard disk, smart media card (SMC), SD card, flash card, etc., equipped on the device. Furthermore, the computer-readable storage medium can include both internal storage units of any data-processing device and external storage devices. The computer-readable storage medium is used to store the computer program and other programs and data required by the data-processing device, and can also be used to temporarily store data that has been output or will be output.

[0074] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0075] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for vulnerability discovery in IoT device firmware, characterized in that, include: The firmware of IoT devices under test with different instruction set architectures is collected, and the firmware of the IoT devices under test is preprocessed to extract key firmware information, including the instruction set architecture, load base address, function symbol table, and firmware executable program. Based on the instruction set architecture, load base address, and function symbol table of the firmware, the function semantic information of the executable program of the firmware is recovered. The function semantic information is used to identify the entry function that receives external data, the memory copying function, and the dynamic memory allocation function. The tainted parameters of the above functions are determined, and the tainted parameters of the memory copying function are monitored using hook technology. Using the entry function and memory copying function as the starting and ending points respectively, an inter-process control flow graph is generated by combining them in pairs in the firmware executable program. Based on the inter-process control flow graph, the program is sliced ​​forward and backward to extract complete dangerous code fragments. Dynamic memory allocation functions that cannot be simulated by the cross-architecture simulation model are reconstructed. The reconstructed dynamic memory allocation functions should ensure that memory allocation operations can be correctly executed in the cross-architecture simulation model to avoid crashes due to undefined behavior during the simulation process. The dangerous code snippet was simulated using a cross-architecture simulation model and iteratively tested using a fuzz testing framework, recording test cases and runtime information when the program crashed. Specifically, based on the firmware's instruction set architecture, load base address, and function symbol table, the function semantics information of the firmware executable program is recovered, including the entry function for receiving external data, memory copying functions, and dynamic memory allocation functions. The tainted parameters of these functions are determined, and hook technology is used to monitor the tainted parameters of the memory copying functions, including: The firmware executable program is disassembled using reverse engineering tools, and the function semantic information of the firmware executable program is recovered based on the firmware's instruction set architecture, load base address, and function symbol table. Based on prior knowledge, a heuristic method is designed to identify the entry function for receiving external data, memory copying functions, and dynamic memory allocation functions in the firmware executable program. By analyzing the return values ​​and parameters of the entry function, memory copying function, and dynamic memory allocation function in their respective functions, tainted parameters are identified. For each memory copy function, tainted parameters of the memory copy function are monitored using hook technology. If a memory leak occurs, error handling code is executed.

2. The vulnerability discovery method for IoT device firmware according to claim 1, characterized in that, Preprocess the firmware of the IoT device under test to extract key firmware information, including: The firmware of the IoT device under test is unpacked using an unpacking tool to identify the firmware's instruction set architecture, extract the firmware's function symbol table, and determine and extract the firmware's executable program after determining the size and location of the unpacked file. Based on the instruction set architecture of the firmware, the base address of the executable program of the firmware is identified using a base address identification tool.

3. The vulnerability discovery method for IoT device firmware according to claim 1, characterized in that, Using the entry function for receiving external data and the memory copying function as the starting and ending points respectively, an inter-process control flow graph is generated by combining them in pairs within the firmware executable program. Based on data flow analysis, forward and backward slicing is performed within the inter-process control flow graph to extract complete dangerous code fragments. Furthermore, dynamic memory allocation functions that cannot be simulated by the cross-architecture simulation model are reconstructed, including: The entry function for receiving external data and the memory copying function are combined in pairs and used as the start and end points of the function call relationship, respectively, to extract the inter-process control flow graph of the firmware executable program. Using the tainted parameters of the entry function as the starting point of data flow analysis, forward and backward slicing of the program is performed in the inter-process control flow graph based on the data flow analysis, and complete dangerous code fragments are extracted from each inter-process control flow graph. For dynamic memory allocation functions in the dangerous code snippets that cannot be simulated by the cross-architecture simulation model, a function refactoring method is used to implement similar function functionality outside the cross-architecture simulation model.

4. The vulnerability discovery method for IoT device firmware according to claim 1, characterized in that, The dangerous code snippet was simulated using a cross-architecture simulation model, and iterative testing was performed using a fuzz testing framework. Test cases and runtime information at the time of program crashes were recorded, including: The dangerous code snippet was simulated using a cross-architecture simulation model, and program crashes were dynamically monitored. Iterative testing is performed using a fuzz testing framework. If a program crash occurs, the current test case and the firmware runtime information of the IoT device under test are recorded. If no new program crashes occur within a preset time, the fuzzing process will exit, and the crash logs will be analyzed to identify vulnerabilities in the firmware under test.

5. A vulnerability discovery device for IoT device firmware, characterized in that, include: The preprocessing module is used to collect firmware of IoT devices under test with different instruction set architectures, preprocess the firmware of the IoT devices under test, and extract key firmware information, including the instruction set architecture, load base address, function symbol table, and firmware executable program. The identification and monitoring module recovers the function semantic information of the firmware executable program based on the instruction set architecture, load base address, and function symbol table of the firmware. It uses the function semantic information to identify the entry function that receives external data, the memory copying function, and the dynamic memory allocation function, determines the tainted parameters of the above functions, and uses hook technology to monitor the tainted parameters of the memory copying function. The program static slicing module is used to generate an inter-process control flow graph by combining the entry function and the memory copying function as the starting and ending points, respectively, in the firmware executable program. Based on the inter-process control flow graph, the module performs forward and backward slicing to extract complete dangerous code fragments. It also reconstructs dynamic memory allocation functions that cannot be simulated in the cross-architecture simulation model. The reconstructed dynamic memory allocation functions should ensure that memory allocation operations can be correctly executed in the cross-architecture simulation model to avoid crashes due to undefined behavior during simulation. The dynamic fuzzing module is used to simulate the execution of the dangerous code fragment using a cross-architecture simulation model, and connect to the fuzzing framework for iterative testing, recording test cases and runtime information when the program crashes; Specifically, based on the firmware's instruction set architecture, load base address, and function symbol table, the function semantics information of the firmware executable program is recovered, including the entry function for receiving external data, memory copying functions, and dynamic memory allocation functions. The tainted parameters of these functions are determined, and hook technology is used to monitor the tainted parameters of the memory copying functions, including: The firmware executable program is disassembled using reverse engineering tools, and the function semantic information of the firmware executable program is recovered based on the firmware's instruction set architecture, load base address, and function symbol table. Based on prior knowledge, a heuristic method is designed to identify the entry function for receiving external data, memory copying functions, and dynamic memory allocation functions in the firmware executable program. By analyzing the return values ​​and parameters of the entry function, memory copying function, and dynamic memory allocation function in their respective functions, tainted parameters are identified. For each memory copy function, tainted parameters of the memory copy function are monitored using hook technology. If a memory leak occurs, error handling code is executed.

6. An electronic device, characterized in that, include: One or more processors; Memory, used to store 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 any one of claims 1-4.

7. A computer-readable storage medium storing computer instructions thereon, characterized in that, When executed by the processor, this instruction implements the steps of the method as described in any one of claims 1-4.

Images