A vulnerability cause localization method based on data richness and migration cost perception

Abstract

The application discloses a kind of based on data richness and migration cost perception's vulnerability cause positioning method, purpose is to solve the low accuracy of current vulnerability cause positioning method, slow problem.The technical scheme is first inferred vulnerability collapse related node using the vulnerability collapse related node inference method based on dynamic and static combination;Then the value of vulnerability collapse related node in the running process of test case generated by fuzz testing is monitored using the high-quality test case generation method based on data richness guidance, to increase the data richness of value as guidance to generate high-quality test case, while state transition test case is obtained by screening using the fuzz testing method based on migration cost reduction;Finally, the vulnerability trigger related node ranking is obtained by means of stain analysis, mutual information algorithm and clustering algorithm, and the vulnerability cause is inferred.The application can improve the accuracy of vulnerability cause positioning, improve the positioning speed, so as to realize the rapid and accurate repair of vulnerability.

Description

Technical Field

[0001] This invention relates to the field of software vulnerability cause localization, and specifically to a vulnerability cause localization method based on data richness and migration cost awareness. Background Technology

[0002] With the rapid development of information technology, software, as the core carrier of information processing and interaction, has been widely used in various critical infrastructure fields, including finance, healthcare, transportation, and energy. However, the existence of software vulnerabilities seriously threatens the security, stability, and reliability of information systems, potentially leading to security risks such as data breaches, system crashes, and privilege abuse. Specifically, software vulnerabilities refer to defects or weaknesses in a software system that can be exploited to violate security policies. These vulnerabilities may stem from various errors and oversights during the software development process, such as non-standard coding practices, logical design flaws, improper handling of boundary conditions, and insufficient validation of user input. Attackers can exploit these vulnerabilities to perform malicious operations, such as unauthorized access to the system, privilege escalation, theft of sensitive information, and implantation of malware.

[0003] To quickly and effectively patch vulnerabilities and address the risks they pose, software vulnerability root cause localization techniques have emerged. Software vulnerability root cause localization refers to the process of identifying the root cause or trigger point of a software vulnerability through analysis and research during software development or debugging. Specifically, it focuses on the "source" of the vulnerability—what code logic, input conditions, or environmental factors triggered its occurrence. In contrast, software vulnerability localization emphasizes finding the "crash point"—the specific location where the program fails or malfunctions due to the vulnerability. For example, suppose a program causes a buffer overflow due to improper user input validation. Software vulnerability localization might point to the specific line number or function call (i.e., location) where the program crashes, while software vulnerability root cause localization delves deeper to discover that the root cause—the lack of input length checks—triggered the overflow, rather than simply providing the location of the crash.

[0004] Locating the root cause of software vulnerabilities is a crucial step in vulnerability remediation, and its effective location and repair are of great significance. For example, fuzzing is currently the most popular vulnerability discovery method. It can discover a large number of input samples that can cause program crashes in a short period of time. Security personnel have used this technique to discover high-risk vulnerabilities such as CVE-2019-13720, CVE-2023-2908, and CVE-2018-4990. However, fuzzing cannot be used directly to locate the root cause of a vulnerability. To fix the software vulnerabilities behind the abnormal samples generated by fuzzing, developers have to manually conduct in-depth and detailed analysis of the abnormal samples to gradually clarify the root cause of the software vulnerability. The current state of highly automated vulnerability discovery and heavy reliance on human experts for vulnerability root cause analysis results in a large number of vulnerabilities not being repaired in a timely and effective manner. According to the "Vulnerability and Threat Trends Report 2024" released by Skybox Security Research Lab, a new software vulnerability will appear on average every 17 minutes in 2024, while the average time to fix a vulnerability exceeds 100 days. More worryingly, 75% of new vulnerabilities are exploited within 19 days or less, while the patching of most software vulnerabilities lags far behind this time window. Furthermore, inaccurate vulnerability root cause identification often leads to inadequate patching. Therefore, promoting the development of automatic vulnerability root cause identification technology is crucial for improving vulnerability patching efficiency and avoiding inadequate patching. Unfortunately, compared to fuzz testing technology, the research and application of automatic vulnerability root cause identification technology is still in a relatively early stage, and has not yet received sufficient attention or mature solutions.

[0005] Statistical vulnerability root cause localization methods are currently the mainstream automated methods for vulnerability root cause localization. These methods infer the cause of the vulnerability based on statistical laws by comparing the differences between crashed and non-crash samples during runtime. Among them, predicate-based vulnerability root cause localization methods are the most important statistical methods. These methods introduce the concept of a predicate, which is a Boolean expression used to describe a specific state during program runtime. Predicate-based vulnerability root cause localization methods first generate predefined predicates in the target program, then use fuzzing tools to generate a large number of crashed and non-crash samples, and statistically analyze the results of the predicates in each sample during program runtime, such as whether the predicate value is true or false. Finally, the predicates are ranked by calculating probability values, which serves as the ranking of vulnerability root causes. Aurora is a representative method among predicate-based vulnerability root cause localization methods (see...). AURORA: Statistical Crash Analysis for Automated Root Cause Explanation | USENIXIt first generates a large number of crash and non-crash samples based on an initial proof-of-concept (PoC, sample code or test cases that prove the existence of a vulnerability in the software). Then, it runs each sample and records the program's running state, using predicates to describe the crash conditions. Finally, it infers the cause of the vulnerability based on the state differences between the crash and non-crash samples. (See Racing) usenixsecurity24_slides-xu- dandan.pdf Racing is a method that introduces reinforcement learning techniques to optimize fuzz testing strategies based on Aurora. It accelerates the statistical analysis process through negative example sampling, but its predicate construction still follows the Aurora framework. Although the Racing method significantly improves localization speed compared to Aurora, its predicate construction remains the same, and the differences in variable values ​​between generated samples are still small. Furthermore, it may generate misleading false negative examples, resulting in relatively low localization accuracy. (See BENZENE) Benzene:A Practical Root Cause Analysis System with an Under- Constrained State Mutation | IEEE Conference Publication | IEEE Xplore This method introduces constrained state mutations through dynamic binary analysis to generate crash and non-crash behavior paths. It then combines this with code coverage graphs to calculate behavioral similarity, ultimately generating a comprehensive predicate to describe crash behavior and analyze potential vulnerability causes. However, this method relies on runtime mutation techniques, which may introduce program crashes caused by other vulnerabilities not being analyzed, such as memory out-of-bounds access. These crashes are unrelated to those caused by Proof-of-Concept (PoC), leading to inaccurate localization results.

[0006] Although statistical vulnerability causation methods such as Aurora have shown good analytical results for some vulnerabilities, their ability to pinpoint causes is limited by several constraints: First, statistical methods are highly dependent on sample quality, i.e., the degree of difference in variable values ​​between samples. Existing works all use coverage-guided fuzzing to generate the required samples. Coverage-guided fuzzing aims to explore more execution paths and does not focus on changes in variable values ​​during sample runtime. Therefore, existing coverage-guided fuzzing is difficult to generate high-quality samples suitable for vulnerability causation. Second, the ability to correctly generate predicates to describe vulnerability causes is a key factor in determining the accuracy of subsequent causation. Existing works only predefine simple predicates, making it difficult to generate correct predicates for slightly more complex vulnerabilities. Furthermore, due to the diversity of vulnerabilities, the predicate set generated by existing methods cannot describe all vulnerability causes, leading to inaccurate vulnerability causation.

[0007] The aforementioned limitations result in low accuracy in vulnerability cause identification and a lengthy process. Inaccurate vulnerability cause identification leads to incomplete vulnerability remediation, meaning the remediation measures fail to cover the true root cause of the vulnerability, allowing attackers to trigger the vulnerability again by simply modifying the Proof-of-Concept (PoC). Furthermore, inaccurate cause identification forces remediation personnel to inspect multiple potentially dangerous code locations, significantly increasing the time required for remediation. This not only prolongs the remediation cycle but also further increases the risk of the vulnerability being exploited by attackers.

[0008] In summary, current mainstream vulnerability cause localization methods generally suffer from low accuracy and slow speed, making them difficult to apply in practice. Researching and developing more advanced and effective software vulnerability cause localization technologies is of significant practical importance. How to improve the accuracy and efficiency of vulnerability cause localization is a technical issue of great concern to those skilled in the art. Summary of the Invention

[0009] The technical problem this invention aims to solve is that while current vulnerability discovery is highly automated, vulnerability cause localization still heavily relies on manual intervention, and the methods for vulnerability cause localization generally suffer from low accuracy and slow speed, resulting in a large number of vulnerabilities not being patched in a timely manner. This invention provides a vulnerability cause localization method based on data richness and migration cost awareness, enabling rapid vulnerability cause localization and solving the problems of low accuracy and efficiency in vulnerability cause localization.

[0010] To address the aforementioned technical problems, the technical solution of this invention is as follows: First, starting with a crash test case and a target program, a vulnerability crash-related node inference method based on a combination of static and dynamic methods is used to infer vulnerability crash-related nodes. Then, a high-quality test case generation method guided by data richness is used to monitor the values ​​of vulnerability crash-related nodes during the execution of test cases generated by fuzzing. The increased data richness of the values ​​guides the generation of high-quality test cases. Simultaneously, a fuzzing method based on reduced migration costs is used to filter and obtain state transition test cases. Finally, a vulnerability cause localization method based on test case state transitions is used. Through taint analysis, mutual information algorithms, and clustering algorithms, a ranking of vulnerability trigger points is obtained, and the vulnerability cause-related code is inferred. This vulnerability cause-related code is then sent to an existing large-scale vulnerability remediation model, enabling rapid and accurate vulnerability remediation.

[0011] This invention includes the following steps:

[0012] The first step is to infer vulnerability-related nodes using a dynamic and static combined vulnerability crash-related node inference method. The method is as follows:

[0013] 1.1 The target program Prog was compiled using the LLVM compilation framework (see the literature "LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation", Chris Lattner et al., "LLVM: A Compilation Framework for Lifelong Program Analysis and Transformation", published in 2004) to generate intermediate code IRProg that is independent of the source code language and hardware.

[0014] 1.2 Value flow analysis of IRProg was performed using the SVF tool (see the literature "SVF: interprocedural static value-flow analysis in LLVM", Yulei Sui et al., "SVF: Interprocedural Static Value-Flow Analysis in LLVM", published in 2016), constructing an interprocedural sparse value flow graph VFG of IRProg, where VFG = {(node 11 ,node 12 (edge1), ..., (node) n1 ,node n2 ,edge n ), ..., (node N1 ,node N2 ,edge N )}, 1≤n≤N, where N is the total number of value flow dependencies in VFG (see the literature "SVF: interprocedural static value-flow analysis in LLVM", Yulei Sui et al., "SVF: Interprocedural Static Value-Flow Analysis in LLVM", published in 2016), node n1 node n2 These are nodes in VFG, and their contents are either a statement, a parameter, a variable, or a memory region in IRProg. (edge) n An edge in a VFG represents an edge originating from node [node name missing]. n1 Point to node n2 Value flow dependencies;

