Embedded firmware hybrid symbolic execution testing systems, methods, devices, and media

Abstract

The embedded firmware hybrid symbolic execution test system, method, device and medium provided by the embodiments of the present disclosure comprise an initial converter, a symbolic execution virtual machine and a peripheral debugger; the initial converter fuses high semantic source code and low semantic assembly code in semantics to obtain a hybrid semantic IR file; the symbolic execution virtual machine finds a plurality of behavior paths included in the hybrid semantic IR file and state information of nodes included in each behavior path through a symbolic variable, and generates a test case corresponding to each abnormal trigger node according to the abnormal trigger nodes of the plurality of behavior paths; and the peripheral debugger reproduces and analyzes a test problem according to the test case. The engineering value of test vulnerability verification is improved.

Description

Technical Field

[0001] This invention relates to the field of security protection technology and related technical fields, specifically to an embedded firmware hybrid symbol execution test system, method, device and medium. Background Technology

[0002] With the widespread deployment of embedded devices and the continuous expansion of the IoT ecosystem, systemic vulnerabilities caused by embedded firmware security issues are becoming increasingly common, and their destructiveness and cost are extremely high. However, existing security testing methods are insufficient for efficiently detecting deep vulnerabilities in embedded firmware, especially in complex systems that simultaneously contain C code, assembly code, and third-party binary libraries, where the problem is particularly prominent.

[0003] The existing security testing methods have the following problems: 1. Current security analysis is often limited to the high-level C / C++ language layer and ignores the assembly component, resulting in one-sided system testing; 2. When faced with firmware with a large number of I / O operations, complex memory mapping and interrupt mechanisms, the original symbolic execution platform has difficulty accurately simulating its behavior; 3. The current symbolic execution process does not fully support context switching and peripheral device interaction, resulting in insufficient test path coverage and unstable results. Summary of the Invention

[0004] The embodiments described herein provide an embedded firmware hybrid symbolic execution test system, method, apparatus, and storage medium that address the problems existing in the prior art.

[0005] In a first aspect, according to the present disclosure, an embedded firmware hybrid symbolic execution test system is provided, comprising: an initial converter, a symbolic execution virtual machine, and a peripheral debugger;

[0006] The initial converter is configured to semantically fuse high-semantic source code with low-semantic assembly code to obtain a hybrid semantic IR file;

[0007] The symbolic execution virtual machine is configured to look up multiple behavior paths and the status information of nodes included in the hybrid semantic IR file through symbolic variables, and generate test cases corresponding to each abnormal trigger node based on the abnormal trigger nodes of the multiple behavior paths. The symbolic execution virtual machine includes memory layout replication, interrupt virtual scheduling, DMA virtual processing, and symbolic memory monitoring and abnormal collection functions. The status information includes path constraints, input conditions, interrupt trigger sequences, and peripheral data interaction records.

[0008] The peripheral debugger is configured to reproduce and analyze test problems based on the test cases.

[0009] In some embodiments of this disclosure, the initial converter includes a boosting unit, an intermediate layer bridging unit, and a merging unit;

[0010] The enhancement unit is configured to compile high-semantic source code into LLVM Bitcode and convert low-semantic assembly code into LLVM IR representation. The LLVM Bitcode includes high-level semantic information such as variables, structures, and function scope in the high-semantic source code, and the LLVM IR representation includes the instruction order and register behavior in the low-semantic assembly code and is compatible with LLVM semantics.

[0011] The intermediate bridging unit is configured to insert an interface shim function between the high-semantic source code and the low-semantic assembly code;

[0012] The merging unit is configured to integrate LLVM Bitcode and LLVM IR representation to generate a hybrid semantic IR file.

[0013] In some embodiments of this disclosure, the interface shim function first switches the context state to a logic stack variable and executes low-semantic assembly code, and after the low-semantic assembly code execution is completed, switches the context state to the initial state and continues to execute high-semantic source code.

[0014] In some embodiments of this disclosure, the symbolic execution virtual machine includes a loading unit, a path information determination unit, and a test case generation unit;

[0015] The loading unit is configured to load a hybrid semantic IR file;

[0016] The path information determination unit is configured to search for multiple behavioral paths included in the hybrid semantic IR file and the status information of the nodes included in each behavioral path by using symbolic variables;

[0017] The test case generation unit is configured to determine the abnormal triggering nodes of each behavior path based on the status information of the symbol nodes included in multiple behavior paths, and generate test cases corresponding to each abnormal triggering node.

[0018] In some embodiments of this disclosure, the path information determination unit includes a memory layout replication subunit, an interrupt scheduling simulation subunit, a DMA region processing subunit, a memory monitoring and anomaly collection subunit, and a path information determination subunit;

[0019] The memory layout replication subunit is configured to construct a hybrid memory model and map high-level variables in the hybrid semantic IR file to raw addresses, as well as to the peripheral space.

