Directional fuzzing method and system based on selective hybrid execution and fine-grained distance computation

Abstract

The application discloses a kind of directional fuzzy test method and system based on selective hybrid execution and fine-grained distance calculation, the method is first to the program to be measured Static analysis, construct control flow graph and call graph, and extract basic block related to target code reach and vulnerability trigger in combination with data dependency;Subsequently, the relevant code segment is selectively plugged by hybrid execution compiler, and the target reachability probability is calculated based on conflict basic block, conflict tree and linear equation set, which is converted into fine-grained distance information;In the test phase, the fuzzy test engine and the hybrid execution module cooperate through shared memory and synchronization mechanism, and generate and screen test cases together.The present application provides a feasible solution to the problems of insufficient target guidance accuracy, high hybrid execution overhead and low test collaboration efficiency in existing directional fuzzy testing, which can improve the target code reach efficiency and vulnerability mining efficiency.

Description

Technical Field

[0001] This invention relates to the field of software security testing and vulnerability discovery technology, specifically to a targeted fuzzing technique for target code regions, used to improve the efficiency of reaching specified code locations or target paths in target programs and the efficiency of vulnerability triggering. Background Technology

[0002] With the continuous expansion of software system scale and the widespread application of open-source software, various basic libraries, third-party components, and open-source frameworks have been extensively integrated into software systems such as operating systems, network services, industrial control, and smart terminals. At the same time, the number of software vulnerabilities continues to increase, and these vulnerabilities are spreading more widely and having a greater impact. Once a security flaw exists in an underlying open-source component, it often spreads to multiple application scenarios through dependencies. Therefore, efficient and automated vulnerability discovery technologies are urgently needed.

[0003] Fuzzing, as an important software security testing method, boasts advantages such as high automation, strong ability to discover real-world vulnerabilities, and good engineering applicability, and has been widely applied in the field of vulnerability discovery. Traditional fuzzing typically aims to improve the overall coverage of a program by continuously mutating the input and exploring more paths based on execution feedback. However, this type of method lacks the ability to guide specific target code regions. When facing known high-risk code, patch-related code, or the location of vulnerabilities to be verified, it is prone to problems such as scattered testing resources, low target reach efficiency, and slow vulnerability triggering speed.

[0004] To improve the efficiency of testing at specified target locations, researchers have proposed a directional fuzzy testing technique. This technique typically combines static analysis information of the program to calculate the distance from the program's location to the target location, and uses this distance to guide seed scheduling and energy allocation. However, most existing methods rely on structural information in the control flow graph or call graph for distance calculation, making it difficult to accurately characterize the real impact of complex control flows, loop structures, and cross-process paths on target reachability, resulting in limited guidance effectiveness.

[0005] Furthermore, when the target path contains complex constraints, relying solely on random mutation often fails to quickly construct inputs that satisfy the conditions. Although some methods introduce symbolic execution to enhance path solving capabilities, existing schemes combining fuzzing and symbolic execution generally suffer from problems such as excessive symbolization scope, high execution overhead, and insufficient coordination with testing, easily generating a large amount of redundant overhead unrelated to the target. Therefore, there is an urgent need for a vulnerability discovery method that targets the code region and possesses both precise guidance capabilities and efficient coordination mechanisms. Summary of the Invention

[0006] The purpose of this invention is to address the problems in existing targeted fuzzing methods, such as inaccurate target distance modeling, low efficiency in reaching target code under complex path conditions, and insufficient coordination between fuzzing and hybrid execution, which limits vulnerability discovery efficiency. This invention proposes a hybrid targeted fuzzing method and system for target code regions. This method can improve the efficiency of test cases reaching target code locations, enhance the ability to explore complex constrained paths, and improve the triggering efficiency of target-related vulnerabilities and the overall vulnerability discovery efficiency, while ensuring controllable testing overhead.

[0007] The specific technical solution of this invention is as follows:

[0008] The directional fuzz testing method based on selective hybrid execution and fine-grained distance calculation includes the following steps:

[0009] S1. Target-Related Code Segment Extraction: Static analysis is performed on the program under test to construct its control flow graph and call graph, and the indirect call relationships are analyzed to obtain relatively complete cross-process control flow information and extract data dependencies in the program under test. Based on the control flow relationships and data dependencies, control flow-related basic blocks that can affect the target code's arrival and data flow-related basic blocks that can affect the vulnerability triggering state are identified. Using the control flow-related basic blocks and data flow-related basic blocks as target-related code segments, a hybrid execution compiler is used to selectively instrument the program under test, generating a program under test that has been selectively instrumented by hybrid execution.

[0010] S2. Calculate probability-based fine-grained distance: Extract conflicting basic blocks with cyclic dependencies or back-edge relationships from the control flow graph, and construct corresponding conflict trees with each conflicting basic block as the root node. Combine multiple conflict trees to form a conflict forest. Perform static analysis on each conflict tree to determine the probability contribution of leaf nodes and the dependencies between conflicting basic blocks, and construct a system of linear equations accordingly. Obtain the target reachability probability of each conflicting basic block by solving the system of linear equations, and recursively calculate the reachability probability of other basic blocks after eliminating cyclic dependencies. Convert the reachability probabilities into distance values ​​according to a preset mapping rule to form fine-grained distance information for subsequent seed scheduling and target guidance.

[0011] S3. Perform fuzz testing: Before the test begins, initialize the global variables, shared variables, queue state, and runtime parameters required for fuzz testing, and create a subprocess to handle the seeds that need to be mixed for execution. During the fuzz testing mutation phase, copy the seeds that need to be mixed for execution to the shared memory area, and notify the mixed execution module to perform a round of mixed execution through a synchronization mechanism. After receiving the signal, the mixed execution module reads the corresponding seed file from the shared memory pool, performs mixed execution analysis on it, and generates new test cases. The test cases generated by fuzz testing and the test cases generated by mixed execution are submitted to the processing queue. The fuzz testing engine filters the test cases based on coverage feedback, distance feedback, and execution results, and saves important test cases with new coverage, target proximity, or continued exploration value to the seed queue for the next round of fuzz testing.

[0012] In a preferred embodiment, step S1, the identification of control flow-related basic blocks and data flow-related basic blocks, includes: based on the control flow graph and call graph, analyzing the basic blocks and cross-function call points that can reach the target basic block, starting from the target basic block, and marking them as control flow-related basic blocks; based on variable definition relationships and usage relationships, performing forward dependency analysis and backward dependency analysis starting from the relevant variables in the target basic block, and marking the basic blocks that can affect the execution state of the target basic block or are affected by the execution result of the target basic block as data flow-related basic blocks;