[0015] 1.3 Input the initial proof-of-concept (PoC) into Prog and run Prog, recording the statements and parameter information at the point of Prog's crash, denoted as CrashInfo = {var1, var2, ..., var...} q ,…,var Q}, 1≤q≤Q, where Q is the total number of statements and parameters at the point of Prog crash, var q This is the statement and parameter information for the qth statement in CrashInfo.

[0016] 1.4 Traverse the VFG to establish a correspondence between elements in CrashInfo and nodes in the VFG, generating an initial set of vulnerability crash point node addresses, CrashVar. The method is as follows:

[0017] 1.4.1 Let variables i = 1 and n = 1, and initialize CrashVar to empty;

[0018] 1.4.2 Extract the nth triplet from the VFG (node) n1 ,node n2 ,edge n Extract node n2 The statements and parameter information contained in the node n2 The statements and parameter information contained therein are placed in node. n2 The NodeInfo collection of statement and parameter information n2 In NodeInfo n2 ={var1,var2,…,var p ,…,var P}, 1≤p≤P, where P is a node n2 The total number of statements and parameters contained in var p It contains the p-th statement and parameter information in NodeInfo;

[0019] 1.4.3 CrashInfo and NodeInfo n2 Perform the intersection operation to obtain the intersection result Res;

[0020] 1.4.4 If Res is empty, it means that node n2 If not the initial vulnerability-caused node, proceed to 1.4.6; if not empty, it means node n2 The same statements and parameter information as CrashInfo may be related to the occurrence of the crash; see section 1.4.5.

[0021] 1.4.5 Record node n2 The address is the corresponding address of the i-th initial vulnerability-caused node in VFG, nodeAddr. i If nodeAddr i If not in CrashVar, then the node will be... i Add CrashVar, and simultaneously set i = i + 1, then proceed to step 1.4.6; if nodeAddr i If it already exists in CrashVar, then no operation will be performed on CrashVar, and the process will proceed directly to step 1.4.6;

[0022] 1.4.6 Let n = n + 1;

[0023] 1.4.7 If n > N, it means that the traversal of VFG has been completed, and the initial set of vulnerability crash node addresses, CrashVar, has been obtained, where CrashVar = {nodeAddr1, nodeAddr2, ..., nodeAddr...} i ,…,nodeAddr I}, 1≤i≤I, where I is the total number of initial vulnerability crash node addresses, go to 1.5; if n≤N, it means that the traversal of VFG has not yet been completed, go to 1.4.2;

[0024] 1.5 Analyze VFG to identify other potential vulnerability crash statements and parameter information that have data flow relationships with the initial vulnerability crash node in CrashVar, and generate a set of suspicious vulnerability crash node addresses, SusVar. The method is as follows:

[0025] 1.5.1 Initialize SusVar = CrashVar, and set nodeAddr1, nodeAddr2, ..., nodeAddr in CrashVar. i ,…,nodeAddr I Load the elements into the node address queue NodeQueue, and let |NodeQueue| be the number of elements in NodeQueue;

[0026] 1.5.2 Let variable i = 1. If |NodeQueue| ≠ 0, go to step 1.5.3; if |NodeQueue| = 0, it means that the traversal of the nodes to be verified has been completed, go to step 1.5.5.

[0027] 1.5.3 Retrieve the first element from the head of the NodeQueue (let's call it nodeAddr). i Extract nodeAddr i Let the corresponding node be node. i2 Search for nodes in VFG i2 The triplet for the second element (node) i1 ,node i2 ,edge i If nodeAddr exists, proceed to step 1.5.4 if it does; otherwise, delete nodeAddr from NodeQueue. i Proceed to step 1.5.2;

[0028] 1.5.4 Based on VFG edge i Value stream dependency relationship, if the node in VFG i2 It is a node that has been compromised due to a suspected vulnerability. i1This is also a node that is suspected of having a vulnerability and crashing. (The node is likely a placeholder or error.) i1 address nodeAddr i Add to the end of the NodeQueue, and also add nodeAddr i Add nodeAddr to the set SusVar, let I = I + 1, and remove nodeAddr from NodeQueue. i Proceed to step 1.5.2;

[0029] 1.5.5 At this point, |NodeQueue| = 0, indicating that the extraction of suspicious vulnerability crash nodes has been completed, and the set of suspicious vulnerability crash node addresses, SusVar, has been obtained, where SusVar = {nodeAddr1, nodeAddr2, ..., nodeAddr...} m ,…,nodeAddr M}, 1≤m≤M, where M is the total number of potentially vulnerable and crashed node addresses, M=I, nodeAddr m With nodeAddr i The meaning is the same; it is the address of the m-th suspected vulnerability crash node in VFG. The subscript is changed to m only to illustrate that there is a difference in the number of elements in SusVar and CrashVar. Proceed to step 1.6.

[0030] 1.6 Using CLANG (see the LLVM official documentation for details) Clang Compiler User's Manual—Clang 21.0.0 git documentation Compile Prog;

[0031] 1.7 Using the GDB debugger (see the GNU official documentation "...") GDB Documentation The dynamic debugging function (December 22, 2023) tracks the actual execution path of Prog, sets breakpoints at the addresses of all suspected vulnerability crash nodes contained in SusVar, and filters out the nodes that actually participated in the execution based on the breakpoint hits during execution, extracting the set of suspected vulnerability crash nodes FlitVar. The method is as follows:

[0032] 1.7.1 Empty the suspected vulnerability-caused node set FlitVar, and extract nodeAddr1, nodeAddr2, ..., nodeAddr from SusVar. m ,…,nodeAddr M The statements and parameter information contained in the corresponding nodes in VFG, i.e., node1, node2, ..., node in Prog. m ,…,node M The location.

[0033] 1.7.2 Setting breakpoints B1, B2, ..., B in Prog using the GDB debugger m,…,B M That is, set a breakpoint B1 at node1 of Prog, set a breakpoint B2 at node2 of Prog, ..., set a breakpoint B1 at node1 of Prog, ..., set a breakpoint B2 at node1 of Prog. m Set breakpoint B at point B m ..., in Prog's node M Set breakpoint B at point B M , obtain Prog with breakpoints set; initialize variable k = 1;

[0034] 1.7.3 Using PoC as input, run Prog with breakpoints set in the GDB debugger;

[0035] 1.7.4 If a Prog instance with set breakpoints hits a breakpoint, let B be the breakpoint. m Prog, see 1.7.5; if Prog does not hit the breakpoint, it means a crash has been triggered. Rename the node at the crash point to node_. crash , see version 1.7.6;

[0036] 1.7.5 will B m node at m Add to collection FiltVar, node m Become the k-th element of the set FiltVar, representing the k-th suspected vulnerability crash node in the program Prog. k Let k = k + 1, go to step 1.7.3, and continue running Prog with breakpoints set in the GDB debugger;

[0037] 1.7.6 will add the node at the crash point. crash Add to collection FiltVar, node crash Become the k-th element of FiltVar (node) k ;

[0038] 1.7.7 Obtain the set of suspected vulnerability-damaged and crashed nodes, FiltVar, where FiltVar = {node1, node2, ..., node...} k ,…,node K}, 1≤k≤K, where K is the total number of potentially vulnerable and crashed nodes, K≤M;

[0039] At this point, the FiltVar collection retains only nodes that appear on the actual execution path of the PoC and have a static value flow relationship with the initial vulnerability crash node. This ensures that no real vulnerability crash-related nodes are mistakenly deleted, while improving the accuracy and efficiency of the FiltVar collection. This provides accurate data support for subsequent test case generation and vulnerability cause localization. Proceed to the second step.

[0040] The second step involves using a data richness-guided high-quality test case generation method to monitor the values ​​of vulnerability crash nodes in FiltVar during the execution of test cases generated during fuzzing. The data richness of these values ​​is then used as a guide to generate high-quality test cases with increased data richness. Finally, a fuzzing method that reduces migration costs is used to filter these high-quality test cases, resulting in state transition test cases. The method is as follows:

[0041] 2.1 Using LLVM-10 instrumentation tools (see details) llvm / llvm-project:The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. In the Prog source code, find node1, node2, ..., node in FiltVar. k ,…,node K The definitions or usage locations are determined, and instrumentation is performed at these locations in the Prog source code to generate the instrumented intermediate representation file Prog_IR. At this point, node1, node2, ..., node... k ,…,node K These are the corresponding K stake positions.

[0042] 2.2 Using the clang-10 compiler (see details) Clang 10.0.0Release Notes—Clang 10 documentation The compiler `Prog_IR` is used to compile the executable program `Prog_I`. During compilation, the memory error checking tool `AddressSanitizer` is used (AddressSanitizer is a tool for detecting memory errors in C / C++ programs (such as out-of-bounds access, use-and-free, etc.), first released in 2012; see details...). AddressSanitizer Wiki Detect crash information of the target program Prog_I.

[0043] 2.3 Based on PoC, the fuzz testing tool AFL-FUZZ was used (see details). The AFL++ fuzzing framework|AFLplusplus (Version 2.65d) Generates a test case set S, S = {s1, s2, ..., s...} f ,…,s F}, 1≤f≤F, S is the set of test cases generated by AFL-FUZZ based on PoC, F is the total number of test cases in S, s f It is the f-th test case in S.

[0044] 2.4 The test case set S is filtered for data richness and classified for crash judgment to obtain the state transition test case set TransVar. The method is as follows:

[0045] 2.4.1 Initialize the minimum state transition value Min of the test cases to +∞, initialize the current test case state transition difference Min' to +∞, initialize the number of vulnerability crash nodes passed by crash test cases (Counts_crash) to 0, initialize the number of vulnerability crash nodes passed by non-crash test cases (Counts_noncrash) to 0, initialize the state transition test case set TransVar to empty, initialize the test case data richness hash value set HashVar to empty; initialize the crash information recording variable flag to 0, initialize the test case real state label set Y to empty. Let variables f = 1, t = 1;

[0046] 2.4.2 Initialize the test case data richness value_hash initial value H0 = 0, set the number of vulnerable crash nodes Counts to an initial value of 0, and set k = 1;

[0047] 2.4.3 will s f Input the data into the target program Prog_I after instrumentation, run Prog_I, and calculate s based on the running results. f The data richness value_hash is determined by the following method:

[0048] 2.4.3.1 When Prog_I passes through node k When, get node k The corresponding value of the instrumentation variable X k Let Counts = Counts + 1;

[0049] 2.4.3.2 H k-1 With X k Perform hash calculation to generate the k-th hash value H. k That is: H k =hash(H k-1 ,X k )

[0050] 2.4.3.3 Let value_hash = H k , k = k + 1;

[0051] 2.4.3.4 If k > K, it means that for s f Once the data richness calculation is complete, the final value_hash is obtained; proceed to 2.4.3.5; if k≤K, proceed to 2.4.3.1.

[0052] 2.4.3.5 Test Cases f After execution is complete in the target program Prog_I, if s fIf Prog_I crashes (the crash signal can be echoed using AddressSanitizer), record the crash information variable flag = 1; if s f If it does not cause Prog_I to crash, then set flag = 0.

