A computer network security software debugging method and system

Abstract

The application provides a computer network security software debugging method and system. A plurality of test nodes of a source program in target network security software are set, a key test node is located based on an execution state at each test node, and a target search domain when the source program is tested is constructed by program context information of the key test node. A plurality of program slices with abnormalities in the source program are determined based on a static control flow graph and a dynamic control flow graph of program code in the target search domain. Test overhead of each program slice is determined according to test coverage information of each program slice and path complexity when the source program is tested. Constraint levels of each program slice are determined according to all test overhead and membership between each program slice. Each program slice is debugged through the constraint level of each program slice. The above scheme can accurately point to a problem code line in a network security software debugging process based on constraint levels of each program slice.

Description

Technical Field

[0001] This application relates to the field of network security software technology, and more specifically, to a method and system for debugging computer network security software. Background Technology

[0002] In today's digital age, the internet has become deeply integrated into all aspects of society, and cyber threats have grown explosively. Traditional, simple protection technologies can no longer meet the increasingly complex security needs. To address these challenges, cybersecurity software has emerged. Cybersecurity software integrates a variety of advanced technologies, such as using encryption technology to protect the confidentiality of data during transmission and storage, and using vulnerability scanning technology to proactively detect security vulnerabilities in systems and software. The comprehensive application of these technologies builds a robust defense for cybersecurity. Among these, debugging cybersecurity software has become a crucial step in effectively improving its protective performance.

[0003] In the debugging of existing network security software, the main methods rely on capturing and analyzing network traffic and tracing code to identify logical flaws and security vulnerabilities. These methods are combined with static code analysis and dynamic runtime testing to verify the software's security and stability, ensuring that the software can effectively defend against potential threats in complex network environments and guaranteeing system security and reliability. However, network security software debugging typically uses global path tracing to traverse the entire program execution path for error localization, lacking detailed analysis of local errors. This makes it difficult to accurately pinpoint the problematic line of code during debugging, thus reducing the accuracy of debugging. Therefore, how to accurately pinpoint the problematic line of code during network security software debugging and improve its accuracy has become a challenge for the industry. Summary of the Invention

[0004] This application provides a method and system for debugging computer network security software, which can accurately pinpoint the problematic line of code during the debugging process of network security software, thereby improving the debugging accuracy of network security software.

[0005] In a first aspect, this application provides a method for debugging computer network security software, comprising the following steps:

[0006] Set up multiple test nodes in the source program of the target network security software, and collect the execution status of each test node when the source program executes test data;

[0007] Based on the execution status at each test node, the key test nodes of the source program in the target network security software are located, and the target search domain for testing the source program is constructed using the program context information of the key test nodes.

[0008] Determine the static control flow graph and dynamic control flow graph of the program code in the target search domain, and perform anomaly slicing on the program entities in the target search domain based on the static control flow graph and the dynamic control flow graph to obtain multiple program slices in the source program that contain anomalies.

[0009] Obtain test coverage information for each program slice, and determine the test overhead for each program slice based on the test coverage information for each program slice and the path complexity when the source program in the target network security software executes the test data;

[0010] The constraint level of each program slice in the source program is determined based on all test overheads and the hierarchical relationships between each program slice.

[0011] Each program slice is debugged by the constraint level of each program slice.

[0012] In some embodiments, setting multiple test nodes in the source program of the target network security software specifically includes:

[0013] Static analysis is performed on the source code of the target network security software to obtain the conditional branch points and loop structure points of the source code;

[0014] Set the conditional branch point and the loop structure point as test nodes in the source program of the target network security software.

[0015] In some embodiments, locating key test nodes in the source program of the target network security software based on the execution status at each test node specifically includes:

[0016] Obtain the execution status at each test node;

[0017] The execution status at each test node is analyzed to obtain the analysis result at each test node. According to the execution order of the test data in the source program, the first test node whose analysis result indicates that the program failed to execute is extracted as the key test node of the source program in the target network security software.

[0018] In some embodiments, constructing the target search domain for testing the source program using the program context information of the key test nodes specifically includes:

[0019] Extract the program context information of the key test nodes;

[0020] Based on the program context information, the call chain associated with the key test node is analyzed;

[0021] The target search domain for testing the source program is constructed based on the call chain and the initial code location of the source program.

[0022] In some embodiments, performing anomaly slicing on program entities in the target search domain based on the static control flow graph and the dynamic control flow graph to obtain multiple program slices containing anomalies in the source program specifically includes:

[0023] Based on the static control flow graph, several static suspicious statements are identified when the target search domain does not execute test data;

[0024] Based on the dynamic control flow graph, multiple dynamic suspicious statements are identified when the target search domain executes test data.

[0025] Select a static suspicious statement as the selected static suspicious statement, perform statement association analysis on the selected static suspicious statement and each dynamic suspicious statement to obtain the statement association status of the selected static suspicious statement, and continue to determine the statement association status of the remaining static suspicious statements.