[0013] A control flow dependent basic block is a basic block located on any potential control flow path leading to a target basic block. Formally, let... Indicates from basic blocks Departure, after passing through If the set of basic blocks reachable within a control flow edge is given, then the set of control flow dependent basic blocks is defined as follows:

[0014] ,

[0015] As long as a certain basic block If the successor reachable set contains at least one target basic block, then the basic block... That is to belong to Retain all basic blocks that may affect the program's progress toward the target execution path for subsequent instrumentation.

[0016] For cross-process control dependencies, if the function It contains a call point that invokes the called function. ,and There exists belonging to The basic blocks, then The corresponding call point basic block is also marked as a control flow dependency basic block, and its definition is as follows:

[0017] ,

[0018] This propagation mechanism enables the capture of control dependencies across multiple functions, thereby preserving all cross-process paths leading to the target.

[0019] For cross-process data dependencies, the analysis is further extended to function parameters, pointer dereferences, and return values.

[0020] set up For a set of program variables, Given the set of basic blocks, for any basic block Define its variable definition set as The variable uses a set as Furthermore, define data dependencies. for:

[0021] ,

[0022] The above relationship means: if a certain variable In basic blocks Defined in, and in the basic block If used in, then This establishes a data dependency relationship, and its transitive closure can be obtained by recursively applying this relationship. , used to characterize indirect dependencies formed through intermediate variables or intermediate definitions;

[0023] Based on this, from the target basic block The starting point defines its data flow dependency closure as follows:

[0024] ,

[0025] Among them, conditions This represents all elements that affect the target basic block. The basic block, i.e., backward dependency; condition Indicates all objects affected by the target basic block. The affected basic blocks, i.e., forward dependencies, are defined as the set of global data flow dependent basic blocks for all target basic blocks:

[0026] ,

[0027] The formal definition above provides a unified representation of the data flow relationships in the program, which can be understood as a static approximate model of taint propagation, that is, it covers both backward dependency chains and forward dependency chains within the program scope.

[0028] In a preferred embodiment, in step S1, selective instrumentation includes: merging control flow-related basic blocks and data flow-related basic blocks into target-related code segments; inserting symbolic logic, constraint recording logic, and runtime auxiliary logic required for hybrid execution only into the target-related code segments through a hybrid execution compiler; and maintaining specific execution for target-independent code segments to reduce the overhead of constructing unrelated path constraints and hybrid execution.

[0029] In a preferred embodiment, step S2, the extraction of conflicting basic blocks includes: traversing the basic blocks and their successor relationships in the control flow graph, determining whether the basic block can reach itself again through one or more control flow edges; if it can reach itself again, the basic block is marked as a conflicting basic block, which is used to probabilistically model the circular dependencies generated by loops, back edges or unstructured jumps.

[0030] The program under test is first represented as a control flow graph consisting of basic blocks and control flow edges. Let... Represents the target basic block set. Indicates from basic blocks Departure, after passing no more than The set of basic blocks reachable after a control flow edge, wherein If a basic block can be reached again through one or more control flow transitions, it means that the basic block is located in a circular structure or a back edge structure. To handle this type of circular dependency, the set of conflicting basic blocks is defined as follows:

[0031] ,

[0032] in, Represents the set of all conflicting basic blocks, for those belonging to The reachability probability of the target of the basic blocks cannot be directly calculated by simply following the recursive method in the acyclic graph, otherwise circular dependencies will be generated. Therefore, the conflicting basic blocks are processed separately first, and then the remaining acyclic parts are recursively probabilistically propagated.

[0033] For each conflicting basic block , construct Conflict tree with root node The conflict tree is used to represent the conflicting basic blocks. The path of a basic block that can be reached when propagating forward along the control flow from the starting point until a leaf node is reached. If a certain basic block... There is no successor basic block, or Belongs to a predefined set of basic probability blocks, or If a node belongs to the set of conflicting basic blocks again, then that basic block is treated as a leaf node in the conflict tree. The set of leaf nodes is defined as follows:

[0034] ,

[0035] in, This represents the set of basic blocks whose probability values ​​can be directly determined; this set mainly includes the target set of basic blocks. and the basic block set of call points Its definition is as follows:

[0036] ,

[0037] For the target basic block Its target reachability probability is defined as This indicates that the basic block has reached the target location; for a terminating basic block that cannot reach the target, its target reachability probability is defined as... For call point basic blocks Its probability is determined by the probability of the entry basic block of the called function, and the target position, termination position and cross-function call position are uniformly included in the probability propagation framework;

[0038] In the conflict tree In the middle, set Representing basic blocks The number of successor basic blocks, Representing basic blocks At the level of the conflict tree, This represents the least common multiple of the number of successors of all basic blocks at this level, for leaf nodes in the conflict tree. Its leaf coefficient is denoted as This is used to indicate the relationship between the leaf node and the root node. The probability contributions of all leaf nodes can be represented by the following vector:

[0039] ,

[0040] At the same time, set up a conflict tree The normalization coefficient of the root node is It is used to uniformly normalize the probability coefficients generated during propagation at different levels. Representing a conflict tree The maximum depth is then:

[0041] ,

[0042] Using the leaf coefficients and root node normalization coefficients mentioned above, the probability contribution of each leaf node to the root node in each conflict tree can be represented as a linear relationship. Since different conflicting basic blocks may be interdependent, all conflicting trees together form a conflict forest, denoted as:

[0043] ,

[0044] Based on this conflict forest, a global system of linear equations can be established:

[0045] ,

[0046] in, This represents the reachability probability vector of all conflicting basic blocks. This represents the probability dependency matrix between conflicting basic blocks generated by the cyclic structure. This represents the constant term contributed by the target basic block, the terminating basic block, and the predefined probability basic block. By solving this system of linear equations, the target reachability probability of each conflicting basic block can be obtained, enabling consistent and fine-grained modeling of the target reachability of basic blocks in the presence of loops, back edges, or unstructured jumps.

[0047] In a preferred embodiment, step S2, the conflict tree construction includes: using a conflict basic block as the root node, expanding the reachable path along the subsequent direction of the control flow; stopping the expansion when the path reaches a basic block without a successor, a predefined probability basic block, or another conflict basic block; using the basic block that has stopped expanding as a leaf node, and recording the contribution relationship of the leaf node to the reachability probability of the root node's target; multiple conflict trees together constitute a conflict forest.