[0020] The interrupt scheduling simulation subunit is configured to parse the interrupt address in the hybrid semantic IR file according to the hardware vector table, mark the location of the virtual event in the hybrid semantic IR file, insert ISR scheduling in the hybrid semantic IR file according to rules or symbolic events, and automatically manage stack saving / restoration in the hybrid semantic IR file.

[0021] The DMA region processing subunit is configured to identify DMA buffer usage regions in the hybrid semantic IR file, and to capture DMA out-of-bounds access and data synchronization conflicts in the hybrid semantic IR file.

[0022] The memory monitoring and anomaly collection subunit is configured to check for Use-After-Free (UAF), out-of-bounds, and dangling pointer issues in the hybrid semantic IR file, and record the triggering path, input conditions, path constraints, and anomaly causes of the anomaly triggering node.

[0023] The path information determination subunit is configured to, based on the processing results of the memory layout replication subunit, interrupt scheduling simulation subunit, DMA region processing subunit, and memory monitoring and anomaly acquisition subunit, search for multiple behavioral paths included in the hybrid semantic IR file and the status information of the nodes included in each behavioral path through symbolic variables.

[0024] In some embodiments of this disclosure, the test case generation unit includes a multi-path state tree generation subunit and a test report generation subunit;

[0025] The multipath state tree generation subunit is configured to generate a multipath state tree based on the multiple behavioral paths included in the searched hybrid semantic IR file and the association between any two behavioral paths.

[0026] The test report generation subunit is configured to generate test cases corresponding to each exception trigger node based on the exception trigger nodes of the multi-path state tree, and generate a test report.

[0027] In some embodiments of this disclosure, the test report generation subunit includes an anomaly collection subunit and a test case export subunit;

[0028] The anomaly acquisition subunit is configured to determine the anomaly triggering nodes of the multi-path state tree and acquire the state information corresponding to each anomaly triggering point.

[0029] The test case export subunit is configured to generate test cases corresponding to each abnormal trigger node and generate a test report based on the abnormal trigger nodes of the determined multi-path state tree and the collected state information corresponding to each abnormal trigger node.

[0030] Secondly, according to the content of this disclosure, an embedded firmware hybrid symbol execution test method is provided, including:

[0031] By semantically fusing high-semantic source code with low-semantic assembly code, a hybrid semantic IR file is obtained;

[0032] The symbolic execution virtual machine (SVM) is used to find the multiple behavior paths and the status information of the nodes included in the hybrid semantic IR file by using symbolic variables. Based on the abnormal triggering nodes of the multiple behavior paths, test cases corresponding to each abnormal triggering node are generated. The symbolic execution virtual machine includes memory layout replication, interrupt virtual scheduling, DMA virtual processing, and symbolic memory monitoring and abnormal collection functions. The status information includes path constraints, input conditions, interrupt triggering sequences, and peripheral data interaction records.

[0033] Based on the test cases, reproduce and analyze the test problems.

[0034] Thirdly, according to the present disclosure, a computer device is provided, comprising:

[0035] One or more processors;

[0036] Storage device for storing one or more programs.

[0037] 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 of the first aspects.

[0038] Fourthly, according to the present disclosure, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the methods described in any of the first aspects.

[0039] This disclosure provides an embedded firmware hybrid symbolic execution testing system, method, device, and storage medium. An initial converter semantically fuses high-semantic source code with low-semantic assembly code to obtain a hybrid semantic IR file. A symbolic execution virtual machine uses symbolic variables to find multiple behavioral paths and the state information of nodes within each behavioral path in the hybrid semantic IR file, and generates test cases corresponding to each exception triggering node based on the exception triggering nodes of the multiple behavioral paths. A peripheral debugger reproduces and analyzes test problems based on the test cases. First, the initial converter automatically translates the assembly blocks of the embedded architecture (such as ARMv7-M) into an LLVM-compatible IR, and then combines it with high-level source code through the Glue mechanism to finally form a "hybrid semantic IR." This process does not require manual transcoding and can automatically link the source code and assembly code to form a complete symbolic execution model. Secondly, the Symbolic Execution Virtual Machine (SVM) adds support for peripherals, interrupt mechanisms, and stack contexts to the KLEE symbolic engine. It also supports high-semantic memory mapping structure processing, allowing it to simultaneously track variable information from high-level memory access (IR) and pointer access behavior from low-level IR, performing memory checks and dynamic tracking of whether security rules have been broken on both types of data. During SVM execution, for each potentially defective path triggered, the system records the input conditions (i.e., the range of input variable values), constraints, peripheral data interaction records, and interrupt trigger sequences along that path, ultimately deriving a set of test cases that can realistically reproduce the behavior. These test cases conform to real-world embedded systems, such as "DMA read out of bounds occurs when the UART buffer is not cleared," greatly enhancing the engineering value of vulnerability verification.

[0040] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0041] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings of the embodiments will be briefly described below. It should be understood that the drawings described below only relate to some embodiments of this disclosure and are not intended to limit this disclosure, wherein:

[0042] Figure 1 This is a schematic diagram of the structure of an embedded firmware hybrid symbol execution test system provided in an embodiment of this disclosure;