[0026] Based on the associated states of all statements, multiple abnormal program statements are extracted from all static suspicious statements. Each abnormal program statement is then independently segmented to obtain multiple program slices containing anomalies in the source program.

[0027] In some embodiments, determining the test overhead of each program slice based on the test coverage information of each program slice and the path complexity when the source program in the target network security software executes the test data specifically includes:

[0028] Obtain the static and dynamic control flow graphs of the program code in the target search domain;

[0029] Extract the total number of actual execution paths and the total number of covered paths of the source program from the static control flow graph and the dynamic control flow graph, respectively;

[0030] The path complexity of the source program in the target network security software when executing the test data is determined based on the total number of actual execution paths and the total number of covered paths.

[0031] The execution coverage of each program slice is determined based on the test coverage information of each program slice;

[0032] The test cost of each program slice is determined by the execution coverage and path complexity corresponding to each program slice.

[0033] In some embodiments, the execution status at each test node is collected by a debugger when the source program executes test data.

[0034] Secondly, this application provides a computer network security software debugging system, comprising:

[0035] The acquisition module is used to set up multiple test nodes in the source program of the target network security software and acquire the execution status of each test node when the source program executes test data;

[0036] The processing module is used to locate the key test nodes of the source program in the target network security software based on the execution status at each test node, and to construct the target search domain for testing the source program using the program context information of the key test nodes.

[0037] The processing module is further configured to determine the static control flow graph and dynamic control flow graph of the program code in the target search domain, and perform anomaly slicing on the program entities in the target search domain based on the static control flow graph and the dynamic control flow graph to obtain multiple program slices in the source program that contain anomalies.

[0038] The processing module is also used to obtain test coverage information for each program slice, and determine the test overhead of each program slice based on the test coverage information of each program slice and the path complexity when the source program in the target network security software executes the test data.

[0039] The processing module is also used to determine the constraint level of each program slice in the source program based on all test overhead and the membership relationship between each program slice;

[0040] An execution module is used to debug each program slice according to the constraint level of each program slice.

[0041] Thirdly, this application provides a computer device, the computer device including a memory and a processor, the memory storing code, and the processor being configured to acquire the code and execute the above-described computer network security software debugging method.

[0042] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned computer network security software debugging method.

[0043] The technical solutions provided by the embodiments disclosed in this application have the following beneficial effects:

[0044] The computer network security software debugging method and system provided in this application firstly sets up multiple test nodes for the source program in the target network security software and collects the execution status of each test node when the source program executes test data; secondly, based on the execution status of each test node, the key test nodes of the source program in the target network security software are located, and the target search domain for testing the source program is constructed through the program context information of the key test nodes; further, the static control flow graph and dynamic control flow graph of the program code in the target search domain are determined, and the program entities in the target search domain are anomaly sliced ​​based on the static control flow graph and the dynamic control flow graph to obtain multiple program slices with anomalies in the source program; further, the test coverage information of each program slice is obtained, and the test overhead of each program slice is determined according to the test coverage information of each program slice and the path complexity when the source program in the target network security software executes the test data; then, the constraint level of each program slice in the source program is determined according to all the test overhead and the membership relationship between each program slice; finally, each program slice is debugged according to the constraint level of each program slice.

[0045] Therefore, this application can accurately pinpoint problematic lines of code during the debugging process of network security software, thereby improving the debugging accuracy of network security software. Firstly, by collecting the execution status of each test node when the source program in the target network security software is executed, it can effectively analyze whether the program executes as expected, which is beneficial for developers to debug and optimize. Secondly, based on the execution status at each test node, the key test nodes of the source program in the target network security software are located, and the target search domain for testing the source program is constructed using the program context information of the key test nodes. This can effectively identify code segments, functions, and data structures related to the target test, enabling refined analysis of local errors in the source program, thereby analyzing parts related to abnormal behavior and providing conditions for subsequent debugging and error localization. Furthermore, based on the static and dynamic control flow graphs of the program code in the target search domain, the program code in the target search domain is analyzed... The system performs anomaly slicing to obtain multiple program slices containing anomalies in the source code, accurately locating the problematic program segments and avoiding omissions. Then, based on the test coverage information of each program slice and the path complexity when the source code in the target network security software executes test data, the test overhead of each program slice is determined to quantify the complexity and cost of testing activities. This provides accurate cost quantification for testing the target network security software, helping to optimize resource allocation and test case design, and improving the overall efficiency and quality of testing. Finally, based on all test overheads and the hierarchical relationships between program slices, the constraint level of each program slice in the source code is determined, and each program slice is debugged using its constraint level. In summary, the technical solution provided in this application can accurately pinpoint problematic lines of code during network security software debugging, thereby improving the debugging accuracy of network security software. Attached Figure Description

[0046] Figure 1 This is an exemplary flowchart of a computer network security software debugging method according to some embodiments of this application;

[0047] Figure 2 This is an exemplary flowchart illustrating the determination of a target search domain according to some embodiments of this application;