[0048] In a preferred embodiment, step S2, the construction of the linear equation system includes: performing static analysis on each conflict tree and calculating the probability contribution coefficient of the leaf node to the root node; forming a coefficient matrix based on the dependency relationship between different conflict basic blocks; and using the known probabilities corresponding to the target basic block, the termination basic block, and the predefined probability basic block as constant terms to construct a linear equation system for solving the reachability probability of the target of the conflict basic block.

[0049] In a preferred embodiment, step S2, recursive probability propagation includes: after obtaining the target reachability probability of the conflicting basic block, using the conflicting basic block probability as a known value; for basic blocks without circular dependencies, performing recursive propagation based on the target reachability probability of their direct successor basic blocks; for call point basic blocks, updating the target reachability probability of the call point basic block based on the target reachability probability of the called function entry basic block.

[0050] After solving for the probabilities of conflicting basic blocks, the remaining control flow graph can be considered as an acyclic structure, and the reachability probability of general basic blocks can be calculated recursively. Let... Representing basic blocks The probability of reaching any target basic block, for any basic block The probability calculation rules are defined as follows:

[0051] ,

[0052] in, Representing basic blocks A fixed constant probability value, when If the block belongs to the target block, the call point block, or the conflicting block, its predefined or solved probability value is used directly; otherwise, the block... The probability of a is obtained by averaging the probabilities of all its direct successor basic blocks;

[0053] For cross-function call relationships, probability propagation is performed on the call graph. Let the function... There is a call point in it. Its calling function Then the probability of the basic block of the call point is determined by the called function. The probability of the entry basic block is determined, that is:

[0054] ,

[0055] This definition allows the probability of control flow within a function and the probability of calls between functions to be unified into the same computational framework.

[0056] After obtaining the reachability probability of the basic block, the probability value is further converted into a distance value so that it can be combined with the seed scheduling and energy allocation mechanism in directional fuzz testing for any basic block. Its distance The definition is as follows:

[0057] ,

[0058] Among them, when When, it represents a basic block. Since it is already a target basic block or equivalent to a target location, its distance is defined as... ;when When this condition is met, it indicates that the basic block cannot reach the target location, so its distance is set to the maximum value in the implementation. ;when When the distance is defined as the reciprocal of the probability, this definition ensures a monotonic correspondence between the target reachability probability and the distance. That is, the higher the reachability probability, the smaller the distance; the lower the reachability probability, the larger the distance. This characteristic meets the requirement of using distance information to guide the test input to gradually approach the target code in directional fuzzy testing.

[0059] Functional distance It can be represented by the distance to the basic block at the function entry point, that is:

[0060] ,

[0061] During fuzz testing, for a given test input, the execution path may traverse multiple functions and multiple basic blocks. If the test input... The set of functions traversed during a single execution is: Then its input-level distance can be expressed as:

[0062] ,

[0063] Therefore, test inputs with smaller distance values ​​indicate that their execution paths are closer to the target code region overall, and the fuzzing engine can prioritize the mutation and scheduling of such inputs in subsequent tests; test inputs with larger distance values ​​indicate that they are relatively far from the target code region, and their scheduling priority can be reduced accordingly.

[0064] In a preferred embodiment, the synchronization mechanism in step S3 includes: creating a shared memory region and initializing synchronization variables or semaphores before the test begins; during the fuzz test mutation phase, the fuzz test engine writes the seeds that need to be mixed-executed into the shared memory region and notifies the mixed-execution module through synchronization variables or semaphores; after receiving the notification, the mixed-execution module reads the seed file in the shared memory and performs mixed-execution to generate new test cases.

[0065] In a preferred embodiment, the information interaction between fuzz testing and hybrid execution in step S3 includes: the fuzz testing engine and the hybrid execution module sharing seed status, coverage feedback, distance feedback, and execution results; test cases generated by hybrid execution and test cases generated by fuzz testing mutation are submitted to a unified processing queue, and the fuzz testing engine filters them based on global coverage information, target distance information, and execution results, saving test cases with new coverage, target proximity, or continued exploration value to the seed queue.

[0066] A targeted fuzzing system based on selective hybrid execution and fine-grained distance calculation is used to execute the targeted fuzzing method. It includes a static analyzer, a symbolic compiler, a fuzzing compiler, and a fuzzing engine. The system performs static analysis on the program under test, constructing a control flow graph and a call graph, analyzing indirect call relationships, and extracting data dependencies. Based on control flow relationships and data dependencies, it identifies control flow-related basic blocks affecting the reachability of the target code and data flow-related basic blocks affecting the vulnerability triggering state. The hybrid execution compiler selectively instrumentes these basic blocks, generating the program under test with selective hybrid execution instrumentation. The system extracts conflicting basic blocks from the control flow graph, constructs conflict trees and conflict forests, and solves for the target reachability probability of conflicting basic blocks using a system of linear equations. Based on this, it recursively calculates the reachability probability of other basic blocks and converts it into fine-grained distance information. During testing, the system initializes shared variables and runtime state, writes the seeds requiring hybrid execution into shared memory, and notifies the hybrid execution module to generate test cases. Subsequently, the fuzzing engine uniformly filters the test cases generated by fuzzing and hybrid execution, and saves important test cases to a seed queue for the next round of testing.

[0067] The core technical principle of this invention is a directional fuzzing method based on selective hybrid execution and fine-grained distance calculation. It is implemented using software such as a static analyzer, a symbolic compiler, a fuzzing compiler, and a fuzzing engine. First, key program information is extracted through static analysis. The static analyzer receives the source code of the program under test, the target code location information, and the intermediate compilation representation, and performs control flow analysis, call relationship analysis, and target relevance analysis on the program. First, starting from the function containing the target basic block, all call chains that can reach the target function are searched backward along the call graph, extracting a set of key functions related to the reachability of the target code. Further, within the scope of the key functions, the target basic block and the call point basic blocks that call the key and target functions are identified as initial reference nodes for subsequent analysis. Then, based on the control flow graph analysis of the relevant basic blocks in the program that can reach the reference nodes, a target-related code region is constructed. Finally, within the target-related code region, combining the reachability relationships between basic blocks, cross-procedure call relationships, and path propagation characteristics, fine-grained distance values ​​from each basic block to the target code are calculated, and key code segment information and distance information are output. The key code segment information is used to limit the scope of symbolization processing, and the distance information is used for seed scheduling, energy allocation and target guidance in the subsequent fuzzing process.