[0043] Figure 2 This is a schematic diagram of another embedded firmware hybrid symbol execution test system provided in this embodiment of the present disclosure;

[0044] Figure 3 This is a flowchart illustrating an embedded firmware hybrid symbol execution test method provided in an embodiment of this disclosure;

[0045] Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this disclosure.

[0046] In the accompanying diagram, markers with the same last two digits correspond to the same elements. It should be noted that the elements in the diagram are schematic and not drawn to scale. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the described embodiments of this disclosure without creative effort are also within the scope of protection of this disclosure.

[0048] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this subject matter pertains. It will be further understood that terms such as those defined in commonly used dictionaries shall be interpreted as having the meaning consistent with their meaning in the context of the specification and in the relevant art, and shall not be interpreted in an idealized or overly formal form unless otherwise explicitly defined herein. As used herein, the statement of “connecting” or “coupling” two or more parts together shall mean that these parts are directly joined together or joined through one or more intermediate components.

[0049] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of the phrase "embodiment" in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0050] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists, A and B exist simultaneously, or B exists. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0051] Furthermore, in all embodiments of this disclosure, terms such as “first” and “second” are used only to distinguish one component (or part of a component) from another component (or another part of a component).

[0052] In the description of this application, unless otherwise stated, "multiple" means two or more (including two), and similarly, "multiple groups" means two or more (including two groups).

[0053] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0054] In view of the problems existing in the prior art, the present disclosure provides an embedded firmware hybrid symbol execution test system. Figure 1 This is a schematic diagram of the structure of an embedded firmware hybrid symbolic execution test system provided in an embodiment of this disclosure, as shown below. Figure 1 As shown, the embedded firmware hybrid symbolic execution test system includes: an initial converter, a symbolic execution virtual machine, and a peripheral debugger. The initial converter 10 is configured to semantically fuse high-semantic source code with low-semantic assembly code to obtain a hybrid semantic IR file. The symbolic execution virtual machine 20 is configured to search for multiple behavioral paths included in the hybrid semantic IR file and the status information of the nodes included in each behavioral path through symbolic variables, and generate test cases corresponding to each abnormal triggering node based on the abnormal triggering nodes of the multiple behavioral paths. The symbolic execution virtual machine includes memory layout replication, interrupt virtual scheduling, DMA virtual processing, and symbolic memory monitoring and abnormal collection functions. The status information includes path constraints, input conditions, interrupt trigger sequences, and peripheral data interaction records. The peripheral debugger 30 is configured to reproduce and analyze test problems based on the test cases.

[0055] LLVM (Low Level Virtual Machine) is a modular compiler infrastructure project that supports a variety of intermediate representation technologies. In particular, its core intermediate language LLVM-IR, which uses static single assignment (SSA) format, is widely used for dynamic and static analysis, optimization, and backend implementation of new programming languages.

[0056] In traditional LLVM, high-semantic C / C++ source code is translated into rich-type LLVMBitcode using Clang, while low-semantic assembly code cannot be represented as standard LLVM Bitcode. Based on the problems existing in the prior art, the embedded firmware hybrid symbolic execution test system provided in this disclosure includes an initial converter. This initial converter can not only translate high-semantic source code into LLVMBitcode, but also translate low-semantic assembly code into LLVM IR representation. Furthermore, it performs semantic fusion between the translated LLVMBitcode and LLVM IR representation to obtain a hybrid semantic IR file.

[0057] First, the high-semantic source code and low-semantic assembly code are processed by an initial converter. The high-semantic source code is converted into LLVM Bitcode, and the low-semantic assembly code is converted into LLVM IR representation. Then, the LLVM Bitcode corresponding to the high-semantic source code and the LLVM IR corresponding to the low-semantic assembly code are integrated to obtain a hybrid semantic IR file.

[0058] Specifically, the low-semantic assembly code is converted into LLVM IR through the Static Lifter. The core goal is to express instruction behavior using LLVM's intermediate language (IR), thereby enabling symbolic execution under the LLVM framework.

[0059] The static lifter translates low-semantic assembly code into LLVM IR mapping processing logic, including:

[0060] Instruction semantic mapping: Basic instructions in assembly code such as MOV, LDR, STR, ADD, and SUB are mapped one by one to their equivalent operations in LLVM (such as store, load, add, etc.). For example, MOV R0, #1 will be converted to %r0 = add i320, 1 in LLVM IR (or directly i321 is stored in the variable bit of %r0).

[0061] Architecture-aware mapping: For specific architectures (such as ARMv7-M), the lifter preserves the order of behavior and register access paths for registers, conditional execution, stack operations, etc., to avoid losing key execution semantics in the abstraction.

[0062] Control flow instruction processing: Jump or call instructions such as BL, BX, and BNE are translated into LLVM IR control flow instructions such as br, call, and ret; at the same time, corresponding basic blocks and control flow graph (CFG) structures are inserted into LLVM IR to ensure flow continuity.