[0048] Figure 3 This is an exemplary flowchart illustrating the determination of multiple program slices according to some embodiments of this application;

[0049] Figure 4 This is a schematic diagram of the structure of a computer network security software debugging system according to some embodiments of this application;

[0050] Figure 5 This is a schematic diagram of the structure of a computer device that implements a computer network security software debugging method according to some embodiments of this application. Detailed Implementation

[0051] To better understand the technical solution of this application, the technical solution of this application will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0052] refer to Figure 1 The figure is an exemplary flowchart of a computer network security software debugging method according to some embodiments of this application. The computer network security software debugging method 100 mainly includes the following steps:

[0053] In step 101, multiple test nodes are set up for the source program in the target network security software, and the execution status of each test node is collected when the source program executes test data.

[0054] In some embodiments, setting up multiple test nodes for the source code in the target network security software can be achieved by the following steps:

[0055] Static analysis is performed on the source code of the target network security software to obtain the conditional branch points and loop structure points of the source code;

[0056] Set the conditional branch point and the loop structure point as test nodes in the source program of the target network security software.

[0057] In practice, firstly, the source code of the target network security software is parsed using the SonarQube static code analysis tool to extract the control flow graph of the source code. The control flow graph represents the basic blocks and execution paths in the source code and can clearly show the conditional branch points and loop structure points in the source code. The conditional branch points and loop structure points of the source code are extracted from the control flow graph. Then, the conditional branch points and loop structure points are set as test nodes in the source code of the target network security software.

[0058] It should be noted that, in this embodiment, the conditional branch point represents the location where a conditional judgment statement appears in the program; the loop structure point represents the location where a loop control structure appears in the program; and the test node in this application represents the location where debugging stops during program debugging. When the program reaches the test node, it will pause execution to allow for inspection, analysis, or modification, which is beneficial for developers to locate and resolve errors or problems in the program.

[0059] In a specific implementation, the execution status at each test node is collected when the source program executes test data using a Windows debugger. The execution status includes two states: program execution successful and program execution unsuccessful. In addition, in other embodiments, a Web development debugger or a mobile development debugger can also be used to collect the execution status at each test node when the source program executes test data. This is not a limitation here.

[0060] It should be noted that in this application, the execution status refers to the status information when the program runs to the test node. The execution status includes two states: program execution passed and program execution failed. The execution status reflects the dynamic behavior and execution result of the source program at that position. By analyzing the execution status, it is possible to effectively analyze whether the program executes as expected, which is beneficial for developers to debug and optimize.

[0061] In step 102, key test nodes of the source program in the target network security software are located based on the execution status at each test node, and the target search domain for testing the source program is constructed using the program context information of the key test nodes.

[0062] In some embodiments, locating key test nodes in the source program of the target network security software based on the execution status at each test node can be achieved using the following steps:

[0063] Obtain the execution status at each test node;

[0064] The execution status at each test node is analyzed to obtain the analysis result at each test node. According to the execution order of the test data in the source program, the first test node whose analysis result indicates that the program failed to execute is extracted as the key test node of the source program in the target network security software.

[0065] In practice, firstly, the execution status of each test node is obtained; then, the execution status of each test node is parsed using the scripting language Python to obtain the parsing result of each test node. According to the execution order of the test data in the source program, the first test node whose parsing result indicates that the program failed to execute is extracted as the key test node of the source program in the target network security software.

[0066] It should be noted that, in this application, the key test node refers to the critical code location that has a significant impact on the program execution result. Specifically, the key test node is the first test node where the program fails to execute when the source program executes the test data. By determining the key test node, the possible anomalies in the source program during the debugging process of the target network security software can be effectively analyzed.

[0067] In some embodiments, reference Figure 2 As shown, this figure is an exemplary flowchart illustrating the determination of the target search domain according to some embodiments of this application. In this embodiment, the target search domain for testing the source program using the program context information of the key test nodes can be constructed using the following steps:

[0068] First, in step 1021, the program context information of the key test node is extracted;

[0069] Then, in step 1022, the call chain associated with the key test node is analyzed based on the program context information;

[0070] Finally, in step 1023, the target search domain for testing the source program is constructed based on the call chain and the initial code location of the source program.

[0071] In specific implementation, firstly, the program context information of the key test node is extracted using the status query function in the software debugging tool GDB. The program context information includes all program segments before the key test node and subsequent program segments associated with the key test node. Different program segments have different code paths. Then, the call chain associated with the key test node is analyzed based on the program context information. That is, the symbolic execution engine (KLEE) in the symbolic execution tool is used to reverse analyze the code paths in the program context information to obtain the call chain associated with the key test node. For example, the symbolic execution engine treats the input variables in the program context information as symbolic values ​​and gradually derives the call chain associated with the key test node, such as "variable x>5 and y=z+1". Finally, the target search domain for testing the source program is constructed based on the call chain and the initial code position of the source program. That is, the low-level virtual machine (LLVM) in the static program analysis tool is used to locate the position of the call chain in the source program, and the program range between the position of the call chain and the initial code position of the source program is used as the target search domain for testing the source program.

