Vulnerability cause positioning method based on data richness and migration cost perception

Abstract

The invention discloses a vulnerability cause positioning method based on data richness and migration cost perception, and aims to solve the problems of low accuracy and slow speed of a current vulnerability cause positioning method. According to the technical scheme, firstly, a vulnerability collapse related node inference method based on dynamic and static combination is adopted to infer vulnerability collapse related nodes; and then monitoring values of related nodes of vulnerability collapse in the running process of the test case generated by the fuzzy test through a high-quality test case generation method based on data richness guidance, and generating the high-quality test case by taking increase of data richness of the values as guidance. Meanwhile, a state transition test case is obtained through screening by a fuzzy test method based on migration cost reduction; and finally, through taint analysis, a mutual information algorithm and a clustering algorithm, obtaining a vulnerability triggering related node ranking, and deducing a vulnerability cause. By adopting the method and the device, the vulnerability cause positioning accuracy can be improved, the positioning speed is improved, and the vulnerability can be quickly and accurately repaired.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of software vulnerability cause localization, and particularly relates to a vulnerability cause localization method based on data richness and migration cost perception. BACKGROUND

[0002] With the rapid development of information technology, software has been widely used in various critical infrastructure fields, including finance, medical care, transportation, and energy, as the core carrier of information processing and interaction. However, the existence of software vulnerabilities seriously threatens the security, stability, and reliability of information systems, and may lead to data leakage, system crashes, and abuse of authority, etc. Specifically, software vulnerabilities refer to defects or weaknesses in software systems that can be used to violate security policies. These vulnerabilities may be caused by various errors and omissions in the software development process, such as non-standard code writing, logic design defects, improper handling of boundary conditions, and insufficient verification of user input. Attackers can exploit these vulnerabilities to perform malicious operations, such as unauthorized access to systems, privilege escalation, theft of sensitive information, and implantation of malicious software, etc.

[0003] In order to quickly and effectively repair vulnerabilities to address the risks posed by software vulnerabilities, software vulnerability cause localization technology has emerged. Software vulnerability cause localization refers to the process of determining the root cause or trigger point of a software vulnerability during software development or debugging by analysis and research. Specifically, it focuses on the "source" of the vulnerability, that is, what kind of code logic, input condition, or environmental factor triggers the occurrence of the vulnerability. In contrast, software vulnerability localization focuses more on finding the "crash point" of the vulnerability, that is, the specific location where the program crashes due to the vulnerability. For example, if a program crashes due to a buffer overflow caused by not properly validating user input, software vulnerability localization may point out the specific line number or specific function call (i.e., location) where the program crashes, while software vulnerability cause localization will further analyze and find that the lack of input length checking is the root cause that triggers the overflow, rather than just giving the location of the program crash.

[0004] Software bug cause localization is a key step for bug fixing, which is of great importance for effective bug localization and fixing. For example, fuzzing is the most popular bug mining method, which can find a large number of input samples that can cause program crashes in a short time. Security personnel have found high-risk vulnerabilities such as CVE-2019-13720, CVE-2023-2908, and CVE-2018-4990 using this technology. However, fuzzing cannot be directly used to locate bug causes. In order to fix the software bug behind the abnormal sample generated by fuzzing, developers have to manually analyze the abnormal sample in depth and detail, so as to gradually clarify the software bug cause. The current situation of highly automated bug mining and serious dependence on manual expert bug cause analysis leads to a large number of bugs that cannot be repaired in time and effectively. According to the Vulnerability and Threat Trends Report 2024 published by Skybox Security Research Laboratory, there is a new software bug every 17 minutes in 2024, and the average bug fixing time is more than 100 days. More worrying is that 75% of new bugs are exploited within 19 days or less, while the repair speed of most software bugs is far behind this time window. In addition, imprecise bug cause localization often leads to insufficient patches. Therefore, promoting the development of bug cause automatic localization technology is of great importance to improve bug fixing efficiency and avoid insufficient bug fixing. Unfortunately, compared with fuzzing technology, the research and application of bug cause automatic localization technology is still in its infancy and has not received enough attention and mature solutions.

[0005] Statistical-based bug cause localization method is the current mainstream automatic bug cause localization method. This method compares the differences between crash samples and non-crash samples in runtime, and infers the bug cause based on statistical rules. Among them, the predicate-based bug cause localization method is the most important statistical-based bug cause localization method. This method proposes the concept of predicate, which is a Boolean expression used to describe the specific state of program runtime. The predicate-based bug cause localization method first generates pre-defined predicates in the target program, then uses a fuzzing tool to generate a large number of crash samples and non-crash samples, and counts the results of the predicates in each sample, such as true or false, and finally ranks the predicates by calculating the probability value as the bug cause ranking. Aurora is a representative method of predicate-based bug root cause localization method (see AURORA: Statistical Crash Analysis for Automated Root Cause Explanation|USENIX), which first generates a large number of crash samples and non-crash samples based on an initial Proof of Concept (PoC) and then runs each sample and tracks the program's state, uses predicates to describe the crash conditions, and finally infers the cause of the vulnerability according to the state differences between the crash samples and the non-crash samples. Racing (see usenixsecurity24_slides-xu- dandan.pdf ) is a method that introduces reinforcement learning techniques to optimize fuzzing strategies based on Aurora. It accelerates the statistical analysis process by sampling counterexample inputs, but its predicate construction still follows the Aurora framework. Although the Racing method significantly improves the positioning speed, its predicate construction is still the same as Aurora, and the differences in variable values between the generated samples are still small. At the same time, it may generate misleading false negatives, resulting in low positioning accuracy. BENZENE (see Benzene:A Practical Root Cause Analysis System with an Under- Constrained State Mutation | IEEE Conference Publication | IEEE Xplore ) introduces constrained state mutation through dynamic binary analysis, generates crash and non-crash behavior paths, and calculates behavior similarity combined with code coverage graphs to generate comprehensive predicates that describe crash behavior and analyze potential vulnerability causes. However, this method relies on runtime mutation techniques, which may introduce program crashes caused by other non-analyzed vulnerabilities such as memory access out-of-bounds, which are not related to the crashes caused by PoC, making the positioning results inaccurate.

[0006] Although methods such as Aurora based on statistics have shown good analysis results on some vulnerabilities, the limitations of such methods limit their ability to locate causes: first, statistical-based methods highly depend on sample quality, i.e., the difference in variable values between samples, while existing work generates required samples using coverage-guided fuzzing. Coverage-guided fuzzing aims to explore more execution paths and does not focus on changes in variable values during sample execution, so existing coverage-guided fuzzing is difficult to generate high-quality samples suitable for vulnerability cause localization. Second, the ability to correctly generate predicates describing vulnerability causes is a key factor in determining the accuracy of subsequent localization, while existing work only predefines simple predicates, making it difficult to generate correct predicates for slightly complex vulnerabilities. Due to the diversity of vulnerabilities, the predicate set generated by existing methods cannot describe all vulnerability causes, resulting in inaccurate vulnerability cause localization.

[0007] The above limitations result in low accuracy of vulnerability cause positioning and long time required for the vulnerability cause positioning process. Inaccurate vulnerability cause positioning results in incomplete vulnerability repair, i.e., the repair measures do not cover the real vulnerability root, so that the attacker can continue to trigger the vulnerability by simply modifying the PoC. At the same time, inaccurate vulnerability cause positioning also forces the vulnerability repair personnel to check multiple potential dangerous code locations, greatly increasing the time required for vulnerability repair. This not only prolongs the repair period, but also further increases the risk of vulnerability being exploited by attackers.

[0008] In summary, the current mainstream vulnerability cause positioning method generally has the problems of low positioning accuracy and slow positioning speed, and is difficult to be practically applied. It is of great practical significance to research and develop more advanced and effective software vulnerability cause positioning technology. How to improve the accuracy and efficiency of vulnerability cause positioning is a technical problem that technicians in the field are extremely concerned about. SUMMARY

[0009] The technical problem to be solved by the present application is that the current vulnerability mining is highly automated, but the vulnerability cause positioning heavily relies on manual work, and the vulnerability cause positioning method generally has the problems of low positioning accuracy and slow positioning speed, resulting in a large number of vulnerabilities that cannot be repaired in time. A vulnerability cause positioning method based on data richness and migration cost perception is provided to realize rapid positioning of vulnerability causes and solve the problems of low accuracy and efficiency of vulnerability cause positioning.

[0010] To solve the above technical problems, the technical scheme of the present application is as follows: first, starting from a crash use case and a target program, a vulnerability crash related node inference method based on dynamic and static combination is used to infer the vulnerability crash related node. Then, a high-quality test case generation method based on data richness guidance is used to monitor the value of the vulnerability crash related node in the running process of the test case generated by the fuzz test, and the data richness of the value is increased to guide the generation of high-quality test cases, and a fuzz test method based on migration cost reduction is used to screen the state transition test cases. Finally, a vulnerability cause positioning method based on test case state transition is used to obtain the vulnerability trigger point ranking through the pollution analysis, mutual information algorithm and clustering algorithm, and the vulnerability cause related code is inferred, and the vulnerability cause related code is sent to the existing vulnerability repair large model, so that the rapid and accurate repair of the vulnerability can be realized.