[0068] Secondly, selective symbolic compilation is performed. The symbolic compiler selectively performs symbolic compilation on the program under test based on the key code segment information output by the static analyzer. Specifically, symbolic logic is inserted only into key basic blocks, key branch conditions, key comparison operations, and program statements on the propagation chain of related input variables that are related to the target code's arrival and vulnerability triggering process. This allows the target-related path conditions to be extracted and solved at runtime. For code regions that are unrelated to the target or contribute little to the arrival of the target, their original execution mode is maintained.

[0069] Next, the fuzzing compiler performs instrumentation compilation on the program under test based on the fine-grained distance information generated by the static analyzer. The system inserts runtime monitoring logic at the relevant basic blocks, edges, or branches of the program to record the coverage path of the test input, path hit status, and corresponding distance value changes during execution. Simultaneously, it maps the distance values ​​of each basic block to runtime-accessible data structures, enabling the fuzzing engine to obtain the proximity between the current input and the target code in real time. In addition, runtime support code required for fuzzing is inserted during the compilation phase, including shared memory data structures, execution status recording variables, seed scheduling auxiliary variables, distance feedback variables, and communication interfaces required for hybrid execution coordination.

[0070] Finally, in the hybrid execution process, the fuzzing engine loads the program under test after symbolic compilation and fuzzing instrumentation, and begins iterative testing with the initial seed set as input. During testing, the fuzzing engine first selects and mutates the seeds, generating candidate test cases and driving program execution. After each round of execution, it obtains the coverage information, path hit status, and distance changes related to the target code based on runtime feedback, and evaluates the proximity of the current input to the target code accordingly. For test inputs that can shorten the target distance, cover critical code regions, or show high potential, the fuzzing engine increases their scheduling priority and allocates more mutation energy to guide subsequent tests towards convergence towards the target code region. When it is detected that some inputs are blocked at critical branches for a long time and it is difficult to continue to approach the target by random mutation alone, the fuzzing engine triggers the hybrid execution module to solve the relevant critical path conditions, generate new test cases that meet the constraints, and add them back to the fuzzing queue for continued execution.

[0071] Beneficial effects:

[0072] 1) By combining selective hybrid execution with targeted fuzzing, this invention can more efficiently guide test input to approach the target code region, thereby improving the efficiency of discovering target-related vulnerabilities.

[0073] 2) This invention can trigger abnormal behaviors under multiple different execution paths corresponding to the same vulnerability, thereby generating diverse vulnerability trigger samples, providing support for subsequent vulnerability exploitation analysis, cause location and remediation verification.

[0074] 3) This invention employs a fine-grained distance calculation method, which can more accurately characterize the proximity between the program location and the target code, and has better guidance effect and performance compared with existing distance calculation methods.

[0075] 4) This invention constructs a highly integrated hybrid execution collaboration mechanism, enabling runtime resource sharing and test information sharing between the hybrid executor and the fuzz tester, and reducing additional overhead by reusing the test framework and execution process, thereby improving overall test efficiency. Attached Figure Description

[0076] Figure 1 This is a schematic diagram of the overall system architecture and operation of the present invention.

[0077] Figure 2 This is a schematic diagram of the process of the present invention.

[0078] Figure 3 This is a schematic diagram of the fuzz testing engine of the present invention. Detailed Implementation

[0079] The embodiments of the present invention will be described in detail below with reference to the accompanying drawings: The present invention is implemented based on the technical solution of this embodiment, and detailed implementation methods and specific operation processes are given, but the protection scope of the present invention is not limited to the following embodiments.

[0080] Example 1: System Architecture:

[0081] like Figure 1 As shown, this embodiment proposes a directional fuzzy testing system based on selective hybrid execution and fine-grained distance calculation. This system mainly comprises the following two core entities:

[0082] 1. Static Analysis and Compiler: The static analysis and compiler is the front-end analysis and construction module of the test system in this embodiment. Its main function is to perform static program analysis on the program under test based on the target code location given by the user, and generate the analysis results and executable program required for subsequent fuzzing. In addition, the static analysis and compiler includes a symbolic compilation submodule and a fuzzing compilation submodule. The symbolic compilation submodule performs selective symbolic processing on the program under test based on key code segment information, inserting mixed execution logic only on program statements, variables and constraint points closely related to target arrival and vulnerability triggering, so as to reduce path explosion and runtime overhead caused by full symbolication; the fuzzing compilation submodule inserts runtime code such as coverage feedback, distance feedback, state sharing and scheduling support into the program based on distance information and runtime cooperation requirements, so that the generated target program can simultaneously support coverage feedback, target distance feedback and collaborative interaction with the mixed execution module.

[0083] 2. Hybrid Execution Engine: The hybrid execution engine is the core of the test system in this embodiment. Its main function is to perform targeted fuzz testing on the target program after static analysis and compilation during the testing phase, and to trigger the hybrid execution module to solve the critical path conditions when necessary, so as to improve the efficiency of the target code and the vulnerability triggering capability.

[0084] Example 2: Fuzzy Testing Method Flow:

[0085] like Figure 2 As shown, the method flow of this embodiment covers the entire testing process from obtaining the source code of the program under test to fuzz testing, specifically including the following steps:

[0086] S1. Extraction of target-related code segments:

[0087] Hybrid execution enables precise reasoning about path constraints, but its effectiveness in hybrid targeted fuzzing largely depends on which program regions symbolic reasoning is applied to. Unrestricted symbolic instrumentation often leads to a large number of test cases irrelevant to the target. To address this issue, this embodiment proposes a selective symbolic instrumentation module that constrains hybrid execution to semantically relevant program regions. This module utilizes static control flow dependency analysis and data flow dependency analysis to identify fundamental blocks and functions that directly affect target reachability or vulnerability triggering. By applying symbolic instrumentation only to these regions, the overhead of hybrid execution can be significantly reduced while ensuring that symbolic exploration makes a real contribution to targeted fuzzing.

[0088] To reduce the overhead of mixed execution and improve the relevance of generated test cases to the target, this embodiment performs selective compile-time instrumentation during the SymCC compilation phase. Unlike a method that uniformly instrumentes all basic blocks, this embodiment combines control flow dependency analysis and data flow dependency analysis to perform symbolic instrumentation only on basic blocks that are semantically relevant to the target, while omitting symbolic processing on basic blocks unrelated to the target. Therefore, the symbolic exploration process primarily focuses on execution paths that contribute to reaching the target or triggering the target vulnerability.

