Embedded firmware program vulnerability detection method, system and device and storage medium

Abstract

The invention discloses an embedded firmware program vulnerability detection method, system and device and a storage medium. The method comprises the steps of initializing and setting, starting a debugging host, and loading a firmware program and a target code area; program monitoring and instrumentation are conducted, specifically, a program monitor is started, and dynamic binary instrumentation is conducted on a specified code area of the firmware program; symbolic execution and path constraint extraction: a symbolic execution engine receives the basic block instruction stream transmitted by the program monitor, and a symbolic executor executes and extracts the path constraint; symbol storage and backup storage management: storing the data in a symbol storage module, and managing the data through a backup storage module; exploring and executing the test case, wherein the explorer selects the test case to explore and execute; vulnerability detection and result output, wherein the symbolic execution engine detects vulnerabilities according to the state of the path constraint and outputs a result; according to the method and the device, the accuracy and the efficiency of embedded firmware program vulnerability detection can be improved.

Description

Technical Field

[0001] The present invention relates to a vulnerability detection method, system, device and storage medium, and particularly to a method, system, device and storage medium for detecting vulnerabilities in an embedded firmware program, belonging to the technical fields of power systems and power markets. Background Art

[0002] With the popularization of the Internet of Things, various Internet of Things applications represented by smart homes, sensing and monitoring, and industrial control have been integrated into all aspects of human social life. The Internet of Things node devices are essentially embedded computing devices, and their core codes (boot programs, operating systems, application programs, etc.) and data (file systems, configuration information, etc.) are generally stored in the FLASH storage of the devices, collectively referred to as firmware. Some specific reasons in the Internet of Things field make it easy for security risks to exist in the firmware.

[0003] During the software security testing process, it is usually necessary to conduct extensive testing on the software to discover potential security problems. However, not all code areas or functions are equally important or prone to vulnerabilities. By locating specific vulnerabilities, testers can concentrate resources on in-depth analysis of the code areas most likely to have security problems, thereby improving the pertinence and efficiency of testing. In addition, currently, vulnerability location often relies on manual analysis and judgment, which is both time-consuming and laborious. Although there are some automated tools that can help locate vulnerabilities, their accuracy and reliability still need to be improved. Therefore, improving the automation degree of vulnerability location and reducing manual intervention are the keys to improving the efficiency of vulnerability detection.

[0004] The prior art "CN101714119B Test data generator and method based on binary program", the method described in this patent is a test data generation technology based on binary programs. It uses initial test data and binary program state information to obtain conditional jump addresses through dynamic symbolic execution, and then generates test data that matches a preset guiding path. The technical effect is to improve the pertinence and generation efficiency of test data, and help to discover potential defects in the program.

[0005] In the prior art, the testing of embedded firmware is limited by the insufficient resources and low coverage rate of traditional methods. Although symbolic execution technology is powerful, it faces challenges such as environmental modeling and path explosion in the testing of embedded firmware. Summary of the Invention

[0006] Object of the Invention: The object of the present invention is to provide a method, system, device and storage medium for detecting vulnerabilities in an embedded firmware program that can improve the detection accuracy and efficiency.

[0007] Technical Solution: The method for detecting vulnerabilities in an embedded firmware program according to the present invention includes:

[0008] Through a program monitor, perform dynamic binary instrumentation on a specified code area of the firmware program to obtain a basic block instruction stream;

[0009] The symbolic execution engine receives the basic block instruction stream and extracts path constraints;

[0010] The explorer selects test cases for exploration and execution to obtain the status of path constraints;

[0011] The symbolic execution engine detects vulnerabilities based on the status of the path constraints and outputs the results.

[0012] Further, before performing dynamic binary instrumentation on a specified code area of the firmware program through a program monitor to obtain a basic block instruction stream, it further includes: starting a debug host, loading the firmware program and the target code area, initializing the program monitor, the symbolic execution engine, the backup storage, the symbol storage, and the explorer, and configuring the path exploration strategy of the explorer;

[0013] Among them, the path exploration strategy includes a depth-first algorithm and an algorithm for exploring according to a specified path; the depth-first algorithm continuously explores the successors of branch nodes until reaching the leaf nodes to traverse the binary program; the algorithm for exploring according to a specified path makes the hybrid symbolic execution system explore along the given execution path.

