Computer network security software debugging method and system

Abstract

The invention provides a computer network security software debugging method and system, and the method comprises the steps: setting a plurality of test nodes of a source program in target network security software, and positioning a key test node based on the execution state of each test node; constructing a target search domain when the source program is tested through the program context information of the key test node; determining a plurality of abnormal program slices in the source program based on the static control flow diagram and the dynamic control flow diagram of the program code in the target search domain; determining the test overhead of each program slice according to the test coverage information of each program slice and the path complexity when the source program executes the test data; determining the constraint level of each program slice according to all the test overhead and the membership relationship among the program slices; and debugging each program slice through the constraint level of each program slice. According to the scheme, on the basis of the constraint level of each program slice, the problem code line can be accurately pointed in the network security software debugging process.

Description

Technical Field

[0001] This application relates to the technical field of network security software. More specifically, this application relates to a method and system for debugging computer network security software. Background Art

[0002] In today's digital age, the network has been deeply integrated into all aspects of society, and network threats have also increased explosively. Traditional simple protection technologies can no longer meet the increasingly complex security requirements. To address these challenges, network security software has emerged. Network security software incorporates a variety of advanced technologies. For example, data confidentiality during transmission and storage is protected through encryption technology, and security vulnerabilities in systems and software are actively detected through vulnerability scanning technology. The comprehensive application of these technologies builds a solid defense line for network security. Among them, to effectively improve the protection performance of network security software, the debugging of network security software has become a crucial link.

[0003] In the debugging of existing network security software, the debugging of network security software mainly relies on capturing and analyzing network traffic and code tracing to identify logical defects and security vulnerabilities in the network security software. At the same time, methods such as static code analysis and dynamic runtime testing are combined to verify the security and stability of the software, ensuring that the network security software can effectively resist potential threats in a complex network environment and guarantee the security and reliability of the system. However, in the debugging of network security software, the global path tracing method is usually used to traverse the complete path of program execution for program error location, lacking refined analysis of local errors, making it impossible to accurately point to the problem code line during the debugging process of network security software, thereby reducing the debugging accuracy of network security software. Therefore, how to accurately point to the problem code line during the debugging process of network security software and then improve the debugging accuracy of network security software has become a difficult problem faced by the industry. Summary of the Invention

[0004] This application provides a method and system for debugging computer network security software, which can accurately point to the problem code line 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, including the following steps: Set multiple test nodes for the source program in the target network security software, and collect the execution status at each test node when the source program executes test data; 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 construct the target search domain for the source program during testing through the program context information of the key test nodes; Determine the static control flow graph and the dynamic control flow graph of the program code in the target search domain, and perform exception 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 with exceptions in the source program; Obtain the test coverage information of each program slice, and determine the test overhead of each program slice 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; Determine the constraint level of each program slice in the source program according to all the test overheads and the subordination relationships among the program slices; Debug each program slice according to the constraint level of each program slice.

[0006] In some embodiments, setting multiple test nodes of the source program in the target network security software specifically includes: Perform static analysis on the source program in the target network security software to obtain the conditional branch points and loop structure points of the source program; Set the conditional branch points and the loop structure points as the test nodes of the source program in the target network security software respectively.

[0007] In some embodiments, locating the key test nodes of the source program in the target network security software based on the execution status at each test node specifically includes: Obtain the execution status at each test node; Parse the execution status at each test node to obtain the parsing result at each test node, and extract the first test node with a parsing result of program execution failure as the key test node of the source program in the target network security software according to the execution order of the source program executing the test data.

[0008] In some embodiments, constructing the target search domain for testing the source program through the program context information of the key test node specifically includes: Extract the program context information of the key test node; Analyze the call chain associated with the key test node based on the program context information; Construct the target search domain for testing the source program according to the call chain and the initial code position of the source program.

[0009] In some embodiments, performing exception 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 with exceptions in the source program specifically includes: Determine multiple static suspicious statements when the target search domain has not executed test data based on the static control flow graph; Determine multiple dynamic suspicious statements when the target search domain executes test data based on the dynamic control flow graph; Select a static suspicious statement as the selected static suspicious statement, perform statement association analysis between 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; Extract multiple abnormal program statements from all static suspicious statements according to all statement association statuses, and perform independent segmentation on each abnormal program statement to obtain multiple program slices with abnormalities in the source program.