[0072] It should be noted that, in this embodiment, the call chain represents the program statements called in connection with the key test node. Specifically, the call chain refers to the subsequent program statements called in connection with the key test node. By determining the call chain, the range of program statements associated with the key test node can be effectively analyzed. In this application, the target search domain represents the program range to be tested. Specifically, the target search domain is a specific code region related to program behavior, derived from the context information of the key test node. The target search domain contains the code range that may cause program abnormalities or errors and is the key object for debugging and optimization. By determining the target search domain, the code segments, functions, and data structures related to the target test can be effectively identified, and the parts related to abnormal behavior can be analyzed, providing conditions for subsequent debugging and error localization.

[0073] In step 103, the static control flow graph and dynamic control flow graph of the program code in the target search domain are determined, and the program entities in the target search domain are sliced ​​for anomalies based on the static control flow graph and the dynamic control flow graph to obtain multiple program slices in the source program that contain anomalies.

[0074] In some embodiments, determining the static and dynamic control flow graphs of the program code in the target search domain may be achieved through the following steps:

[0075] When the source program does not execute test data, static logic structure analysis is performed on the program code in the target search domain to obtain the static control flow graph of the program code in the target search domain;

[0076] When the source program executes the test data, dynamic logic structure analysis is performed on the program code in the target search domain to obtain the dynamic control flow graph of the program code in the target search domain.

[0077] In specific implementation, firstly, when the source program is not executing test data, the low-level virtual machine (LLVM) in the static program analysis tool performs static logic structure analysis on the program code in the target search domain to obtain the static control flow graph of the program code in the target search domain. For example, the LLVM parses the lexical and syntactic structures of the program code in the target search domain to generate an abstract syntax tree, and further extracts the basic blocks of the program code in the target search domain, such as conditional branches, loop structures, and function call relationships. The basic blocks are mapped to the abstract syntax tree to obtain the static control flow graph of the program code in the target search domain. Then, when the source program executes test data, the dynamic instrumentation tool (Pin) in the dynamic program analysis tool performs dynamic logic structure analysis on the program code in the target search domain to obtain the dynamic control flow graph of the program code in the target search domain. This will not be elaborated here. In addition, in other embodiments, other dynamic instrumentation tools can also be used to perform dynamic logic structure analysis on the program code in the target search domain, such as Dyninst and Frida. This is not limited here.

[0078] It should be noted that, in this embodiment, static logical structure analysis refers to the process of analyzing program statements in a program that has not been executed; in this embodiment, dynamic logical structure analysis refers to the process of analyzing program statements in a running program; in this application, the static control flow graph represents the logical structure diagram when the program code has not been executed. Specifically, the static control flow graph is a graph structure generated after modeling the logical structure of the program code in the target search domain using static analysis techniques when the source program has not been executed. The static control flow graph graphically represents the control flow relationship between various basic blocks (such as statement blocks, conditional branches, loop structures, etc.) in the program, and is used to describe the possible execution paths of the program; in this application, the dynamic control flow graph represents the logical structure diagram when the program code has not been executed. Specifically, the dynamic control flow graph... Dynamic control flow graphs (DCFlowGraphs) record the actual execution paths between basic program blocks in the target search domain during source program runtime using dynamic analysis techniques. They graphically represent the program's control flow. Unlike static DCFlowGraphs, which only contain the actual execution paths under specific input conditions, dynamic DCFlowGraphs show which code is actually executed, static DCFlowGraphs display all possible code execution paths and provide the program's complete logical structure. By locating abnormal path branches (such as unexpected conditional jumps or repeatedly executed loops) in the dynamic DCFlowGraph and combining this with the logical information from the static DCFlowGraph, the location of errors and their potential causes can be quickly identified.

[0079] In some embodiments, reference Figure 3As shown, this figure is an exemplary flowchart of determining multiple program slices according to some embodiments of this application. In this embodiment, the abnormal slices of program entities in the target search domain are obtained by performing abnormal slicing based on the static control flow graph and the dynamic control flow graph to obtain multiple program slices with abnormalities in the source program. This can be achieved by the following steps:

[0080] First, in step 1031, based on the static control flow graph, multiple static suspicious statements are identified when the target search domain does not execute test data;

[0081] Secondly, in step 1032, multiple dynamic suspicious statements are determined based on the dynamic control flow graph when the target search domain executes test data;

[0082] Then, in step 1033, a static suspicious statement is selected as the selected static suspicious statement, and the selected static suspicious statement is analyzed with each dynamic suspicious statement to obtain the statement association status of the selected static suspicious statement. The statement association status of the remaining static suspicious statements is then determined.

[0083] Finally, in step 1034, multiple abnormal program statements are extracted from all static suspicious statements based on all statement association states, and each abnormal program statement is independently segmented to obtain multiple program slices in the source program that contain abnormalities.