[0063] Memory mapping and register abstraction: MMIO access is mapped via fixed address load / store; physical registers are typically mapped to specific LLVM virtual variables, such as %r0, %r1, etc.

[0064] The key to processing different assembly code lies in equivalent semantic conversion and maintaining the execution order, with the goal of enabling subsequent KLEE to recognize their symbolic execution semantics.

[0065] By using Clang compilation, high-level semantics such as function names, variables, struct definitions, and block scope in the high-semantic source code are preserved, thereby enabling the compilation of high-semantic source code into LLVM Bitcode.

[0066] After translating high-semantic source code into LLVM Bitcode and low-semantic assembly code into LLVM IR representation, a hybrid semantic IR file is obtained by semantically fusing the LLVM Bitcode and LLVM IR representation.

[0067] Symbolic execution

[0068] Symbolic execution is a technique for automated program analysis that treats input as symbolic variables rather than concrete numerical values, thereby systematically exploring all possible paths in a program and identifying execution behavior under various constraints. This technique can be used to discover hidden errors at boundaries, such as out-of-bounds access, null pointer dereferences, and logical vulnerabilities.

[0069] The Symbolic Execution Virtual Machine is a widely used open-source symbolic execution engine developed based on LLVM IR. Its core is a constraint solver and a branch path tracing mechanism, which can analyze each logical path in the generated LLVM Bitcode to verify whether the program has potential defects or abnormal execution paths.

[0070] In this embodiment of the disclosure, an embedded firmware hybrid symbolic execution test system is configured to include a symbolic execution virtual machine (MAM). The MAM can execute a hybrid semantic IR file, which is a fusion of high-semantic source code and low-semantic assembly code. The MAM processes the hybrid semantic IR file, simultaneously tracking variable information from the high-semantic source code and pointer access behavior from the low-semantic assembly code. Memory checks and dynamic tracking of whether security rules are violated are performed on both types of data. This allows for the determination of multiple behavioral paths within the hybrid semantic IR file, the state information of nodes within different behavioral paths, and the generation of test cases corresponding to anomaly triggering nodes.

[0071] During the execution of the symbolic execution virtual machine, for each potentially defective path triggered, the system records the input conditions (i.e., the range of input variable values), constraints, peripheral data interaction records, and interrupt trigger sequences along that path. This process ultimately derives a set of test cases that can realistically reproduce the behavior. These test cases conform to real-world embedded systems, such as "DMA read out of bounds occurs when the UART buffer is not cleared." This mechanism greatly enhances the engineering value of vulnerability verification.

[0072] The embedded firmware hybrid symbolic execution testing system provided in this disclosure includes an initial converter that semantically fuses high-semantic source code and low-semantic assembly code to obtain a hybrid semantic IR file; a symbolic execution virtual machine that uses symbolic variables to find multiple behavioral paths included in the hybrid semantic IR file and the state information of the nodes included in each behavioral path, and generates test cases corresponding to each abnormal triggering node based on the abnormal triggering nodes of the multiple behavioral paths; and a peripheral debugger that reproduces and analyzes the test problems based on the test cases. First, the initial converter automatically translates the assembly blocks of the embedded architecture (such as ARMv7-M) into an LLVM-compatible IR, and then combines it with the high-level source code through the Glue mechanism to finally form a "hybrid semantic IR". This process does not require manual transcoding and can automatically link the source code and assembly code to form a complete symbolic execution model. Secondly, the Symbolic Execution Virtual Machine (SVM) adds support for peripherals, interrupt mechanisms, and stack contexts to the KLEE symbolic engine. It also supports high-semantic memory mapping structure processing, allowing it to simultaneously track variable information from high-level memory access (IR) and pointer access behavior from low-level IR, performing memory checks and dynamic tracking of whether security rules have been broken on both types of data. During SVM execution, for each potentially defective path triggered, the system records the input conditions (i.e., the range of input variable values), constraints, peripheral data interaction records, and interrupt trigger sequences along that path, ultimately deriving a set of test cases that can realistically reproduce the behavior. These test cases conform to real-world embedded systems, such as "DMA read out of bounds occurs when the UART buffer is not cleared," greatly enhancing the engineering value of vulnerability verification.

[0073] In the specific implementation method, combined with Figure 2 The initial converter 10 includes a lift unit 11, an intermediate layer bridging unit 12, and a merging unit 13. The lift unit 11 is configured to compile high-semantic source code into LLVM Bitcode and convert low-semantic assembly code into LLVM IR representation. The LLVM Bitcode includes high-level semantic information such as variables, structures, and function scope in the high-semantic source code, while the LLVM IR representation includes instruction order and register behavior in the low-semantic assembly code and is compatible with LLVM semantics. The intermediate layer bridging unit 12 is configured to insert an interface shim function between the high-semantic source code and the low-semantic assembly code. The merging unit 13 is configured to integrate the LLVM Bitcode and the LLVM IR representation to generate a hybrid semantic IR file.