[0014] Further, the dynamic binary instrumentation of the specified code area of the firmware program further includes using the binary program instrumentation method of gdb-server to specifically execute and monitor the firmware program, and using the Python plug-in of gdb to implement the control of the instrumentation process.

[0015] Further, the symbolic execution engine receives the basic block instruction stream and extracts path constraints, specifically as follows:

[0016] The symbolic execution engine receives the basic block instruction stream;

[0017] The intermediate representation lifter uses PyVEX to convert the binary machine instructions of the basic block instruction stream into an intermediate representation;

[0018] The symbolic executor completes the execution on the intermediate representation and collects path constraints at the jump points involving symbols;

[0019] The symbolic solver uses a solver to solve the collected path constraints to generate test cases.

[0020] Further, before the explorer selects test cases for exploration and execution to obtain the status of path constraints, it also includes: storing data in the symbolic storage module and managing it through the backup storage module. Specifically, it stores the data of the symbolic memory and symbolic registers in the symbolic storage module; when the symbolic execution engine fails to read content from the symbolic storage, the backup storage reads the required content from the entity device memory through the binary instrumentation module to initialize the symbolic storage data.

[0021] Further, the explorer selects test cases for exploration and execution to obtain the status of path constraints, specifically:

[0022] The explorer selects test cases from the test case set according to the set path exploration strategy;

[0023] Through the instrumentation module, the initial input is passed to the firmware program on the embedded device for specific execution;

[0024] The program monitor monitors the execution process and passes the basic block instruction stream to the symbolic execution engine for a new round of symbolic execution and path constraint extraction.

[0025] Further, the symbolic execution engine detects vulnerabilities according to the status of the path constraints and outputs the results, specifically:

[0026] The symbolic execution engine monitors the process of symbolic execution. When it finds that the path constraints cannot be satisfied or an exception is triggered, it determines that there is a potential vulnerability;

[0027] The detected vulnerability information is output to the debug host for further analysis and processing by the user.

[0028] Based on the same inventive concept, the present invention also provides an embedded firmware program vulnerability detection system, including:

[0029] An initialization and setting module, used to start the debug host, load the firmware program and the target code area;

[0030] A program monitoring and instrumentation module, used to perform dynamic binary instrumentation on the specified code area of the firmware program through the program monitor to obtain the basic block instruction stream;

[0031] A symbolic execution and path constraint extraction module, used to receive the basic block instruction stream through the symbolic execution engine and extract path constraints;

[0032] A symbolic storage and backup storage management module, used to store data in the symbolic storage module and manage it through the backup storage module;

[0033] A test case exploration and execution module, used to select test cases for exploration and execution through the explorer to obtain the status of path constraints;

[0034] A vulnerability detection and result output module, which is used for the symbolic execution engine to detect vulnerabilities according to the state of the path constraint and output the results.

[0035] Furthermore, the initialization and setting module is also used to initialize the program monitor, symbolic execution engine, backup storage, symbol storage, and explorer, and configure the path exploration strategy of the explorer;

[0036] Among them, the path exploration strategy includes a depth-first algorithm and an algorithm for exploring according to a specified path; the depth-first algorithm continuously explores the successors of branch nodes until reaching the leaf nodes to traverse the binary program; the algorithm for exploring according to a specified path makes the hybrid symbolic execution system explore along the given execution path.

[0037] Furthermore, the program monitoring and instrumentation module is specifically used to perform specific execution and monitoring on the firmware program by using the binary program instrumentation method of gdb-server, and use the Python plugin of gdb to realize the control of the instrumentation process.

[0038] Furthermore, the symbolic execution and path constraint extraction module is used to receive the basic block instruction stream through the symbolic execution engine and extract path constraints, specifically:

[0039] The symbolic execution engine receives the basic block instruction stream;

[0040] The intermediate representation lifter uses PyVEX to convert the binary machine instructions of the basic block instruction stream into an intermediate representation;

[0041] The symbolic executor completes the execution on the intermediate representation and collects path constraints at the jump points involving symbols;

[0042] The symbolic solver uses the solver to solve the collected path constraints to generate test cases.

[0043] Furthermore, the storage and backup storage management module is used to store data in the symbol storage module and manage it through the backup storage module. Specifically, it stores the data of the symbol memory and symbol registers in the symbol storage module; when the symbolic execution engine fails to read the content from the symbol storage, the backup storage reads the required content from the physical device memory through the binary instrumentation module to initialize the symbol storage data.