[0010] In some embodiments, determining the test overhead of each program slice 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 specifically includes: Obtain the static control flow graph and dynamic control flow graph 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; Determine the path complexity when the source program in the target network security software executes the test data according to the total number of actual execution paths and the total number of covered paths; Determine the execution coverage of each program slice according to the test coverage information of each program slice; Determine the test overhead of each program slice from the execution coverage and path complexity corresponding to each program slice.

[0011] In some embodiments, collect the execution status at each test node when the source program executes test data through a debugger.

[0012] In a second aspect, the present application provides a computer network security software debugging system, including: A collection module, configured to set multiple test nodes of the source program in the target network security software, and collect the execution status at each test node when the source program executes test data; A processing module, configured 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 construct a target search domain for the source program during testing through the program context information of the key test nodes; The processing module is further configured to determine the static control flow graph and the dynamic control flow graph of the program code in the target search domain, and perform exception slicing on the program entities in the target search domain based on the static control flow graph and the dynamic control flow graph, so as to obtain multiple program slices with exceptions in the source program; The processing module is further configured to obtain the test coverage information of each program slice, and determine the test overhead of each program slice 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; The processing module is further configured to determine the constraint level of each program slice in the source program according to all the test overheads and the subordination relationships between the program slices; The execution module is configured to debug each program slice according to the constraint level of each program slice.

[0013] In a third aspect, the present application provides a computer device, which includes a memory and a processor. The memory stores code, and the processor is configured to obtain the code and execute the above computer network security software debugging method.

[0014] In a fourth aspect, the present application provides a computer-readable storage medium, which stores a computer program, and when the computer program is executed by a processor, the above computer network security software debugging method is implemented.

[0015] The technical solution provided by the embodiments disclosed in the present application has the following beneficial effects: In the computer network security software debugging method and system provided by the present application, first, multiple test nodes of the source program in the target network security software are set, and the execution status at each test node when the source program executes the test data is collected; 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 when the source program is tested is constructed through the program context information of the key test nodes; further, the static control flow graph and the dynamic control flow graph of the program code in the target search domain are determined, and exception slicing is performed on the program entities in the target search domain based on the static control flow graph and the dynamic control flow graph, so as to obtain multiple program slices with exceptions in the source program; furthermore, 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 overheads and the subordination relationships between the program slices; finally, each program slice is debugged according to the constraint level of each program slice.

[0016] As can be seen, the present application can accurately point to the problem code line during the debugging process of network security software, thereby improving the debugging accuracy of network security software. First, by collecting the execution status at each test node when the source program of the target network security software executes test data, it is possible to effectively analyze whether the program executes as expected, which is beneficial for developers to perform debugging and optimization. Second, 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 through the program context information of the key test nodes. This can effectively identify the code segments, functions, and data structures related to the target test, so as to conduct a refined analysis of local errors in the source program, and thus analyze the part related to abnormal behavior, providing conditions for subsequent debugging and error location. Further, based on the static control flow graph and dynamic control flow graph of the program code in the target search domain, abnormal slicing is performed on the program entities in the target search domain to obtain multiple program slices with abnormalities in the source program, so as to accurately locate the program fragments with abnormalities and avoid omission of abnormal program fragments. Then, according to the test coverage information of each program slice and the path complexity when the source program of the target network security software executes test data, the test cost of each program slice is determined to quantify the complexity and cost of the test activity, providing an accurate cost quantification basis for the test of the target network security software, which helps to optimize resource allocation and test case design and improve the overall efficiency and quality of the test. Finally, according to all the test costs and the subordination relationships between each program slice, the constraint level of each program slice in the source program is determined, and each program slice is debugged through the constraint level of each program slice. In summary, the technical solution provided by the present application can accurately point to the problem code line during the debugging process of network security software, thereby improving the debugging accuracy of network security software. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 is an exemplary flowchart of a computer network security software debugging method shown in some embodiments of the present application; Figure 2 is an exemplary flowchart of determining a target search domain shown in some embodiments of the present application; Figure 3 is an exemplary flowchart of determining multiple program slices shown in some embodiments of the present application; Figure 4 is a schematic structural diagram of a computer network security software debugging system shown in some embodiments of the present application; Figure 5 is a schematic structural diagram of a computer device for implementing the computer network security software debugging method shown in some embodiments of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0018] To better understand the technical solution of this application, the technical solution of this application will be described in detail below in conjunction with the accompanying drawings of the specification and specific implementation manners.