[0074] Because the semantic levels of the LLVM Bitcode translated from high-semantic source code and the LLVM IR translated from low-semantic assembly code are different, inconsistencies in control flow and register / memory states can occur. Therefore, an intermediate bridging unit needs to be introduced. The intermediate bridging unit is implemented based on the interface shim function. Specifically, the interface shim function is inserted between the end of the high-semantic source code and the beginning of the low-semantic assembly code. The core function of the interface shim method is to correctly save and restore the execution context during scheduler switching, enabling seamless transitions between high-semantic source code and low-semantic assembly code.

[0075] Specifically, the interface shim function first switches the context state to the logical stack variable and executes low-semantic assembly code. After the low-semantic assembly code finishes executing, it switches the context state back to the initial state and continues executing the high-semantic source code.

[0076] Scheduler switching refers to the process during the execution of the initial converter where a program may jump from high-semantic source code to low-semantic assembly code (e.g., calling a hardware initialization function), or return from low-semantic assembly code to high-semantic source code, or even have its current path interrupted by an interrupt handler (ISR) at any point. This "language segment / semantic segment" transition is called "scheduler switching." To ensure that the initial converter can correctly restore the context during scheduler switching, the following state information must be kept consistent before and after the switch: register state saving and restoration (e.g., R0-R12, SP, LR), stack frame information (function stack, local variables, call relationships), symbolic variable and memory block mapping relationships (e.g., the region pointed to by a struct pointer in C cannot be misused in assembly), and execution point restoration, to ensure the correct return jump point.

[0077] The specific working process of the shimblock function:

[0078] 1. Push the current context state (registers, SP) to the logical stack variables;

[0079] 2. Forward execution to the header of the low-semantic assembly code;

[0080] 3. After the low-semantic assembly code finishes execution, pop it back to its original state from the shimblock.

[0081] 4. Jump back to the high-semantic source code control flow and continue execution of the path symbols.

[0082] The interface shim is to ensure "high semantic source code" The key bridging logic between the "path validity" and the "execution state correctness" of low-semantic assembly code is not just a call to the wrapper function, but also a "cross-semantic execution context protection mechanism".

[0083] In the specific implementation method, continue to combine Figure 2 The symbolic execution virtual machine includes a loading unit 21, a path information determination unit 22, and a test case generation unit 23. The loading unit 21 is configured to load a hybrid semantic IR file. The path information determination unit 22 is configured to search for multiple behavioral paths included in the hybrid semantic IR file and the status information of the nodes included in each behavioral path through symbolic variables. The test case generation unit 23 is configured to determine the abnormal triggering nodes of each behavioral path based on the status information of the symbol nodes included in the multiple behavioral paths, and generate test cases corresponding to each abnormal triggering node.

[0084] Specifically, the loading unit that executes the virtual machine first loads the hybrid semantic IR file. Then, the memory layout replication subunit, interrupt scheduling simulation subunit, DMA region processing subunit, and memory monitoring and exception collection subunit of the path information determination unit process the hybrid semantic IR file loaded by the loading unit. Based on the processing results of the hybrid semantic IR file by the memory layout replication subunit, interrupt scheduling simulation subunit, DMA region processing subunit, and memory monitoring and exception collection subunit, the path information determination subunit uses symbolic variables to find the multiple behavioral paths included in the hybrid semantic IR file and the status information of the nodes included in each behavioral path. Finally, the test case generation unit determines the exception triggering nodes of each behavioral path based on the status information of the symbolic nodes included in the multiple behavioral paths and generates test cases corresponding to each exception triggering node.

[0085] The process of analyzing and executing the merged hybrid semantic IR file is completed based on the symbolic execution virtual machine (based on the KLEE engine). The analysis and execution process is mainly achieved through the collaborative work of four sub-units: memory layout replication sub-unit, interrupt scheduling simulation sub-unit, DMA region processing sub-unit, and memory monitoring and anomaly collection sub-unit.

[0086] Specifically, the memory layout replication subunit is configured to build a hybrid memory model and map high-level variables in the hybrid semantic IR file to raw addresses, as well as the peripheral space; the interrupt scheduling simulation subunit is configured to parse interrupt addresses in the hybrid semantic IR file according to the hardware vector table, mark the location of virtual events in the hybrid semantic IR file, insert ISR scheduling in the hybrid semantic IR file according to rules or symbolic events, and automatically manage stack saving / restoration in the hybrid semantic IR file; the DMA region processing subunit is configured to identify DMA buffer usage areas in the hybrid semantic IR file and capture DMA out-of-bounds access and data synchronization conflicts in the hybrid semantic IR file; and the memory monitoring and exception acquisition subunit is configured to check for Use-After-Free (UAF), out-of-bounds, and dangling pointer problems in the hybrid semantic IR file, and record the trigger path, input conditions, path constraints, and exception causes of exception triggering nodes.