[0053] 2.4.3.6 If value_hash∈HashVar, go to 2.4.3.6.1; if value_hash is not in HashVar, go to 2.4.3.6.2.

[0054] 2.4.3.6.1 At this point, value_hash ∈ HashVar, indicating that test case s f No data richness was increased, i.e., s f If no new program behavior is introduced (such as new execution paths and variable state combinations), s is abandoned. f Let f = f + 1. If f ≤ F, go to 2.4.2 and perform the operation on the next test case; if f > F, go to 2.4.6.

[0055] 2.4.3.6.2 At this point, value_hash is not in HashVar, so determine s i The data richness has been increased; see version 2.4.4.

[0056] 2.4.4 If flag = 1, go to 2.4.4.1; if flag = 0, go to 2.5.4.2.

[0057] 2.4.4.1 Let Counts_crash = Counts, and let the current test case state transition difference Min' = |Counts_crash - Counts_noncrash|. If Min' < Min, it will be used as the t-th test case s that satisfies the conditions of increased data richness and reduced migration cost. f Store it in the state transition test case set TransVar, that is, let s f TV becomes the t-th element in TransVar t Add value_hash to the test case data richness hash set HashVar, and let y f =1 (representing s) f This will cause Prog_I to crash, and will... f Add the test case's true state label set Y, let Min = Min', let t = t + 1, go to 2.5.4.3; if Min' ≥ Min, then abandon s. f , see section 2.4.4.3.

[0058] 2.4.4.2 Let Counts_noncrash = Counts, let Min’ = ∣Counts_crash - Counts_noncrash∣. If Min’ < Min, then s f is stored as the t-th test case that satisfies the increase in data richness and the reduction in migration cost in the set TransVar, and value_hash is added to the set HashVar. Let y f = 0 (indicating that s f does not cause Prog_I to crash), y f is added to Y, let Min = Min’, let t = t + 1, and go to 2.4.4.3; if Min’ ≥ Min, then discard s f , and go to 2.4.4.3.

[0059] 2.4.4.3 If f < F, let f = f + 1, and go to 2.4.2 to operate on the next test case; if f ≥ F, it means that the final state transition test case set TransVar and the test case true state label set Y are obtained. TransVar = {TV1, TV2, …, TV t , …, TV T}, Y = {y1, y2, …, y t , …, y T}, 1 ≤ t ≤ T, where T is the total number of state transition test cases. TV t is the t-th test case in TransVar that satisfies the increase in data richness and the reduction in migration cost, and y t is the test case true state label of TV t . y t = 1 indicates that TV t causes Prog_I to crash, and y t = 0 indicates that TV t does not cause Prog_I to crash. Go to the third step.

[0060] The third step: Based on Prog and PoC, analyze Prog through taint analysis to obtain the candidate vulnerability trigger related node set Z. Z = {z1, z2, …, z r , …, z RNext, based on the state transition test case set TransVar, the mutual information algorithm is used to filter Z to obtain a more accurate set of candidate vulnerability trigger-related nodes, i.e., the optimized set of candidate vulnerability trigger-related nodes Z'. Finally, the K-means clustering algorithm is used to cluster all test cases in TransVar for all candidate vulnerability trigger-related nodes in Z'. The accuracy of the clustering results is evaluated using the real state labels of the test cases. Based on the accuracy of the clustering results, all candidate vulnerability trigger-related nodes in Z' are ranked as the final vulnerability cause localization result. The method is as follows:

[0061] 3.1 Input the PoC into Prog using DFSan, a dynamic instrumentation tool based on LLVM (see the official LLVM documentation for details). DataFlowSanitizer—Clang21.0.0git documentation Tracing the propagation path of the PoC, identifying all contaminated nodes in the Prog, and adding all contaminated nodes in the Prog to the candidate vulnerability trigger-related node set Z, Z = {z1, z2, ..., z...} r ,…,z R}, 1≤r≤R, where R is the total number of nodes related to the candidate vulnerability trigger, z r This is the r-th contaminated node in Prog, which is also the r-th candidate vulnerability trigger-related node in Z.

[0062] 3.2 Due to the large scale and complex data flow of the software, taint analysis may trace a large number of nodes unrelated to the vulnerability. These could include intermediate variables that are tainted only in certain execution paths but do not affect the crash, or redundant taint points introduced by pointer aliases and control flow branches. To narrow down the scope of nodes related to the vulnerability trigger, a mutual information algorithm (see details...) is used. Research on Mutual Information Feature Selection Algorithm Based on Grassberger Entropy - Baidu Scholar, Lanzhou University 2015 The process involves filtering Z to generate an optimized and sorted set of candidate vulnerability trigger-related nodes Z' and a set VSet for clustering operations, where Z' = {z'1, z'2, ..., z'}. p ,z' p+1 ,…,z' P},P≤R,z' p It is the p-th optimized candidate vulnerability triggering related node in Z', VSet={V'1,V'2,…,V' p ,…,V' P}, V' p It is z' p The corresponding candidate vulnerability triggers the relevant node state set.

[0063] The specific method is as follows:

[0064] 3.2.1 Let t = 1, initialize Z' to empty, set the vulnerability optimization threshold, requiring θ to satisfy 0 < θ < 1, with a preferred θ = 0.5; initialize R vulnerability triggering related node state sets V1, V2, ..., V r ,…,V R V is empty r It is the set of node states related to the r-th vulnerability trigger.

[0065] 3.2.2 Let variable r = 1.

[0066] 3.2.3 TV t Input the data into Prog, use the GDB debugger to debug Prog and record the nodes related to candidate vulnerability triggers. r , will z r Add to V r middle.

[0067] 3.2.4 Let r = r + 1. If r ≤ R, go to 3.2.2; if r > R, it means that in TV... t The state recording of the candidate vulnerability trigger-related node set Z under the Prog input condition is complete. Proceed to 3.2.5.

[0068] 3.2.5 Let t = t + 1. If t ≤ T, go to 3.2.2; if t > T, it means that the final result has been obtained in TransVar, where TV1, TV2, ..., TV t TV T The set of candidate vulnerability triggering related node states V1, V2, ..., V3 as input to Prog r ,…,V R See section 3.2.6;

[0069] 3.2.6 Initialize a two-dimensional empty feature array X, and sort V1, V2, ..., V... according to their indices. r ,…,V R Add to array X, resulting in X = [V1, V2, ..., V r ,…,V R Let MI = mutual_info_classif(X,Y) (mutual_info_classif(X,Y) is the mutual_info_classif function in the scikit-learn library (see details)). mutual_info_ classif—scikit-learn 1.6.1 documentation The function is to calculate the mutual information values ​​of X and Y, and obtain the mutual information value set MI, where MI = {mi1, mi2, ..., mi...}. r ,…,mi R}, mi r Let r be the r-th mutual information value in MI, used to measure V in X. rThe corresponding z r Correlation with program Prog crash, 0≤mi r ≤1, mi r The larger the value, the greater the value of z. r The more closely related it is to the program Prog crash.

[0070] 3.2.7 The candidate vulnerability trigger-related node set Z is filtered and sorted to obtain the sorted candidate vulnerability trigger-related node set Z', and a set VSet for clustering operations is generated, VSet = {V'1, V'2, ..., V'...} p ,…,V' P}, V' p With z' p One-to-one correspondence, is z' p The corresponding candidate vulnerability triggers the relevant node state set.

[0071] 3.2.7.1 Let variable r = 1, let p = 1, initialize VSet to empty, and initialize Z' to empty.

[0072] 3.2.7.2 If mi r ≥θ indicates that z r The crash of program Prog is sufficiently relevant to z' p =z r , let V' p =V r , will z' p Add to Z', and add to V' p Add to VSet, let r = r + 1, let p = p + 1, go to step 3.2.7.3; if mi r If <θ, proceed directly to step 3.2.7.3.

[0073] 3.2.7.3 If r ≤ R, go to 3.2.7.2; if r > R, it means that the selection of elements in Z is complete, and we get Z' = {z'1, z'2, ..., z'}. p ,z' p+1 ,…,z' P} and VSet={V'1, V'2,...,V' p ,V' p+1 ,…,V' P}, where P≤R, and V' p With z' p One-to-one correspondence. Based on the mutual information value of each element in Z', the elements in Z' and VSet are simultaneously sorted. The larger the mutual information value, the smaller the corresponding element index. This yields the sorted candidate vulnerability trigger-related node set Z' and VSet, where Z' = {z'1, z'2, ..., z'}. p ,z' p+1 ,…,z'P}, VSet={V'1, V'2,...,V' p ,V' p+1 ,…,V' P},P≤R,z' p It is the p-th optimized candidate vulnerability trigger-related node in Z', V' p It is z' p The corresponding candidate vulnerability triggers the relevant node state set, z' p The corresponding mutual information value > z' p+1 The corresponding mutual information value is then used to proceed to step 3.3.

[0074] 3.3 To further infer the causes of vulnerabilities and rank their probabilities as actual vulnerability causes, a K-means clustering algorithm is used based on the set VSet and the set Z' of candidate vulnerability trigger-related nodes (see details). Clustering analysis algorithm - K- Means Clustering Explained - CSDN Blog The TransVar clusters are then performed, and the Z's values ​​are sorted based on the clustering results to obtain the rankingVar set representing the location of vulnerability causes. The specific steps are as follows:

[0075] 3.3.1 Let p = 1;

[0076] 3.3.2 Based on z' p and V' p For TV1, TV2, ..., TV in TransVar t TV T Construct a feature vector for each test case to obtain the feature vector set F for the p-th test case. p F p ={f1 (p) f2 (p) ,…,f t (p) ,…,f T (p)}, f t (p) Based on TV t In z' p and V' p The feature vector is constructed from the state information (such as variable values, execution paths, or node states) (see details on the construction method). Clustering Analysis Algorithm - K-means Clustering Explained - CSDN Blog Set the target cluster number U = 2, with F p As input, the test cases in TransVar are divided into two clusters, Ci and Cv, using the K-means clustering algorithm. 1p and C 2p C 1p Indicates z' p The cluster of crash test cases obtained by cluster analysis, C2p Indicates z' p Cluster analysis yields clusters of non-crash test cases.

[0077] 3.3.3 Using TV1, TV2, ..., TV in TransVar t TV T The real state labels y1, y2, ..., y t ,…,y T Evaluate the clustering results for TV t If TV t I was assigned to C 1p And y t =1, or TV t I was assigned to C 2p And y t =0, then TV is considered to be t The classification is correct.

[0078] 3.3.4 Statistics on TV1, TV2, ..., TV t TV T Number of correctly classified elements (samples) p Calculation based on z' p and V' p Accuracy of clustering results based on constructed feature vectors p Accuracy p =(samples) p ) / T, where Accuracy p Indicated based on z' p and V' p The degree of consistency between the clustering results of the constructed feature vectors and the true state labels;