[0089] A control flow dependent basic block is a basic block located on any potential control flow path leading to the target basic block. Formally, let... Indicates from basic blocks Departure, after passing through If the set of basic blocks reachable within a control flow edge is given, then the set of control flow dependent basic blocks is defined as follows:

[0090] ,

[0091] As long as a certain basic block If the successor reachable set contains at least one target basic block, then the basic block... That is to belong to By using the above definition, all basic blocks that may affect the program's progress toward the target execution path can be retained for subsequent instrumentation.

[0092] For cross-process control dependencies, this embodiment further extends the above definition beyond function boundaries. If the function It contains a call point that invokes the called function. ,and There exists belonging to The basic blocks, then The corresponding call point basic block is also marked as a control flow dependency basic block, and its definition is as follows:

[0093] ,

[0094] This propagation mechanism enables the capture of control dependencies across multiple functions, thereby preserving all cross-process paths leading to the target.

[0095] Control flow dependencies help test whether input reaches the target code, while data flow dependencies help trigger actual vulnerabilities after reaching the target. Therefore, this embodiment identifies data flow dependent basic blocks based on the read / write relationships of variables related to the target basic block. For cross-procedure data dependencies, the analysis is further extended to function parameters, pointer dereferences, and return values.

[0096] set up For a set of program variables, For any basic block, ... Define its variable definition set as The variable uses a set as Furthermore, define data dependencies. for:

[0097] ,

[0098] The above relationship means: if a certain variable In basic blocks Defined in, and in the basic block If used in, then This establishes a data dependency. By recursively applying this dependency, its transitive closure can be obtained. , is used to characterize indirect dependencies formed through intermediate variables or intermediate definitions.

[0099] Based on this, from the target basic block The starting point defines its data flow dependency closure as follows:

[0100] ,

[0101] Among them, conditions This represents all elements that affect the target basic block. The basic block, i.e., backward dependency; condition Indicates all objects affected by the target basic block. The affected basic blocks, i.e., forward dependencies. For all target basic blocks, the set of global data flow dependent basic blocks is defined as follows:

[0102] ,

[0103] The formal definition above provides a unified representation of the data flow relationships in the program, which can be understood as a static approximate model of taint propagation, that is, it covers both backward dependency chains and forward dependency chains within the program scope.

[0104] S2, Fine-grained probability-based distance calculation

[0105] This step proposes a fine-grained, probabilistic distance calculation method to measure the reachability probability of each basic block in a program to a target basic block, and further converts this probability into a distance value that can be used for directional fuzzy test scheduling. Unlike traditional distance measurement methods based on control flow graph or call graph structures, this embodiment does not directly use path length as the sole basis for target proximity. Instead, it characterizes the probability of the program continuing execution from the current basic block and eventually reaching the target basic block through probability propagation. Therefore, it can more precisely reflect the impact of branching structures, loop structures, and cross-function call relationships on target reachability.

[0106] In this embodiment, the program under test is first represented as a control flow graph consisting of basic blocks and control flow edges. Let... Represents the target basic block set. Indicates from basic blocks Departure, after passing no more than The set of basic blocks reachable after a control flow edge, wherein If a basic block can be reached again through one or more control flow transitions, it indicates that the basic block is located in a circular structure or a back-edge structure. To handle this type of circular dependency, this embodiment defines the following set of conflicting basic blocks:

[0107] ,

[0108] in, This represents the set of all conflicting basic blocks. For those belonging to... The reachability probability of the target basic blocks cannot be directly calculated using the recursive method in acyclic graphs, otherwise circular dependencies will occur. Therefore, this embodiment first processes the conflicting basic blocks separately, and then performs recursive probability propagation on the remaining acyclic parts.

[0109] For each conflicting basic block This embodiment is constructed based on Conflict tree with root node This conflict tree is used to represent the conflicting basic blocks. The path forward along the control flow from the starting point can reach any basic block, until a leaf node is reached. If a certain basic block... There is no successor basic block, or Belongs to a predefined set of basic probability blocks, or If a node belongs to the set of conflicting basic blocks again, then that basic block is designated as a leaf node in the conflict tree. The set of leaf nodes is defined as follows:

[0110] ,

[0111] in, This represents the set of basic blocks whose probability values ​​can be directly determined. This set primarily includes the target set of basic blocks. and the basic block set of call points Its definition is as follows:

[0112] ,

[0113] For the target basic block Its target reachability probability is defined as This indicates that the basic block has reached the target location; for a terminating basic block that cannot reach the target, its target reachability probability is defined as... For call point basic blocks The probability is determined by the probability of the entry block of the called function. In this way, the target position, termination position, and cross-function call position can be uniformly incorporated into the probability propagation framework.

[0114] In the conflict tree In the middle, set Representing basic blocks The number of successor basic blocks, Representing basic blocks At the level of the conflict tree, This represents the least common multiple of the number of successors of all basic blocks at this level. For leaf nodes in the conflict tree... Its leaf coefficient is denoted as This is used to indicate the relationship between the leaf node and the root node. The probability contribution of all leaf nodes. The coefficients of all leaf nodes can be formed into the following vector:

[0115] ,

[0116] At the same time, set up a conflict tree The normalization coefficient of the root node is It is used to uniformly normalize the probability coefficients generated during propagation at different levels. If Representing a conflict tree The maximum depth is then:

[0117] ,

[0118] Using the leaf coefficients and root node normalization coefficients described above, the probability contribution of each leaf node to the root node in each conflict tree can be expressed as a linear relationship. Since different conflicting basic blocks may be interdependent, all conflicting trees together form a conflict forest, denoted as:

[0119] ,

[0120] Based on this conflict forest, a global system of linear equations can be established:

[0121] ,

[0122] in, This represents the reachability probability vector of all conflicting basic blocks. This represents the probability dependency matrix between conflicting basic blocks generated by the cyclic structure. This represents the constant term contributed by the target basic block, the terminating basic block, and the predefined probability basic blocks. By solving this system of linear equations, the target reachability probability of each conflicting basic block can be obtained. Thus, this embodiment can perform consistent and fine-grained modeling of the target reachability of basic blocks in the presence of cycles, back edges, or unstructured jumps.

[0123] After solving for the probability of conflicting basic blocks, the remaining control flow graph can be considered as an acyclic structure, and the goal reachability probability of general basic blocks can be calculated recursively. Let... Representing basic blocks The probability of reaching any target basic block. For any basic block The probability calculation rules are defined as follows:

[0124] ,

[0125] in, Representing basic blocks A fixed constant probability value. When If the block belongs to the target block, the call point block, or the conflicting block, its predefined or solved probability value is used directly; otherwise, the block... The probability of a target being reached is obtained by averaging the probabilities of all its direct successor basic blocks. This calculation method means that, in the absence of additional dynamic execution information, the probability of a program moving from the current basic block to each successor basic block is considered to be the same. Therefore, the probability of the current basic block reaching the target can be obtained by aggregating the target reachability probabilities of its successor basic blocks.

[0126] For cross-function call relationships, this embodiment further performs probability propagation on the call graph. Let the function... There is a call point in it. Its calling function The probability of the basic block at that call point is determined by the called function. The probability of the entry basic block is determined, that is:

[0127] ,

[0128] This definition unifies the control flow probability within a function and the inter-function call probability into a single computational framework. Specifically, the probability is first calculated for functions directly containing the target basic block, and then propagated along the reverse call graph to their caller functions. If a function can eventually reach the target function through the call chain, the probability of the relevant call points within that function is updated based on the probability of the entry basic block of the called function, thus further influencing the probabilities of other basic blocks within the caller function. This process continues until all functions and basic blocks that can reach the target basic block obtain their corresponding target reachability probabilities.

[0129] After obtaining the target reachability probability of the basic block, this embodiment further converts the probability value into a distance value to integrate with the seed scheduling and energy allocation mechanisms in oriented fuzzy testing. For any basic block... Its distance The definition is as follows:

[0130] ,

[0131] Among them, when When, it represents a basic block. Since it is already a target basic block or equivalent to a target location, its distance is defined as... ;when When this condition is met, it indicates that the basic block cannot reach the target location, so its distance is set to the maximum value in the implementation. ;when When the probability of reaching a target is 1, the distance is defined as the reciprocal of the probability. This definition ensures a monotonic correspondence between the probability of reaching the target and the distance; that is, the higher the probability of reaching the target, the smaller the distance, and vice versa. This characteristic aligns with the requirement in directional fuzzy testing to use distance information to guide the test input gradually closer to the target code.

[0132] Furthermore, function-level distance It can be represented by the distance to the basic block at the function entry point, that is:

[0133] ,

[0134] During fuzzing, for a given test input, its execution path may traverse multiple functions and basic blocks. To measure the overall proximity of the test input to the target code, this embodiment calculates the input-level distance based on the distances between the functions or basic blocks traversed during execution. Following the distance aggregation concept in directed fuzzing, the input-level distance can be obtained by averaging the distances between related functions or basic blocks along its execution path. If the test input... The set of functions traversed during a single execution is: Then its input-level distance can be expressed as:

[0135] ,

[0136] Therefore, test inputs with smaller distance values ​​indicate that their execution paths are generally closer to the target code region, and the fuzzing engine can prioritize such inputs for mutation and scheduling in subsequent tests. Test inputs with larger distance values ​​indicate that they are relatively far from the target code region, and their scheduling priority can be reduced accordingly. Through the above-described fine-grained probability-based distance calculation method, this embodiment can establish unified target guidance information for each basic block, function, and test input during the static analysis phase, thereby providing a basis for seed selection, energy allocation, and path exploration in the subsequent fuzzing process.

[0137] S3, Fuzzy Test

[0138] like Figure 3 As shown, after preprocessing is completed, the system begins the fuzzing process. First, in the fuzzing initialization phase, the system initializes the shared variables, state variables, queue variables, and key runtime parameters required for fuzzing, and creates a subprocess to handle the seeds to be mixed execution, thus establishing a collaborative environment between the fuzzing engine and the mixed execution module.

[0139] During the fuzzing execution phase, the fuzzing engine selects test cases from the seed queue according to the seed scheduling strategy and performs mutation operations on them to generate new candidate test cases. For seeds that require further hybrid execution, the fuzzing engine copies them to the shared memory region and notifies the hybrid execution module to start a round of hybrid execution via a synchronization signal. Upon receiving the notification, the hybrid execution module reads the corresponding seed file from the shared memory pool and performs hybrid execution analysis based on the seed to generate new test cases.

[0140] Subsequently, test cases generated by fuzzing mutations and those generated by the hybrid execution module are submitted to a unified processing queue for screening. The fuzzing engine assesses the validity and priority of test cases in the queue based on coverage feedback, target distance feedback, and test case execution results. Important test cases that generate new coverage, shorten target distance, traverse target-related code regions, or have further exploration value are saved in a seed queue for subsequent rounds of fuzzing. Test cases with high repetition, weak target relevance, or lacking further exploration value are not saved as priority seeds, thereby reducing redundant testing overhead and improving fuzzing efficiency.

[0141] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A directional fuzzy testing method based on selective hybrid execution and fine-grained distance calculation, characterized in that, Includes the following steps: S1. Extraction of target-related code segments: Perform static analysis on the program under test, construct the control flow graph and call graph of the program under test, analyze the indirect call relationships in them to obtain more complete cross-process control flow information, and extract the data dependencies in the program under test. Based on control flow relationships and data dependencies, identify control flow-related basic blocks that can affect the arrival of the target code, as well as data flow-related basic blocks that can affect the vulnerability triggering state; Using control flow-related basic blocks and data flow-related basic blocks as target-related code segments, the mixed execution compiler selectively instrumentes the program under test, generating a program under test that is selectively instrumented by mixed execution. S2. Calculate the fine-grained distance based on probability: Extract conflicting basic blocks with cyclic dependencies or back edge relationships from the control flow graph, and construct the corresponding conflict tree with each conflicting basic block as the root node. Combine multiple conflict trees to form a conflict forest. Static analysis is performed on each conflict tree to determine the probability contribution of leaf nodes and the dependencies between conflicting basic blocks, and a system of linear equations is constructed accordingly. The reachability probability of each conflicting basic block is obtained by solving the system of linear equations, and the reachability probability of other basic blocks is recursively calculated after eliminating circular dependencies. The reachability probabilities are converted into distance values ​​according to a preset mapping rule to form fine-grained distance information for subsequent seed scheduling and target guidance. S3. Perform fuzz testing: Before the test begins, initialize the global variables, shared variables, queue state, and runtime parameters required for fuzz testing, and create a child process to handle the seeds that need to be mixed for execution; during the fuzz testing mutation phase, copy the seeds that need to be mixed for execution to the shared memory area, and notify the mixed execution module to perform a round of mixed execution through the synchronization mechanism; after receiving the signal, the mixed execution module reads the corresponding seed file from the shared memory pool, performs mixed execution analysis on it, and generates new test cases; Both test cases generated by fuzzing and test cases generated by hybrid execution are submitted to the processing queue. The fuzzing engine filters test cases based on coverage feedback, distance feedback, and execution results, and saves important test cases with new coverage, target proximity, or value for further exploration to the seed queue for use in the next round of fuzzing.