[0087] In a specific implementation, when a mixed semantic IR file accesses the MMIO region, the memory layout replication subunit triggers the peripheral simulator to generate a response; the peripheral simulator determines that the access timing meets the interrupt triggering condition, the interrupt scheduling simulation subunit calls the interrupt responder to schedule the ISR; if a post-free access behavior occurs in the ISR, the memory monitor of the memory monitoring and anomaly collection subunit captures the Use-After-Free vulnerability; all abnormal behaviors are recorded along with their paths and symbol inputs, and test cases are exported.

[0088] The above embodiments exemplify how the three subunits—the memory layout replication subunit, the interrupt scheduling simulation subunit, and the memory monitoring and anomaly collection subunit—jointly cover the address space, peripheral behavior, and interrupt handling process during the execution of the symbolic execution virtual machine.

[0089] In this embodiment, the memory layout replication subunit, interrupt scheduling simulation subunit, DMA region processing subunit, and memory monitoring and anomaly acquisition subunit of the symbolic execution virtual machine realize complete modeling and behavior path tracing of embedded system behavior in the hybrid semantic IR file analysis process, thus connecting the detection link between static structure and dynamic behavior.

[0090] After analyzing the hybrid semantic IR file, the symbolic execution virtual machine can determine the multiple behavioral paths included in the hybrid semantic IR file and the state information of the nodes included in each behavioral path. Since there are correlations between the multiple behavioral paths generated by the analysis, in order to ensure the comprehensiveness of the test case coverage corresponding to each anomaly triggering node in the final generation, after finding the multiple behavioral paths included in the hybrid semantic IR file, a multi-path state tree generation sub-unit is formed. Based on the multiple behavioral paths included in the hybrid semantic IR file and the correlation between any two behavioral paths, a multi-path state tree is generated. Then, a test report generation sub-unit generates test cases corresponding to each anomaly triggering node based on the anomaly triggering nodes in the multi-path state tree and generates a test report.

[0091] The test report generation subunit includes an anomaly collection subunit and a test case export subunit.

[0092] The anomaly acquisition subunit is configured to determine the anomaly trigger nodes of the multi-path state tree and collect the state information corresponding to each anomaly trigger point; the test case export subunit is configured to generate test cases corresponding to each anomaly trigger node based on the determined anomaly trigger nodes of the multi-path state tree and the collected state information corresponding to each anomaly trigger point, and generate a test report.

[0093] In the process of generating a multi-path state tree based on the multiple behavioral paths and the relationships between any two behavioral paths included in the searched hybrid semantic IR file, if any two behavioral paths include at least one common node, then there is a relationship between these two behavioral paths. Therefore, the constructed multi-path state tree has two branches at that node, and each branch includes branch states, such as memory mapping, input symbol constraints, and execution path history. Finally, test cases are generated by deriving sub-units from test cases to produce test cases corresponding to each exception triggering node included in the multi-path state tree. Based on the test cases corresponding to each exception triggering node, a test report is generated. This achieves the ability to derive test cases with realistic meaning and reproducibility from the abstract state of the hybrid semantic IR file, which can be used for security analysis, remediation verification, and system regression testing.

[0094] Based on the above embodiments, Figure 3 This is a flowchart illustrating an embedded firmware hybrid symbol execution test method provided in an embodiment of this disclosure, as shown below. Figure 3 As shown, the embedded firmware hybrid symbol execution test method includes:

[0095] S310. Semantically fuse the high-semantic source code with the low-semantic assembly code to obtain a hybrid semantic IR file.

[0096] S320. Locate the multiple behavior paths and the status information of the nodes included in each behavior path in the hybrid semantic IR file by using symbolic variables, and generate test cases corresponding to each abnormal trigger node based on the abnormal trigger nodes of the multiple behavior paths.

[0097] The symbolic execution virtual machine includes memory layout replication, interrupt virtual scheduling, DMA virtual processing, and symbolic memory monitoring and anomaly collection functions. The status information includes path constraints, input conditions, interrupt triggering sequences, and peripheral data interaction records.

[0098] S330. Based on the test cases, reproduce and analyze the test problems.

[0099] The embedded firmware hybrid symbolic execution testing method provided in this disclosure first semantically fuses high-semantic source code and low-semantic assembly code to obtain a hybrid semantic IR file. Then, it uses symbolic variables to find multiple behavioral paths included in the hybrid semantic IR file and the state information of nodes included in each behavioral path. Based on the abnormal triggering nodes of the multiple behavioral paths, it generates test cases corresponding to each abnormal triggering node. Finally, based on the test cases, it reproduces and analyzes the test problems. First, an initial converter automatically translates the assembly blocks of the embedded architecture (such as ARMv7-M) into an LLVM-compatible IR. Then, through the Glue mechanism, it combines with the high-level source code to ultimately form a "hybrid semantic IR." This process does not require manual transcoding and can automatically link the source code and assembly code to form a complete symbolic execution model. Secondly, the Symbolic Execution Virtual Machine (SVM) adds support for peripherals, interrupt mechanisms, and stack contexts to the KLEE symbolic engine. It also supports high-semantic memory mapping structure processing, allowing it to simultaneously track variable information from high-level memory access (IR) and pointer access behavior from low-level IR, performing memory checks and dynamic tracking of whether security rules have been broken on both types of data. During SVM execution, for each potentially defective path triggered, the system records the input conditions (i.e., the range of input variable values), constraints, peripheral data interaction records, and interrupt trigger sequences along that path, ultimately deriving a set of test cases that can realistically reproduce the behavior. These test cases conform to real-world embedded systems, such as "DMA read out of bounds occurs when the UART buffer is not cleared," greatly enhancing the engineering value of vulnerability verification.