[0019] Refer to Figure 1 , which is an exemplary flowchart of a computer network security software debugging method shown according to some embodiments of this application. The computer network security software debugging method 100 mainly includes the following steps: In step 101, multiple test nodes of the source program in the target network security software are set, and the execution status at each test node when the source program executes test data is collected.

[0020] In some embodiments, setting multiple test nodes of the source program in the target network security software can be implemented by the following steps, that is: Perform static analysis on the source program in the target network security software to obtain the conditional branch points and loop structure points of the source program; Respectively set the conditional branch points and the loop structure points as the test nodes of the source program in the target network security software.

[0021] In specific implementation, first, use the SonarQube in the static code analysis tool to parse the source program of the target network security software, extract the control flow graph of the source program. The control flow graph is a representation of the basic blocks and execution paths in the source code, and the control flow graph can clearly show the conditional branch points and loop structure points in the source program. Extract the conditional branch points and loop structure points of the source program from the control flow graph; then, respectively set the conditional branch points and the loop structure points as the test nodes of the source program in the target network security software.

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

[0023] In specific implementation, collect the execution status at each test node when the source program executes test data through the Windows debugger. The execution status includes two states: program execution passes and program execution fails. 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, which is not limited here.

[0024] It should be noted that in this application, the execution status represents the status information of the program when it runs to the test node. The execution status includes two statuses: the program execution passes and the program execution fails. The execution status reflects the dynamic behavior and execution result of the source program at this position. By analyzing the execution status, it is possible to effectively analyze whether the program is executed as expected, which is beneficial for developers to perform debugging and optimization.

[0025] In step 102, 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 through the program context information of the key test nodes.

[0026] In some embodiments, locating the key test nodes of the source program in the target network security software based on the execution status at each test node can be implemented by the following steps, that is: Obtain the execution status at each test node; Parse the execution status at each test node to obtain the parsing result at each test node. According to the execution order of the test data by the source program, extract the first test node whose parsing result is that the program execution fails as the key test node of the source program in the target network security software.

[0027] In specific implementation, first, obtain the execution status at each test node; then, use the scripting language Python to parse the execution status at each test node to obtain the parsing result at each test node. According to the execution order of the test data by the source program, extract the first test node whose parsing result is that the program execution fails as the key test node of the source program in the target network security software.

[0028] It should be noted that in this application, the key test node represents a key code position that has an important impact on the program execution result. Specifically, the key test node is the first test node where the program execution fails when the source program executes the test data. By determining the key test node, it is possible to effectively analyze the possible abnormal points of the source program during the debugging process of the target network security software.

[0029] In some embodiments, refer to Figure 2 As shown, this figure is an exemplary flowchart for determining the target search domain according to some embodiments of the present application. In this embodiment, constructing the target search domain for testing the source program through the program context information of the key test nodes can be implemented by the following steps: First, in step 1021, extract the program context information of the key test nodes; Then, in step 1022, a call chain associated with the key test node is analyzed based on the program context information. Finally, in step 1023, a target search domain for testing the source program is constructed according to the call chain and the initial code position of the source program.

[0030] When specifically implemented, first, the program context information of the key test node is extracted through the status query function in the software debugging tool GDB. The program context information includes all program fragments before the key test node and subsequent program fragments associated with the key test node. Different program fragments have different code paths. Then, a 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 perform reverse analysis on 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 subsequent key test node, such as "variable x > 5 and y = z + 1". Finally, a target search domain for testing the source program is constructed according to the call chain and the initial code position of the source program, that is, the position of the call chain in the source program is located through the low-level virtual machine (LLVM) in the static program analysis tool, 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.

[0031] It should be noted that in this embodiment, the call chain represents the call program statements associated with the key test node. Specifically, the call chain is the subsequent call program statements associated 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 derived through the context information of the key test node and is a specific code area related to program behavior. The target search domain contains the code range that may cause program exceptions 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 then the part related to abnormal behavior can be analyzed, providing conditions for subsequent debugging and error location.