[0079] 3.3.5 Let p = p + 1; if p ≤ P, go to 3.3.2; if p > P, it means that for all z' in Z'... p After the cluster analysis is completed, the accuracy set Accuracy is obtained, where Accuracy = {Accuracy1, Accuracy2, ..., Accuracy}. p ,…,Accuracy P}, see section 3.3.6;

[0080] 3.3.6 Based on the size of each element in Accuracy, the elements within Z' are sorted in a second round from high to low. After the second round of sorting, the vulnerability cause location ranking set RankingVar = {rank1, rank2, ..., rank...} is obtained. p , ...rank P}, rank pThis refers to the element in Z' ranked p in terms of accuracy from highest to lowest. If 1 ≤ a ≤ b ≤ P, then the rank is... a Accuracy a ≥rank b Accuracy b Accuracy a Indicated based on z' a The degree of consistency between the clustering results and the true state labels, Accuracy b Indicated based on z' b The degree of consistency between the clustering results and the actual state labels.

[0081] After obtaining the probability ranking set RankingVar of vulnerability causes, RankingVar can be used to identify the most likely vulnerability trigger locations and their related code snippets in the Prog. These code snippets (e.g., the top-ranked code snippets in RankingVar) along with necessary contextual information (such as function call stacks or variable definitions) are then sent to an existing vulnerability remediation model. The vulnerability remediation model focuses on the most likely vulnerability trigger locations and their related code snippets based on RankingVar, thereby improving the accuracy and efficiency of remediation while reducing misjudgments or redundant modifications to irrelevant code, ultimately achieving fast and accurate vulnerability remediation. Therefore, RankingVar is the result of using this invention to locate the vulnerability causes in the Prog.

[0082] Compared with the prior art, the present invention can achieve the following beneficial effects:

[0083] 1. The first step of this invention is to infer vulnerability-related nodes based on a dynamic and static combined vulnerability crash-related node inference method. The second step is to generate high-quality test cases through a high-quality test case generation method guided by data richness, and to filter state transition test cases through a fuzzy testing method based on reduced migration costs. The third step significantly improves the accuracy of vulnerability cause localization through mutual information algorithm and K-means clustering. Experiments using this invention on multiple open-source software (such as mruby, libtiff, lua, libzip, libjpeg, and 15 vulnerability examples) verified the superiority of this invention. The results show that this invention ranks the real vulnerability cause first in 73.3% of the test cases and ranks the real vulnerability cause in the top 5 in 93.3% of the test cases, far outperforming existing methods Aurora and Racing. For example, in the CVE-2022-0240 vulnerability in mruby, this invention ranked the actual vulnerability cause first, while Aurora ranked it eighth, and Racing failed to locate the actual vulnerability cause. In the CVE-2017-12858 vulnerability in libzip, this invention ranked the actual vulnerability cause first, Aurora ranked it ninth, and Racing ranked it twenty-fourth. Compared to Aurora and Racing, this invention improved the average ranking by approximately 85%, significantly reducing misleading location results and providing developers with more accurate vulnerability cause localization.

[0084] 2. In the third step, this invention rapidly filters irrelevant candidate positions using a mutual information algorithm and combines it with K-means clustering for accurate classification of state transition test cases, demonstrating highly efficient computational performance. Experiments show that in 15 test cases, the cause localization time of this invention is typically controlled within 1 minute. For example, analyzing the true cause of the CVE-2017-12858 vulnerability in the open-source software libzip takes 4 seconds, and analyzing the true cause of the CVE-2023-3164 vulnerability in the open-source software libtiff takes 9 seconds. This efficiency ensures that in complex software environments, this invention can quickly generate vulnerability cause rankings, meeting the dual requirements of real-time performance and accuracy in actual development scenarios. Simultaneously, this invention reduces the computational burden of subsequent analysis through high-quality test case generation, further improving overall localization efficiency.

[0085] 3. The vulnerability cause location ranking set (RankingVar) generated by this invention provides high-priority cause code segments for existing large-scale vulnerability remediation models, significantly improving the targeting and success rate of remediation. Experimental results (see Table 1) show that this invention ranks the actual causes in the top 5 in 93.3% of test cases (e.g., lua bug#5.0-2 ranks 5th, readelfCVE-2022-45703 ranks 1st), ensuring that the remediation model can quickly focus on key code areas and reduce misjudgments and redundant modifications to irrelevant code. For example, in the pdfresurrect CVE-2019-14934 vulnerability, this invention ranks 1st, accurately locating the cause code, which greatly shortens the remediation investigation time compared to Aurora (ranked 6th) and Racing (failed to locate). The accurate location capability of this invention effectively reduces the vulnerability remediation cycle and enhances the ability of software systems to resist attacks. Attached Figure Description

[0086] Figure 1 This is the overall flowchart of the present invention. Detailed Implementation

[0087] Specific examples of the present invention will be described below with reference to the accompanying drawings. Figure 1 As shown, the present invention includes the following steps:

[0088] The first step is to infer vulnerability-related nodes using a dynamic and static combined vulnerability crash-related node inference method. The method is as follows:

[0089] 1.1 The target program Prog is compiled using the LLVM compilation framework to generate intermediate code IRProg, which is independent of the source code language and hardware.

[0090] 1.2 Use the SVF tool to perform value flow analysis on IRProg and construct the inter-process sparse value flow graph VFG of IRProg, where VFG = {(node 11 ,node 12 (edge1), ..., (node) n1 ,node n2 ,edge n ), ..., (node N1 ,node N2 ,edge N )}, 1≤n≤N, where N is the total number of value flow dependencies in the VFG, node n1 node n2 These are nodes in VFG, and their contents are either a statement, a parameter, a variable, or a memory region in IRProg. (edge) n An edge in a VFG represents an edge originating from node [node name missing].n1 Point to node n2 Value flow dependencies;

[0091] 1.3 Input the initial proof-of-concept (PoC) into Prog and run Prog, recording the statements and parameter information at the point of Prog's crash, denoted as CrashInfo = {var1, var2, ..., var...} q ,…,var Q}, 1≤q≤Q, where Q is the total number of statements and parameters at the point of Prog crash, var q This is the statement and parameter information for the qth statement in CrashInfo.

[0092] 1.4 Traverse the VFG to establish a correspondence between elements in CrashInfo and nodes in the VFG, generating an initial set of vulnerability crash point node addresses, CrashVar. The method is as follows:

[0093] 1.4.1 Let variables i = 1 and n = 1, and initialize CrashVar to empty;

[0094] 1.4.2 Extract the nth triplet from the VFG (node) n1 ,node n2 ,edge n Extract node n2 The statements and parameter information contained in the node n2 The statements and parameter information contained therein are placed in node. n2 The NodeInfo collection of statement and parameter information n2 In NodeInfo n2 ={var1,var2,…,var p ,…,var P}, 1≤p≤P, where P is a node n2 The total number of statements and parameters contained in var p It contains the p-th statement and parameter information in NodeInfo;

[0095] 1.4.3 CrashInfo and NodeInfo n2 Perform the intersection operation to obtain the intersection result Res;

[0096] 1.4.4 If Res is empty, it means that node n2 If not the initial vulnerability-caused node, proceed to 1.4.6; if not empty, it means node n2 The same statements and parameter information as CrashInfo may be related to the occurrence of the crash; see section 1.4.5.

[0097] 1.4.5 Record node n2 The address is the corresponding address of the i-th initial vulnerability-caused node in VFG, nodeAddr. i If nodeAddr i If not in CrashVar, then the node will be... i Add CrashVar, and simultaneously set i = i + 1, then proceed to step 1.4.6; if nodeAddr i If it already exists in CrashVar, then no operation will be performed on CrashVar, and the process will proceed directly to step 1.4.6;

[0098] 1.4.6 Let n = n + 1;

[0099] 1.4.7 If n > N, it means that the traversal of VFG has been completed, and the initial set of vulnerability crash node addresses, CrashVar, has been obtained, where CrashVar = {nodeAddr1, nodeAddr2, ..., nodeAddr...} i ,…,nodeAddr I}, 1≤i≤I, where I is the total number of initial vulnerability crash node addresses, go to 1.5; if n≤N, it means that the traversal of VFG has not yet been completed, go to 1.4.2;

[0100] 1.5 Analyze VFG to identify other potential vulnerability crash statements and parameter information that have data flow relationships with the initial vulnerability crash node in CrashVar, and generate a set of suspicious vulnerability crash node addresses, SusVar. The method is as follows:

[0101] 1.5.1 Initialize SusVar = CrashVar, and set nodeAddr1, nodeAddr2, ..., nodeAddr in CrashVar. i ,…,nodeAddr I Load the elements into the node address queue NodeQueue, and let |NodeQueue| be the number of elements in NodeQueue;

[0102] 1.5.2 Let variable i = 1. If |NodeQueue| ≠ 0, go to step 1.5.3; if |NodeQueue| = 0, it means that the traversal of the nodes to be verified has been completed, go to step 1.5.5.

[0103] 1.5.3 Retrieve the first element from the head of the NodeQueue (let's call it nodeAddr). i Extract nodeAddr i Let the corresponding node be node. i2 Search for nodes in VFG i2The triplet for the second element (node) i1 ,node i2 ,edge i If nodeAddr exists, proceed to step 1.5.4 if it does; otherwise, delete nodeAddr from NodeQueue. i Proceed to step 1.5.2;

[0104] 1.5.4 Based on VFG edge i Value stream dependency relationship, if the node in VFG i2 It is a node that has been compromised due to a suspected vulnerability. i1 This is also a node that is suspected of having a vulnerability and crashing. (The node is likely a placeholder or error.) i1 address nodeAddr i Add to the end of the NodeQueue, and also add nodeAddr i Add nodeAddr to the set SusVar, let I = I + 1, and remove nodeAddr from NodeQueue. i Proceed to step 1.5.2;

[0105] 1.5.5 At this point, |NodeQueue| = 0, indicating that the extraction of suspicious vulnerability crash nodes has been completed, and the set of suspicious vulnerability crash node addresses, SusVar, has been obtained, where SusVar = {nodeAddr1, nodeAddr2, ..., nodeAddr...} m ,…,nodeAddr M}, 1≤m≤M, where M is the total number of potentially vulnerable and crashed node addresses, M=I, nodeAddr m With nodeAddr i The meaning is the same; it is the address of the m-th suspected vulnerability crash node in VFG. The subscript is changed to m only to illustrate that there is a difference in the number of elements in SusVar and CrashVar. Proceed to step 1.6.

[0106] 1.6 Compile Prog using CLANG;

[0107] 1.7 Using the dynamic debugging function of the GDB debugger, trace the actual execution path of Prog, set breakpoints at the addresses of all suspected vulnerability crash nodes contained in SusVar, and filter out the nodes actually involved in the execution based on the breakpoint hits during execution. Extract the set of suspected vulnerability crash nodes FlitVar. The method is as follows:

[0108] 1.7.1 Empty the suspected vulnerability-caused node set FlitVar, and extract nodeAddr1, nodeAddr2, ..., nodeAddr from SusVar. m,…,nodeAddr M The statements and parameter information contained in the corresponding nodes in VFG, i.e., node1, node2, ..., node in Prog. m ,…,node M The location.