[0100] This application also provides a computer device, please refer to the following for details. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0101] The computer device includes a memory 510 and a processor 520 that are interconnected via a system bus. It should be noted that only a computer device with components 510-520 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components may be implemented alternatively. Those skilled in the art will understand that the computer device described herein is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0102] Computer devices can include desktop computers, laptops, handheld computers, and cloud servers. These devices allow for human-computer interaction with users through keyboards, mice, remote controls, touchpads, or voice-activated devices.

[0103] The memory 510 includes at least one type of readable storage medium, including non-volatile memory or volatile memory, such as flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. RAM may include static RAM or dynamic RAM. In some embodiments, the memory 510 may be an internal storage unit of a computer device, such as the hard disk or memory of the computer device. In other embodiments, the memory 510 may also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, or flash card equipped on the computer device. Of course, the memory 510 may include both internal storage units and external storage devices of the computer device. In this embodiment, the memory 510 is typically used to store the operating system and various application software installed on the computer device, such as the program code of the method described above. In addition, the memory 510 may also be used to temporarily store various types of data that have been output or will be output.

[0104] The processor 520 is typically used to perform the overall operation of a computer device. In this embodiment, the memory 510 is used to store program code or instructions, including computer operation instructions. The processor 520 is used to execute the program code or instructions stored in the memory 510 or to process data, such as program code that runs the methods described above.

[0105] In this article, the bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus system can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0106] Another embodiment of this application also provides a computer-readable medium, which may be a computer-readable signal medium or a computer-readable medium. A processor in a computer reads computer-readable program code stored in the computer-readable medium, enabling the processor to execute the functional actions specified in each step or combination of steps in the above method; and to generate means for implementing the functional actions specified in each block or combination of blocks in the block diagram.

[0107] Computer-readable media include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared memory or semiconductor systems, devices or apparatuses, or any suitable combination thereof, wherein the memory is used to store program code or instructions, the program code including computer operation instructions, and the processor is used to execute the program code or instructions of the above-described methods stored in the memory.

[0108] The definitions of memory and processor can be found in the description of the foregoing computer device embodiments, and will not be repeated here.

[0109] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0110] In the various embodiments of this application, the functional units or modules can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0111] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0112] Unless otherwise expressly indicated by the context, the singular form of words used herein and in the appended claims includes the plural form, and vice versa. Thus, when referring to the singular, the plural form of the corresponding term is generally included. Similarly, the terms “comprising” and “including” shall be interpreted as including rather than exclusively. Likewise, the terms “including” and “or” shall be interpreted as including unless such interpretation is expressly prohibited herein. Where the term “example” is used herein, particularly when it follows a set of terms, the “example” is merely exemplary and illustrative and should not be considered exclusive or extensive.

[0113] Further aspects and scope of adaptation become apparent from the description provided herein. It should be understood that various aspects of this application may be implemented individually or in combination with one or more other aspects. It should also be understood that the descriptions and specific embodiments herein are for illustrative purposes only and are not intended to limit the scope of this application.

[0114] Several embodiments of this disclosure have been described in detail above. However, it is obvious that those skilled in the art can make various modifications and variations to the embodiments of this disclosure without departing from the spirit and scope of this disclosure. The scope of protection of this disclosure is defined by the appended claims.

Claims

1. An embedded firmware hybrid symbolic execution testing system, comprising: The application relates to a symbol execution virtual machine and a peripheral debugger. The initial converter is configured to perform semantic fusion on high semantic source code and low semantic assembly code to obtain a mixed semantic IR file. The symbol execution virtual machine is configured to search for state information of nodes included in multiple behavior paths and included in each behavior path in the mixed semantic IR file through a symbol variable, and generate test cases corresponding to each abnormal trigger node according to the abnormal trigger nodes of the multiple behavior paths, wherein the symbol execution virtual machine comprises a memory layout replication function, an interrupt virtual scheduling function, a DMA virtual processing function and a symbol memory monitoring and exception collection function, and the state information comprises path constraint conditions, input conditions, interrupt trigger sequences and peripheral data interaction records. The peripheral debugger is configured to reproduce and analyze a test problem according to the test cases. The initial converter comprises a promotion unit, an intermediate layer bridging unit and a merging unit. The promotion unit is configured to compile high semantic source code into an LLVM Bitcode and convert low semantic assembly code into an LLVM IR expression form, wherein the LLVM Bitcode comprises high-level semantic information such as variables, structure bodies and function scopes in the high semantic source code, the LLVM IR expression form comprises instruction sequences and register behaviors in the low semantic assembly code, and the LLVM IR expression form is compatible with an LLVM semantic; The intermediate layer bridging unit is configured to insert an interface shim function between the high semantic source code and the low semantic assembly code, wherein the interface shim function firstly switches a context state to a logical stack variable, executes the low semantic assembly code, and then switches the context state to an initial state after the execution of the low semantic assembly code, and continues to execute the high semantic source code. The merging unit is configured to generate the mixed semantic IR file after integrating the LLVM Bitcode and the LLVM IR expression form. The symbol execution virtual machine comprises a loading unit, a path information determination unit and a test case generation unit.