[0032] 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 abnormal slicing is performed 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 with exceptions in the source program.

[0033] In some embodiments, the following steps may be adopted to determine the static control flow graph and the dynamic control flow graph of the program code in the target search domain, that is: When the test data is not executed in the source program, perform static logical 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; When the test data is executed in the source program, perform dynamic logical 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.

[0034] In specific implementation, first, when the test data is not executed in the source program, perform static logical structure analysis on the program code in the target search domain through the Low-Level Virtual Machine (LLVM) in the static program analysis tool 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 elements 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, and maps the basic blocks to the abstract syntax tree to obtain the static control flow graph of the program code in the target search domain. Then, when the test data is executed in the source program, perform dynamic logical structure analysis on the program code in the target search domain through the dynamic instrumentation tool (Pin) in the dynamic program analysis tool to obtain the dynamic control flow graph of the program code in the target search domain, which will not be elaborated here. In addition, in other embodiments, other dynamic instrumentation tools may also be used to perform dynamic logical structure analysis on the program code in the target search domain, such as Dyninst, Frida, which are not limited here.

[0035] It should be noted that in this embodiment, the static logical structure analysis refers to the process of analyzing program statements of an unrun program; the dynamic logical structure analysis in this embodiment refers to the process of analyzing program statements of a running program; the static control flow graph in this application represents the logical structure graph when the program code is not executed. Specifically, the static control flow graph is a graph structure generated by modeling the logical structure of the program code in the target search domain through static analysis techniques when the source program is not executed. The static control flow graph represents the control flow relationship between each basic block (such as statement blocks, conditional branches, loop structures, etc.) in the program in graphical form, and is used to describe the possible execution paths of the program; the dynamic control flow graph in this application represents the logical structure graph when the program code is not executed. Specifically, the dynamic control flow graph is a graph that records the actual execution paths between the program basic blocks of the program code in the target search domain through dynamic analysis techniques when the source program is actually running, and represents the control flow during program operation in graphical form. Different from the static control flow graph, the dynamic control flow graph only contains the actual execution paths of the program under specific input conditions, rather than all possible execution paths; the dynamic control flow graph reflects the actual execution paths of the program under specific input conditions and shows which code is actually executed. The static control flow graph shows all possible code execution paths and provides the complete logical structure of the program. By locating abnormal path branches (such as unexpected conditional jumps, repeatedly executed loops, etc.) in the dynamic control flow graph and combining the logical information of the static control flow graph, the location where the error occurs and its potential causes can be quickly located.

[0036] In some embodiments, as shown in Figure 3 the figure is an exemplary flowchart for determining multiple program slices according to some embodiments of the present application. In this embodiment, abnormal slicing of program entities in the target search domain is performed based on the static control flow graph and the dynamic control flow graph, and multiple program slices with anomalies in the source program can be obtained by the following steps: First, in step 1031, based on the static control flow graph, multiple static suspicious statements when the test data is not executed in the target search domain are determined; Secondly, in step 1032, based on the dynamic control flow graph, multiple dynamic suspicious statements when the test data is executed in the target search domain are determined; Then, in step 1033, 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 status of the selected static suspicious statement, and the statement association status of the remaining static suspicious statements is continuously determined; Finally, in step 1034, multiple abnormal program statements are extracted from all static suspicious statements according to all statement association states, and each abnormal program statement is independently sliced to obtain multiple program slices with anomalies in the source program.