2. The directional fuzzy testing method based on selective hybrid execution and fine-grained distance calculation according to claim 1, characterized in that, In step S1, the identification of control flow-related basic blocks and data flow-related basic blocks includes: based on the control flow graph and call graph, analyzing the basic blocks and cross-function call points that can reach the target basic block, starting from the target basic block, and marking them as control flow-related basic blocks; based on variable definition relationships and usage relationships, performing forward dependency analysis and backward dependency analysis starting from the relevant variables in the target basic block, and marking the basic blocks that can affect the execution state of the target basic block or are affected by the execution result of the target basic block as data flow-related basic blocks; A control flow dependent basic block is a basic block located on any potential control flow path leading to a target basic block. Formally, let... Indicates from basic blocks Departure, after passing through If the set of basic blocks reachable within a control flow edge is given, then the set of control flow dependent basic blocks is defined as follows: ， As long as a certain basic block If the successor reachable set contains at least one target basic block, then the basic block... That is to belong to Retain all basic blocks that may affect the program's progress toward the target execution path for subsequent instrumentation; For cross-process control dependencies, if the function It contains a call point that invokes the called function. ,and There exists belonging to The basic blocks, then The corresponding call point basic block is also marked as a control flow dependency basic block, and its definition is as follows: ， This propagation mechanism enables the capture of control dependencies across multiple functions, thereby preserving all cross-process paths leading to the target. For cross-process data dependencies, the analysis is further extended to function parameters, pointer dereferences, and return values. set up For a set of program variables, Given the set of basic blocks, for any basic block Define its variable definition set as The variable uses a set as Furthermore, define data dependencies. for: ， The above relationship indicates that if a certain variable In basic blocks Defined in, and in the basic block If used in, then This establishes a data dependency relationship, and its transitive closure can be obtained by recursively applying this relationship. , used to characterize indirect dependencies formed through intermediate variables or intermediate definitions; Based on this, from the target basic block The starting point defines its data flow dependency closure as follows: ， Among them, conditions This indicates all elements that will affect the target basic block. The basic block, i.e., backward dependency; condition Indicates all objects affected by the target basic block. The affected basic blocks, i.e., forward dependencies, are defined as the set of global data flow dependent basic blocks for all target basic blocks: ， The formal definition above provides a unified representation of the data flow relationships in the program, which can be understood as a static approximate model of taint propagation, that is, it covers both backward dependency chains and forward dependency chains within the program scope.

3. The directional fuzzy testing method based on selective hybrid execution and fine-grained distance calculation according to claim 1, characterized in that, In step S1, selective instrumentation includes: merging control flow-related basic blocks and data flow-related basic blocks into target-related code segments; inserting symbolic logic, constraint recording logic, and runtime auxiliary logic required for hybrid execution only into the target-related code segments through the hybrid execution compiler; and maintaining specific execution for target-independent code segments to reduce the overhead of constructing unrelated path constraints and hybrid execution.

4. The directional fuzzy testing method based on selective hybrid execution and fine-grained distance calculation according to claim 1, characterized in that, In step S2, the extraction of conflicting basic blocks includes: traversing the basic blocks and their successor relationships in the control flow graph, determining whether the basic block can reach itself again through one or more control flow edges; if it can reach itself again, the basic block is marked as a conflicting basic block, which is used to probabilistically model the circular dependencies generated by loops, back edges or unstructured jumps. The program under test is first represented as a control flow graph consisting of basic blocks and control flow edges. Let... Represents the target basic block set. Indicates from basic blocks Departure, after passing no more than The set of basic blocks reachable after a control flow edge, wherein If a basic block can be reached again through one or more control flow transitions, it means that the basic block is located in a circular structure or a back edge structure. To handle this type of circular dependency, the set of conflicting basic blocks is defined as follows: ， in, Represents the set of all conflicting basic blocks, for those belonging to The reachability probability of the target of the basic blocks cannot be directly calculated by simply following the recursive method in the acyclic graph, otherwise circular dependencies will be generated. Therefore, the conflicting basic blocks are processed separately first, and then the remaining acyclic parts are recursively probabilistically propagated. For each conflicting basic block , construct Conflict tree with root node This conflict tree is used to represent the conflicting basic blocks. The path of a basic block that can be reached when propagating forward along the control flow from the starting point until a leaf node is reached. If a certain basic block... There is no successor basic block, or Belongs to a predefined set of basic probability blocks, or If a basic block belongs to the set of conflicting basic blocks again, then that basic block is treated as a leaf node in the conflict tree. The set of leaf nodes is defined as follows: ， in, This represents the set of basic blocks whose probability values ​​can be directly determined; this set mainly includes the target set of basic blocks. and the basic block set of call points Its definition is as follows: ， For the target basic block Its target reachability probability is defined as This indicates that the basic block has reached the target location; for a terminating basic block that cannot reach the target, its target reachability probability is defined as... For call point basic blocks Its probability is determined by the probability of the entry basic block of the called function, and the target position, termination position and cross-function call position are uniformly included in the probability propagation framework; In the conflict tree In the middle, set Representing basic blocks The number of successor basic blocks, Representing basic blocks At the level of the conflict tree, This represents the least common multiple of the number of successors of all basic blocks at this level, for leaf nodes in the conflict tree. Its leaf coefficient is denoted as This is used to indicate the relationship between the leaf node and the root node. The probability contributions of all leaf nodes can be represented by the following vector: ， At the same time, set up a conflict tree The normalization coefficient of the root node is It is used to uniformly normalize the probability coefficients generated during propagation at different levels. Representing a conflict tree The maximum depth is then: ， Using the leaf coefficients and root node normalization coefficients mentioned above, the probability contribution of each leaf node to the root node in each conflict tree can be represented as a linear relationship. Since different conflicting basic blocks may be interdependent, all conflicting trees together form a conflict forest, denoted as: ， Based on this conflict forest, a global system of linear equations can be established: ， in, This represents the reachability probability vector of all conflicting basic blocks. This represents the probability dependency matrix between conflicting basic blocks generated by the cyclic structure. This represents the constant term contributed by the target basic block, the terminating basic block, and the predefined probability basic block. By solving this system of linear equations, the target reachability probability of each conflicting basic block can be obtained, enabling consistent and fine-grained modeling of the target reachability of basic blocks in the presence of loops, back edges, or unstructured jumps.