2. The system of claim 1, wherein, The loading unit is configured to load the mixed semantic IR file. The path information determination unit is configured to search for state information of nodes included in multiple behavior paths and included in each behavior path in the mixed semantic IR file through a symbol variable. The test case generation unit is configured to determine abnormal trigger nodes of each behavior path according to state information of symbol nodes included in the multiple behavior paths, and generate test cases corresponding to each abnormal trigger node. The path information determination unit comprises a memory layout replication subunit, an interrupt scheduling simulation subunit, a DMA region processing subunit, a memory monitoring and exception collection subunit and a path information determination subunit.

3. The system of claim 2, wherein, The memory layout replication subunit is configured to construct a mixed memory model, map high-level variables in the mixed semantic IR file to a bare address, and map a peripheral space. ​ The interrupt scheduling simulation subunit is configured to parse the interrupt address in the hybrid semantic IR file according to a hardware vector table, mark a virtual event occurrence position in the hybrid semantic IR file, insert an ISR schedule in the hybrid semantic IR file according to a rule or a symbol event, and automatically manage stack saving / restoring in the hybrid semantic IR file; The DMA region processing subunit is configured to identify a DMA buffer use region in the hybrid semantic IR file, and capture DMA out-of-bound access and data synchronization conflict in the hybrid semantic IR file; The memory monitoring and exception collection subunit is configured to check Use-After-Free (UAF), out-of-bound, and dangling pointer problems in the hybrid semantic IR file, and record a trigger path, an input condition, a path constraint condition, and an exception cause of an exception trigger node; The path information determination subunit is configured to determine, according to processing results of the memory layout replication subunit, the interrupt scheduling simulation subunit, the DMA region processing subunit, and the memory monitoring and exception collection subunit, a plurality of behavior paths included in the hybrid semantic IR file and state information of nodes included in each behavior path through a symbol variable.

4. The system of claim 2, wherein, The test case generation unit includes a multi-path state tree generation subunit and a test report generation subunit; The multi-path state tree generation subunit is configured to generate a multi-path state tree according to a plurality of behavior paths included in the hybrid semantic IR file and an association relationship between any two behavior paths. The test report generation subunit is configured to generate a test case corresponding to each exception trigger node according to an exception trigger node of the multi-path state tree, and generate a test report.

5. The system of claim 4, wherein, The test report generation subunit includes an exception collection subunit and a test case export subunit; The exception collection subunit is configured to determine an exception trigger node of the multi-path state tree, and collect state information corresponding to each exception trigger point; The test case export subunit is configured to generate a test case corresponding to each exception trigger node according to the determined exception trigger node of the multi-path state tree and the collected state information corresponding to each exception trigger point, and generate a test report.

6. An embedded firmware hybrid symbolic execution testing method, characterized by, It includes: Semantics of high semantic source code and low semantic assembly code are fused to obtain a hybrid semantic IR file; A plurality of behavior paths included in the hybrid semantic IR file and state information of nodes included in each behavior path are found through a symbol variable, and a test case corresponding to each exception trigger node is generated according to an exception trigger node of the plurality of behavior paths, wherein the symbolic execution virtual machine includes memory layout replication, interrupt virtual scheduling, DMA virtual processing, and symbol memory monitoring and exception collection functions, and the state information includes path constraint conditions, input conditions, interrupt trigger sequences, and peripheral data interaction records; According to the test case, a test problem is reproduced and analyzed; The semantics of high semantic source code and low semantic assembly code are fused to obtain a hybrid semantic IR file, including: Compiling high semantic source code into LLVM Bitcode, and converting low semantic assembly code into LLVM IR expression form, wherein the LLVM Bitcode includes high-level semantic information such as variable, structure, function scope and the like in the high semantic source code, and the LLVM IR expression form includes instruction sequence and register behavior in the low semantic assembly code and is compatible with LLVM semantics; Inserting an interface shim function between the high semantic source code and the low semantic assembly code, wherein the interface shim function first switches a context state to a logical stack variable, executes the low semantic assembly code, and switches the context state to an initial state after the low semantic assembly code is executed, and continues to execute the high semantic source code; After the LLVM Bitcode and the LLVM IR expression form are integrated, a mixed semantic IR file is generated.

7. A computer device, comprising: Including: One or more processors; A storage device 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 of claim 6.

8. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the method of claim 6.

Images