[0037] In specific implementation, first, 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 test data in the target search domain is not executed. For example, these static suspicious statements can verify the suspicious code identification of the static control flow graph through logical assertions in the low-level virtual machine, obtaining multiple static suspicious statements when the test data in the target search domain is not executed. The static suspicious statements include, but are not limited to, statements with uninitialized variables, branch statements with a condition always false, etc., and finally multiple static suspicious statements are obtained. Secondly, a dynamic instrumentation tool (Pin) is used to identify suspicious code in the dynamic control flow graph, obtaining multiple dynamic suspicious statements when the test data in the target search domain is executed, which will not be elaborated here. For example, the dynamic suspicious statements include, but are not limited to, null pointer reference statements, infinite loop path statements, 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, and continue to determine the statement association states of the remaining static suspicious statements, that is: select a static suspicious statement as the selected static suspicious statement, and determine whether there is a variable name match between the selected static suspicious statement and each dynamic suspicious statement through variable name matching technology. If there is a variable name match, set the statement association state between the selected static suspicious statement and each dynamic suspicious statement to statement association. If there is no variable name match, set the statement association state between the selected static suspicious statement and each dynamic suspicious statement to statement non-association, and continue to determine the statement association states of the remaining static suspicious statements. Finally, multiple abnormal program statements are extracted from all static suspicious statements according to all statement association states, and each abnormal program statement is independently sliced to obtain multiple program slices with anomalies in the source program, that is: extract the static suspicious statements corresponding to statement association from all statement association states as abnormal program statements, and thus obtain multiple abnormal program statements. Each abnormal program statement is used as an independent slice unit, and each abnormal program statement is sliced through program slicing technology to generate multiple program slices with anomalies in the source program.

[0038] It should be noted that in this embodiment, static suspicious statements refer to code statements that may have abnormal behaviors when the program is not executed. Static suspicious statements are not program statements that have problems directly after running, but code segments with potential problems inferred based on the static characteristics of the code. By determining static suspicious statements, potential problems can be discovered before the program runs, reducing the possibility of runtime errors; in this embodiment, dynamic suspicious statements refer to code statements that may have abnormal behaviors when the program is executed. Dynamic suspicious statements are based on the actual running state and data flow performance of the program, complementing static suspicious statements and being an indispensable part of the debugging and optimization process; in this embodiment, the statement association state refers to the association situation between program statements. Specifically, the statement association state is the association situation between static suspicious statements and dynamic suspicious statements, and the statement association state includes two states: statement association and statement non - association; in this embodiment, abnormal program statements refer to program statements with abnormalities; in this application, an abnormal program slice with an abnormality refers to a single program statement with an abnormality; in addition, the static control flow graph covers all possible paths of the program, providing a wide range of suspicious program statements. Whether or not they are actually executed, the static control flow graph ensures that the initial range of abnormal slices does not miss potential abnormal points. The dynamic control flow graph reduces the unnecessary analysis range through runtime data, focusing attention on the paths and code that actually cause problems, avoiding overfitting in static analysis, and providing a more accurate range for the identification of abnormal program statements. Therefore, the program statements that ultimately exhibit abnormalities 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.

[0039] It should also be noted that in this application, an abnormal slice refers to the process of slicing abnormal program statements in the source program. Among them, abnormal slicing is performed on program entities in the target search domain based on the static control flow graph and the dynamic control flow graph, that is: determining multiple static suspicious statements in the target search domain when the test data is not executed based on the static control flow graph; determining multiple dynamic suspicious statements in the target search domain when the test data is executed based on the dynamic control flow graph; selecting a 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, and continuing to determine the statement association states of the remaining static suspicious statements; extracting multiple abnormal program statements from all static suspicious statements according to all statement association states, and independently slicing each abnormal program statement to obtain multiple program slices with abnormalities in the source program, that is, completing the abnormal slicing of program entities in the target search domain.

[0040] In step 104, obtain the test coverage information of each program slice, and determine the test overhead of each program slice 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.

[0041] When specifically implemented, the test coverage information of each program slice can be obtained through a code coverage tool (JaCoCo). The test coverage information represents data related to test coverage when the program code runs. The test coverage information is an important basis for evaluating the effectiveness of test cases, used to reflect the test scope and omission situation of the code. The test coverage information includes the number of calls of the program slice when the source program executes different test data, that is, the test coverage information includes multiple test coverage values, namely, the number of calls is characterized by the test coverage value.

[0042] In some embodiments, determining the test overhead of each program slice 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 can be implemented by the following steps, that is: Obtain the static control flow graph and dynamic control flow graph 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; Determine the path complexity when the source program in the target network security software executes the test data according to the total number of actual execution paths and the total number of covered paths; Determine the execution coverage of each program slice according to the test coverage information of each program slice; Determine the test overhead of each program slice from the execution coverage corresponding to each program slice and the path complexity.