[0109] 1.7.2 Setting breakpoints B1, B2, ..., B in Prog using the GDB debugger m ,…,B M That is, set a breakpoint B1 at node1 of Prog, set a breakpoint B2 at node2 of Prog, ..., set a breakpoint B1 at node1 of Prog, ..., set a breakpoint B2 at node1 of Prog. m Set breakpoint B at point B m ..., in Prog's node M Set breakpoint B at point B M , obtain Prog with breakpoints set; initialize variable k = 1;

[0110] 1.7.3 Using PoC as input, run Prog with breakpoints set in the GDB debugger;

[0111] 1.7.4 If a Prog instance with set breakpoints hits a breakpoint, let B be the breakpoint. m Prog, see 1.7.5; if Prog does not hit the breakpoint, it means a crash has been triggered. Rename the node at the crash point to node_. crash , see version 1.7.6;

[0112] 1.7.5 will B m node at m Add to collection FiltVar, node m Become the k-th element of the set FiltVar, representing the k-th suspected vulnerability crash node in the program Prog. k Let k = k + 1, go to step 1.7.3, and continue running Prog with breakpoints set in the GDB debugger;

[0113] 1.7.6 will add the node at the crash point. crash Add to collection FiltVar, node crash Become the k-th element of FiltVar (node) k ;

[0114] 1.7.7 Obtain the set of suspected vulnerability-damaged and crashed nodes, FiltVar, where FiltVar = {node1, node2, ..., node...} k ,…,node K}, 1≤k≤K, where K is the total number of potentially vulnerable and crashed nodes, K≤M;

[0115] At this point, the FiltVar collection retains only nodes that appear on the actual execution path of the PoC and have a static value flow relationship with the initial vulnerability crash node. This ensures that no real vulnerability crash-related nodes are mistakenly deleted, while improving the accuracy and efficiency of the FiltVar collection. This provides accurate data support for subsequent test case generation and vulnerability cause localization. Proceed to the second step.

[0116] The second step involves using a data richness-guided high-quality test case generation method to monitor the values ​​of vulnerability crash nodes in FiltVar during the execution of test cases generated during fuzzing. The data richness of these values ​​is then used as a guide to generate high-quality test cases with increased data richness. Finally, a fuzzing method that reduces migration costs is used to filter these high-quality test cases, resulting in state transition test cases. The method is as follows:

[0117] 2.1 Using the LLVM-10 instrumentation tool, locate node1, node2, ..., node in the FiltVar source code. k ,…,node K The definitions or usage locations are determined, and instrumentation is performed at these locations in the Prog source code to generate the instrumented intermediate representation file Prog_IR. At this point, node1, node2, ..., node... k ,…,node K These are the corresponding K stake positions.

[0118] 2.2 Using the clang-10 compiler, Prog_IR is compiled into the executable target program Prog_I. During the compilation process, the memory error checking tool AddressSanitizer is used to detect crash information in the target program Prog_I.

[0119] 2.3 Based on PoC, the test case set S, S = {s1, s2, ..., s...}, is generated using the fuzz testing tool AFL-FUZZ 2.65d. f ,…,s F}, 1≤f≤F, S is the set of test cases generated by AFL-FUZZ based on PoC, F is the total number of test cases in S, s f It is the f-th test case in S.

[0120] 2.4 The test case set S is filtered for data richness and classified for crash judgment to obtain the state transition test case set TransVar. The method is as follows:

[0121] 2.4.1 Initialize the minimum state transition value Min of the test cases to +∞, initialize the current test case state transition difference Min' to +∞, initialize the number of vulnerability crash nodes passed by crash test cases (Counts_crash) to 0, initialize the number of vulnerability crash nodes passed by non-crash test cases (Counts_noncrash) to 0, initialize the state transition test case set TransVar to empty, initialize the test case data richness hash value set HashVar to empty; initialize the crash information recording variable flag to 0, initialize the test case real state label set Y to empty. Let variables f = 1, t = 1;

[0122] 2.4.2 Initialize the test case data richness value_hash initial value H0 = 0, set the number of vulnerable crash nodes Counts to an initial value of 0, and set k = 1;

[0123] 2.4.3 will s f Input the data into the target program Prog_I after instrumentation, run Prog_I, and calculate s based on the running results. f The data richness value_hash is determined by the following method:

[0124] 2.4.3.1 When Prog_I passes through node k When, get node k The corresponding value of the instrumentation variable X k Let Counts = Counts + 1;

[0125] 2.4.3.2 H k-1 With X k Perform hash calculation to generate the k-th hash value H. k That is: H k =hash(H k-1 ,X k )

[0126] 2.4.3.3 Let value_hash = H k , k = k + 1;

[0127] 2.4.3.4 If k > K, it means that for s f Once the data richness calculation is complete, the final value_hash is obtained; proceed to 2.4.3.5; if k≤K, proceed to 2.4.3.1.

[0128] 2.4.3.5 Test Cases f After execution is complete in the target program Prog_I, if s fIf Prog_I crashes (the crash signal can be echoed using AddressSanitizer), record the crash information variable flag = 1; if s f If it does not cause Prog_I to crash, then set flag = 0.

[0129] 2.4.3.6 If value_hash∈HashVar, go to 2.4.3.6.1; if value_hash is not in HashVar, go to 2.4.3.6.2.

[0130] 2.4.3.6.1 At this point, value_hash ∈ HashVar, indicating that test case s f No data richness was increased, i.e., s f If no new program behavior is introduced (such as new execution paths and variable state combinations), s is abandoned. f Let f = f + 1. If f ≤ F, go to 2.4.2 and perform the operation on the next test case; if f > F, go to 2.4.6.

[0131] 2.4.3.6.2 At this point, value_hash is not in HashVar, so determine s i The data richness has been increased; see version 2.4.4.

[0132] 2.4.4 If flag = 1, go to 2.4.4.1; if flag = 0, go to 2.5.4.2.

[0133] 2.4.4.1 Let Counts_crash = Counts, and let the current test case state transition difference Min' = |Counts_crash - Counts_noncrash|. If Min' < Min, it will be used as the t-th test case s that satisfies the conditions of increased data richness and reduced migration cost. f Store it in the state transition test case set TransVar, that is, let s f TV becomes the t-th element in TransVar t Add value_hash to the test case data richness hash set HashVar, and let y f =1 (representing s) f This will cause Prog_I to crash, and will... f Add the test case's true state label set Y, let Min = Min', let t = t + 1, go to 2.5.4.3; if Min' ≥ Min, then abandon s. f , see section 2.4.4.3.

[0134] 2.4.4.2 Let Counts_noncrash = Counts, let Min’ = ∣Counts_crash - Counts_noncrash∣. If Min’ < Min, then store s f as the t-th test case that satisfies the increase in data richness and the decrease in migration cost in the set TransVar, and add value_hash to the set HashVar. Let y f = 0 (indicating that s f does not cause Prog_I to crash), add y f to Y, let Min = Min’, let t = t + 1, and go to 2.4.4.3; if Min’ ≥ Min, then discard s f , and go to 2.4.4.3.

[0135] 2.4.4.3 If f < F, let f = f + 1, and go to 2.4.2 to operate on the next test case; if f ≥ F, it means that the final set of state transition test cases TransVar and the set of true state labels Y of the test cases are obtained. TransVar = {TV1, TV2, …, TV t , …, TV T}, Y = {y1, y2, …, y t , …, y T}, 1 ≤ t ≤ T, where T is the total number of state transition test cases. TV t is the t-th test case in TransVar that satisfies the increase in data richness and the decrease in migration cost, and y t is the true state label of the test case of TV t . y t = 1 indicates that TV t will cause Prog_I to crash, and y t = 0 indicates that TV t does not cause Prog_I to crash. Go to the third step.

[0136] Third step, based on Prog and PoC, analyze Prog through taint analysis to obtain the set Z of candidate vulnerability trigger-related nodes. Z = {z1, z2, …, z r , …, z RNext, based on the state transition test case set TransVar, the mutual information algorithm is used to filter Z to obtain a more accurate set of candidate vulnerability trigger-related nodes, i.e., the optimized set of candidate vulnerability trigger-related nodes Z'. Finally, the K-means clustering algorithm is used to cluster all test cases in TransVar for all candidate vulnerability trigger-related nodes in Z'. The accuracy of the clustering results is evaluated using the real state labels of the test cases. Based on the accuracy of the clustering results, all candidate vulnerability trigger-related nodes in Z' are ranked as the final vulnerability cause localization result. The method is as follows:

[0137] 3.1 Input the PoC into Prog, and use the LLVM-based dynamic instrumentation tool DFSan to trace the propagation path of the PoC, identify all contaminated nodes in Prog, and add all contaminated nodes in Prog to the candidate vulnerability trigger-related node set Z, Z = {z1, z2, ..., z...} r ,…,z R}, 1≤r≤R, where R is the total number of nodes related to the candidate vulnerability trigger, z r This is the r-th contaminated node in Prog, which is also the r-th candidate vulnerability trigger-related node in Z.

[0138] 3.2 Due to the large scale of the software and the complexity of the data flow, taint analysis may trace a large number of nodes unrelated to the vulnerability. These could include intermediate variables that are only tainted on certain execution paths but do not affect the crash, or redundant taint points introduced by pointer aliases and control flow branches. To narrow down the range of vulnerability-triggered nodes, a mutual information algorithm is used to filter Z, generating an optimized and sorted set of candidate vulnerability-triggered nodes Z' and a set VSet for clustering operations, Z' = {z'1, z'2, ..., z'}. p ,z' p+1 ,…,z' P},P≤R,z' p It is the p-th optimized candidate vulnerability triggering related node in Z', VSet={V'1,V'2,…,V' p ,…,V' P}, V' p It is z' p The corresponding candidate vulnerability triggers the relevant node state set. The specific method is as follows:

[0139] 3.2.1 Let t = 1, initialize Z' to empty, set the vulnerability optimization threshold, requiring θ to satisfy 0 < θ < 1, with a preferred θ = 0.5; initialize R vulnerability triggering related node state sets V1, V2, ..., V r ,…,V R V is empty r It is the set of node states related to the r-th vulnerability trigger.

[0140] 3.2.2 Let variable r = 1.

[0141] 3.2.3 TV t Input the data into Prog, use the GDB debugger to debug Prog and record the nodes related to candidate vulnerability triggers. r , will z r Add to V r middle.

[0142] 3.2.4 Let r = r + 1. If r ≤ R, go to 3.2.2; if r > R, it means that in TV... t The state recording of the candidate vulnerability trigger-related node set Z under the Prog input condition is complete. Proceed to 3.2.5.

[0143] 3.2.5 Let t = t + 1. If t ≤ T, go to 3.2.2; if t > T, it means that the final result has been obtained in TransVar, where TV1, TV2, ..., TV t TV T The set of candidate vulnerability triggering related node states V1, V2, ..., V3 as input to Prog r ,…,V R See section 3.2.6;

[0144] 3.2.6 Initialize a two-dimensional empty feature array X, and sort V1, V2, ..., V... according to their indices. r ,…,V R Add to array X, resulting in X = [V1, V2, ..., V r ,…,V R Let MI = mutual_info_classif(X,Y) (mutual_info_classif(X,Y) is the mutual_info_classif function in the scikit-learn library (see details)). mutual_info_ classif—scikit-learn 1.6.1 documentation The function is to calculate the mutual information values ​​of X and Y, and obtain the mutual information value set MI, where MI = {mi1, mi2, ..., mi...}. r ,…,mi R}, mi r Let r be the r-th mutual information value in MI, used to measure V in X. r The corresponding z r Correlation with program Prog crash, 0≤mi r ≤1, mi r The larger the value, the greater the value of z. r The more closely related it is to the program Prog crash.

[0145] 3.2.7 The candidate vulnerability trigger-related node set Z is filtered and sorted to obtain the sorted candidate vulnerability trigger-related node set Z', and a set VSet for clustering operations is generated, VSet = {V'1, V'2, ..., V'...} p ,…,V' P}, V' p With z' p One-to-one correspondence, is z' p The corresponding candidate vulnerability triggers the relevant node state set.