[0044] Furthermore, the test case exploration and execution module is used to select test cases through the explorer for exploration and execution to obtain the state of the path constraint, specifically:

[0045] The explorer selects test cases from the test case set according to the set path exploration strategy;

[0046] The initial input is passed to the firmware program on the embedded device through the instrumentation module for specific execution;

[0047] The program monitor monitors the execution process and passes the basic block instruction stream to the symbolic execution engine for a new round of symbolic execution and path constraint extraction.

[0048] Furthermore, the vulnerability detection and result output module is used for the symbolic execution engine to detect vulnerabilities according to the status of the path constraints and output the results, specifically:

[0049] The symbolic execution engine monitors the process of symbolic execution. When it is found that the path constraints cannot be satisfied or an exception is triggered, it is determined as a potential vulnerability;

[0050] The detected vulnerability information is output to the debug host for further analysis and processing by the user.

[0051] Based on the same inventive concept, the present invention also provides a computing device, including: one or more processors, one or more memories, and one or more programs. The programs are stored in the memory and are configured to be executed by the processor. When the programs are loaded into the processor, the steps of the method for detecting vulnerabilities in an embedded firmware program according to any one of the above are implemented.

[0052] Based on the same inventive concept, the present invention also provides a storage medium. The storage medium stores a computer program, and the computer program includes program instructions. When the program instructions are executed by the processor, the processor is caused to execute the steps of the method for detecting vulnerabilities in an embedded firmware program according to any one of the above.

[0053] Advantageous effects: Compared with the prior art, the present invention improves the pertinence and effectiveness of vulnerability detection through the path exploration strategy of the explorer. The explorer can select test cases according to the set path exploration strategy, making the vulnerability detection more targeted and effective. Whether it is the depth-first algorithm or the specified-path exploration algorithm, it can adjust the direction and focus of vulnerability detection according to actual needs, improving the efficiency and quality of vulnerability detection; through automatic control, the cost of manual intervention is reduced. The automatic control of the instrumentation process is realized by using the Python plug-in of gdb, reducing the cost and complexity of manual intervention. This ability of automatic control makes the vulnerability detection process more efficient and reliable, reducing the possibility of human errors. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 is the flowchart of the method according to an embodiment of the present invention;

[0055] Figure 2 is the system schematic diagram according to an embodiment of the present invention;

[0056] Figure 3 Schematic diagram of the interrelationship of the core units of the embodiments of the present invention. Detailed implementation manners

[0057] The technical solutions of the present invention will be further described below in conjunction with the accompanying drawings and embodiments.

[0058] The following are the explanations of the relevant technical terms in the present invention:

[0059] Embedded firmware program: Firmware is a software embedded in a hardware device for controlling the operation and functions of the device. Different from the software that usually runs on a general-purpose computer, firmware is usually optimized for a specific hardware platform and task. It can implement device initialization, hardware control, driver programs, and basic functions. Firmware is usually stored in a memory that is not easily modified, such as flash memory, to ensure the stability of the device. In the design of embedded systems, the writing and optimization of firmware are crucial for the stability and performance of the system.

[0060] Symbolic execution: It is a program analysis technique that uses symbolic values instead of concrete values as inputs to execute a program. Through symbolic execution, the behavior of the program under specific inputs can be analyzed, and the inputs that trigger specific code regions or errors can be found. Symbolic execution has wide applications in fields such as software testing, vulnerability discovery, and security analysis.

[0061] Binary instrumentation: It refers to inserting new code at any position in an existing binary program to observe or modify the behavior of the binary program. This technique is commonly used in scenarios such as program analysis, performance optimization, debugging, and testing. Through binary instrumentation, runtime information of the program can be collected, or the execution flow of the program can be changed without modifying the original code.

[0062] Symbolic store: It is a collection of symbol files, indexes, and tools for storing and managing symbol-related information. Administrators can use symbolic store tools to add and delete files and save executable image files that can be extracted using a symbol server. These files are indexed according to unique parameters such as timestamps and image sizes, facilitating subsequent analysis and debugging work.

[0063] Explorer: In hybrid symbolic execution or similar techniques, the explorer usually serves as the main control module responsible for controlling the entire execution flow. It can select test paths according to preset strategies or algorithms and interact with the firmware program through the instrumentation module. The explorer is also responsible for collecting and analyzing test results to discover possible defects or errors.