[0084] In specific implementation, firstly, the low-level virtual machine (LLVM) in the static program analysis tool is used to identify suspicious code in the static control flow graph, obtaining multiple static suspicious statements when the target search domain does not execute test data. For example, these static suspicious statements can be verified by logical assertions in the low-level virtual machine to identify suspicious code in the static control flow graph, obtaining multiple static suspicious statements when the target search domain does not execute test data. Static suspicious statements include, but are not limited to, statements with uninitialized variables, branch statements with conditions always being false, etc., ultimately obtaining multiple static suspicious statements. Secondly, the dynamic control flow graph is used to identify suspicious code in the dynamic instrumentation tool (Pin), obtaining multiple dynamic suspicious statements when the target search domain executes test data. These are not elaborated here, but include, for example, statements with null pointer references, infinite loop paths, etc. Then, a static suspicious statement is selected as the selected static suspicious statement, and statement association analysis is performed between the selected static suspicious statement and each dynamic suspicious statement to obtain the statement association state of the selected static suspicious statement, continuing to determine the remaining static suspicious statements. The statement association status of suspicious statements is determined as follows: A static suspicious statement is selected as the selected static suspicious statement. Variable name matching technology is used to determine whether there is a variable name match between the selected static suspicious statement and each dynamic suspicious statement. If a variable name match exists, the statement association status between the selected static suspicious statement and each dynamic suspicious statement is set to statement association. If no variable name match exists, the statement association status between the selected static suspicious statement and each dynamic suspicious statement is set to statement non-association. The statement association status of the remaining static suspicious statements is then determined. Finally, based on all statement association statuses, multiple abnormal program statements are extracted from all static suspicious statements. Each abnormal program statement is independently segmented to obtain multiple program slices containing anomalies in the source program. That is, the static suspicious statements corresponding to the statement associations are extracted from all statement association statuses as abnormal program statements, thereby obtaining multiple abnormal program statements. Each abnormal program statement is treated as an independent slice unit, and program slicing technology is used to segment each abnormal program statement to generate multiple program slices containing anomalies in the source program.

[0085] It should be noted that in this embodiment, static suspicious statements refer to code statements that may exhibit abnormal behavior before the program is executed. Static suspicious statements are not program statements that cause problems after execution, but rather code segments with potential problems inferred based on the static characteristics of the code. Identifying static suspicious statements allows potential problems to be discovered before program execution, reducing the possibility of runtime errors. In this embodiment, dynamic suspicious statements refer to code statements that may exhibit abnormal behavior during program execution. Dynamic suspicious statements are based on the actual running state and data flow behavior of the program, complementing static suspicious statements and forming an indispensable part of the debugging and optimization process. In this embodiment, statement association status represents the association between program statements; specifically, it refers to the association between static and dynamic suspicious statements. The statement association status includes… The system includes two states: statement association and statement non-association. In this embodiment, an abnormal program statement refers to a program statement that is abnormal. In this application, an abnormal program slice refers to a single program statement that is abnormal. Furthermore, the static control flow graph covers all possible paths of the program and provides a wide range of suspicious program statements. Regardless of whether they are actually executed, the static control flow graph ensures that the initial range of the abnormal slice does not miss potential anomalies. The dynamic control flow graph reduces the unnecessary analysis range by using runtime data, focusing attention on the actual paths and code that cause problems, avoiding overfitting in static analysis, and providing a more accurate range for the identification of abnormal program statements. Therefore, the program statement that ultimately causes anomalies can be extracted through the correlation between static suspicious statements and dynamic suspicious statements, thereby improving the debugging effectiveness of the target network security software.

[0086] It should also be noted that, in this application, anomaly slicing refers to the process of segmenting abnormal program statements in the source program. Specifically, based on the static control flow graph and the dynamic control flow graph, anomaly slicing is performed on program entities in the target search domain. This involves: identifying multiple static suspicious statements in the target search domain when test data is not executed, based on the static control flow graph; identifying multiple dynamic suspicious statements in the target search domain when test data is executed, based on the dynamic control flow graph; selecting one static suspicious statement as the selected static suspicious statement; performing statement association analysis between the selected static suspicious statement and each dynamic suspicious statement to obtain the statement association state of the selected static suspicious statement; continuing to determine the statement association states of the remaining static suspicious statements; extracting multiple abnormal program statements from all static suspicious statements based on all statement association states; and independently segmenting each abnormal program statement to obtain multiple program slices containing anomalies in the source program, thus completing the anomaly slicing of program entities in the target search domain.

[0087] In step 104, test coverage information for each program slice is obtained, and the test overhead for each program slice is determined based on the test coverage information for each program slice and the path complexity when the source program in the target network security software executes the test data.

[0088] In practice, test coverage information for each program slice can be obtained through a code coverage tool (JaCoCo). The test coverage information represents data related to test coverage during program code execution. Test coverage information is an important basis for evaluating the effectiveness of test cases and is used to reflect the test scope and omissions of the code. The test coverage information includes the number of times the program slice is called when the source program executes different test data. That is, the test coverage information contains multiple test coverage values, which represent the number of calls using test coverage values.