5. The directional fuzzy testing method based on selective hybrid execution and fine-grained distance calculation according to claim 1, characterized in that, In step S2, the conflict tree construction includes: taking the conflict basic block as the root node, expanding the reachable path along the successor direction of the control flow; stopping the expansion when the path reaches a basic block without successors, a predefined probability basic block, or another conflict basic block; taking the basic block that has stopped expanding as a leaf node, and recording the contribution relationship of the leaf node to the reachability probability of the root node's target; multiple conflict trees together constitute a conflict forest.

6. The directional fuzzy testing method based on selective hybrid execution and fine-grained distance calculation according to claim 1, characterized in that, In step S2, the construction of the linear equation system includes: performing static analysis on each conflict tree and calculating the probability contribution coefficient of the leaf node to the root node; forming a coefficient matrix based on the dependency relationship between different conflict basic blocks; and using the known probabilities corresponding to the target basic block, the termination basic block, and the predefined probability basic block as constant terms to construct a linear equation system for solving the reachability probability of the target of the conflict basic block.

7. The directional fuzzy testing method based on selective hybrid execution and fine-grained distance calculation according to claim 1, characterized in that, In step S2, the recursive probability propagation includes: after solving for the target reachability probability of the conflicting basic block, the probability of the conflicting basic block is used as a known value; for basic blocks without circular dependencies, recursive propagation is performed based on the target reachability probability of their direct successor basic blocks; for call point basic blocks, the target reachability probability of the call point basic block is updated based on the target reachability probability of the entry basic block of the called function. After solving for the probabilities of conflicting basic blocks, the remaining control flow graph can be considered as an acyclic structure, and the goal reachability probability of general basic blocks can be calculated recursively. Let... Representing basic blocks The probability of reaching any target basic block, for any basic block The probability calculation rules are defined as follows: ， in, Representing basic blocks A fixed constant probability value, when If the block belongs to the target block, the call point block, or the conflicting block, its predefined or solved probability value is used directly; otherwise, the block... The probability of a is obtained by averaging the probabilities of all its direct successor basic blocks; For cross-function call relationships, probability propagation is performed on the call graph. Let the function... There is a call point in it. Its calling function Then the probability of the basic block of the call point is determined by the called function. The probability of the entry basic block is determined, that is: ， This definition allows the probability of control flow within a function and the probability of calls between functions to be unified into the same computational framework. After obtaining the reachability probability of the basic block, the probability value is further converted into a distance value so that it can be combined with the seed scheduling and energy allocation mechanism in directional fuzz testing for any basic block. Its distance The definition is as follows: ， Among them, when When, it represents a basic block. Since it is already a target basic block or equivalent to a target location, its distance is defined as... ;when When this condition is met, it indicates that the basic block cannot reach the target location, so its distance is set to the maximum value in the implementation. ;when When the distance is defined as the reciprocal of the probability, this definition ensures a monotonic correspondence between the target reachability probability and the distance. That is, the higher the reachability probability, the smaller the distance; the lower the reachability probability, the larger the distance. This characteristic meets the requirement of using distance information to guide the test input to gradually approach the target code in directional fuzzy testing. Functional distance It can be represented by the distance to the basic block at the function entry point, that is: ， During fuzz testing, for a given test input, the execution path may traverse multiple functions and multiple basic blocks. If the test input... The set of functions traversed during a single execution is: Then its input-level distance can be expressed as: ， Therefore, test inputs with smaller distance values ​​indicate that their execution paths are closer to the target code region overall, and the fuzzing engine can prioritize the mutation and scheduling of such inputs in subsequent tests; test inputs with larger distance values ​​indicate that they are relatively far from the target code region, and their scheduling priority can be reduced accordingly.

8. The directional fuzzy testing method based on selective hybrid execution and fine-grained distance calculation according to claim 1, characterized in that, In step S3, the synchronization mechanism includes: creating a shared memory region and initializing synchronization variables or semaphores before the test begins; during the fuzz test mutation phase, the fuzz test engine writes the seeds that need to be mixed-executed into the shared memory region and notifies the mixed-execution module through synchronization variables or semaphores; after receiving the notification, the mixed-execution module reads the seed file in the shared memory and performs mixed-execution to generate new test cases.

9. The directional fuzzy testing method based on selective hybrid execution and fine-grained distance calculation according to claim 1, characterized in that, In step S3, the information interaction between fuzz testing and hybrid execution includes: the fuzz testing engine and the hybrid execution module share seed state, coverage feedback, distance feedback and execution results; the test cases generated by hybrid execution and the test cases generated by fuzz testing mutation are submitted to a unified processing queue, and the fuzz testing engine filters them based on global coverage information, target distance information and execution results, and saves the test cases with new coverage, target proximity or continued exploration value to the seed queue.

10. A directional fuzzy testing system based on selective hybrid execution and fine-grained distance calculation, characterized in that, The system is used to execute the directional fuzz testing method according to any one of claims 1-9, including a static analyzer, a symbolic compiler, a fuzz test compiler, and a fuzz test engine. The system performs static analysis on the program under test, constructs a control flow graph and a call graph, analyzes indirect call relationships, and extracts data dependencies. Based on control flow relationships and data dependencies, we identify control flow-related basic blocks that affect the arrival of the target code and data flow-related basic blocks that affect the vulnerability triggering state. We then selectively instrument these basic blocks using a hybrid execution compiler to generate a test program that is selectively instrumented by hybrid execution. The system extracts conflicting basic blocks from the control flow graph, constructs conflict trees and conflict forests, and solves the reachability probability of the conflicting basic blocks through a system of linear equations. Based on this, it recursively calculates the reachability probability of other basic blocks and converts it into fine-grained distance information. During testing, the system initializes shared variables and runtime state, writes the seeds that need to be mixed-execution into shared memory, and notifies the mixed-execution module to generate test cases. Subsequently, the fuzzing engine uniformly filters the test cases generated by fuzzing and mixed-execution, and saves important test cases to the seed queue for the next round of testing.

Images