[0064] As shown in the Figure 1 accompanying drawings, the method for detecting vulnerabilities in an embedded firmware program according to the embodiments of the present invention includes:

[0065] Step 1: Initialization and Setup; Start the debug host and load the firmware program and the target code area;

[0066] Step 2: Program Monitoring and Instrumentation; Use the program monitor to perform dynamic binary instrumentation on the specified code area of the firmware program to obtain the basic block instruction stream;

[0067] Step 3: Symbolic Execution and Path Constraint Extraction; The symbolic execution engine receives the basic block instruction stream and extracts path constraints;

[0068] Step 4: Symbolic Storage and Backup Storage Management; Store data in the symbolic storage module and manage it through the backup storage module;

[0069] Step 5: Test Case Exploration and Execution; The explorer selects test cases for exploration and execution to obtain the status of path constraints;

[0070] Step 6: Vulnerability Detection and Result Output; The symbolic execution engine detects vulnerabilities based on the status of the path constraints and outputs the results.

[0071] Specifically, Step 1: Initialization and Setup

[0072] Start the debug host and load the firmware program and the target code area.

[0073] Initialize the program monitor, symbolic execution engine, backup storage, symbolic storage, and explorer.

[0074] Configure the path exploration strategy (depth-first algorithm or specified path exploration algorithm) of the explorer.

[0075] Step 2: Program Monitoring and Instrumentation

[0076] The program monitor starts and performs dynamic binary instrumentation on the specified code area of the firmware program.

[0077] Use the binary program instrumentation method of gdb-server to specifically execute and monitor the firmware program.

[0078] Use the Python plugin of gdb to implement automatic control of the instrumentation process.

[0079] Step 3: Symbolic Execution and Path Constraint Extraction

[0080] The symbolic execution engine receives the basic block instruction stream passed by the program monitor.

[0081] The intermediate representation lifter uses PyVEX to convert binary machine instructions into intermediate representation.

[0082] The symbolic executor executes on the intermediate representation and collects path constraints at jump points involving symbols.

[0083] The symbolic solver uses the Z3 solver to solve the collected path constraints and generate test cases.

[0084] Step 4: Symbolic storage and backup storage management

[0085] The symbolic storage is used to store the data of the symbolic memory and symbolic registers.

[0086] When the symbolic execution engine fails to read content from the symbolic storage, the backup storage reads the required content from the entity device memory through the binary instrumentation module to initialize the symbolic storage data.

[0087] Step 5: Test case exploration and execution

[0088] The explorer selects test cases from the test case set according to the set path exploration strategy.

[0089] Through the instrumentation module, the initial input is passed to the firmware program on the embedded device for specific execution.

[0090] The program monitor monitors the execution process and passes the basic block instruction stream to the symbolic execution engine for a new round of symbolic execution and path constraint extraction.

[0091] Step 6: Vulnerability detection and result output

[0092] During the symbolic execution process, if the symbolic execution engine finds that the path constraints cannot be satisfied or an exception is triggered, it is determined as a potential vulnerability.

[0093] The detected vulnerability information is output to the debug host for further analysis and processing by the user.

[0094] This method aims to achieve efficient and comprehensive vulnerability detection of embedded system firmware programs through hybrid symbolic execution technology.

[0095] Based on the same inventive concept, this embodiment also provides an embedded firmware program vulnerability detection system, as Figure 2 shown, including:

[0096] An initialization and setup module, used to start the debug host, load the firmware program and the target code area;

[0097] A program monitoring and instrumentation module, used to perform dynamic binary instrumentation on a specified code area of the firmware program through a program monitor to obtain the basic block instruction stream;

[0098] A symbolic execution and path constraint extraction module, used to receive the basic block instruction stream through a symbolic execution engine and extract path constraints;

[0099] A symbol storage and backup storage management module for storing data in the symbol storage module and managing it through the backup storage module;

[0100] A test case exploration and execution module for selecting test cases through an explorer for exploration and execution to obtain the status of path constraints;

[0101] A vulnerability detection and result output module for the symbolic execution engine to detect vulnerabilities based on the status of the path constraints and output the results.

[0102] Furthermore, the initialization and setting module further includes an initialization program monitor, a symbolic execution engine, a backup storage, a symbol storage, and an explorer, and configures the path exploration strategy of the explorer;