[0043] In specific implementation, first, obtain the static control flow graph and the dynamic control flow graph of the program code in the target search domain; secondly, the low-level virtual machine (LLVM) in the static program analysis tool and the dynamic instrumentation tool (Pin) respectively 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. 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; further, determine the path complexity when the source program in the target network security software executes the test data according to the total number of actual execution paths and the total number of covered paths, that is: use the quotient of the total number of covered paths and the total number of actual execution paths as the path complexity when the source program in the target network security software executes the test data. In addition, in other embodiments, other calculation methods may also be used to calculate the path complexity when the source program in the target network security software executes the test data, which is not limited here; then, determine the execution coverage of each program slice according to the test coverage information of each program slice, that is: for each program slice, calculate the average value of all test coverage values in the test coverage information corresponding to the program slice, and use the average calculation result as the execution coverage of the program slice, thereby obtaining the execution coverage of each program slice. In addition, in other embodiments, other calculation methods may also be used to calculate the execution coverage of each program slice, which is not limited here; finally, determine the test overhead of each program slice according to the execution coverage and the path complexity corresponding to each program slice, that is: for each program slice, perform a weighted sum of the execution coverage and the path complexity corresponding to the program slice, and use the weighted sum result as the test overhead of the program slice, thereby obtaining the test overhead of each program slice. Among them, the weights of the execution coverage and the path complexity can be set according to actual needs, which is not limited here. In addition, in other embodiments, other calculation methods may also be used to calculate the test overhead of each program slice.

[0044] 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 in the source program 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 in the source program when the test data is executed; in this application, the path complexity represents an index for measuring the logical complexity of the program. The path complexity can reflect the number of execution paths in the program and the difficulty of testing and maintenance; in this embodiment, the execution coverage represents the ratio of the code range actually covered by the test to the total code range, which is used to evaluate the effectiveness of the test cases in covering the program code. The execution coverage can reflect whether the test cases fully verify the logical functions of the program; in this application, the test overhead represents the resource consumption for verifying the correctness of the program code. The test overhead quantifies the complexity and cost of the test activities. The test overhead provides an accurate cost quantification basis for software testing, which helps to optimize resource allocation and test case design and improve the overall efficiency and quality of the test.

[0045] In step 105, according to all the test overheads and the subordination relationships between each program slice, determine the constraint levels of each program slice in the source program.

[0046] In some embodiments, determining the constraint levels of each program slice in the source program according to all the test overheads and the subordination relationships between each program slice can adopt the following steps, that is: Determine the subordination relationships between each program slice; Perform clustering analysis on all the program slices according to all the subordination relationships to obtain multiple slice association clusters; Calculate the comprehensive test overhead of each slice association cluster based on the test overhead of each program slice; Determine the constraint level of each slice association cluster according to the comprehensive test overhead of each slice association cluster, and map the constraint level of each slice association cluster to each program slice within the corresponding association cluster to obtain the constraint levels of each program slice in the source program.

[0047] In specific implementation, first, determine the subordination relationship between each program slice, that is: construct the control flow graph of the source program through the Low-Level Virtual Machine (LLVM) in the static program analysis tool, and automatically identify the subordination relationship between each program slice from the control flow graph. In addition, the statement relationship algorithm can also be used to determine the subordination relationship between each program slice, which is not limited here; second, perform clustering analysis on all program slices according to all the subordination relationships to obtain multiple slice association clusters, that is: divide the program slices with the same subordination relationship into one slice association cluster from all the program slices, and then obtain multiple slice association clusters; then, calculate the comprehensive test overhead of each slice association cluster based on the test overhead of each program slice, that is: for each slice association cluster, calculate the average value of the test overheads of each program slice in the slice association cluster, and use the average calculation result as the comprehensive test overhead of the slice association cluster, and then obtain the comprehensive test overheads of each slice association cluster; finally, determine the constraint level of each slice association cluster according to the comprehensive test overhead of each slice association cluster, and map the constraint level of each slice association cluster to each program slice within the corresponding association cluster to obtain the constraint levels of each program slice in the source program, that is: arrange the comprehensive test overheads of each slice association cluster in ascending order, and label the constraint levels of each slice association cluster according to the arrangement order, and map the constraint level of each slice association cluster to each program slice within the corresponding association cluster to obtain the constraint levels of each program slice in the source program.

[0048] It should be noted that in this embodiment, the subordination 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 for 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 for program slices with anomalies. In the debugging of network security software, there may be multiple associated abnormal program segments in the source program. 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 key parts of the system or program can be processed in a timely manner.