[0089] In some embodiments, determining the test overhead of each program slice based on the test coverage information of each program slice and the path complexity when the source program in the target network security software executes the test data can be achieved by the following steps:

[0090] Obtain the static and dynamic control flow graphs of the program code in the target search domain;

[0091] Extract the total number of actual execution paths and the total number of covered paths of the source program from the static control flow graph and the dynamic control flow graph, respectively;

[0092] The path complexity of the source program in the target network security software when executing the test data is determined based on the total number of actual execution paths and the total number of covered paths.

[0093] The execution coverage of each program slice is determined based on the test coverage information of each program slice;

[0094] The test cost of each program slice is determined by the execution coverage and path complexity corresponding to each program slice.

[0095] In specific implementation, firstly, the static control flow graph and dynamic control flow graph of the program code in the target search domain are obtained; secondly, the low-level virtual machine (LLVM) and dynamic instrumentation tool in the static program analysis tool extract the total number of actual execution paths and the total number of covered paths of the source program from the static control flow graph and the dynamic control flow graph, respectively. The total number of actual execution paths is the total number of execution paths extracted from the static control flow graph, and the total number of covered paths is the total number of execution paths extracted from the dynamic control flow graph; furthermore, the path complexity of the source program in the target network security software when executing the test data is determined based on the total number of actual execution paths and the total number of covered paths, that is, the quotient of the total number of covered paths and the total number of actual execution paths is taken as the path complexity of the source program in the target network security software when executing the test data. In addition, in other embodiments, other calculation methods can be used to calculate the path complexity of the source program in the target network security software when executing the test data, which is not limited here; then, based on The execution coverage of each program slice is determined based on the test coverage information of each program slice. Specifically, for each program slice, the mean of all test coverage values ​​in the test coverage information corresponding to the program slice is calculated, and the mean calculation result is used as the execution coverage of the program slice. Alternatively, in other embodiments, other calculation methods can be used to calculate the execution coverage of each program slice, which is not limited here. Finally, the test overhead of each program slice is determined based on the execution coverage and path complexity. Specifically, for each program slice, the weighted sum of the execution coverage and path complexity corresponding to the program slice is calculated, and the weighted sum result is used as the test overhead of the program slice. The weights of execution coverage and path complexity can be set according to actual needs and are not limited here. Additionally, in other embodiments, other calculation methods can be used to calculate the test overhead of each program slice.

[0096] It should be noted that, in this embodiment, the total number of actual execution paths represents the total number of paths in the source program when the test data is not executed; specifically, the total number of actual execution paths is the total number of execution paths included when the test data is not executed. In this embodiment, the total number of covered paths represents the total number of paths in the source program when the test data is executed; specifically, the total number of covered paths is the total number of execution paths included when the test data is executed. In this application, path complexity represents an indicator of program logic complexity, which reflects the number of execution paths in the program and the difficulty of testing and maintenance. In this embodiment, execution coverage represents the ratio of the actual tested and covered code range to the total code range, used to evaluate the effectiveness of test cases in covering program code. Execution coverage reflects whether test cases have fully verified the program's logical functionality. In this application, test overhead represents the resource consumption for verifying the correctness of program code. Test overhead quantifies the complexity and cost of testing activities, providing a precise cost quantification basis for software testing, which helps optimize resource allocation and test case design, and improves the overall efficiency and quality of testing.

[0097] In step 105, the constraint level of each program slice in the source program is determined based on all test overheads and the membership relationships between each program slice.

[0098] In some embodiments, determining the constraint level of each program slice in the source program based on all test overheads and the membership relationships between each program slice can be achieved using the following steps:

[0099] Determine the hierarchical relationships between the various program slices;

[0100] Cluster analysis was performed on all program slices based on all membership relationships to obtain multiple slice association clusters;

[0101] Calculate the comprehensive test cost of each slice-related cluster based on the test cost of each program slice;

[0102] The constraint level of each slice association cluster is determined based on the comprehensive test cost of each slice association cluster. The constraint level of each slice association cluster is then mapped to each program slice within the corresponding association cluster to obtain the constraint level of each program slice in the source program.

[0103] In specific implementation, firstly, the membership relationships between each program slice are determined. This involves constructing the control flow graph of the source program using a low-level virtual machine (LLVM) in a static program analysis tool, and automatically identifying the membership relationships between each program slice from the control flow graph. Alternatively, a statement relationship algorithm can be used to determine the membership relationships between each program slice; this is not a limitation here. Secondly, cluster analysis is performed on all program slices based on all membership relationships to obtain multiple slice association clusters. That is, program slices with the same membership relationship are grouped into one slice association cluster, resulting in multiple slice association clusters. Then, the comprehensive test cost of each slice association cluster is calculated based on the test cost of each program slice. That is, for each slice association... The test overhead of each program slice in a slice-associated cluster is averaged and used as the comprehensive test overhead of the slice-associated cluster. Finally, the constraint level of each slice-associated cluster is determined based on its comprehensive test overhead, and the constraint level is mapped to each program slice within that cluster to obtain the constraint level of each program slice in the source program. Specifically, the comprehensive test overhead of each slice-associated cluster is sorted in ascending order, and the constraint level of each cluster is set according to the sorting order label. The constraint level of each slice-associated cluster is then mapped to each program slice within that cluster to obtain the constraint level of each program slice in the source program.