[0103] Among them, the path exploration strategy includes a depth-first algorithm and an algorithm for exploring according to a specified path; the depth-first algorithm continuously explores the successors of branch nodes until reaching the leaf nodes to traverse the binary program; the algorithm for exploring according to a specified path makes the hybrid symbolic execution system explore along the given execution path.

[0104] Furthermore, the program monitoring and instrumentation module performs dynamic binary instrumentation on the specified code area of the firmware program, and also includes using the binary program instrumentation method of gdb-server to specifically execute and monitor the firmware program, and using the Python plugin of gdb to implement the control of the instrumentation process.

[0105] Furthermore, in the symbolic execution and path constraint extraction module, the symbolic execution engine receives the basic block instruction stream and extracts path constraints, and the symbolic execution engine receives the basic block instruction stream;

[0106] The intermediate representation lifter uses PyVEX to convert the binary machine instructions of the basic block instruction stream into an intermediate representation;

[0107] The symbolic executor completes the execution on the intermediate representation and collects path constraints at the jump points involving symbols;

[0108] The symbolic solver uses a solver to solve the collected path constraints to generate test cases.

[0109] Furthermore, for the symbol storage and backup storage management module that stores data in the symbol storage module and manages it through the backup storage module, specifically, it stores the data of the symbol memory and symbol registers in the symbol storage module; when the symbolic execution engine fails to read the content from the symbol storage, the backup storage reads the required content from the entity device memory through the binary instrumentation module for initializing the symbol storage data.

[0110] Furthermore, the test case exploration and execution module selects test cases for exploration and execution through the explorer to obtain the status of the path constraints, specifically:

[0111] The explorer selects test cases from the test case set according to the set path exploration strategy;

[0112] Through the instrumentation module, the initial input is passed to the firmware program on the embedded device for specific execution;

[0113] The program monitor monitors the execution process and passes the basic block instruction stream to the symbolic execution engine for a new round of symbolic execution and path constraint extraction.

[0114] Furthermore, the symbolic execution engine of the vulnerability detection and result output module detects vulnerabilities and outputs results according to the status of the path constraints, specifically:

[0115] The symbolic execution engine monitors the symbolic execution process. When it finds that the path constraints cannot be met or an exception is triggered, it is determined as a potential vulnerability.

[0116] The detected vulnerability information is output to the debugging host for further analysis and processing by the user.

[0117] This embodiment mainly includes five core units: program monitor, symbolic execution engine, backup storage, symbolic storage, and explorer. The interaction relationship between them is as follows: Figure 3 shown.

[0118] in:

[0119] 1. Program monitor: that is, specific execution, obtaining the specified code area of ​​the target program in units of basic blocks of binary programs, and passing the extracted basic block instruction stream to the symbolic execution engine. Specifically, dynamic binary instrumentation, through the binary program instrumentation method based on gdb-server, realizes the specific execution and monitoring of the firmware program. The Python plug-in of gdb is used to realize the automatic control of the instrumentation process.

[0120] 2. Symbolic execution engine: responsible for converting binary basic blocks into intermediate representations, and executing the intermediate representations and extracting path constraints on the interpreter.

[0121] The symbolic execution engine includes three sub-modules, namely the binary to intermediate representation language module, the symbolic executor module and the constraint solver module.

[0122] A. Intermediate representation lifter

[0123] In the intermediate representation lifter that implements the intermediate representation conversion module, we use PyVEX to convert the binary machine instructions of the firmware program.

[0124] B. Symbol Executor

[0125] The key function of the symbol executor is to collect path constraints at jump points involving symbols. When encountering a VEX branch statement, the symbol executor will collect symbol constraint conditions pointing to bypass successor branch points according to semantics.

[0126] C. Symbol Solver

[0127] We select Z3 as the constraint solver. We solve the constraints collected in each symbol execution after each single execution is completed, and store the generated results in the test case set. According to the strategy formulated in the explorer, we select the specified test cases for the next round of hybrid symbolic execution analysis.

[0128] 3. Symbol Storage and Backup Storage: A three - level storage structure is adopted to realize the unified storage of symbol memory and symbol registers, shielding the impact of the target program architecture on symbolic execution. When the symbol execution engine fails to read content from the symbol storage, the backup storage reads the required content from the entity device memory through the binary instrumentation module to initialize the symbol storage data.