[0049] In step 106, debug each program slice according to the constraint level of each program slice.

[0050] In some embodiments, debugging each program slice according to the constraint level of each program slice can be implemented by the following steps, that is: Obtain the constraint level of each program slice; Arrange each program slice according to the constraint level of each program slice, and debug each program slice according to the arrangement order.

[0051] In specific implementation, first, obtain the constraint level of each program slice. Second, arrange each of the program slices according to the constraint level of each program slice, and use a debugging tool (such as GDB, LLDB) to debug the program slices in the arranged order. After the debugging is completed, mark the repaired code as resolved.

[0052] In addition, on the other hand of the present application, in some embodiments, the present application provides a computer network security software debugging system. Refer to Figure 4 , which is a schematic structural diagram of a computer network security software debugging system shown according to some embodiments of the present application. The computer network security software debugging system 200 includes: a collection module 201, a processing module 202, and an execution module 203, which are described as follows: Collection module 201. In the present application, the collection module 201 is mainly used to set multiple test nodes of the source program in the target network security software, and collect the execution status at each test node when the source program executes test data. Processing module 202. In the present application, the processing module 202 is mainly 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 construct a target search domain for the source program during testing through the program context information of the key test nodes. The processing module 202 is further used to determine the static control flow graph and the dynamic control flow graph of the program code in the target search domain, and perform abnormal 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 with abnormalities in the source program. In addition, the processing module 202 is further used to obtain the test coverage information of each program slice, and determine the test overhead of each program slice 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. Furthermore, the processing module 202 is further used to determine the constraint level of each program slice in the source program according to all the test overheads and the subordination relationship between the program slices. Execution module 203. In the present application, the execution module 203 is mainly used to debug each program slice according to the constraint level of each program slice.

[0053] In addition, the present application further provides a computer device, which includes a memory and a processor. The memory stores code, and the processor is configured to obtain the code and execute the above-mentioned computer network security software debugging method.

[0054] In some embodiments, refer to Figure 5, which is a schematic structural diagram of a computer device implementing a computer network security software debugging method according to some embodiments of the present application. The computer network security software debugging method in the above embodiments can be implemented by Figure 5 the computer device shown. The computer device 300 includes at least one processor 301, a communication bus 302, a memory 303, and at least one communication interface 304.

[0055] The processor 301 can be a general-purpose central processing unit (CPU), or a specific application integrated circuit (ASIC), or one or more for controlling the execution of the computer network security software debugging method in the present application.

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

[0057] The memory 303 can be a read-only memory (ROM), or other types of static storage devices that can store static information and instructions, a random access memory (RAM), or other types of dynamic storage devices that can store 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 compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disks, or other magnetic storage devices, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 303 can exist independently and be connected to the processor 301 through the communication bus 302. The memory 303 can also be integrated with the processor 301.

[0058] Among them, the memory 303 is used to store the program code for executing the solution of the present application, and is controlled by the processor 301 to execute. The processor 301 is used to execute the program code stored in the memory 303. The program code can include one or more software modules. The determination of the computer network security software debugging method in the above embodiments can be implemented by one or more software modules in the processor 301 and the program code in the memory 303.

[0059] A communication interface 304, using any device such as a transceiver, for communicating with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area networks (WLAN), etc.

[0060] In a specific implementation, as an example, a computer device may include multiple processors, and each of these processors may be a single-core (single CPU) processor or a multi-core (multi CPU) processor. Here, the processor may refer to one or more devices, circuits, and / or processing cores for processing data (such as computer program instructions).

[0061] The above computer device may be a general-purpose computer device or a special-purpose computer device. In a specific implementation, the computer device may be a desktop computer, a laptop computer, a network server, a personal digital assistant (PDA), a mobile phone, a tablet computer, a wireless terminal device, a communication device, or an embedded device. The embodiments of the present application do not limit the type of the computer device.

[0062] In addition, the present application also provides a computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, the above computer network security software debugging method is implemented.

[0063] Although the preferred embodiments of the present application have been described, those skilled in the art can make additional changes and modifications once they learn the basic creative concept. Therefore, the appended claims are intended to be interpreted to include the preferred embodiments as well as all changes and modifications falling within the scope of the present application.