[0146] 3.2.7.1 Let variable r = 1, let p = 1, initialize VSet to empty, and initialize Z' to empty.

[0147] 3.2.7.2 If mi r ≥θ indicates that z r The crash of program Prog is sufficiently relevant to z' p =z r , let V' p =V r , will z' p Add to Z', and add to V' p Add to VSet, let r = r + 1, let p = p + 1, go to step 3.2.7.3; if mi r If <θ, proceed directly to step 3.2.7.3.

[0148] 3.2.7.3 If r ≤ R, go to 3.2.7.2; if r > R, it means that the selection of elements in Z is complete, and we get Z' = {z'1, z'2, ..., z'}. p ,z' p+1 ,…,z' P} and VSet={V'1, V'2,...,V' p ,V' p+1 ,…,V' P}, where P≤R, and V' p With z' p One-to-one correspondence. Based on the mutual information value of each element in Z', the elements in Z' and VSet are simultaneously sorted. The larger the mutual information value, the smaller the corresponding element index. This yields the sorted candidate vulnerability trigger-related node set Z' and VSet, where Z' = {z'1, z'2, ..., z'}. p ,z' p+1 ,…,z' P}, VSet={V'1, V'2,...,V' p ,V' p+1 ,…,V' P},P≤R,z' p It is the p-th optimized candidate vulnerability trigger-related node in Z', V'p It is z' p The corresponding candidate vulnerability triggers the relevant node state set, z' p The corresponding mutual information value > z' p+1 The corresponding mutual information value is then used to proceed to step 3.3.

[0149] 3.3 To further infer the causes of vulnerabilities and rank their probabilities as actual vulnerability causes, based on the set VSet and the set Z' of candidate vulnerability trigger-related nodes, the K-means clustering algorithm is used to cluster TransVar. The results of the clustering are then used to sort Z' and obtain the ranking set RankingVar for the location of vulnerability causes. The specific steps are as follows:

[0150] 3.3.1 Let p = 1;

[0151] 3.3.2 Based on z' p and V' p For TV1, TV2, ..., TV in TransVar t TV T Construct a feature vector for each test case to obtain the feature vector set F for the p-th test case. p F p ={f1 (p) f2 (p) ,…,f t (p) ,…,f T (p)}, f t (p) Based on TV t In z' p and V' p The feature vector is constructed from the state information (such as variable values, execution paths, or node states). The target cluster number U = 2 is set, and F... p As input, the test cases in TransVar are divided into two clusters, Ci and Cv, using the K-means clustering algorithm. 1p and C 2p C 1p Indicates z' p The cluster of crash test cases obtained by cluster analysis, C 2p Indicates z' p Cluster analysis yields clusters of non-crash test cases.

[0152] 3.3.3 Using TV1, TV2, ..., TV in TransVar t TV T The real state labels y1, y2, ..., y t ,…,y TEvaluate the clustering results for TV t If TV t I was assigned to C 1p And y t =1, or TV t I was assigned to C 2p And y t =0, then TV is considered to be t The classification is correct.

[0153] 3.3.4 Statistics on TV1, TV2, ..., TV t TV T Number of correctly classified elements (samples) p Calculation based on z' p and V' p Accuracy of clustering results based on constructed feature vectors p Accuracy p =(samples) p ) / T, where Accuracy p Indicated based on z' p and V' p The degree of consistency between the clustering results of the constructed feature vectors and the true state labels;

[0154] 3.3.5 Let p = p + 1; if p ≤ P, go to 3.3.2; if p > P, it means that for all z' in Z'... p After the cluster analysis is completed, the accuracy set Accuracy is obtained, where Accuracy = {Accuracy1, Accuracy2, ..., Accuracy}. p ,…,Accuracy P}, see section 3.3.6;

[0155] 3.3.6 Based on the size of each element in Accuracy, the elements within Z' are sorted in a second round from high to low. After the second round of sorting, the vulnerability cause location ranking set RankingVar = {rank1, rank2, ..., rank...} is obtained. p , ...rank P}, rank p This refers to the element in Z' ranked p in terms of accuracy from highest to lowest. If 1 ≤ a ≤ b ≤ P, then the rank is... a Accuracy a ≥rank b Accuracy b Accuracy a Indicated based on z' a The degree of consistency between the clustering results and the true state labels, Accuracyb Indicated based on z' b The degree of consistency between the clustering results and the actual state labels.

[0156] To verify the effectiveness of the application vulnerability cause analysis method of this invention, a comparative experiment was conducted on a computer equipped with Ubuntu 22.04 operating system, Intel(R) Xeon(R) Gold 6430 and 256GB RAM, comparing the present invention with the Aurora and Racing methods in the background art.

[0157] The experiment selected 15 real-world vulnerabilities, covering multiple open-source software programs, including mruby, libtiff, lua, readelf, nm, libzip, libjpeg, nasm, ezXML, and pdfresurrect. The corresponding source code lines for these vulnerabilities ranged from 857 to 980,019 lines. These vulnerabilities encompassed eight different types of common software vulnerabilities: NULL pointer dereference, heap buffer overflow, use-after-free, integer overflow, out-of-bounds write, uninitialized variable, division-by-zero, and negation overflow. Specific vulnerabilities included CVE-2022-0240, CVE-2023-3164, and CVE-2017-12858, etc. Detailed information is shown in Table 1.

[0158] Following the comparison method of Racing, to ensure sufficient test case generation, if Aurora generates fewer than 100 test cases within 2 hours, an additional 10 hours of fuzzing is added, for a total of 12 hours. The fuzzing time in this invention is fixed at 30 minutes to ensure high-quality test case generation, followed by cause analysis. In terms of evaluation criteria, the official vulnerability patch is considered the actual vulnerability cause. Referring to the evaluation method in Aurora: if the actual vulnerability cause appears within the top 50 of the results ranking, it is considered successfully located; the ranking of the actual vulnerability cause in the results ranking is the main indicator of accuracy.

[0159] The experiment executed steps one through three of this invention, generating a ranking set of vulnerability cause locations called RankingVar, and compared it with the location results of Aurora and Racing. Table 1 shows the comparison results of the vulnerability cause location accuracy of this invention with Aurora and Racing. Table 1 shows that this invention exhibits a significant advantage in location accuracy. In 15 test cases, this invention ranked the actual vulnerability cause first in 73.3% of the test cases and ranked it in the top 5 in 93.3% of the test cases, achieving a 100% success rate. In contrast, Aurora failed to locate the vulnerability in 33.3% of the test cases (marked as X), with a higher average ranking than this invention; Racing failed to locate the vulnerability in 26.7% of the test cases, and its ranking was generally poor in the successfully located cases. For example, when analyzing the CVE-2022-0240 vulnerability in the open-source software mruby, this invention ranked the actual cause of the vulnerability as number 1, Aurora ranked it as number 8, while Racing failed to locate the actual cause of the vulnerability; when analyzing the CVE-2023-3164 vulnerability in the open-source software libtiff, this invention ranked the actual cause of the vulnerability as number 1, Aurora failed to locate it as number 16, and Racing ranked it as number 16.

[0160] Table 1. Comparison of the accuracy of vulnerability cause localization between this invention and Aurora and Racing.

[0161]

[0162]

[0163] Table 2 shows the comparison of vulnerability cause analysis time between this invention and Aurora and Racing. Table 2 indicates that this invention is highly efficient in locating the cause, typically completing the analysis within one minute. For example, when analyzing the actual cause of the CVE-2017-12858 vulnerability in the open-source software libzip, it took 4 seconds, while Aurora took 1 minute and 53 seconds, and Racing took 10 seconds. When analyzing the actual cause of the CVE-2023-3164 vulnerability in the open-source software libtiff, it took 9 seconds, while Aurora took 23 minutes and 26 seconds, and Racing took 1 minute. This invention demonstrates good practicality.

[0164] Table 2 Comparison of vulnerability cause analysis time between this invention and Aurora and Racing

[0165]

[0166]

Claims