[0129] 4. Explorer: As the main control module of hybrid symbolic execution, the explorer runs on the debug host. Under the control of the user script, the explorer passes the initial input to the firmware program on the embedded device for specific execution through the instrumentation module. After the symbol execution engine collects and solves to generate test cases, the explorer selects test cases according to the specified strategy for the next round of testing.

[0130] To meet the analysis requirements, we have implemented two path exploration strategies for the explorer:

[0131] One is the depth - first algorithm, which continuously explores the successors of branch nodes until reaching the leaf nodes. In theory, it can traverse the binary program. The other is the algorithm for exploring according to the specified path. This algorithm allows the hybrid symbolic execution system to explore along the given execution path according to the given execution path. This can greatly shorten the time required for analysis to reach a specific program location under the condition of a known path and improve the practicality of the system.

[0132] To implement hybrid symbolic execution analysis guided by a specific path, we have developed an explorer and a gdb hybrid symbolic execution analysis script. The explorer receives the path specified by the user and the maximum number of test rounds as input, and then guides the hybrid symbolic execution to perform analysis according to this path.

[0133] When the explorer starts, it first starts the gdbserver on the physical device, and then generates a unique trace_id and test_case based on the current execution round and the number of tests. Next, the explorer starts gdb and loads the hybrid symbolic execution analysis script fw_sym_trc_test.py to assist in the analysis process.

[0134] During the operation of the explorer, it deserializes the path and constraint files generated by the analysis script. For the test cases generated by the bypass branches, the explorer serializes them according to specific rules (such as depth and execution round) and saves them to different test case files. Only when these test cases meet the path conditions specified by the user will they be recorded and used for subsequent analysis.

[0135] The gdb hybrid symbolic execution analysis script is responsible for performing the analysis driven by the specified test cases. During the analysis process, the script records the detailed information of each executed node, including the node address, the successor address of the branch node, the bypass exit address, and the corresponding test case. This information will be written into the trace file in text form.

[0136] Once the path executed by the analysis script reaches the set target point, it notifies the explorer to stop the analysis work, which marks the completion of the path-guided hybrid symbolic execution analysis task. However, if the target node cannot be reached within the specified number of analysis rounds, it means that the hybrid symbolic execution analysis cannot be completed this time.

[0137] In this way, we can achieve precise control and guidance of specific paths, thereby more effectively performing hybrid symbolic execution analysis. Based on the algorithm of exploring by specified paths, the system has the function of exploring by paths to generate specific test cases, which will partially alleviate the path explosion problem faced by the system when analyzing small programs.

[0138] Based on the same inventive concept, this embodiment also provides a computing device, including: one or more processors, one or more memories, and one or more programs, where the programs are stored in the memory and configured to be executed by the processor, and when the programs are loaded into the processor, the steps of the method for detecting vulnerabilities in an embedded firmware program according to any one of the above are implemented.

[0139] Based on the same inventive concept, this embodiment also provides a storage medium, where the storage medium stores a computer program, the computer program includes program instructions, and when the program instructions are executed by the processor, the processor is caused to execute the steps of the method for detecting vulnerabilities in an embedded firmware program according to any one of the above.

[0140] The present invention solves the environmental modeling problem by proposing a method capable of accurately modeling and simulating the specific hardware and operating system environments required for the operation of embedded firmware programs; copes with the challenge of path explosion by developing effective strategies or algorithms to reduce the huge number of execution paths that the firmware program may generate; and explores ways to implement efficient symbolic execution testing on resource-constrained embedded devices to solve the problem of symbolic execution efficiency, thereby comprehensively improving the accuracy and efficiency of symbolic execution testing of embedded firmware programs and providing more effective guarantees for the security and reliability of embedded systems.

Claims

1. A method for detecting vulnerabilities in embedded firmware programs, characterized in that: include: Through the program monitor, dynamic binary instrumentation is performed on the specified code area of ​​the firmware program to obtain the basic block instruction stream; The symbolic execution engine receives the basic block instruction stream and extracts path constraints; The explorer selects test cases for exploration and execution, and obtains the status of path constraints; The symbolic execution engine detects vulnerabilities according to the status of the path constraints and outputs results.