[0104] It should be noted that, in this embodiment, the membership relationship represents the dependency relationship between program segments; in this embodiment, the slice association cluster represents a combination of multiple similar program slices; in this embodiment, the comprehensive test overhead represents the overall test overhead of measuring all program slices in the slice association cluster; in this application, the constraint level represents the priority of constraint restriction, specifically, the constraint level is the level of constraint restriction on program slices with anomalies. In the debugging of network security software, the source program may have multiple associated abnormal program segments. Therefore, by determining the constraint level, the allocation of resources can be optimized, and more resources can be invested in tasks with high constraint levels to ensure that the critical parts of the system or program can be processed in a timely manner.

[0105] In step 106, each program slice is debugged by the constraint level of each program slice.

[0106] In some embodiments, debugging each program slice by constraint level can be achieved by the following steps:

[0107] Obtain the constraint level for each program slice;

[0108] Each program slice is arranged according to its constraint level, and each program slice is debugged in the order of arrangement.

[0109] In practice, firstly, the constraint level of each program slice is obtained; secondly, each program slice is arranged according to its constraint level, and a debugging tool (such as GDB or LLDB) is used to debug the program slices in the order of arrangement. After debugging, the fixed code is marked as resolved.

[0110] In another aspect, in some embodiments, this application provides a computer network security software debugging system, with reference to... Figure 4 The figure is a schematic diagram of the structure of a computer network security software debugging system according to some embodiments of this application. The computer network security software debugging system 200 includes: a data acquisition module 201, a processing module 202, and an execution module 203, which are described below:

[0111] The acquisition module 201 in this application is mainly used to set up multiple test nodes in the source program of the target network security software and to acquire the execution status of each test node when the source program executes test data.

[0112] Processing module 202 in this application is mainly used to locate the key test nodes of the source program in the target network security software based on the execution status of each test node, and to construct the target search domain for testing the source program through the program context information of the key test nodes.

[0113] The processing module 202 is further configured to determine the static control flow graph and dynamic control flow graph of the program code in the target search domain, and perform anomaly slicing on the program entities in the target search domain based on the static control flow graph and the dynamic control flow graph to obtain multiple program slices in the source program that contain anomalies.

[0114] In addition, the processing module 202 is also used to obtain the test coverage information of each program slice, and determine the test cost of each program slice based on the test coverage information of each program slice and the path complexity when the source program in the target network security software executes the test data.

[0115] Furthermore, the processing module 202 is also used to determine the constraint level of each program slice in the source program based on all test overheads and the membership relationships between each program slice;

[0116] The execution module 203 in this application is mainly used to debug each program slice according to the constraint level of each program slice.

[0117] In addition, this application also provides a computer device, the computer device including a memory and a processor, the memory storing code, and the processor being configured to acquire the code and execute the above-described computer network security software debugging method.

[0118] In some embodiments, reference Figure 5 The figure is a schematic diagram of the structure of a computer device implementing a computer network security software debugging method according to some embodiments of this application. The computer network security software debugging method in the above embodiments can be implemented through... Figure 5 The computer device shown is used to implement this, and the computer device 300 includes at least one processor 301, a communication bus 302, a memory 303, and at least one communication interface 304.

[0119] The processor 301 may be a general-purpose central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more devices used to control the execution of the computer network security software debugging method described in this application.

[0120] The communication bus 302 can be used to transmit information between the aforementioned components.

[0121] The memory 303 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CDROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), a magnetic disk or other magnetic storage device, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory 303 may exist independently and be connected to the processor 301 via the communication bus 302. The memory 303 may also be integrated with the processor 301.

[0122] The memory 303 stores program code for executing the scheme of this application, and its execution is controlled by the processor 301. The processor 301 executes the program code stored in the memory 303. The program code may include one or more software modules. In the above embodiments, the determination of the computer network security software debugging method can be achieved through the processor 301 and one or more software modules in the program code in the memory 303.

[0123] Communication interface 304 uses any transceiver-like device to communicate with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area networks (WLAN), etc.

[0124] In a specific implementation, as one example, a computer device may include multiple processors, each of which may be a single-core (single CPU) processor or a multi-core (multi CPU) processor. Here, a processor may refer to one or more devices, circuits, and / or processing cores used to process data (e.g., computer program instructions).