1. A vulnerability cause localization method based on data richness and migration cost awareness, characterized in that... Includes the following steps: The first step is to infer vulnerability-related nodes using a dynamic and static combined vulnerability crash-related node inference method. The method is as follows: 1.1 The target program Prog is compiled using the LLVM compilation framework to generate intermediate code IRProg, which is independent of the source code language and hardware. 1.2 Use the SVF tool to perform value flow analysis on IRProg and construct the inter-process sparse value flow graph VFG of IRProg, where VFG = {(node 11 ,node 12 (edge1), ..., (node) n1 ,node n2 ,edge n ), ..., (node N1 ,node N2 ,edge N )}, 1≤n≤N, where N is the total number of value flow dependencies in the VFG, node n1 node n2 These are nodes in VFG, and their contents are either a statement, a parameter, a variable, or a memory region in IRProg. (edge) n An edge in a VFG represents an edge originating from node [node name missing]. n1 Point to node n2 Value flow dependencies; 1.3 Input the initial proof-of-concept (PoC) into Prog and run Prog, recording the statements and parameter information at the point of Prog's crash, denoted as CrashInfo = {var1, var2, ..., var...} q ,…,var Q }, 1≤q≤Q, where Q is the total number of statements and parameters at the point of Prog crash, var q This refers to the q-th statement and parameter information in CrashInfo; 1.4 Traverse the VFG to establish a correspondence between the elements in CrashInfo and the nodes in the VFG, generating an initial set of vulnerability crash point node addresses, CrashVar, where CrashVar = {nodeAddr1, nodeAddr2, ..., nodeAddr...} i ,…,nodeAddr I }, 1≤i≤I, where I is the total number of initial vulnerability crash node addresses; 1.5 Analyze VFG to identify other potential vulnerability crash statements and parameter information that have a data flow relationship with the initial vulnerability crash node in CrashVar, and generate a set of suspicious vulnerability crash node addresses SusVar, SusVar = {nodeAddr1, nodeAddr2, ..., nodeAddr...} m ,…,nodeAddr M }, 1≤m≤M, where M is the total number of potentially vulnerable and crashed node addresses, nodeAddr m With nodeAddr i They have the same meaning; they are the corresponding addresses of the m-th suspected vulnerability crash node in VFG. 1.6 Compile Prog using CLANG; 1.7 Using the dynamic debugging function of the GDB debugger, trace the actual execution path of Prog, set breakpoints at all suspicious vulnerability crash node addresses contained in SusVar, and filter out the nodes actually involved in the execution based on the breakpoint hits during execution. Extract the suspicious vulnerability crash node set FlitVar, FiltVar = {node1, node2, ..., node...} k ,…,node K }, node k It is the kth suspected vulnerability crash node in the program Prog, 1≤k≤K, where K is the total number of suspected vulnerability crash nodes, K≤M; The second step involves using a data richness-guided high-quality test case generation method to monitor the values ​​of vulnerability crash nodes in FiltVar during the execution of test cases generated during fuzzing. High-quality test cases with increased data richness are then generated based on the data richness of these values. Finally, a fuzzing method that reduces migration costs is used to filter these high-quality test cases, resulting in state transition test cases. The method is as follows: 2.1 Using the LLVM-10 instrumentation tool, locate node1, node2, ..., node in the FiltVar source code. k ,…,node K The definitions or usage locations are determined, and instrumentation is performed at these locations in the Prog source code to generate the instrumented intermediate representation file Prog_IR. At this point, node1, node2, ..., node... k ,…,node K That is, the corresponding K stake positions; 2.2 Using the clang-10 compiler, Prog_IR is compiled into an executable target program Prog_I; during the compilation process, the memory error checking tool AddressSanitizer is used to detect crash information of the target program Prog_I; 2.3 Based on PoC, the test case set S is generated using the fuzz testing tool AFL-FUZZ, where S = {s1, s2, ..., s}. f ,…,s F }, 1≤f≤F, S is the set of test cases generated by AFL-FUZZ based on PoC, F is the total number of test cases in S, s f It is the f-th test case in S; 2.4 The test case set S is filtered for data richness and classified for crash judgment to obtain the state transition test case set TransVar and the test case real state label set Y, where TransVar = {TV1, TV2, ..., TV...} t TV T }, Y = {y1, y2, ..., y t ,…,y T }, 1≤t≤T, where T is the total number of state transition test cases, and TV t To satisfy the t-th test case in TransVar with increased data richness and reduced migration cost, y t For TV t The test case real state label, y t =1 indicates TV t This will cause Prog_I to crash, y t =0 indicates TV t It will not cause Prog_I to crash; The third step, based on Prog and PoC, is to obtain the set Z of candidate vulnerability trigger-related nodes through taint analysis Prog, where Z = {z1, z2, ..., z}. r ,…,z R Next, based on the state transition test case set TransVar, the mutual information algorithm is used to filter Z to obtain a more accurate set of candidate vulnerability trigger-related nodes, i.e., the optimized set of candidate vulnerability trigger-related nodes Z', and a set VSet for clustering operations is generated. Finally, the K-means clustering algorithm is used to cluster all test cases in TransVar based on the set VSet and the set of candidate vulnerability trigger-related nodes Z'. The accuracy of the clustering results is evaluated using the real state labels of the test cases. Based on the accuracy of the clustering results, all candidate vulnerability trigger-related nodes in Z' are ranked as the final vulnerability cause localization result. The method is as follows: 3.1 Input the PoC into Prog, and use the LLVM-based dynamic instrumentation tool DFSan to trace the propagation path of the PoC, identify all contaminated nodes in Prog, and add all contaminated nodes in Prog to the candidate vulnerability trigger-related node set Z, Z = {z1, z2, ..., z...} r ,…,z R }, 1≤r≤R, where R is the total number of nodes related to the candidate vulnerability trigger, z r This refers to the r-th contaminated node in Prog, which is also the r-th candidate vulnerability trigger-related node in Z; 3.2 The mutual information algorithm is used to filter Z, generating an optimized and sorted set of candidate vulnerability trigger-related nodes Z' and a set VSet for clustering operations, Z' = {z'1, z'2, ..., z'}. p ,z' p+1 ,…,z' P },P≤R,z' p It is the p-th optimized candidate vulnerability triggering related node in Z'; z' p The corresponding mutual information value > z' p+1 The corresponding mutual information values; VSet = {V'1, V'2, ..., V' p ,…,V' P }, V' p It is z' p The corresponding candidate vulnerability triggers the relevant node state set; 3.3 Based on the set VSet and the set Z' of candidate vulnerability trigger-related nodes, the K-means clustering algorithm is used to cluster TransVar to obtain the ranking set RankingVar of the vulnerability cause location, RankingVar = {rank1, rank2, ..., rank...} p , ...rank P }, rank p Let p be the element in Z' ranked from highest to lowest accuracy. If 1 ≤ a ≤ b ≤ P, then the rank is... a Accuracy a ≥rank b Accuracy b Accuracy a Indicated based on z' a The degree of consistency between the clustering results and the true state labels, Accuracy b Indicated based on z' b The degree of consistency between the clustering results and the actual state labels; RankingVar is the result of locating the cause of vulnerabilities in Prog.

2. The vulnerability cause localization method based on data richness and migration cost awareness as described in claim 1, characterized in that... The method described in step 1.4 for traversing the VFG to establish a correspondence between elements in CrashInfo and nodes in the VFG, and generating the initial set of vulnerability crash point node addresses, CrashVar, is as follows: 1.4.1 Let variables i = 1 and n = 1, and initialize CrashVar to empty; 1.4.2 Extract the nth triplet from the VFG (node) n1 ,node n2 ,edge n Extract node n2 The statements and parameter information contained in the node n2 The statements and parameter information contained therein are placed in node. n2 The NodeInfo collection of statement and parameter information n2 In NodeInfo n2 ={var1,var2,…,var p ,…,var P }, 1≤p≤P, where P is a node n2 The total number of statements and parameters contained in var p It contains the p-th statement and parameter information in NodeInfo; 1.4.3 CrashInfo and NodeInfo n2 Perform the intersection operation to obtain the intersection result Res; 1.4.4 If Res is empty, go to 1.4.6; if it is not empty, go to 1.4.5; 1.4.5 Record node n2 The address is the corresponding address of the i-th initial vulnerability-caused node in VFG, nodeAddr. i If nodeAddr i If not in CrashVar, then the node will be... i Add CrashVar, and simultaneously set i = i + 1, then proceed to step 1.4.6; if nodeAddr i If it already exists in CrashVar, proceed directly to step 1.4.6; 1.4.6 Let n = n + 1; 1.4.7 If n > N, it means that the traversal of VFG has been completed, and the initial set of vulnerability crash node addresses, CrashVar, has been obtained, where CrashVar = {nodeAddr1, nodeAddr2, ..., nodeAddr...} i ,…,nodeAddr I }, End; If n≤N, it means that the traversal of VFG has not been completed, go to 1.4.

2.

3. The vulnerability cause localization method based on data richness and migration cost awareness as described in claim 1, characterized in that... The method described in step 1.5 for analyzing VFG, identifying other potential vulnerability crash statements and parameter information that have a data flow relationship with the initial vulnerability crash node in CrashVar, and generating a set of suspicious vulnerability crash node addresses, SusVar, is as follows: 1.5.1 Initialize SusVar = CrashVar, and set nodeAddr1, nodeAddr2, ..., nodeAddr in CrashVar. i ,…,nodeAddr I Load the elements into the node address queue NodeQueue, and let |NodeQueue| be the number of elements in NodeQueue; 1.5.2 Let variable i = 1. If |NodeQueue| ≠ 0, go to step 1.5.3; if |NodeQueue| = 0, it means that the traversal of the nodes to be verified has been completed, go to step 1.5.

5. 1.5.3 Retrieve the first element from the head of the NodeQueue, nodeAddr i Extract nodeAddr i Let the corresponding node be node. i2 Search for nodes in VFG i2 The triplet for the second element (node) i1 ,node i2 ,edge i If nodeAddr exists, proceed to step 1.5.4 if it does; otherwise, delete nodeAddr from NodeQueue. i Proceed to step 1.5.2; 1.5.4 Based on VFG edge i Value stream dependency relationship, if the node in VFG i2 It is a node that has been compromised due to a suspected vulnerability. i1 It is also a node with a suspected vulnerability that crashed; the node i1 The address nodeAddr i Add to the end of the NodeQueue, and also add nodeAddr i Add nodeAddr to the set SusVar, let I = I + 1, and remove nodeAddr from NodeQueue. i Proceed to step 1.5.2; 1.5.5 At this point, |NodeQueue| = 0, indicating that the extraction of suspicious vulnerability crash nodes has been completed, and the set of suspicious vulnerability crash node addresses, SusVar, has been obtained, where SusVar = {nodeAddr1, nodeAddr2, ..., nodeAddr...} m ,…,nodeAddr M }, 1≤m≤M, where M is the total number of addresses of suspected vulnerability-caused crash nodes, M=I.

4. The vulnerability cause localization method based on data richness and migration cost awareness as described in claim 1, characterized in that... Step 1.7 describes tracing the actual execution path of Prog using the dynamic debugging function of the GDB debugger, setting breakpoints at the addresses of all suspected vulnerability crash nodes contained in SusVar, and filtering out the nodes actually involved in the execution based on the breakpoint hits during execution. The method for extracting the suspected vulnerability crash node set FlitVar is as follows: 1.7.1 Empty the suspected vulnerability-caused node set FlitVar, and extract nodeAddr1, nodeAddr2, ..., nodeAddr from SusVar. m ,…,nodeAddr M The statements and parameter information contained in the corresponding nodes in VFG, i.e., node1, node2, ..., node in Prog. m ,…,node M Location; 1.7.2 Setting breakpoints B1, B2, ..., B in Prog using the GDB debugger m ,…,B M That is, set a breakpoint B1 at node1 of Prog, set a breakpoint B2 at node2 of Prog, ..., set a breakpoint B1 at node1 of Prog, ..., set a breakpoint B2 at node1 of Prog. m Set breakpoint B at point B m ..., in Prog's node M Set breakpoint B at point B M , obtain Prog with breakpoints set; initialize variable k = 1; 1.7.3 Using PoC as input, run Prog with breakpoints set in the GDB debugger; 1.7.4 If a Prog instance with set breakpoints hits a breakpoint, let B be the breakpoint. m Prog, see section 1.7.5; if Prog does not hit the breakpoint, it means a crash has been triggered. Rename the node at the crash point to node_. crash , see version 1.7.6; 1.7.5 will B m node at m Add to collection FiltVar, node m Become the k-th element of the set FiltVar, representing the k-th suspected vulnerability crash node in the program Prog. k Let k = k + 1, go to step 1.7.3, and continue running Prog with breakpoints set in the GDB debugger; 1.7.6 will add node crash Add to collection FiltVar, node crash Become the k-th element of FiltVar (node) k ; 1.7.7 Obtain the set of suspected vulnerability-damaged and crashed nodes, FiltVar, where FiltVar = {node1, node2, ..., node...} k ,…,node K } 5. The vulnerability cause localization method based on data richness and migration cost awareness as described in claim 1, characterized in that the method for performing data richness filtering and crash judgment classification on the test case set S in step 2.4 to obtain the state transition test case set TransVar is as follows: 2.4.1 Initialize the minimum state transition value Min of the test cases to +∞, initialize the current test case state transition difference Min' to +∞, initialize the number of crash test cases that passed through the vulnerability crash node Counts_crash to 0, initialize the number of non-crash test cases that passed through the vulnerability crash node Counts_noncrash to 0, initialize the state transition test case set TransVar to empty, initialize the test case data richness hash value set HashVar to empty; initialize the crash information record variable flag to 0, initialize the test case real state label set Y to empty; set variables f = 1, t = 1; 2.4.2 Initialize the test case data richness value_hash initial value H0 = 0, set the number of vulnerable crash nodes Counts to an initial value of 0, and set k = 1; 2.4.3 will s f Input the data into the target program Prog_I after instrumentation, run Prog_I, and calculate s based on the running results. f The data richness value_hash is determined by the following method: 2.4.3.1 When Prog_I passes through node k When, get node k The corresponding value of the instrumentation variable X k Let Counts = Counts + 1; 2.4.3.2 H k-1 With X k Perform hash calculation to generate the k-th hash value H. k That is: H k =hash(H k-1 ,X k ) 2.4.3.3 Let value_hash = H k , k = k + 1; 2.4.3.4 If k > K, it means that for s f Once the data richness calculation is complete, the final value_hash is obtained; proceed to 2.4.3.5; if k≤K, proceed to 2.4.3.