[0064] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application is also intended to include these modifications and variations.

Claims

1. A computer network security software debugging method, characterized in that: The steps include: Setting multiple test nodes of a source program in the target network security software, and collecting the execution status of each test node when the source program executes test data; Locate key test nodes of the source program in the target network security software based on the execution status at each test node, and construct a target search domain when the source program is tested through program context information of the key test nodes; Determine a static control flow graph and a dynamic control flow graph of the program code in the target search domain, perform exception slicing on the program entity in the target search domain based on the static control flow graph and the dynamic control flow graph, and obtain a plurality of program slices with exceptions in the source program; Acquire test coverage information of each program slice, and determine the test overhead of each program slice 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; Determine the constraint level of each program slice in the source program according to all test overheads and the affiliation between each program slice; Each program slice is debugged with respect to its constraint level.

2. The method according to claim 1, characterized in that Setting multiple test nodes of the source program in the target network security software specifically includes: Performing static analysis on the source program in the target network security software to obtain conditional branch points and loop structure points of the source program; The conditional branch point and the loop structure point are respectively set as test nodes of the source program in the target network security software.

3. The method according to claim 1, characterized in that 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, including: Get the execution status of each test node; The execution status at each test node is parsed to obtain the parsing result at each test node, and according to the execution order of the source program executing the test data, the first test node whose parsing result is that the program execution fails is extracted as the key test node of the source program in the target network security software.

4. The method according to claim 1, characterized in that Constructing the target search domain for testing the source program through the program context information of the key test node specifically includes: Extracting program context information of the key test nodes; Analyzing a call chain associated with the key test node based on the program context information; A target search domain for testing the source program is constructed based on the call chain and the initial code position of the source program.

5. The method according to claim 1, characterized in that Performing abnormal slicing on the program entity in the target search domain based on the static control flow graph and the dynamic control flow graph to obtain a plurality of program slices having abnormalities in the source program specifically includes: Determine, based on the static control flow graph, a plurality of static suspicious statements when the target search domain does not execute test data; Determine, based on the dynamic control flow graph, a plurality of dynamic suspicious statements when the target search domain executes test data; Selecting a static suspicious statement as a selected static suspicious statement, performing statement association analysis on the selected static suspicious statement and each dynamic suspicious statement, obtaining a statement association state of the selected static suspicious statement, and continuing to determine the statement association states of the remaining static suspicious statements; A plurality of abnormal program statements are extracted from all static suspicious statements according to all statement association states, and each abnormal program statement is independently segmented to obtain a plurality of program slices having abnormalities in the source program.

6. The method according to claim 1, characterized in that Determining the test overhead of each program slice 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 specifically includes: Obtaining a static control flow graph and a dynamic control flow graph of program codes in a target search domain; Extracting 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; Determine the path complexity of the source program in the target network security software when executing the test data according to the total number of actual execution paths and the total number of covered paths; Determine the execution coverage of each program slice according to the test coverage information of each program slice; The test overhead of each program slice is determined by the execution coverage and path complexity corresponding to each program slice.

7. The method according to claim 1, characterized in that The execution status of each test node when the source program executes the test data is collected through the debugger.

8. A computer network security software debugging system, characterized in that: include: A collection module, used to set multiple test nodes of a source program in a target network security software, and collect the execution status of each test node when the source program executes test data; A processing module, used to locate key test nodes of a source program in a target network security software based on the execution status at each test node, and to construct a target search domain when the source program is tested through program context information of the key test nodes; The processing module is further used to determine a static control flow graph and a dynamic control flow graph of the program code in the target search domain, and perform abnormal slicing on the program entity in the target search domain based on the static control flow graph and the dynamic control flow graph to obtain a plurality of program slices with abnormalities in the source program; The processing module is further used to obtain test coverage information of each program slice, and determine the test overhead of each program slice 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; The processing module is further used to determine the constraint level of each program slice in the source program according to all test overheads and the affiliation between each program slice; An execution module is used to debug each program slice according to the constraint level of each program slice.

9. A computer device, characterized in that: The computer device comprises a memory and a processor, the memory stores codes, and the processor is configured to obtain the codes and execute the computer network security software debugging method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the computer network security software debugging method according to any one of claims 1 to 7 is implemented.

Images