2. The embedded firmware program vulnerability detection method according to claim 1, characterized in that: Before dynamically performing binary instrumentation on a designated code area of ​​a firmware program through a program monitor and obtaining a basic block instruction stream, the process also includes: starting a debugging host, loading the firmware program and a target code area, initializing a program monitor, a symbolic execution engine, a backup storage, a symbolic storage and an explorer, and configuring a path exploration strategy of the explorer; Among them, the path exploration strategy includes a depth-first algorithm and an algorithm for exploring along a specified path; the depth-first algorithm continuously explores the successors of branch nodes until reaching a leaf node, traversing the binary program; the algorithm for exploring along a specified path, based on a given execution path, enables the hybrid symbolic execution system to explore along the path.

3. The embedded firmware program vulnerability detection method according to claim 1, characterized in that: The dynamic binary plugging of the designated code area of ​​the firmware program also includes using the binary program plugging method of gdb-server to specifically execute and monitor the firmware program, and using the Python plug-in of gdb to control the plugging process.

4. The embedded firmware program vulnerability detection method according to claim 1, characterized in that: The symbolic execution engine receives the basic block instruction stream and extracts path constraints, specifically: The symbolic execution engine receives the basic block instruction stream; The intermediate representation lifter uses PyVEX to convert the binary machine instructions of the basic block instruction stream into an intermediate representation; The symbolic executor performs execution on the intermediate representation and collects path constraints at jump points involving symbols; The symbolic solver uses the solver to solve the collected path constraints and generate test cases.

5. The embedded firmware program vulnerability detection method according to claim 1, characterized in that: Before the explorer selects a test case for exploration and execution and obtains the status of the path constraints, it also includes: storing data in a symbol storage module and managing it through a backup storage module. Specifically, the data of the symbol memory and the symbol register are stored in the symbol storage module; when the symbolic execution engine fails to read content from the symbol storage, the backup storage reads the required content from the physical device memory through the binary stub module to initialize the symbol storage data.

6. The embedded firmware program vulnerability detection method according to claim 1, characterized in that: The explorer selects test cases for exploration and execution, and obtains the status of path constraints, specifically: The explorer selects test cases from the test case set according to the set path exploration strategy; Through the instrumentation module, the initial input is passed to the firmware program on the embedded device for specific execution; The program monitor monitors the execution process and passes the basic block instruction stream to the symbolic execution engine for a new round of symbolic execution and path constraint extraction.

7. The embedded firmware program vulnerability detection method according to claim 1, characterized in that: The symbolic execution engine detects vulnerabilities and outputs results according to the status of the path constraints, specifically: The symbolic execution engine monitors the symbolic execution process. When it finds that the path constraints cannot be met or an exception is triggered, it is determined as a potential vulnerability. The detected vulnerability information is output to the debugging host for further analysis and processing by the user.

8. An embedded firmware program vulnerability detection system, characterized in that: include: Initialization and setup module, used to start the debugging host, load the firmware program and target code area; The program monitoring and plugging module is used to perform dynamic binary plugging on the specified code area of ​​the firmware program through the program monitor to obtain the basic block instruction stream; A symbolic execution and path constraint extraction module, used for receiving the basic block instruction stream through a symbolic execution engine and extracting path constraints; A symbol storage and backup storage management module, used to store data in the symbol storage module and manage it through the backup storage module; The test case exploration and execution module is used to select test cases for exploration and execution through the explorer to obtain the status of path constraints; The vulnerability detection and result output module is used for the symbolic execution engine to detect vulnerabilities and output results according to the status of the path constraints.

9. The embedded firmware program vulnerability detection system according to claim 8, characterized in that: The symbolic execution and path constraint extraction module is used to receive the basic block instruction stream through the symbolic execution engine and extract the path constraints, specifically: The symbolic execution engine receives the basic block instruction stream; The intermediate representation lifter uses PyVEX to convert the binary machine instructions of the basic block instruction stream into an intermediate representation; The symbolic executor performs execution on the intermediate representation and collects path constraints at jump points involving symbols; The symbolic solver uses the solver to solve the collected path constraints and generate test cases.

10. A computing device, characterized in that include: One or more processors, one or more memories, and one or more programs, wherein the programs are stored in the memories and configured to be executed by the processors, and when the programs are loaded into the processors, the steps of the embedded firmware program vulnerability detection method according to any one of claims 1 to 7 are implemented.

11. A storage medium, characterized in that: The storage medium stores a computer program, which includes program instructions. When the program instructions are executed by a processor, the processor executes the steps of the embedded firmware program vulnerability detection method according to any one of claims 1 to 7.

Images