[0011] The present application comprises the following steps:

[0012] In the first step, a vulnerability crash related node inference method based on dynamic and static combination is used to infer the vulnerability crash related node. The method is as follows:

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

[0014] 1.2 Perform value flow analysis on IRProg using the SVF tool (see the paper "SVF: interprocedural Static Value-Flow Analysis in LLVM", Yulei Sui et al., 2016) to construct the interprocedural sparse value flow graph VFG of IRProg, VFG = {(node 11 ,node 12 ,edge1), …, (node n1 ,node n2 ,edge n ), …, (node N1 ,node N2 ,edge N )}, 1≤n≤N, N is the total number of value flow dependencies in VFG (see the paper "SVF: interprocedural static value-flow analysis in LLVM", Yulei Sui et al., 2016), node n1 and node n2 are nodes in VFG, containing a statement, a parameter, a variable, or a block memory region in IRProg, respectively, and edge n is an edge in VFG, representing a value flow dependency from node n1 to node n2 .

[0015] 1.3 Input the initial proof of concept PoC to Prog and run Prog, record the statement and parameter information at the crash of Prog, let CrashInfo = {var1, var2, …, var q , …, var Q}, 1≤q≤Q, Q is the total number of statements and parameter information at the crash of Prog, and var q is the qth statement or parameter information in CrashInfo.

[0016] 1.4 Traverse the VFG, so that the elements in Crashlnfo correspond to the nodes in the VFG, and generate the initial vulnerability crash point node address set CrashVar, by the following method:

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

[0018] 1.4.2 Take out the nth triple (node n1 , node n2 , edge n ) in the VFG, extract the statements and parameter information contained in node n2 , and put the statements and parameter information contained in node n2 into the statement and parameter information set NodeInfo n2 of node n2 , NodeInfo n2 = {var1, var2, …, var p , …, var P}, 1≤p≤P, P is the total number of statements and parameter information contained in node n2 , and var p is the pth statement and parameter information in NodeInfo;

[0019] 1.4.3 Perform intersection operation on Crashlnfo and NodeInfo n2 , and obtain the intersection result Res;

[0020] 1.4.4 If Res is empty, it means that node n2 is not an initial vulnerability crash node, go to 1.4.6; if Res is not empty, it means that node n2 has the same statements and parameter information as Crashlnfo, and is possibly related to the generation of the crash, go to 1.4.5;

[0021] 1.4.5 Record the address of node n2 as the corresponding address nodeAddr i of the ith initial vulnerability crash node in the VFG, if nodeAddr i is not in CrashVar, add node i to CrashVar, and let i = i + 1, go to step 1.4.6; if nodeAddr i already exists in CrashVar, do not perform any operation on CrashVar, and go 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 vulnerability crash node address set CrashVar is obtained, CrashVar = {nodeAddr1, nodeAddr2, …, nodeAddr i ,…,nodeAddr I}, 1≤i≤I, I is the total number of initial vulnerability crash node addresses, turn to 1.5; if n≤N, it means that the traversal of VFG has not been completed, turn to 1.4.2;

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

[0025] 1.5.1 Initialize SusVar = CrashVar, load nodeAddr1, nodeAddr2, …, nodeAddr i ,…,nodeAddr I in CrashVar to 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, turn to step 1.5.3; if |NodeQueue| = 0, it means that the traversal of the to-be-verified node has been completed, turn to step 1.5.5;

[0027] 1.5.3 Take out the first element (let it be nodeAddr i ) at the head of the queue NodeQueue, extract the node corresponding to nodeAddr i , let it be node i2 , find in VFG whether a triple (node i2 , node i1 , edge i2 ) exists with node i as the second element, if it exists, turn to step 1.5.4; if it does not exist, delete nodeAddr i from NodeQueue, turn to step 1.5.2;

[0028] 1.5.4 Based on the value flow dependency relationship of edge i in VFG, if the node node i2 in VFG is a suspicious vulnerability crash node, node i1Also the suspicious vulnerability crash node. Add the address nodeAddr i of node i1 to the tail of NodeQueue, and add nodeAddr i to the set SusVar, let I = I + 1, and delete nodeAddr i from NodeQueue, and go to step 1.5.2;

[0029] 1.5.5 At this time |NodeQueue| = 0, which means that the extraction of suspicious vulnerability crash nodes has been completed, and the set of suspicious vulnerability crash node addresses SusVar is obtained, SusVar = {nodeAddr1, nodeAddr2, …, nodeAddr m , …, nodeAddr M}, 1≤m≤M, M is the total number of suspicious vulnerability crash node addresses, M = I, nodeAddr m and nodeAddr i have the same meaning, and are the corresponding addresses of the mth suspicious vulnerability crash node in VFG, and the subscript m is only used to indicate that the number of elements in SusVar and CrashVar is different. Go to step 1.6;

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

[0031] 1.7 Use the dynamic debugging function of GDB debugger (see GNU official document “ GDB Documentation ”, December 22, 2023) to track the actual execution path of Prog, set breakpoints at all suspicious vulnerability crash node addresses contained in SusVar, and filter out the nodes actually participating in running according to the breakpoint hit situation during execution, and extract the suspicious vulnerability crash node set FlitVar, the method is:

[0032] 1.7.1 Let the suspicious vulnerability crash node set FlitVar be empty, and extract the nodeAddr1, nodeAddr2, …, nodeAddr m , …, nodeAddr M in SusVar in the corresponding nodes in VFG, that is, the positions of node1, node2, …, node m , …, node M in Prog.

[0033] 1.7.2 Use GDB debugger to set breakpoints B1, B2, …, B m,…,B M , that is, set breakpoint B1 at node1 of Prog, set breakpoint B2 at node2 of Prog, ..., set breakpoint B3 at node1 of Prog m Set breakpoint B m ,…, in the node of Prog M Set breakpoint B M , get the Prog with breakpoint set; initialize variable k=1;

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

[0035] 1.7.4 If a breakpoint is set in the program and a breakpoint is hit, let B m , go to 1.7.5; if Prog does not hit the breakpoint, it means that the crash has been triggered, and let the node at the crash point be node crash , transfer to 1.7.6;

[0036] 1.7.5 B m Node m Add to collection FiltVar, node m Becomes the kth element of the set FiltVar, representing the kth suspected vulnerability crash node node in the program Prog k , set k = k + 1, go to step 1.7.3, and continue running the program with the breakpoint set in the GDB debugger;

[0037] 1.7.6 The node at the crash point crash Add to collection FiltVar, node crash Become the kth element node of FiltVar k ;

[0038] 1.7.7 Get the suspected vulnerability crash node set FiltVar, FiltVar = {node1, node2,…, node k ,…,node K}, 1≤k≤K, K is the total number of nodes with suspected vulnerabilities crashing, K≤M;

[0039] At this point, the FiltVar set only retains nodes that appear on the actual PoC execution path and have a static value flow relationship with the initial vulnerability crash node. This ensures that no nodes related to the actual vulnerability crash are accidentally deleted. This also improves the accuracy and efficiency of the FiltVar set, providing accurate data support for subsequent test case generation and vulnerability cause location. Then, we proceed to the second step.

[0040] Secondly, the data richness guided high-quality test case generation method is used to monitor the value of the vulnerability crash node of FiltVar in the running process of the test cases generated in the fuzzing process, and the data richness of the value is used as a guide to generate high-quality test cases with increased data richness, and the state transition test cases are obtained by screening high-quality test cases through the fuzzing method with reduced migration cost. The method is:

[0041] 2.1 Use the instrumentation tool of LLVM-10 (see llvm / llvm-project:The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. , find the definition or use position of node1, node2, …, node k , …, node K in FiltVar in Prog source code, and instrument at these positions in Prog source code to generate instrumented intermediate representation file Prog_IR. At this time, node1, node2, …, node k , …, node K are the corresponding K instrumentation positions.

[0042] 2.2 Use the clang-10 compiler (see Clang 10.0.0Release Notes—Clang 10documentation ) to compile Prog_IR into an executable target program Prog_I. During the compilation process, use the memory error checking tool AddressSanitizer (AddressSanitizer, a tool for detecting C / C++ program memory errors (such as out-of-bound access, use-after-free, etc.), first released in 2012, see AddressSanitizer Wiki ) to detect the crash information of the target program Prog_I.

[0043] 2.3 Based on PoC, use the fuzzing tool AFL-FUZZ (see The AFL++ fuzzing framework|AFLplusplus , version 2.65d) to generate a test case set S, S = {s1, s2, …, s f , …, s F}, 1≤f≤F, S is a test case set generated by AFL-FUZZ based on PoC, F is the total number of test cases in S, s f is the fth test case in S.

[0044] 2.4 Data richness screening and crash judgment classification of test case set S, get state transition test case set TransVar, the method is:

[0045] 2.4.1 Initialize the minimum value Min of the state transition of the test case to +∞, initialize the current test case state transition difference Min' to +∞, initialize the number of the test case passing through the vulnerability crash node Counts_crash to 0, initialize the number of the test case not passing 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, and initialize the test case real state label set Y to empty. Let the variable f = 1 and t = 1.

[0046] 2.4.2 Initialize the initial value H0 of the test case data richness value_hash to 0, let the initial value of the number of the test case passing through the vulnerability crash node Counts be 0, and let k = 1.

[0047] 2.4.3 Put s f into the instrumented target program Prog_I, run Prog_I, and calculate the data richness value_hash of s f according to the running situation, the method being:

[0048] 2.4.3.1 When Prog_I passes through node k , obtain the instrumented variable value X k corresponding to node k , and let Counts = Counts + 1.

[0049] 2.4.3.2 Calculate the hash value H k-1 of H k and X k , that is, H k = hash(H k-1 , X k ).

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

[0051] 2.4.3.4 If k > K, it is indicated that the data richness calculation of s f is completed, the final value_hash is obtained, and 2.4.3.5 is turned to; if k ≤ K, 2.4.3.1 is turned to.

[0052] 2.4.3.5 The test case s f is executed in the target program Prog_I, and if s fCauses Prog_I to crash (using AddressSanitizer can echo the crash signal), record the crash information variable flag = 1; if s f If it does not cause Prog_I to crash, then set flag to 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 time, value_hash∈HashVar, indicating the test case s f No increase in data richness, i.e. s f If no new program behavior is introduced (such as new execution paths and variable state combinations), the s f , let f = f + 1, if f ≤ F, go to 2.4.2 and operate on the next test case; if f > F, go to 2.4.6;

[0055] 2.4.3.6.2 At this time, value_hash is not in HashVar, so determine s i Increased data richness, transferred to 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 tth test case s that meets the requirements of increasing data richness and reducing migration cost. f Stored in the state transition test case set TransVar, that is, s f Become the tth element TV in TransVar t , add value_hash to the test case data richness hash value set HashVar, let y f =1(indicates s f Will cause Prog_I to crash), set y f Add to the test case 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 , go to 2.4.4.3.

[0058] 2.4.4.2 Let Counts noncrash = Counts, let Min' = | Counts crash - Counts noncrash |, if Min' < Min, then add s f to the set Y, let Min = Min', let t = t + 1, go to 2.4.4.3; if Min' ≥ Min, then discard s f , go to 2.4.4.3. f f f , go to 2.4.4.3.

[0059] 2.4.4.3 If f < F, let f = f + 1, 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 real state label set Y are obtained, TransVar = {TV1, TV2,..., TV t ,..., TV T}, Y = {yl, y2,..., y t ,..., y T}, 1 ≤ t ≤ T, T is the total number of state transition test cases, TV t is the tth test case in TransVar that meets the increase in data richness and the decrease in migration cost, y t is the test case real state label of TV t , y t = 1 means that TV t will cause Prog_I to crash, y t = 0 means that TV t will not cause Prog_I to crash. Go to the third step.

[0060] Third step, based on Prog and PoC, obtain the candidate vulnerability trigger related node set Z by analyzing Prog through taint analysis, Z = {zl, z2,..., z r ,..., z R ​​Then, 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, that is, the optimized candidate vulnerability trigger-related node set Z'. Finally, the K-means clustering algorithm is used to cluster all test cases in TransVar using all candidate vulnerability trigger-related nodes in Z'. The accuracy of the clustering results is evaluated using the true 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 location result. The method is as follows:

[0061] 3.1 Input PoC into Prog and use DFSan, a dynamic instrumentation tool based on LLVM (see the LLVM official document " DataFlowSanitizer—Clang21.0.0git documentation ”) Trace the propagation path of 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, R is the total number of nodes related to the candidate vulnerability trigger, z r is the rth contaminated node in Prog, which is also the rth candidate vulnerability triggering related node in Z.

[0062] 3.2 Due to the large scale of software and complex data flow, taint analysis may track a large number of nodes that are not related to the vulnerability, such as intermediate variables that are only contaminated on certain execution paths but do not affect the crash, or redundant contamination points introduced by pointer aliases and control flow branches. In order to narrow the scope of nodes related to vulnerability triggering, the mutual information algorithm (MutualInformation, see Research on Mutual Information Feature Selection Algorithm Based on Grassberger Entropy - Baidu Academic, Lanzhou University, 2015 ) Screen Z and generate an optimized and sorted candidate vulnerability trigger related node set Z' and a set VSet for clustering operations, Z'={z'1,z'2,…,z' p ,z' p+1 ,…,z' P}, P≤R,z' p is the pth optimized candidate vulnerability triggering related node in Z', VSet={V'1,V'2,…,V' p ,…,V' P}, V' p It's z' p The corresponding candidate vulnerability triggers the relevant node status set.

[0063] The specific method is as follows:

[0064] 3.2.1 Let t = 1, initialize Z' as empty, set vulnerability preference threshold θ, require θ satisfy 0 < θ < 1, preferably θ = 0.5; initialize R vulnerability trigger related node state sets V1, V2,..., V r ,..., V R as empty, V r is the rth vulnerability trigger related node state set.

[0065] 3.2.2 Let variable r = 1.

[0066] 3.2.3 Input TV t into Prog, debug prog using GDB debugger and record candidate vulnerability trigger related node z r , add z r into V r .

[0067] 3.2.4 Let r = r + 1, if r ≤ R, go to 3.2.2; if r > R, it means that the state record of candidate vulnerability trigger related node set Z under the condition that TV t is input into Prog is completed, go 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 candidate vulnerability trigger related node state set V1, V2,..., V t ,..., V T under the condition that TV1, TV2,..., TV r ,..., TV R is input into Prog is obtained, go to 3.2.6;

[0069] 3.2.6 Initialize a two-dimensional feature empty array X, add V1, V2,..., V r ,..., V R to array X according to subscript order, get 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 scikit-learn library (see mutual_info_ classif—scikit-learn 1.6.1 documentation for details), the function is to calculate the mutual information value of X and Y), get mutual information value set MI, MI = {mi1, mi2,..., mi r ,..., mi R}, mi r is the rth mutual information value in MI, used to measure the correlation between V rCorresponding z r Correlation with the program Prog crashing, 0≤mi r ≤1, mi r The greater, the greater the correlation between z r and the program Prog crashing.

[0070] 3.2.7 Screening and sorting the candidate vulnerability trigger related node set Z to obtain the sorted candidate vulnerability trigger related node set Z', and generating a set VSet for clustering operation, VSet={V'1, V'2, …, V' p , …, V' P}, V' p Corresponding to z' p , is z' p The corresponding candidate vulnerability trigger related node state set.

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

[0072] 3.2.7.2 If mi r ≥θ, it means that z r is sufficiently correlated with the program Prog crashing, z' p =z r , V' p =V r , z' p is added to Z', V' p is added to VSet, r=r+1, p=p+1, and step 3.2.7.3 is transferred; if mi r <θ, directly transfer to step 3.2.7.3.

[0073] 3.2.7.3 If r≤R, transfer to 3.2.7.2; if r>R, it means that the elements in Z are optimized, 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} are obtained, where P≤R, and V' p Corresponding to z' p , one-to-one correspondence. According to the mutual information value of each element in Z', the elements in Z' and VSet are sorted synchronously, the greater the mutual information value, the smaller the subscript of the corresponding element, and the sorted candidate vulnerability trigger related node set Z' and VSet are obtained, Z'={z'1,z'2,…,z' p ,z' p+1 ,…,z'P}, VSet = { V'1, V'2,..., V'p}, P≤R, z' p , p+1 , P}, P≤R, z' p is the pth optimized candidate vulnerability trigger related node in Z', V' p is the pth optimized candidate vulnerability trigger related node in Z', V' p is the corresponding candidate vulnerability trigger related node state set, z' p is the corresponding mutual information value, z' p+1 is the corresponding mutual information value, go to step 3.3.

[0074] 3.3 For further inference of vulnerability causes and give the probability ranking of its as a real vulnerability cause, based on the set VSet and the candidate vulnerability trigger related node set Z', the K-means clustering algorithm is used (see Cluster analysis algorithm——K- Detailed Explanation of Means Clustering - CSDN Blog ), the TransVar is clustered, and the Z' is sorted according to the clustering results and the ranking set RankingVar of the vulnerability cause position is obtained, the specific steps are as follows:

[0075] 3.3.1 Let p = 1;

[0076] 3.3.2 Based on z' p and V' p , a feature vector is constructed for TV1, TV2,..., TV t ,..., TV T in TransVar respectively, and the pth test case feature vector set F p is obtained, F p = {f1 (p) , f2 (p) ,..., f t (p) ,..., f T (p)}, f t (p) is a feature vector constructed based on the state information (such as variable value, execution path or node state) of TV t in z' p and V' p (construction method see Cluster Analysis Algorithm - K-means Clustering Detailed Explanation - CSDN Blog ). Set the target cluster number U = 2, take F p as input, and divide the test cases in TransVar into two clusters by K-means clustering algorithm, let C 1p and C 2p , C 1p represents the cluster of crash test cases obtained by clustering analysis on z' p , C2p Indicates z' p Clusters of non-crash test cases obtained by cluster analysis.

[0077] 3.3.3 Using TV1, TV2,…, TV in TransVar t ,…,TV T The true state labels y1,y2,…,y t ,…,y T Evaluate the clustering results, for TV t , if TV t Classified as C 1p And y t =1, or TV t Classified as C 2p And y t =0, then TV t The classification is correct.

[0078] 3.3.4 Statistics of TV1, TV2,…, TV t ,…,TV T The number of correctly classified elements in samples p , calculated based on z' p and V' p Accuracy of the clustering results of the constructed feature vector p , Accuracy p =(samples p ) / T, where Accuracy p Indicates based on z' p and V' p The degree of consistency between the clustering results of the constructed feature vector and the true state label;

[0079] 3.3.5 Let p = p + 1; if p ≤ P, go to 3.3.2; if p > P, for all z' in Z', p The cluster analysis is completed and the accuracy set Accuracy is obtained, Accuracy = {Accuracy1, Accuracy2,…, Accuracy p ,…,Accuracy P}, go to 3.3.6;

[0080] 3.3.6 Perform a second round of sorting on the elements in Z' based on the size of each element in Accuracy from high to low. After the second round of sorting, the vulnerability cause ranking set RankingVar = {rank1, rank2, ..., rank p ,…rank P}, rank pThat is, the element ranked p from high to low in the accuracy of Z', if 1≤a≤b≤P, then rank a The accuracy Accuracy a of the element ranked a is greater than or equal to the accuracy Accuracy b of the element ranked b, that is, rank b a a represents the consistency degree of the clustering result based on z' a with the real state label, and Accuracy b represents the consistency degree of the clustering result based on z' b with the real state label.

[0081] After obtaining the probability ranking set RankingVar of the vulnerability causes, the most likely vulnerability triggering position and the related code fragments in Prog can be identified by using RankingVar, and then the code fragments (for example, the code fragments ranked in the top few in RankingVar) are sent to the existing vulnerability repair large model together with the necessary context information (such as function call stack or variable definition). The vulnerability repair large model focuses on the most likely vulnerability triggering position and the related code fragments according to RankingVar, thereby improving the accuracy and efficiency of repair, reducing the misjudgment or redundant modification of irrelevant code, and finally achieving fast and accurate vulnerability repair. Therefore, RankingVar is the result of locating the vulnerability causes of Prog by using the present application.

[0082] Compared with the prior art, the present application has the following beneficial effects:

[0083] 1.The first step of the present application is based on the vulnerability crash related node inference method to infer the vulnerability crash related node, the second step is to generate high-quality test cases through the high-quality test case generation method based on data richness guidance, and to screen state transition test cases through the fuzzing test method based on migration cost reduction, the third step is to significantly improve the accuracy of vulnerability cause positioning through mutual information algorithm and K-means clustering.The present application is used in a plurality of open source software (such as mruby, libtiff, lua, libzip, libjpeg and 15 vulnerability samples), which verifies the superiority of the present application.The results show that the present application 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, which is much better than the existing methods Aurora and Racing.For example, in the CVE-2022-0240 vulnerability of mruby, the present application ranks the real vulnerability cause first, while Aurora ranks the real vulnerability cause eighth, and Racing fails to locate the real vulnerability cause;In the CVE-2017-12858 of libzip, the present application ranks the real vulnerability cause first, Aurora ranks the real vulnerability cause ninth, and Racing ranks the real vulnerability cause twenty-fourth.Compared with Aurora and Racing, the average ranking of the present application is increased by about 85%, which significantly reduces the misleading positioning results, and provides more accurate vulnerability cause positioning for developers.

[0084] 2.The present application quickly filters irrelevant candidate positions through the mutual information algorithm in the third step, and combines K-means clustering to accurately classify state transition test cases, which shows high computing performance.Experiments show that in 15 test cases, the cause positioning time of the present application is usually controlled within 1 minute, such as the real vulnerability cause of analyzing the CVE-2017-12858 vulnerability of open source software libzip, which takes 4 seconds, and the real vulnerability cause of analyzing the CVE-2023-3164 vulnerability of open source software libtiff, which takes 9 seconds.This efficiency ensures that in a complex software environment, the present application can quickly generate vulnerability cause ranking, meet the dual demands of real-time and accuracy in actual development scenarios.At the same time, the present application reduces the computational burden of subsequent analysis through high-quality test case generation, further improving the overall positioning efficiency.

[0085] 3. The generated vulnerability cause location ranking set (RankingVar) of the present application provides high-priority cause code segments for existing vulnerability repair large models, significantly improving the targeting and success rate of repair. The experimental results (see Table 1) show that the present application ranks the real causes in the top 5 in 93.3% of the test cases (such as lua bug#5.0-2 ranked 5th and readelf CVE-2022-45703 ranked 1st), ensuring that the repair model can quickly focus on key code areas, reducing false positives and redundant modifications of irrelevant code. For example, in the CVE-2019-14934 vulnerability of pdfresurrect, the present application ranks first, accurately locating the cause code, greatly shortening the repair and investigation time compared to Aurora (ranking 6th) and Racing (unable to locate). The precise positioning capability of the present application effectively reduces the vulnerability repair cycle and enhances the ability of software systems to resist attacks. BRIEF DESCRIPTION OF DRAWINGS

[0086] Figure 1 is a general flowchart of the present application. DETAILED DESCRIPTION

[0087] The specific examples of the present application will be described below in conjunction with the accompanying drawings. As shown in Figure 1 , the present application includes the following steps:

[0088] First, a dynamic and static combined vulnerability crash related node inference method is used to infer the vulnerability crash related nodes, the method is:

[0089] 1.1 Use the compilation framework LLVM to compile the target program Prog to generate intermediate code IRProg independent of the source code language and hardware;

[0090] 1.2 Use the SVF tool to perform value flow analysis on IRProg to construct the inter-process sparse value flow graph VFG of IRProg, VFG={(node 11 ,node 12 ,edge1),…,(node n1 ,node n2 ,edge n ),…,(node N1 ,node N2 ,edge N )},1≤n≤N,N is the total number of value flow dependencies in VFG, node n1 , node n2 are nodes in VFG, containing a certain statement in IRProg, or a certain parameter, or a certain variable, or a certain block memory area, edge n is an edge in VFG, indicating the dependence of noden1 pointing to node n2 value flow dependency relationship;

[0091] 1.3 input the initial proof of concept PoC into Prog and run Prog, record the statement and parameter information at the crash of Prog, let be CrashInfo = {var1, var2, …, var q , …, var Q}, 1≤q≤Q, Q is the total number of statement and parameter information at the crash of Prog, var q is the qth statement and parameter information in CrashInfo.

[0092] 1.4 traverse VFG, so that the elements in CrashInfo correspond to the nodes in VFG, generate the initial vulnerability crash point node address set CrashVar, the method is:

[0093] 1.4.1 let variable i = 1, n = 1, initialize CrashVar to be empty;

[0094] 1.4.2 take out the nth triple (node n1 , node n2 , edge n ) in VFG, extract the statement and parameter information contained in node n2 , put the statement and parameter information contained in node n2 into the statement and parameter information set NodeInfo n2 of node n2 , NodeInfo n2 = {var1, var2, …, var p , …, var P}, 1≤p≤P, P is the total number of statement and parameter information contained in node n2 , var p is the pth statement and parameter information in NodeInfo.

[0095] 1.4.3 take intersection operation on CrashInfo and NodeInfo n2 , get intersection result Res;

[0096] 1.4.4 if Res is empty, it means that node n2 is not the initial vulnerability crash node, go to 1.4.6; if it is not empty, it means that node n2 has the same statement and parameter information as CrashInfo, which may be related to the generation of the crash, go to 1.4.5;

[0097] 1.4.5 record node n2 nodeAddr i , which is the corresponding address of the i-th initial vulnerability crash node in VFG i , if nodeAddr i is not in CrashVar, add node i to CrashVar, and let i = i + 1, go to step 1.4.6; if nodeAddr i already exists in CrashVar, do not make any operation to CrashVar, and go to step 1.4.6 directly;

[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 vulnerability crash node address set CrashVar is obtained, CrashVar = {nodeAddr1, nodeAddr2, …, nodeAddr I , 1≤i≤I, I is the total number of initial vulnerability crash node addresses, go to step 1.5; if n≤N, it means that the traversal of VFG has not been completed, go to step 1.4.2;

[0100] 1.5 analyze VFG, identify other potential vulnerability crash statements and parameter information that have data flow relationship with the corresponding initial vulnerability crash nodes in CrashVar, and generate suspicious vulnerability crash node address set SusVar, the method is as follows:

[0101] 1.5.1 initialize SusVar = CrashVar, load nodeAddr1, nodeAddr2, …, nodeAddr i , …, nodeAddr I in CrashVar to 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 to-be-verified node has been completed, go to step 1.5.5;

[0103] 1.5.3 take out the first element (let it be nodeAddr i ) at the head of queue NodeQueue, extract the node corresponding to nodeAddr i , let it be node i2 , and find node i2(node i1 , node i2 , edge i ) exists, if yes, go to step 1.5.4; if no, delete nodeAddr i from NodeQueue, go to step 1.5.2;

[0104] 1.5.4 based on the value flow dependency relationship of edge i in VFG, if node i2 in VFG is a suspected vulnerability collapse node, node i1 is also a suspected vulnerability collapse node. Add the address nodeAddr i1 of node i to the tail of NodeQueue, and add nodeAddr i to the set SusVar, let I = I + 1, delete nodeAddr i from NodeQueue, and go to step 1.5.2;

[0105] 1.5.5 at this time |NodeQueue| = 0, which means that the extraction of suspected vulnerability collapse nodes has been completed, and the set SusVar of suspected vulnerability collapse node addresses is obtained, SusVar = {nodeAddr1, nodeAddr2, …, nodeAddr m , …, nodeAddr M}, 1≤m≤M, M is the total number of suspected vulnerability collapse node addresses, M = I, nodeAddr m and nodeAddr i have the same meaning, which is the corresponding address of the mth suspected vulnerability collapse node in VFG, and the subscript m is only used to indicate that the number of elements in SusVar is different from that in CrashVar, go to step 1.6;

[0106] 1.6 compile Prog using CLANG;

[0107] 1.7 track the actual execution path of Prog through the dynamic debugging function of GDB debugger, set breakpoints at all suspected vulnerability collapse node addresses contained in SusVar, and filter out the nodes actually participating in running according to the breakpoint hit condition in the execution process, and extract the suspected vulnerability collapse node set FlitVar, the method is:

[0108] 1.7.1 let the suspected vulnerability collapse node set FlitVar be empty, and extract nodeAddr1, nodeAddr2, …, nodeAddr m from SusVar...., nodeAddr M The statements, parameter information contained in the corresponding nodes in the VFG, i.e. node1, node2,..., node m ..., node M .

[0109] 1.7.2 Setting breakpoints B1, B2,..., B m ..., B M in Prog using GDB debugger, i.e. setting breakpoint B1 at node1 of Prog, setting breakpoint B2 at node2 of Prog,..., setting breakpoint B m at node m of Prog,..., setting breakpoint B M at node M of Prog, obtaining the Prog with breakpoints set; initializing variable k = 1;

[0110] 1.7.3 Running the Prog with breakpoints set in GDB debugger using PoC as input;

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

[0112] 1.7.5 Add node m at B m to the set FiltVar, node m becomes the kth element of the set FiltVar, representing the kth suspicious vulnerability crash node node k in the program Prog, let k = k + 1, go to step 1.7.3, continue running the Prog with breakpoints set in the GDB debugger;

[0113] 1.7.6 Add node crash at the crash point to the set FiltVar, node crash becomes the kth element node k of FiltVar;

[0114] 1.7.7 Obtain the set of suspicious vulnerability crash nodes FiltVar, FiltVar = {node1, node2,..., node k ..., node K}, 1≤k≤K, K is the total number of suspicious vulnerability crash nodes, K≤M;

[0115] At this time, the set FiltVar only retains nodes that both appear on the PoC real execution path and have a static value flow relationship with the initial vulnerability crash node, ensuring that no real vulnerability crash-related nodes are mistakenly deleted, while improving the accuracy and efficiency of the set FiltVar, providing precise data support for subsequent test case generation and vulnerability cause localization, and turning to the second step.

[0116] Secondly, a high-quality test case generation method based on data richness guidance is used to monitor the value of the vulnerability crash node in FiltVar during the execution of the test cases generated during the fuzz testing process, and the data richness of the value is used as a guide to generate high-quality test cases with increased data richness, and state transition test cases are obtained by screening high-quality test cases through a fuzz testing method with reduced migration cost. The method is:

[0117] 2.1 Use the instrumentation tool of LLVM-10 to find the definition or use location of node1, node2, …, node k ,…,node K in Prog source code and instrument at these locations in Prog source code to generate the instrumented intermediate representation file Prog_IR. At this time, node1, node2, …, node k ,…,node K are the corresponding K instrumentation locations.

[0118] 2.2 Use the clang-10 compiler to compile Prog_IR into an executable target program Prog_I. During compilation, use the memory error checking tool AddressSanitizer to detect crash information of the target program Prog_I.

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

[0120] 2.4 Data richness screening and crash judgment classification are performed on the test case set S to obtain the state transition test case set TransVar, the method is:

[0121] 2.4.1 Initialize the minimum value of state transition of test case Min as +∞, initialize the current minimum value of state transition of test case Min' as +∞, initialize the number of test cases passing through the vulnerability crash node Counts_crash as 0, initialize the number of test cases not passing through the vulnerability crash node Counts_noncrash as 0, initialize the set of state transition test cases TransVar as empty, initialize the set of test case data richness hash values HashVar as empty; initialize the crash information record variable flag as 0, initialize the set of real state labels of test cases Y as empty. Let the variable f = 1, t = 1;

[0122] 2.4.2 Initialize the initial value of test case data richness value_hash as H0 = 0, let the initial value of the number of test cases passing through the vulnerability crash node Counts be 0, and let k = 1;

[0123] 2.4.3 Put s f into the instrumented target program Prog_I, run Prog_I, and calculate the data richness value_hash of s f according to the running situation, the method being:

[0124] 2.4.3.1 When Prog_I passes through node k , obtain the value X k of the instrumented variable corresponding to node k , and let Counts = Counts + 1;

[0125] 2.4.3.2 Calculate the hash value H k-1 of H k and X k , that is, H k = hash(H k-1 , X k )

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

[0127] 2.4.3.4 If k > K, it is indicated that the calculation of the data richness of s f is completed, the final value_hash is obtained, and 2.4.3.5 is turned to; if k ≤ K, 2.4.3.1 is turned to;

[0128] 2.4.3.5 The test case s f is executed in the target program Prog_I, and if s fCauses Prog_I to crash (using AddressSanitizer can echo the crash signal), record the crash information variable flag = 1; if s f If it does not cause Prog_I to crash, then set flag to 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 time, value_hash∈HashVar, indicating the test case s f No increase in data richness, i.e. s f If no new program behavior is introduced (such as new execution paths and variable state combinations), the s f , let f = f + 1, if f ≤ F, go to 2.4.2 and operate on the next test case; if f > F, go to 2.4.6;

[0131] 2.4.3.6.2 At this time, value_hash is not in HashVar, so determine s i Increased data richness, transferred to 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 tth test case s that meets the requirements of increasing data richness and reducing migration cost. f Stored in the state transition test case set TransVar, that is, s f Become the tth element TV in TransVar t , add value_hash to the test case data richness hash value set HashVar, let y f =1(indicates s f Will cause Prog_I to crash), set y f Add to the test case 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 , go to 2.4.4.3.

[0134] 2.4.4.2 Let Counts noncrash = Counts, let Min' = | Counts crash - Counts noncrash |, if Min' < Min, then add s f to set Y, let Min = Min', let t = t + 1, go to 2.4.4.3; if Min' ≥ Min, then discard s f , go to 2.4.4.3. f f , go to 2.4.4.3. f .

[0135] 2.4.4.3 If f < F, let f = f + 1, 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 real state label set Y are obtained, TransVar = {TV1, TV2,..., TV t ,..., TV T}, Y = {yl, y2,..., y t ,..., y T}, 1 ≤ t ≤ T, T is the total number of state transition test cases, TV t is the tth test case in TransVar that meets the increase in data richness and the decrease in migration cost, y t is the test case real state label of TV t , y t = 1 means that TV t will cause Prog_I to crash, y t = 0 means that TV t will not cause Prog_I to crash. Go to the third step.

[0136] Third step, based on Prog and PoC, obtain the candidate vulnerability trigger related node set Z by analyzing Prog through taint analysis, Z = {zl, z2,..., z r ,..., z R .}。Then, 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, that is, the optimized candidate vulnerability trigger related node set Z'. Finally, the K-means clustering algorithm is used to cluster all test cases in TransVar in Z' respectively, and the accuracy of the clustering result is evaluated by using the real state label of the test case. According to the accuracy of the clustering result, all candidate vulnerability trigger related nodes in Z' are ranked as the final vulnerability cause positioning result. The method is as follows:

[0137] 3.1 PoC is input into Prog, the dynamic instrumentation tool DFSan based on LLVM is used to track the propagation path of PoC, all contaminated nodes in Prog are identified, and all contaminated nodes in Prog are added to the candidate vulnerability trigger related node set Z, Z = {z1, z2, …, z r ,…,z R}, 1≤r≤R, R is the total number of candidate vulnerability trigger related nodes, z r is the rth contaminated node in Prog, that is, the rth candidate vulnerability trigger related node in Z.

[0138] 3.2 Due to the large size of software and complex data flow, the taint analysis may track a large number of nodes irrelevant to the vulnerability, such as intermediate variables contaminated only on some execution paths but not affecting the crash, or redundant taint points introduced by pointer aliasing and control flow branching. In order to narrow down the range of vulnerability trigger related nodes, the mutual information algorithm is used to screen Z to generate the optimized and sorted candidate vulnerability trigger related node set Z' and the set VSet for clustering operation, Z' = {z'1, z'2, …, z' p ,z' p+1 ,…,z' P}, P≤R, z' p is the pth optimized candidate vulnerability trigger related node in Z', VSet = {V'1, V'2, …, V' p ,…,V' P}, V' p is the candidate vulnerability trigger related node state set corresponding to z' p . The specific method is as follows:

[0139] 3.2.1 Let t = 1, initialize Z' as empty, set the vulnerability preference threshold, require that 0 < θ < 1, and preferably θ = 0.5; initialize the R vulnerability trigger related node state sets V1, V2, …, V r ,…,V R as empty, and V r is the rth vulnerability trigger related node state set.

[0140] 3.2.2 Let variable r = 1.

[0141] 3.2.3 TV t Input into Prog, use GDB debugger to debug prog and record the candidate vulnerability triggering related nodes z r , 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 states of the node set Z related to the candidate vulnerability triggering when used as the input of Prog are recorded. Go 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 is obtained. t ,…,TV T The candidate vulnerability triggers the related node state set V1, V2, ..., V as the input of Prog r ,…,V R , go to 3.2.6;

[0144] 3.2.6 Initialize a two-dimensional feature empty array X and put V1, V2, ..., V r ,…,V R Add to array X, and get 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 mutual_info_ classif—scikit-learn 1.6.1 documentation ), the function 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 is the rth mutual information value in MI, which is used to measure V in X r The corresponding z r Correlation with the crash of program Prog, 0≤mi r ≤1, mi r The larger the value, the z r The more relevant it is to the program Prog crash.

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

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

[0147] 3.2.7.2 If mi r ≥θ, indicating that z r is sufficiently related to the crash of program Prog, let z' p =z r , let V' p =V r , z' p Add to Z', V' p Add to VSet, set r = r + 1, set p = p + 1, go to step 3.2.7.3; if mi r <θ, go directly to step 3.2.7.3.

[0148] 3.2.7.3 If r ≤ R, go to 3.2.7.2; if r > R, the elements in Z are selected and 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. According to the mutual information value corresponding to each element in Z', the elements in Z' and VSet are sorted synchronously. The larger the mutual information value, the smaller the corresponding element index. The sorted candidate vulnerability triggering related node set Z' and VSet are obtained, 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 is the pth optimized candidate vulnerability triggering node in Z', V'p is z' p a corresponding candidate vulnerability trigger related node state set, z' p a corresponding mutual information value > z' p+1 a corresponding mutual information value, go to step 3.3.

[0149] 3.3 To further infer the vulnerability cause and give its probability ranking as a real vulnerability cause, based on the set VSet and the candidate vulnerability trigger related node set Z', a K-means clustering algorithm is used to cluster TransVar, and according to the results obtained after clustering, Z' is sorted and a ranking set RankingVar of vulnerability cause positions is obtained. The specific steps are as follows:

[0150] 3.3.1 Let p = 1;

[0151] 3.3.2 Based on z' p and V' p , a feature vector is constructed for TV1, TV2, …, TV t , …, TV T in TransVar respectively, and the pth test case feature vector set F p is obtained, F p = {f1 (p) , f2 (p) , …, f t (p) , …, f T (p)}, f t (p) is a feature vector constructed based on the state information (such as variable value, execution path or node state) of TV t in z' p and V' p . Set the target cluster number U = 2, and take F p as input, and divide the test cases in TransVar into two clusters by the K-means clustering algorithm, let C 1p and C 2p be C 1p , C p , C 2p , C p , which represent the cluster analysis results of z' t .

[0152] 3.3.3 Use the real state labels y1, y2, …, y T , …, y t of TV1, TV2, …, TV T in TransVar to sort Z' and obtain the ranking set RankingVar of vulnerability cause positions.Evaluate the clustering results, for TV t , if TV t Classified as C 1p And y t =1, or TV t Classified as C 2p And y t =0, then TV t The classification is correct.

[0153] 3.3.4 Statistics of TV1, TV2,…, TV t ,…,TV T The number of elements correctly classified in samples p , calculated based on z' p and V' p Accuracy of the clustering results of the constructed feature vector p , Accuracy p =(samples p ) / T, where Accuracy p Indicates based on z' p and V' p The degree of consistency between the clustering results of the constructed feature vector and the true state label;

[0154] 3.3.5 Let p = p + 1; if p ≤ P, go to 3.3.2; if p > P, for all z' in Z', p The cluster analysis is completed and the accuracy set Accuracy is obtained, Accuracy = {Accuracy1, Accuracy2,…, Accuracy p ,…,Accuracy P}, go to 3.3.6;

[0155] 3.3.6 Perform a second round of sorting on the elements in Z' based on the size of each element in Accuracy from high to low. After the second round of sorting, the vulnerability cause ranking set RankingVar = {rank1, rank2, ..., rank p ,…rank P}, rank p That is, the element with the highest accuracy in Z' ranked p, if 1≤a≤b≤P, then rank a Accuracy a ≥rank b Accuracy b ,Accuracy a Indicates based on z' a The degree of consistency between the clustering results and the true state labels, Accuracyb represents the degree of consistency of the clustering results based on z b with the true status labels.

[0156] To verify the effect of the application vulnerability cause analysis method, a comparative experiment of the application and the Aurora and Racing methods in the background art was carried out on a computer loaded with an Ubuntu 22.04 operating system and Intel(R) Xeon(R) Gold 6430 and 256 GB RAM.

[0157] Fifteen vulnerabilities from the real world were selected in the experiment, covering multiple open source software, including mruby, libtiff, lua, readelf, nm, libzip, libjpeg, nasm, ezXML and pdfresurrect. The number of source code lines corresponding to these vulnerabilities ranged from 857 to 980,019 lines. These vulnerabilities covered 8 different types of common software vulnerability types, including NULL Pointer Dereference, heap-buffer-overflow, use-after-free, integer overflow, out-of-bounds write, uninitialized variable, divide-by-zero and negation overflow. Specific vulnerabilities include CVE-2022-0240, CVE-2023-3164, CVE-2017-12858, etc. See Table 1 for detailed information.

[0158] Referring to the comparison method of Racing, to ensure the sufficiency of the test case generation, if the number of test cases generated by Aurora within 2 hours is less than 100, 10 hours of fuzz testing are added, for a total of 12 hours. The fuzz testing time of the application is fixed at 30 minutes to ensure high-quality test case generation, followed by cause analysis. In terms of evaluation criteria, the official patch of the vulnerability is taken as the true vulnerability cause, and the evaluation method in Aurora is referred to: if the true vulnerability cause appears within the top 50 in the result ranking, it is determined to be successfully located; the position of the true vulnerability cause in the result ranking is taken as the main indicator of accuracy.

[0159] The first to third steps of the present application are performed to generate the vulnerability cause location ranking set RankingVar, and the positioning results of Aurora and Racing are compared. The accuracy comparison results of the present application and Aurora and Racing in vulnerability cause positioning are shown in Table 1. Table 1 shows that the present application has a significant advantage in positioning accuracy. Among the 15 test cases, the present application ranks the real vulnerability cause first in 73.3% of the cases, ranks the top 5 in 93.3% of the cases, and the positioning success rate reaches 100%. In contrast, Aurora fails to locate in 33.3% of the cases, marked as X, and the average ranking is higher than that of the present application; Racing fails to locate in 26.7% of the cases, and the ranking in the successfully located cases is generally poor. As in the analysis of the CVE-2022-0240 vulnerability of the open source software mruby, the present application ranks the real vulnerability cause first, Aurora ranks the real vulnerability cause eighth, and Racing fails to successfully locate the real vulnerability cause; in the analysis of the CVE-2023-3164 vulnerability of the open source software libtiff, the present application ranks the real vulnerability cause first, Aurora fails to successfully locate the real vulnerability cause, and Racing ranks the real vulnerability cause sixteenth.

[0160] Table 1 Comparison of vulnerability cause positioning accuracy of the present application, Aurora and Racing

[0161]

[0162]

[0163] The comparison results of the present application, Aurora and Racing in vulnerability cause analysis time are shown in Table 2. Table 2 shows that the cause positioning time of the present application is efficient, usually completed within 1 minute, such as in the analysis of the real vulnerability cause of the CVE-2017-12858 vulnerability of the open source software libzip, which takes 4 seconds, while Aurora takes 1 minute and 53 seconds, and Racing takes 10 seconds; in the analysis of the real vulnerability cause of the CVE-2023-3164 vulnerability of the open source software libtiff, it takes 9 seconds, while Aurora takes 23 minutes and 26 seconds, and Racing takes 1 minute. The present application shows good practicability.

[0164] Table 2 Comparison of vulnerability cause analysis time of the present application, Aurora and Racing

[0165]

[0166]

Claims

1. A vulnerability cause location method based on data richness and migration cost perception, characterized by The following steps are involved: The first step is to use the vulnerability crash related node inference method based on the combination of dynamic and static inference to infer the vulnerability crash related nodes. The method is: 1.1 Use the compilation framework LLVM to compile the target program Prog and generate the intermediate code IRProg that is independent of the source code language and hardware; 1.2 Use SVF tool to analyze the value flow of IRProg and construct the inter-procedural sparse value flow graph VFG of IRProg, VFG={(node 11 ,node 12 ,edge1),…,(node n1 ,node n2 ,edge n ),…,(node N1 ,node N2 ,edge N )}, 1≤n≤N, N is the total number of flow dependencies in the VFG, node n1 、node n2 It is a node in VFG, and its content is a statement, parameter, variable, or memory area in IRProg. n It is the edge in VFG, indicating the edge from node n1 Point to node n2 The value stream dependencies of 1.3 Input the initial proof-of-concept PoC into Prog and run Prog, record the statement and parameter information of the crash of Prog, let CrashInfo = {var1, var2, ..., var q ,…,var Q }, 1≤q≤Q, Q is the total number of statements and parameter information where the Prog crashes, var q It is the qth statement and parameter information in CrashInfo; 1.4 Traverse the VFG so that the elements in CrashInfo form a corresponding relationship with the nodes in VFG, and generate the initial vulnerability crash point node address set CrashVar, CrashVar = {nodeAddr1, nodeAddr2, ..., nodeAddr i ,…,nodeAddr I }, 1≤i≤I, I is the total number of addresses of the initial vulnerability crash nodes; 1.5 Analyze VFG, identify other potential vulnerability crash statements and parameter information that have data flow relationships with the initial vulnerability crash node corresponding to CrashVar, and generate a suspicious vulnerability crash node address set SusVar, SusVar = {nodeAddr1, nodeAddr2, ..., nodeAddr m ,…,nodeAddr M }, 1≤m≤M, M is the total number of addresses of nodes with suspected vulnerability crashes, nodeAddr m with nodeAddr i The meaning is the same, which is the corresponding address of the mth suspected vulnerability crash node in the VFG; 1.6 Use CLANG to compile Prog; 1.7 Use the dynamic debugging function of the GDB debugger to track the actual execution path of Prog, set breakpoints at the addresses of all suspected vulnerability crash nodes contained in SusVar, filter out the nodes actually involved in the execution according to the breakpoint hit situation during the execution process, and extract the set of suspected vulnerability crash nodes FlitVar, FiltVar = {node1, node2, ..., node k ,…,node K }, node k is the kth suspected vulnerability crash node in program Prog, 1≤k≤K, K is the total number of suspected vulnerability crash nodes, K≤M; In the second step, a high-quality test case generation method based on data richness guidance is used to monitor the values ​​of the vulnerability crash nodes in FiltVar of the test cases generated during the fuzz testing process. The data richness of the values ​​is used as a guide to generate high-quality test cases with increased data richness. The state transition test cases are obtained by screening high-quality test cases through a fuzz testing method with reduced migration cost. The method is as follows: 2.1 Use the LLVM-10 instrumentation tool to find node1, node2, ..., node in FiltVar in the Prog source code k ,…,node K The definition or use location of node1, node2,…, node k ,…,node K That is the corresponding K insertion positions; 2.2 Use the clang-10 compiler to compile Prog_IR into the executable target program Prog_I; during the compilation process, use the memory error checking tool AddressSanitizer to detect the crash information of the target program Prog_I; 2.3 Based on PoC, the fuzz testing tool AFL-FUZZ is used to generate 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 is the fth test case in S; 2.4 Perform data richness screening and crash judgment classification on the test case set S to obtain the state transition test case set TransVar and the test case true state label set Y, TransVar = {TV1, TV2, ..., TV t ,…,TV T }, Y={y1,y2,…,y t ,…,y T }, 1≤t≤T, T is the total number of state transition test cases, TV t To meet the t-th test case in TransVar with increased data richness and reduced migration cost, y t For TV t The true state label of the test case, y t =1 means TV t Will cause Prog_I to crash, y t =0 means TV t Will not cause Prog_I to crash; The third step is to obtain the candidate vulnerability trigger related node set Z based on Prog and PoC by taint analysis of Prog, Z = {z1,z2,…,z r ,…,z R Then, 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, that is, the optimized candidate vulnerability trigger-related node set Z', and the set VSet for clustering operations is generated at the same time. Finally, the K-means clustering algorithm is used to cluster all test cases in TransVar based on the set VSet and the candidate vulnerability trigger-related node set Z'. The accuracy of the clustering results is evaluated using the true state labels of the test cases. According to the accuracy of the clustering results, all candidate vulnerability trigger-related nodes in Z' are ranked as the final vulnerability cause location result. The method is as follows: 3.1 Input PoC into Prog, use DFSan, a dynamic instrumentation tool based on LLVM, to track the propagation path of PoC, identify all contaminated nodes in Prog, and add all contaminated nodes in Prog to the candidate vulnerability triggering related node set Z, where Z = {z1,z2,…,z r ,…,z R }, 1≤r≤R, R is the total number of nodes related to the candidate vulnerability trigger, z r is the rth contaminated node in Prog, which is also the node related to the rth candidate vulnerability trigger in Z; 3.2 Use the mutual information algorithm to screen Z and generate the optimized and sorted candidate vulnerability trigger related node set Z' and the set VSet for clustering operation, Z'={z'1,z'2,…,z' p ,z' p+1 ,…,z' P }, P≤R,z' p is the pth optimized candidate vulnerability triggering related node in Z'; z' p The corresponding mutual information value>z' p+1 Corresponding mutual information value; VSet = {V'1, V'2, ..., V' p ,…,V' P }, V' p It's z' p The corresponding candidate vulnerability triggers the relevant node status set; 3.3 Based on the set VSet and the candidate vulnerability trigger related node set Z', 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 is the element ranked p in Z' from high to low accuracy. If 1≤a≤b≤P, then rank a Accuracy a ≥rank b Accuracy b , Accuracy a Indicates based on z' a The degree of consistency between the clustering results and the true state labels, Accuracy b Indicates based on z' b The degree of consistency between the clustering results and the true state labels; RankingVar is the result of locating the cause of the vulnerability of Prog.

2. The vulnerability cause location method based on data richness and migration cost perception as described in claim 1 is characterized in that Traverse the VFG as described in step 1.4 to form a correspondence between the elements in CrashInfo and the nodes in VFG. The method to generate the initial vulnerability crash point node address set CrashVar is: 1.4.1 Set variables i = 1, n = 1, and initialize CrashVar to empty; 1.4.2 Take out the nth triplet (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 in the node n2 Statement and parameter information collection NodeInfo n2 NodeInfo n2 ={var1,var2,…,var p ,…,var P }, 1≤p≤P, P is a node n2 The total number of statements and parameter information contained in var p It is the pth statement and parameter information in NodeInfo; 1.4.3 CrashInfo and NodeInfo n2 Perform intersection operation to obtain the intersection result Res; 1.4.4 If Res is empty, go to 1.4.6; if not empty, go to 1.4.5; 1.4.5 Recording Node n2 The address is the corresponding address nodeAddr of the i-th initial vulnerability crash node in VFG i If nodeAddr i If it is not in CrashVar, then the node i Add CrashVar, set i=i+1, and go to step 1.4.6; if nodeAddr i If it already exists in CrashVar, go 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 vulnerability crash node address set CrashVar is obtained, CrashVar={nodeAddr1,nodeAddr2,…,nodeAddr i ,…,nodeAddr I }, end; if n≤N, it means that the traversal of the VFG has not been completed, go to 1.4.

2.

3. The vulnerability cause location method based on data richness and migration cost perception as described in claim 1 is characterized in that Analyze VFG as described in step 1.5, identify other potential vulnerability crash statements and parameter information that have a data flow relationship with the initial vulnerability crash node corresponding to CrashVar, and generate the suspicious vulnerability crash node address set SusVar as follows: 1.5.1 Initialize SusVar = CrashVar, and replace nodeAddr1, nodeAddr2, ..., nodeAddr i ,…,nodeAddr I Load into the node address queue NodeQueue, let |NodeQueue| be the number of elements in NodeQueue; 1.5.2 Set variable i = 1. If |NodeQueue| ≠ 0, go to step 1.5.

3. If |NodeQueue| = 0, the traversal of the nodes to be verified has been completed, so go to step 1.5.

5. 1.5.3 Take out the first element nodeAddr at the head of the queue NodeQueue i , extract nodeAddr i The corresponding node is node i2 , search for nodes in VFG i2 The triplet with the second element (node i1 ,node i2 ,edge i ) exists, if so, go to step 1.5.4; if not, delete nodeAddr from NodeQueue i , go to step 1.5.2; 1.5.4 Based on the edge in VFG i The value flow dependency relationship of VFG i2 Is a suspected vulnerability crash node, node i1 It is also a suspected vulnerability crash node; i1 The address nodeAddr i Add to the end of NodeQueue and add nodeAddr i Add to the set SusVar, set I = I + 1, and delete nodeAddr from NodeQueue i , go to step 1.5.2; 1.5.5 At this time, |NodeQueue|=0, indicating that the extraction of the suspected vulnerability crash nodes has been completed, and the suspicious vulnerability crash node address set SusVar is obtained, SusVar={nodeAddr1,nodeAddr2,…,nodeAddr m ,…,nodeAddr M }, 1≤m≤M, M is the total number of addresses of suspected vulnerability crash nodes, M=I.

4. The vulnerability cause location method based on data richness and migration cost perception as described in claim 1 is characterized in that As described in step 1.7, the actual execution path of Prog is tracked through the dynamic debugging function of the GDB debugger. Breakpoints are set at the addresses of all suspected vulnerability crash nodes contained in SusVar. The nodes actually involved in the execution are filtered out based on the breakpoint hits during the execution process. The method to extract the set of suspected vulnerability crash nodes FlitVar is as follows: 1.7.1 Set the suspected vulnerability crash node set FlitVar to empty, extract nodeAddr1, nodeAddr2,…, nodeAddr in SusVar m ,…,nodeAddr M The statements and parameter information contained in the corresponding nodes in VFG, i.e. node1, node2,…, node m ,…,node M location; 1.7.2 Use GDB debugger to set breakpoints B1, B2, ..., B in Prog m ,…,B M , that is, set breakpoint B1 at node1 of Prog, set breakpoint B2 at node2 of Prog, ..., set breakpoint B3 at node1 of Prog m Set breakpoint B m ,…, in the node of Prog M Set breakpoint B M , get the Prog with breakpoint set; initialize variable k=1; 1.7.3 Using the PoC as input, run the program with breakpoints set in the GDB debugger. 1.7.4 If a breakpoint is set in the program and a breakpoint is hit, let B m , go to 1.7.5; if Prog does not hit the breakpoint, it means that the crash has been triggered, and let the node at the crash point be node crash , transfer to 1.7.6; 1.7.5 B m Node m Add to collection FiltVar, node m Becomes the kth element of the set FiltVar, representing the kth suspected vulnerability crash node node in the program Prog k , set k = k + 1, go to step 1.7.3, and continue running the program with the breakpoint set in the GDB debugger; 1.7.6 node crash Add to collection FiltVar, node crash Become the kth element node of FiltVar k ; 1.7.7 Get the suspected vulnerability crash node set FiltVar, FiltVar = {node1, node2,…, node k ,…,node K }.

5. The vulnerability cause location method based on data richness and migration cost perception according to claim 1, wherein the method of performing data richness screening and crash judgment classification on the test case set S in step 2.4 to obtain the state transition test case set TransVar is: 2.4.1 Initialize the minimum state transition value Min of the test case to +∞, initialize the current test case state transition difference value Min' to +∞, initialize the number of crash test cases passing through the vulnerability crash nodes Counts_crash to 0, initialize the number of non-crash test cases passing through the vulnerability crash nodes 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; set variables f = 1, t = 1; 2.4.2 Initialize the test case data richness value_hash to the initial value H0 = 0, set the initial value of the number of nodes that crashed due to the vulnerability Counts to 0, and set k = 1; 2.4.3 will s f Input it into the target program Prog_I after the instrumentation, run Prog_I, and calculate s according to the running situation f The data richness of value_hash is: 2.4.3.1 When Prog_I passes through node k When getting node k The corresponding instrumented variable value is X k , let Counts = Counts + 1; 2.4.3.2 H k-1 With X k Perform hash calculation to generate the kth 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 s f After calculating the data richness and obtaining the final value_hash, go to 2.4.3.

5. If k ≤ K, go to 2.4.3.

1. 2.4.3.5 Test Cases f After the execution is completed in the target program Prog_I, if s f Causes Prog_I to crash and records the crash information variable flag=1; if s f If it does not cause Prog_I to crash, then set flag to 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 time, value_hash∈HashVar, indicating the test case s f No increase in data richness, i.e. s f No new program behavior was introduced, so s was abandoned. f , let f = f + 1, if f ≤ F, go to 2.4.2 and operate on the next test case; if f > F, go to 2.4.6; 2.4.3.6.2 At this time, value_hash is not in HashVar, so determine s i Increased data richness, switched to 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 tth test case s that meets the requirements of increasing data richness and reducing migration cost. f Stored in the state transition test case set TransVar, that is, s f Become the tth element TV in TransVar t , add value_hash to the test case data richness hash value set HashVar, let y f =1,y f =1 means s f Will cause Prog_I to crash, and y f Add to the test case 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 , go to 2.4.4.3; 2.4.4.2 Let Counts_noncrash = Counts, let Min' = |Counts_crash - Counts_noncrash|, if Min' < Min, set s f As the tth test case that satisfies the requirement of increasing data richness and reducing migration cost, it is stored in the set TransVar, and value_hash is added to the set HashVar. Let y f =0,y f =0 means s f Will not cause Prog_I to crash, f Add to Y, set Min = Min', set t = t + 1, go to 2.4.4.3; if Min' ≥ Min, abandon s f , go 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 location method based on data richness and migration cost perception as described in claim 2 is characterized in that 2.5.3.5 step judgment f The method that caused Prog_I to crash was learned by echoing the crash signal through AddressSanitizer.

7. The vulnerability cause location method based on data richness and migration cost perception as described in claim 1 is characterized in that The method for using the mutual information algorithm to screen Z in step 3.2 to generate the optimized and sorted candidate vulnerability trigger-related node set Z' and the set VSet for clustering operation is: 3.2.1 Let t = 1, initialize Z' to be empty, set the vulnerability optimization threshold θ, 0 < θ < 1; initialize R vulnerability trigger related node state sets V1, V2, ..., V r ,…,V R Empty, V r is the set of node states related to the rth vulnerability trigger; 3.2.2 Let variable r = 1; 3.2.3 TV t Input into Prog, use GDB debugger to debug prog and record the candidate vulnerability triggering related nodes z r , 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 of the node set Z related to the candidate vulnerability triggering when it is used as the input of Prog is recorded. Go 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 is obtained. t ,…,TV T The candidate vulnerability triggers the related node state set V1, V2, ..., V as the input of Prog r ,…,V R , go to 3.2.6; 3.2.6 Initialize a two-dimensional feature empty array X and put V1, V2, ..., V r ,…,V R Add to array X, and get 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 is the rth mutual information value in MI, which is used to measure V in X r The corresponding z r Correlation with the crash of program Prog, 0≤mi r ≤1, mi r The larger the value, the z r The more relevant it is to the program Prog crash; 3.2.7 Screen and sort the candidate vulnerability trigger related node set Z to obtain the sorted candidate vulnerability trigger related node set Z', and generate a set VSet for clustering operation, 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 status set.

8. The vulnerability cause location method based on data richness and migration cost perception as described in claim 7 is characterized in that The optimal vulnerability threshold θ in step 3.2.1 is 0.

5.

9. The vulnerability cause location method based on data richness and migration cost perception as described in claim 7 is characterized in that The method for screening and sorting the candidate vulnerability trigger-related node set Z in step 3.2.7 to obtain the sorted candidate vulnerability trigger-related node set Z' and generate the set VSet for clustering operation is: 3.2.7.1 Let r = 1 and p = 1; 3.2.7.2 If mi r ≥θ, indicating that z r is sufficiently related to the crash of program Prog, let z' p =z r , let V' p =V r , z' p Add to Z', V' p Add to VSet, set r = r + 1, set p = p + 1, go to step 3.2.7.3; if mi r <θ, go directly to step 3.2.7.3; 3.2.7.3 If r≤R, go to 3.2.7.2; if r>R, the elements in Z are selected and 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; according to the element z' in Z' p The corresponding mutual information value mi p Size, synchronously sort the elements in Z' and VSet. The larger the mutual information value, the smaller the corresponding element index. The sorted candidate vulnerability trigger related node set 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 is the pth optimized candidate vulnerability triggering node in Z', V' p It's z' p The corresponding vulnerability triggers the relevant node status set, z' p The corresponding mutual information value>z' p The mutual information value corresponding to +1 ends.

10. The vulnerability cause location method based on data richness and migration cost perception as claimed in claim 1, characterized in that In step 3.3, based on the set VSet and the candidate vulnerability trigger related node set Z', the K-means clustering algorithm is used to cluster TransVar to obtain the ranking set RankingVar of the vulnerability cause location: 3.3.1 Let p = 1; 3.3.2 Based on z' p and V' p , are TV1, TV2,…, TV in TransVar t ,…,TV T Construct a feature vector respectively and get the feature vector set F of the pth 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 constructed by the state information under the p As input, the test cases in TransVar are divided into two clusters by K-means clustering algorithm, let C 1p and C 2p , C 1p Indicates z' p The crash test case clusters obtained by cluster analysis, C 2p Indicates z' p A cluster of non-crash test cases obtained by cluster analysis; 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 true state labels y1,y2,…,y t ,…,y T Evaluate the clustering results, for TV t , if TV t Classified as C 1p And y t =1, or TV t Classified as C 2p And y t =0, then TV t Correct classification; 3.3.4 Statistics of TV1, TV2,…, TV t ,…,TV T The number of correctly classified elements in samples p , calculated based on z' p and V' p Accuracy of the clustering results of the constructed feature vector p , Accuracy p =(samples p ) / T, where Accuracy p Indicates based on z' p and V' p The degree of consistency between the clustering results of the constructed feature vector and the true state label; 3.3.5 Let p = p + 1; if p ≤ P, go to 3.3.2; if p > P, for all z' in Z', p The cluster analysis is completed and the accuracy set Accuracy is obtained, Accuracy = {Accuracy1, Accuracy2,…, Accuracy p ,…,Accuracy P }, go to 3.3.6; 3.3.6 Perform a second round of sorting on the elements in Z' based on the size of each element in Accuracy from high to low. After the second round of sorting, the vulnerability cause ranking set RankingVar = {rank1, rank2, ..., rank p ,…rank P }, that is, if 1≤a≤b≤P, then rank a Accuracy a ≥rank b Accuracy b .

Images