[0125] The aforementioned computer device can be a general-purpose computer device or a special-purpose computer device. In specific implementations, the computer device can be a desktop computer, a portable computer, a network server, a handheld digital assistant (PDA), a mobile phone, a tablet computer, a wireless terminal device, a communication device, or an embedded device. This application does not limit the type of computer device.

[0126] In addition, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described computer network security software debugging method.

[0127] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0128] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for debugging computer network security software, characterized in that, Includes the following steps: Set up multiple test nodes in the source program of the target network security software, and collect the execution status of each test node when the source program executes test data; Based on the execution status at each test node, the key test nodes of the source program in the target network security software are located, and the target search domain for testing the source program is constructed using the program context information of the key test nodes. Determine the static control flow graph and dynamic control flow graph of the program code in the target search domain, and perform anomaly slicing on the program entities in the target search domain based on the static control flow graph and the dynamic control flow graph to obtain multiple program slices in the source program that contain anomalies. Obtain test coverage information for each program slice, and determine the test overhead for each program slice based on the test coverage information for each program slice and the path complexity when the source program in the target network security software executes the test data; The constraint level of each program slice in the source program is determined based on all test overheads and the hierarchical relationships between each program slice. Each program slice is debugged by the constraint level of each program slice; Specifically, determining the test overhead for each program slice based on the test coverage information of each program slice and the path complexity when the source program in the target network security software executes the test data includes: Obtain the static and dynamic control flow graphs of the program code in the target search domain; Extract the total number of actual execution paths and the total number of covered paths of the source program from the static control flow graph and the dynamic control flow graph, respectively; The path complexity of the source program in the target network security software when executing the test data is determined based on the total number of actual execution paths and the total number of covered paths. The execution coverage of each program slice is determined based on the test coverage information of each program slice; The test overhead for each program slice is determined by the execution coverage and path complexity corresponding to each program slice, and the test overhead represents the resource consumption for verifying the correctness of the program code.

2. The method as described in claim 1, characterized in that, Setting up multiple test nodes in the source code of the target network security software specifically includes: Static analysis is performed on the source code of the target network security software to obtain the conditional branch points and loop structure points of the source code; Set the conditional branch point and the loop structure point as test nodes in the source program of the target network security software.

3. The method as described in claim 1, characterized in that, Based on the execution status at each test node, the key test nodes in the source program of the target network security software are located, specifically including: Obtain the execution status at each test node; The execution status at each test node is analyzed to obtain the analysis result at each test node. According to the execution order of the test data in the source program, the first test node whose analysis result indicates that the program failed to execute is extracted as the key test node of the source program in the target network security software.

4. The method as described in claim 1, characterized in that, The target search domain for testing the source program, constructed using the program context information of the key test nodes, specifically includes: Extract the program context information of the key test nodes; Based on the program context information, the call chain associated with the key test node is analyzed; The target search domain for testing the source program is constructed based on the call chain and the initial code location of the source program.

5. The method as described in claim 1, characterized in that, Based on the static control flow graph and the dynamic control flow graph, anomaly slicing is performed on the program entities in the target search domain to obtain multiple program slices containing anomalies in the source program, specifically including: Based on the static control flow graph, several static suspicious statements are identified when the target search domain does not execute test data; Based on the dynamic control flow graph, multiple dynamic suspicious statements are identified when the target search domain executes test data. Select a static suspicious statement as the selected static suspicious statement, perform statement association analysis on the selected static suspicious statement and each dynamic suspicious statement to obtain the statement association status of the selected static suspicious statement, and continue to determine the statement association status of the remaining static suspicious statements. Based on the associated states of all statements, multiple abnormal program statements are extracted from all static suspicious statements. Each abnormal program statement is then independently segmented to obtain multiple program slices containing anomalies in the source program.

6. The method as described in claim 1, characterized in that, The debugger collects the execution status of each test node when the source program executes test data.

7. A computer network security software debugging system, which performs security software debugging using the method described in any one of claims 1 to 6, characterized in that, The system includes: The acquisition module is used to set up multiple test nodes in the source program of the target network security software and acquire the execution status of each test node when the source program executes test data; The processing module is used to locate the key test nodes of the source program in the target network security software based on the execution status at each test node, and to construct the target search domain for testing the source program using the program context information of the key test nodes. The processing module is further configured to determine the static control flow graph and dynamic control flow graph of the program code in the target search domain, and perform anomaly slicing on the program entities in the target search domain based on the static control flow graph and the dynamic control flow graph to obtain multiple program slices in the source program that contain anomalies. The processing module is also used to obtain test coverage information for each program slice, and determine the test overhead of each program slice based on the test coverage information of each program slice and the path complexity when the source program in the target network security software executes the test data. The processing module is also used to determine the constraint level of each program slice in the source program based on all test overhead and the membership relationship between each program slice; An execution module is used to debug each program slice according to the constraint level of each program slice.

8. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing code, and the processor being configured to retrieve the code and execute the computer network security software debugging method as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the computer network security software debugging method as described in any one of claims 1 to 6.

Images