1. 2.4.3.5 Test Cases f After execution is complete in the target program Prog_I, if s f This causes Prog_I to crash, recording the crash information variable flag = 1; if s f If it does not cause Prog_I to crash, then set flag = 0; 2.4.3.6 If value_hash∈HashVar, go to 2.4.3.6.1; if value_hash is not in HashVar, go to 2.4.3.6.

2. 2.4.3.6.1 At this point, value_hash ∈ HashVar, indicating that test case s f No data richness was increased, i.e., s f No new procedural behavior was introduced, so s was abandoned. f Let f = f + 1. If f ≤ F, go to 2.4.2 and perform the operation on the next test case; if f > F, go to 2.4.

6. 2.4.3.6.2 At this point, value_hash is not in HashVar, so determine s i Data richness has been increased; see version 2.4.

4. 2.4.4 If flag = 1, go to 2.4.4.1; if flag = 0, go to 2.4.4.

2. 2.4.4.1 Let Counts_crash = Counts, and let the current test case state transition difference Min' = |Counts_crash - Counts_noncrash|. If Min' < Min, it will be used as the t-th test case s that satisfies the conditions of increased data richness and reduced migration cost. f Store them in the state transition test case set TransVar, that is, let s f TV becomes the t-th element in TransVar t Add value_hash to the test case data richness hash set HashVar, and let y f =1, y f =1 indicates s f This will cause Prog_I to crash, and will change y f Add the test case's true state label set Y, let Min = Min', let t = t + 1, go to 2.4.4.3; if Min' ≥ Min, then abandon s. f Proceed to 2.4.4.3; 2.4.4.2 Let Counts_noncrash = Counts, and let Min' = |Counts_crash - Counts_noncrash|. If Min' < Min, then s f The t-th test case that satisfies both increased data richness and reduced migration cost is stored in the TransVar set, and the value_hash is added to the HashVar set, let y f =0, y f =0 indicates s f This will not cause Prog_I to crash, and will change y f Add to Y, let Min = Min', let t = t + 1, go to 2.4.4.3; if Min' ≥ Min, then discard s. f Proceed to 2.4.4.3; 2.4.4.3 If f < F, let f = f + 1, and go to 2.4.2 to operate on the next test case; if f ≥ F, it means that the final state transition test case set TransVar and the test case true state label set Y are obtained, TransVar = {TV1, TV2, …, TV t , …, TV T}, Y = {y1, y2, …, y t , …, y T}, and end.

6. The vulnerability cause localization method based on data richness and migration cost awareness as described in claim 2, characterized in that... The judgment s described in step 2.5.3.5 f The cause of Prog_I's crash is determined by the crash signal echoed by AddressSanitizer.

7. The vulnerability cause localization method based on data richness and migration cost awareness as described in claim 1, characterized in that... The method described in step 3.2 for using the mutual information algorithm to filter Z, generate an optimized and sorted set of candidate vulnerability trigger-related nodes Z' and a set VSet for clustering operations is as follows: 3.2.1 Let t = 1, initialize Z' to empty, set the vulnerability selection threshold θ, 0 < θ < 1; initialize R vulnerability triggering related node state sets V1, V2, ..., V r ,…,V R V is empty r It is the set of node states related to the triggering of the r-th vulnerability; 3.2.2 Let variable r = 1; 3.2.3 TV t Input the data into Prog, use the GDB debugger to debug Prog and record the nodes related to candidate vulnerability triggers. r , will z r Add to V r middle; 3.2.4 Let r = r + 1. If r ≤ R, go to 3.2.2; if r > R, it means that in TV... t The state recording of the set Z of candidate vulnerability trigger-related nodes under the Prog input condition is complete. Proceed to 3.2.5; 3.2.5 Let t = t + 1. If t ≤ T, go to 3.2.2; if t > T, it means that the final result has been obtained in TransVar, where TV1, TV2, ..., TV t TV T The set of candidate vulnerability triggering related node states V1, V2, ..., V3 as input to Prog r ,…,V R See section 3.2.6; 3.2.6 Initialize a two-dimensional empty feature array X, and sort V1, V2, ..., V... according to their indices. r ,…,V R Add to array X, resulting in X = [V1, V2, ..., V r ,…,V R Let MI = mutual_info_classif(X,Y). The function of mutual_info_classif(X,Y) is to calculate the mutual information value of X and Y, and obtain the mutual information value set MI, MI = {mi1,mi2,…,mi...}. r ,…,mi R }, mi r Let r be the r-th mutual information value in MI, used to measure V in X. r The corresponding z r Correlation with program Prog crash, 0≤mi r ≤1, mi r The larger the value, the greater the value of z. r The more closely related it is to the program Prog crash; 3.2.7 The candidate vulnerability trigger-related node set Z is filtered and sorted to obtain the sorted candidate vulnerability trigger-related node set Z', and a set VSet for clustering operations is generated, VSet = {V'1, V'2, ..., V'...} p ,…,V' P }, V' p With z' p One-to-one correspondence, is z' p The corresponding candidate vulnerability triggers the relevant node state set.

8. The vulnerability cause localization method based on data richness and migration cost awareness as described in claim 7, characterized in that... The preferred threshold for the vulnerability described in step 3.2.1 is θ = 0.

5.

9. A vulnerability cause localization method based on data richness and migration cost awareness as described in claim 7, characterized in that... The method described in step 3.2.7 for filtering and sorting the candidate vulnerability trigger-related node set Z to obtain the sorted candidate vulnerability trigger-related node set Z', and generating the set VSet for clustering operations, is as follows: 3.2.7.1 Let variable r = 1, and let p = 1; 3.2.7.2 If mi r ≥θ indicates that z r The crash of program Prog is sufficiently relevant to z' p =z r , let V' p =V r , will z' p Add to Z', and add to V' p Add to VSet, let r = r + 1, let p = p + 1, go to step 3.2.7.3; if mi r If θ <, proceed directly to step 3.2.7.3; 3.2.7.3 If r ≤ R, go to 3.2.7.2; if r > R, it means that the selection of elements in Z is complete, and we get Z' = {z'1, z'2, ..., z'}. p ,…,z' P } and VSet={V'1, V'2,...,V' p ,V' p+1 ,…,V' P }, where P≤R, and z' p With V' p One-to-one correspondence; based on the element z' within Z' p The corresponding mutual information value mi p The size is determined by synchronously sorting the elements in Z' and VSet. The larger the mutual information value, the smaller the corresponding element index, resulting in the sorted set of candidate vulnerability triggering related nodes Z' = {z'1, z'2, ..., z'}. p ,z' p+1 ,…,z' P } and VSet={V'1, V'2,...,V' p ,V' p+1 ,…,V' P },P≤R,z' p It is the p-th optimized candidate vulnerability trigger-related node in Z', V' p It is z' p The corresponding vulnerability trigger-related node state set, z' p The corresponding mutual information value > z' p +1 corresponds to the end of the mutual information value.

10. The vulnerability cause localization method based on data richness and migration cost awareness as described in claim 1, characterized in that... The method described in step 3.3, which uses the K-means clustering algorithm to cluster TransVar based on the set VSet and the set Z' of candidate vulnerability trigger-related nodes, to obtain the ranking set RankingVar of vulnerability cause locations, is as follows: 3.3.1 Let p = 1; 3.3.2 Based on z' p and V' p For TV1, TV2, ..., TV in TransVar t TV T Construct a feature vector for each test case to obtain the feature vector set F for the p-th test case. p F p ={f1 (p) f2 (p) ,…,f t (p) ,…,f T (p) }, f t (p) Based on TV t In z' p and V' p The feature vector is constructed from the state information below; the number of target clusters is set to U=2, with F p As input, the test cases in TransVar are divided into two clusters, Ci and Cv, using the K-means clustering algorithm. 1p and C 2p C 1p Indicates z' p The cluster of crash test cases obtained by cluster analysis, C 2p Indicates z' p Cluster analysis yields clusters of non-crash test cases; the state information refers to variable values, execution paths, or node states. 3.3.3 Using TV1, TV2, ..., TV in TransVar t TV T The real state labels y1, y2, ..., y t ,…,y T Evaluate the clustering results for TV t If TV t I was assigned to C 1p And y t =1, or TV t I was assigned to C 2p And y t =0, then TV t Correctly categorized; 3.3.4 Statistics on TV1, TV2, ..., TV t TV T Number of correctly classified elements (samples) p Calculation based on z' p and V' p Accuracy of clustering results based on constructed feature vectors p Accuracy p =(samples) p ) / T, where Accuracy p Indicated based on z' p and V' p The degree of consistency between the clustering results of the constructed feature vectors and the true state labels; 3.3.5 Let p = p + 1; if p ≤ P, go to 3.3.2; if p > P, it means that for all z' in Z'... p After the cluster analysis is completed, the accuracy set Accuracy is obtained, where Accuracy = {Accuracy1, Accuracy2, ..., Accuracy}. p Accuracy P }, see section 3.3.6; 3.3.6 Based on the size of each element in Accuracy, the elements within Z' are sorted in a second round from high to low. After the second round of sorting, the vulnerability cause location ranking set RankingVar = {rank1, rank2, ..., rank...} is obtained. p , ...rank P }, that is, if 1≤a≤b≤P, then rank a Accuracy a ≥rank b Accuracy b .

Images