Protocol fuzz testing method and system based on long life cycle enumeration variable state

Abstract

The invention relates to a protocol fuzz testing method and system based on a long-life-cycle enumeration variable state. The method comprises the following steps: S1, a static enumeration declaration statement instrumentation analysis stage; s2, a short life cycle enumeration variable dynamic analysis stage; s3, a static assignment statement instrumentation analysis stage; and S4, a fuzzy test stage. The system comprises a static analysis module, a dynamic analysis module, a network IO module and a variation feedback module. According to the method, the source code of the protocol entity program to be tested is statically analyzed to capture distribution and use of enumeration type variables in the source code. State transition is represented by monitoring changes of enumeration variable value domains, and a corresponding state tree structure is constructed, so that stateful grey box fuzz testing is carried out on any protocol entity program to be tested under the condition that extra manual analysis is not needed.

Description

Technical Field

[0001] The present invention belongs to the technical field of fuzzy testing, and in particular relates to a protocol fuzzy testing method and system based on long life cycle enumeration variable states. Background Art

[0002] As a set of rules agreed upon by both parties in network communication, network protocols clearly specify the format, method and error verification mechanism of data transmission. Its core purpose is to ensure that data between different devices and systems can be exchanged error-free and reliably. Although these protocols are designed to ensure the security and consistency of communication, any complex software implementation may introduce vulnerabilities. And with the further iteration of the protocol, more complex branches are introduced, increasing the possibility of vulnerabilities. Attackers can use these vulnerabilities to carry out a variety of attacks, such as data leakage, tampering, denial of service (DoS) attacks, and remote code execution (RCE), thereby threatening the security and stability of the system. For example, the famous malicious vulnerability Heartbleed. In recent years, significant progress has been made in the field of protocol fuzz testing, and the research focus has been mainly on methods based on grammar generation. In recent years, significant progress has been made in the field of protocol fuzz testing, and the research focus has been mainly on methods based on grammar generation. These methods greatly improve the test efficiency by using information such as coverage feedback to guide the generation of test cases, and promote fuzz testing towards maximizing coverage.

[0003] Chinese patent CN118784340A discloses a multi-dimensional monitoring method using the coverage of states during the test process, evaluating the number of times each state is selected for testing, the number of state transition paths from the initial state to the current state, and the number of new test cases generated by the state. And use them to balance the number of long path and short path transfer test cases, ensuring that the test process is both in-depth and extensive to enhance vulnerability mining performance. The response code of the tested protocol is used as the state in the method.

[0004] Chinese patent CN117478566A discloses an innovative field-aware gray-box text protocol fuzz testing technology and system. This invention first uses potential delimiters to split the seed message into multiple fields and records the different values ​​that may appear in each field. Furthermore, based on the diversity and rarity of each field value, a differentiated mutation strength strategy is customized for each field. This method optimizes the random generation efficiency of effective test cases by trying to understand the protocol text message format. But similarly, this method uses the response code of the tested protocol as the status.

[0005] In summary, in the field of fuzz testing of stateful protocols, the existing technology relies on the response code of the specific protocol to help define the state. This also leads to the following problems: At the same time, when dealing with protocols with different response mechanisms, it is often necessary to customize the strategy for extracting response codes for specific types of protocols; For some protocols, the response code is not sufficient to represent the internal status of the protocol; It is not suitable for protocols that have no response code mechanism at all, which limits its versatility and scope of application. Summary of the invention

[0006] The technical problem to be solved by the present invention is to provide a protocol fuzz testing method and system based on the state of long-life enumeration variables, which captures the allocation and use of enumeration type variables in the source code of the protocol entity program to be tested by static analysis. The state transition is characterized by monitoring the changes in the value range of these enumeration variables, and a corresponding state tree structure is constructed, thereby realizing stateful gray box fuzz testing of any protocol entity program to be tested without additional manual analysis.

[0007] The present invention provides a protocol fuzzy testing method based on long life cycle enumeration variable state, comprising the following steps: S1: Enter the static enumeration declaration statement instrumentation analysis phase, deploy the protocol entity program to be tested locally, then compile the protocol entity program to be tested, and use clang to generate the corresponding abstract syntax tree AST for all files of the locally deployed protocol entity program to be tested, analyze the abstract syntax tree AST nodes to determine and instrument the declarations of all enumeration types; S2: Enter the short life cycle enumeration variable dynamic analysis phase, use the stubs of the declaration statement of the enumeration type to analyze the life cycle of the declared variable, and remove the stubs of the enumeration variables with only a short life cycle; S3: Enter the static assignment statement instrumentation analysis phase, remove the monitoring of enumeration variables with only a short life cycle, and use the AST node analysis again to determine and instrument the assignment statements of all remaining enumeration variables, and record their values; S4: Enter the fuzz testing phase, apply the basic principles of fuzz testing, and conduct extensive testing by continuously mutating the initial seed; define and track the state transfer within the entity program of the protocol to be tested; build a state tree node model corresponding to the seed to evaluate the validity of the seed, and feed the evaluation results back to the fuzz testing process to guide the subsequent test case generation and selection.

[0008] Preferably, the specific steps of step S1 include: S1.1: Correctly deploy the complete file of the protocol entity program to be tested in the local environment computer, compile the protocol entity program to be tested and capture all the compilation instructions to finally generate compile_commands.json; S1.1.1: Deploy the complete file of the protocol entity program to be tested correctly in the local environment computer, configure the environment and dependencies required by the protocol entity program to be tested, and use make related instructions to try to compile the complete file. After ensuring that the compilation can be completed, use make clean to clear the compilation; S1.1.2: Compile again, and use bear to capture all compilation instructions to generate a complete compile_commands.json file, which describes the external dependencies and compilation instructions of each .c file; S1.2: For all entity program files of the deployed protocol to be tested, use clang and compile_commands.json to generate the corresponding abstract syntax tree AST; S1.3: The instrumentation locates the direct declaration locations of all non-global enumeration value types by analyzing the abstract syntax tree AST of each file source code.

[0009] Preferably, the specific steps of step S1.3 include: S1.3.1: Create a small cpp tool to analyze the abstract syntax tree AST in the protocol entity program to be tested one by one, detect and report all enumeration type variable declarations in non-global scopes in the C / C++ protocol entity program to be tested. First, define the abstract syntax tree AST enumeration type declaration statement iterator EnumVarDeclVisitor class. The enumeration type declaration statement iterator EnumVarDeclVisitor class inherits the clang built-in visit assignment statement callback function RecursiveASTVisitor template class; S1.3.2: In the EnumVarDeclVisitor class, the method VisitVarDecl is rewritten to call back the VisitVarDecl method. The VisitVarDecl method is called when traversing all variable declaration statements in the abstract syntax tree AST ... It first determines whether the declaration is in the top-level scope, that is, a global variable, and exits if so; Determine whether the declared variable is a certain enumeration type variable, if not, exit; Prints a report of the non-global enumeration variable declaration locations found, including the file path, name, and line number; S1.3.3: Traverse all nodes in the abstract syntax tree AST to match and execute the functions in the EnumVarDeclVisitor class, create a first file, and print the matching declarations to the first file; S1.3.4: Use Python to complete a script, which reads the first file one by one; for each line, it inserts a special statement DECLARE_LIVE_HELPER after the statement in the same line of its source code, and the special statement DECLARE_LIVE_HELPER includes the name name of the declared variable and the address name_ptr of the declared variable.

[0010] Preferably, the specific steps of step S2 include: S2.1: recompile the protocol entity program to be tested using the source file after the instrumentation process in step S1. At this time, the file has completed the instrumentation process in step S1, that is, the special statement DECLARE_LIVE_HELPER is written in several file locations; S2.2: Start pre-testing, run the protocol entity program to be tested and wait for connection as a server, open a new local window as a client, connect to the server, and send some preset messages to simulate the normal data exchange process with the server; repeat the connection and communication multiple times to make the special statement DECLARE_LIVE_HELPER obtain more information; S2.3: Analyze the printed information to mark obvious short-life variables; take the time when the client sends any information to the server as the boundary, extract the printed debugging information area during any two times when the client sends messages to the server for separate analysis, and if it is found that the address of a variable is created during this period and is prompted to be destroyed in the same area, mark it as a short-life variable, otherwise mark it as a long-life variable and no longer pay attention to it; if a variable is marked as a short-life variable, and it is found to be a long-life variable when analyzing other intervals, mark it as a long-life variable; S2.4: Output and record the declaration file names and line numbers of all variables that are completely analyzed and marked as short-lived, so as to facilitate subsequent processing and eliminate the monitoring needs of these variables.

[0011] Preferably, the specific steps of the static assignment statement instrumentation analysis phase in step S3 include: S3.1: Analyze the abstract syntax tree AST of each file source code to locate the assignment statement positions of all non-global enumeration value types for the instrumentation, create a second file, and output the positions to the second file; S3.2: Use a python script to read each line of the second file through the python script, open the corresponding line of the response file, and insert the instrumentation statement _Call_Instrument after the ";" of the same line expression, wherein the instrumentation statement _Call_Instrument includes a globally incremented instrumentation idx and an assignment statement var, and the assignment statement var is the LHS of the current assignment statement.

[0012] Preferably, the specific steps of step S3.1 include: S3.1.1: Use the EnumAssignmentVisitor class, an enumeration type assignment statement iterator, to define a method for traversing the abstract syntax tree AST nodes. This class inherits RecursiveASTVisitor and overrides the VisitBinaryOperator method in the EnumVarDeclVisitor class, an enumeration type declaration statement iterator. The VisitBinaryOperator callback function is called when traversing all assignment type statements in the abstract syntax tree AST. The judgment process of this function is as follows: 4) For the current assignment statement LHS = RHS, take out the left expression LHS of the assignment statement; 5) Determine whether LHS is an enumeration type or a member expression. If neither is true, exit. If it is an enumeration type, execute step 7. If it is a member expression, execute step 6. 6) Loop to make LHS point to its child nodes until there are no child nodes. At this time, determine whether LHS is an enumeration type. If so, execute step 7), otherwise exit; 7) Determine whether the declaration line number of the current LHS is equal to one of the line numbers recorded in step S2.4. Only if there is no match, the target line is considered to be found, and the information of the line is printed; S3.1.2: Recursively perform the algorithm analysis of step S3.1.1 on all files in the project; and output the final result to the second file.

[0013] Preferably, the specific steps of step S4 include: S4.1: recompile the protocol entity program to be tested using the source file after the instrumentation process in step S1; at this point, instrumentation statements _Call_Instrument have been inserted into several file locations to track state transfers and variable changes; S4.2: Perform fuzz test pre-test from at least one seed. First, select any seed from the seed library, start the protocol entity program to be tested, and send the seed to the protocol entity program to be tested for processing. During the seed execution process, the instrumentation statement _Call_Instrument is automatically called and a state transition tree is automatically created. S4.3: Fuzz testing officially begins. In each test, a state is selected from the state transition tree as the current fuzzy state. When selecting seeds, the Markov chain principle is followed, and the seeds with the least number of visits in global access are given priority. S4.4: randomly select a seed associated with this state, start the entity program of the protocol to be tested, and send the seed for testing; S4.4: For the current test seed, define multiple mutation operators, including bit flip, byte flip, double byte flip, random insertion, random deletion, and random splicing; each time a mutation occurs, select several operators to randomly combine and apply them to the original seed to obtain a new seed, and send the new seed for testing; S4.5: After the execution is completed, the execution status is analyzed and the step returns to S4.4 to mutate until the upper limit of 1000 times is reached.

[0014] Preferably, the specific steps of step S4.2 include: S4.2.1: Calculate the new state node flag node_id; the protocol entity program to be tested receives the message sent by the main test process during operation, and in normal processing, it will run the instrumentation statement _Call_Instrument at the instrumentation location and construct a node flag node_id. The node flag node_id construction method is as follows: node_id=(idx<<6)+var, Among them, << means moving to the left, idx means the globally incremented stub idx, var means the assignment statement var, and the assignment statement var is the LHS of the current assignment statement; S4.2.2: Construct new nodes and edges; when the first fuzzy starts, the current state is set to 0 by default. During the execution of the instrumentation statement _Call_Instrument, an edge from node 0 pointing to node marker node_id is constructed, node marker node_id is used as a child node of the current node, and the current state is set to node marker node_id; S4.2.3: Insert the newly discovered edges and nodes into the state transition tree of the current seed, which will facilitate analysis after the test is completed.

[0015] Preferably, the specific steps of step S4.5 include: S4.5.1: Analyze coverage; analyze the bitmap of shared memory to determine whether there is a new coverage edge. If there is a new coverage edge, insert the mutated seed into the seed library; S4.5.2: Analyze the state tree; analyze the current state transition constructed with the help of the instrumentation statement _Call_Instrument, record the current state transition in the global state, and update the number of visits to each state; at the same time, if there is a new state node, insert the corresponding seed into the seed library; S4.5.3: Update the seed execution status; if the mutated new seed is finally saved to the seed library, the state tree constructed with the help of the instrumentation statement _Call_Instrument will be initialized and saved for it, and the seed will be linked to each node in the state tree.

[0016] A system of a protocol fuzz testing method based on long life cycle enumeration variable state, comprising a static analysis module, a dynamic analysis module, a network IO execution module and a mutation feedback module; The static analysis module has two phases of work. The first phase is to insert the declaration position of the enumeration variable. It starts working in the fuzz test preparation phase. By analyzing the abstract syntax tree AST of the protocol entity program to be tested, it identifies and marks the declaration position of all enumeration type variables and performs necessary code insertion operations. The second phase is to insert the assignment statement position. After the dynamic analysis module is completed, the analysis results are used to selectively insert the assignment statement positions of some enumeration variables. The dynamic analysis module starts working after the static analysis module completes the stubbing of the enumeration variable declaration location. It dynamically monitors the actual life cycle of the enumeration variable by simulating the interaction between the client and the server in the normal communication process, identifies the variables with a short life cycle, and marks them as unmonitored objects. The network IO execution module, together with the mutation feedback module, completes the fuzz test and is responsible for processing the sending task of the mutation seed. It listens to the request of the mutation feedback module and works, and uses the Forksever mechanism to process the message as the seed to connect and send the message to the server program under test; The mutation feedback module works in formal fuzz testing, using a random combination of mutation operators to automatically mutate the original seed to generate a new seed. At the same time, the network IO execution module is started to send the new seed for execution. After confirming that the execution is complete, the coverage information and the state tree structure are analyzed to determine whether to save the new seed.

[0017] The present invention has the following technical effects: 1. The present invention captures the allocation and use of enumeration type variables in the source code of the protocol entity program to be tested by static analysis. The state transition is characterized by monitoring the changes in the value range of these enumeration variables, and a corresponding state tree structure is constructed, thereby realizing stateful gray box fuzz testing of any protocol entity program to be tested without additional manual analysis.

[0018] 2. The present invention can automatically detect the assignment statements of enumerated variables inside the protocol entity program to be tested, and accurately insert them. During operation, the system can automatically build a state transition tree to understand and simulate the state machine of the protocol entity program to be tested. This method not only allows the system to explore more in-depth branch paths, but also triggers more potential program vulnerabilities, greatly improving detection efficiency and accuracy. The intelligence level of the system is further improved, so that even in a complex stateful protocol environment, new state transition paths can be efficiently identified and utilized, thereby achieving more comprehensive code coverage and a higher vulnerability discovery rate.

[0019] 3. The present invention uses the value change of the enumerated variable inside the protocol entity program to be tested as the core indicator of the internal state. This method enables indiscriminate and efficient fuzz testing for the protocol entity program to be tested, whether it has a response code or no response code. This method breaks the dependence of traditional testing methods on the response code of a specific type of protocol and provides a wider and more universal applicability. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 A schematic diagram of the overall framework of the protocol fuzzy testing method and system for long life cycle enumeration variable states of the present invention; Figure 2 Graph of the state tree structure automatically created during fuzz testing. DETAILED DESCRIPTION

[0021] In order to make the objectives, technical solutions and advantages of the present invention more clear, the present invention is described in detail below with reference to the accompanying drawings.

[0022] like Figure 1 As shown, the protocol fuzz testing method based on the long life cycle enumeration variable state includes the following steps: S1: Enter the static enumeration declaration statement instrumentation analysis phase, deploy the protocol entity program to be tested locally, then compile the protocol entity program to be tested, and use clang to generate the corresponding abstract syntax tree AST for all files of the locally deployed protocol entity program to be tested, analyze the abstract syntax tree AST nodes to determine and instrument all enumeration type declarations; the main purpose of this phase is to identify all enumeration type declarations in the program and mark them out, in preparation for the analysis of step S2; S1.1: Correctly deploy the complete file of the protocol entity program to be tested in the local environment computer, compile the protocol entity program to be tested and capture all the compilation instructions to finally generate compile_commands.json; S1.1.1: Deploy the complete file of the protocol entity program to be tested correctly in the local environment computer, configure the environment and dependencies required by the protocol entity program to be tested, and use make related instructions to try to compile the complete file. After ensuring that the compilation can be completed, use make clean to clear the compilation; S1.1.2: Compile again, and use bear to capture all compilation instructions to generate a complete compile_commands.json. This file describes the external dependencies and compilation instructions of each .c file; clang only targets a single file when performing abstract syntax tree AST analysis. However, in actual projects, there may be complex cross-file definitions or function calls between files. With the information provided by compile_commands.json, clang can correctly resolve these cross-file references during the analysis process to ensure that complete context information is obtained. In addition, for large projects, not all files are fully used in each compilation. The project usually contains many unit test files or other files with special compilation requirements. compile_commands.json clearly indicates which files are required in the actual compilation process, allowing analysis tools to focus on these key files, improve efficiency and reduce unnecessary computational overhead.

[0023] S1.2: For all entity program files of the deployed protocol to be tested, use clang and compile_commands.json to generate the corresponding abstract syntax tree AST; S1.3: The instrumentation locates the direct declaration locations of all non-global enumeration value types by analyzing the abstract syntax tree AST of each file source code.

[0024] S1.3.1: Create a small cpp tool to analyze the abstract syntax tree AST in the protocol entity program to be tested one by one, detect and report all enumeration type variable declarations in non-global scopes in the C / C++ protocol entity program to be tested. First, define the abstract syntax tree AST enumeration type declaration statement iterator EnumVarDeclVisitor class. The enumeration type declaration statement iterator EnumVarDeclVisitor class inherits the clang built-in visit assignment statement callback function RecursiveASTVisitor template class; S1.3.2: In the EnumVarDeclVisitor class, the method VisitVarDecl is rewritten to call back the VisitVarDecl method. The VisitVarDecl method is called when traversing all variable declaration statements in the abstract syntax tree AST ... 1) It first determines whether the declaration is in the top-level scope, that is, a global variable, and exits if so; 2) Determine whether the declared variable is a certain enumeration type variable, if not, exit; 3) Print the report of the non-global enumeration variable declaration location found, including the file path, name and line number; S1.3.3: Traverse all nodes in the abstract syntax tree AST to match and execute the functions in the EnumVarDeclVisitor class of the enumeration type declaration statement iterator, create a first file, and print the matching declarations to the first file; the analysis of step S1.3.2 can only be applied to a single file, and all files of the entire project need to be recursively read for analysis. The first file is Dec.txt.

[0025] S1.3.4: Use python to complete a script, which reads the first file one by one; for each line, a special statement DECLARE_LIVE_HELPER is inserted after the statement in the same line of the source code, and the special statement DECLARE_LIVE_HELPER includes the name of the declared variable name and the address of the declared variable name_ptr. In use, the special statement DECLARE_LIVE_HELPER is recorded as DECLARE_LIVE_HELPER (name, &name_ptr), and when the enumeration declaration statement CON_FUNC_RETURN ret is found; DECLARE_LIVE_HELPER ("ret", &ret) is written after the same line. When the enumeration declaration statement itself is used as a parameter of a function, and the function is defined as int Set_mode (EnumType mode), DECLARE_LIVE_HELPER ("mode", &mode) is written into the first line of the function.

[0026] S2: Enter the dynamic analysis phase of short-lifecycle enumeration variables, use the stubs of the declaration statements of the enumeration type to analyze the lifecycle of the declared variable, and remove the stubs of enumeration variables with only short lifecycles; run the program in this phase and dynamically analyze the lifecycle length of each specific enumeration variable. Remove the stub code of enumeration variables with only short lifecycles (such as local variables) to reduce unnecessary performance overhead and complexity. In this phase, actual operation can determine which enumeration variables have short lifecycles and are not key variables that affect complex interactive logic; S2.1: Use the source file that has been instrumented in step S1 to recompile the protocol entity program to be tested. At this time, the file has been instrumented by the step S1, that is, the special statement DECLARE_LIVE_HELPER is written in several file locations; DECLARE_LIVE_HELPER (name, & name_ptr) is a self-defined macro behavior, where name is the name of the declared variable and name_ptr is the address of the declared variable. The specific function of DECLARE_LIVE_HELPER (name, & name_ptr) is described as follows. It declares an instantiation variable of the class live_helper, which stores name and name_ptr information and marks it as __attribute__ (cleanup). __attribute__ (cleanup) is an extended attribute supported by GCC and clang compilers, which is used to specify a cleanup function (cleanup function), which will be automatically called at the end of the life cycle of the declared variable. In the custom cleanup function, print the saved name and address, and by comparing the addresses, the declaration position and life cycle end position of a variable can be determined. Use __FILE__ and __LINE__ together to save line numbers for analysis.

[0027] S2.2: Start pre-testing, run the protocol entity program to be tested and wait for connection as a server, open a new local window as a client, connect to the server, and send some preset messages to simulate the normal data exchange process with the server; repeat the connection and communication multiple times to make the special statement DECLARE_LIVE_HELPER obtain more information; S2.3: Analyze the printed information to mark obvious short-life variables; take the time when the client sends any information to the server as the boundary, extract the printed debugging information area during any two times when the client sends messages to the server for separate analysis, and if it is found that the address of a variable is created during this period and is prompted to be destroyed in the same area, mark it as a short-life variable, otherwise mark it as a long-life variable and no longer pay attention to it; if a variable is marked as a short-life variable, and it is found to be a long-life variable when analyzing other intervals, mark it as a long-life variable; S2.4: Output and record the declaration file names and line numbers of all variables that are completely analyzed and marked as short-lived, so as to facilitate subsequent processing and eliminate the monitoring needs of these variables.

[0028] S3: Enter the static assignment statement instrumentation analysis phase, remove the monitoring of enumeration variables with only a short life cycle, and use the analysis of the abstract syntax tree AST nodes again to determine and instrument the assignment statements of all remaining enumeration variables, and record their values; based on step S2, use the dynamically obtained short-life cycle enumeration variable information to further optimize the instrumentation results of step S1 and remove the monitoring of non-critical enumeration variables. Then analyze the abstract syntax tree AST nodes again, locate and instrument the assignment statements of all critical enumeration variables, and record their values. This stage inherits the analysis results of the previous two stages, focusing on the enumeration variables that really need to be focused on, and accurately marking their assignment locations to provide support for subsequent fuzz testing.

[0029] S3.1: The instrumentation locates the positions of all assignment statements of non-global enumeration value types by analyzing the abstract syntax tree AST of each file source code, creates a second file, and outputs the positions to the second file; the second file is ins.txt.

[0030] S3.1.1: Use the EnumAssignmentVisitor class, an enumeration type assignment statement iterator, to define a method for traversing the abstract syntax tree AST nodes. This class inherits RecursiveASTVisitor and overrides the VisitBinaryOperator method in the EnumVarDeclVisitor class, an enumeration type declaration statement iterator. The VisitBinaryOperator callback function is called when traversing all assignment type statements in the abstract syntax tree AST. The judgment process of this function is as follows: 4) For the current assignment statement LHS = RHS, take out the left expression LHS of the assignment statement; 5) Determine whether LHS is an enumeration type or a member expression. If neither is true, exit. If it is an enumeration type, execute step 7. If it is a member expression, execute step 6. 6) Loop to make LHS point to its child nodes until there are no child nodes. At this time, determine whether LHS is an enumeration type. If so, execute step 7), otherwise exit; 7) Determine whether the declaration line number of the current LHS is equal to one of the line numbers recorded in step S2.4. Only if there is no match, the target line is considered to be found, and the information of the line is printed; S3.1.2: Recursively perform the algorithm analysis of step S3.1.1 on all files in the project; and output the final result to the second file S3.2: using a python script, reading each line of the second file through the python script, opening the corresponding line of the response file, inserting the instrumentation statement _Call_Instrument after the ";" of the expression in the same line, wherein the instrumentation statement _Call_Instrument includes a globally incremented instrumentation idx and an assignment statement var, wherein the assignment statement var is the LHS of the current assignment statement; S4: Enter the fuzz testing phase, apply the basic principles of fuzz testing, based on the stub code obtained in step S3, conduct extensive testing by continuously mutating the initial seed data (Seed); define and track the state transitions within the protocol entity program to be tested; build a state tree node model corresponding to the seed to evaluate the validity of the seed, and feed the evaluation results back to the fuzz testing process to guide the subsequent test case generation and selection. Since the assignment statements of key enumeration variables are accurately located in step S3, the value changes and state transitions of these variables can be tracked in real time during the test process. Then build a state transition tree model corresponding to the specific test case to evaluate the validity of the current test seed. Then feed back the evaluation results to the test engine to guide the generation and screening of subsequent test cases, and realize the automation and intelligence of the test. This phase makes full use of the system analysis of the previous three phases to carry out efficient fuzz testing around the core enumeration state changes.

[0031] S4.1: recompile the protocol entity program to be tested using the source file after the instrumentation process in step S1; at this point, instrumentation statements _Call_Instrument have been inserted into several file locations to track state transfers and variable changes; S4.2: Perform fuzz test pre-test from at least one seed. First, select any seed from the seed library, start the protocol entity program to be tested, and send the seed to the protocol entity program to be tested for processing. During the seed execution process, the instrumentation statement _Call_Instrument is automatically called and a state transition tree is automatically created. S4.2.1: Calculate the new state node flag node_id; the protocol entity program to be tested receives the message sent by the main test process during operation, and in normal processing, it will run the instrumentation statement _Call_Instrument at the instrumentation location and construct a node flag node_id. The node flag node_id construction method is as follows: node_id=(idx<<6)+var, Among them, << means moving to the left, idx means the globally incremented stub idx, var means the assignment statement var, and the assignment statement var is the LHS of the current assignment statement; S4.2.2: Construct new nodes and edges; when the first fuzzy starts, the current state is set to 0 by default. During the execution of the instrumentation statement _Call_Instrument, an edge from node 0 pointing to node marker node_id is constructed, node marker node_id is used as a child node of the current node, and the current state is set to node marker node_id; like Figure 2 As shown in , it is a global state tree, in which any pre-order traversal sequence from the root to the leaf node is the state transition experienced by a fuzzy test of a certain seed, such as Figure 2 Path in .

[0032] By establishing a global state tree, it can be used to analyze the state transfer process. Most importantly, using the state tree, in each fuzzy process, you can arbitrarily select a state State, in which several seeds are saved. There is a certain message msg associated with the state in the seed. In the entire content of the seed, until it is sent to msg, the state of the entity program of the protocol to be tested is State. On this basis, the code of deeper states can be further fuzzified. If the global state tree is not used, each fuzzy will always start from state 0, which greatly hinders the exploration of the deep space of stateful protocols.

[0033] S4.2.3: Insert the newly discovered edges and nodes into the state transition tree of the current seed, which will facilitate analysis after the test is completed.

[0034] S4.3: Fuzz testing officially begins. In each test, a state is selected from the state transition tree as the current fuzzy state. When selecting seeds, the Markov chain principle is followed, and the seeds with the least number of visits in global access are given priority. S4.4: randomly select a seed associated with this state, start the entity program of the protocol to be tested, and send the seed for testing; S4.4: For the current test seed, define multiple mutation operators, including bit flip, byte flip, double byte flip, random insertion, random deletion, and random splicing; each time a mutation occurs, select several operators to randomly combine and apply them to the original seed to obtain a new seed, and send the new seed for testing; S4.5: After the execution is completed, the execution status is analyzed and the step returns to S4.4 to mutate until the upper limit of 1000 times is reached.

[0035] S4.5.1: Analyze coverage; analyze the bitmap of shared memory to determine whether there is a new coverage edge. If there is a new coverage edge, insert the mutated seed into the seed library; S4.5.2: Analyze the state tree; analyze the current state transition constructed with the help of the instrumentation statement _Call_Instrument, record the current state transition in the global state, and update the number of visits to each state; at the same time, if there is a new state node, insert the corresponding seed into the seed library; S4.5.3: Update the seed execution status; if the mutated new seed is finally saved to the seed library, the state tree constructed with the help of the instrumentation statement _Call_Instrument will be initialized and saved for it, and the seed will be linked to each node in the state tree.

[0036] For this embodiment, in order to prove the effectiveness of the method of the present invention, the present invention sets up a 24-hour fuzz test in the same experimental environment. The experiment selects the most advanced stateful fuzz test tool AFL-Net and the stateless fuzz test tool LibFuzzer supported by Google as the control group. The test set selects the widely used open source protocols Live555 and Openssl, and tests the same protocol entity program to be tested. Each group of experiments takes 24 hours. In order to reduce the impact of randomness in fuzz testing, all experiments are repeated three times, and the results are averaged. On the coverage edge of RTSP, HYFuzzer covers an additional 2.5% of paths than AFL-Net and an additional 2.6% of paths than LibFuzzer. In terms of crashes, HYFuzzer is 28% more than AFL-Net and 10% more than LibFuzzer; in Openssl, HYFuzzer is 5.6% more than AFL-Net and 2.8% more than LibFuzzer. None of the three fuzzers triggered any crashes within 24 hours.

[0037] Any of the methods or steps described above may be stored as computer instructions or programs in various types of computer memories, and the computer instructions or programs may be recognized by various types of computer processors to implement any of the methods or steps described above.

[0038] The embodiments described above are only descriptions of the preferred modes of the present invention, and are not intended to limit the scope of the present invention. Without departing from the design spirit of the present invention, various modifications and improvements made to the technical solutions of the present invention by ordinary technicians in this field should all fall within the protection scope determined by the claims of the present invention.

Claims

1. A protocol fuzz testing method based on long life cycle enumeration variable state, characterized by: The steps include: S1: Enter the static enumeration declaration statement instrumentation analysis phase, deploy the protocol entity program to be tested locally, then compile the protocol entity program to be tested, and use clang to generate the corresponding abstract syntax tree AST for all files of the locally deployed protocol entity program to be tested, analyze the abstract syntax tree AST nodes to determine and instrument the declarations of all enumeration types; S2: Enter the short life cycle enumeration variable dynamic analysis phase, use the stubs of the declaration statement of the enumeration type to analyze the life cycle of the declared variable, and remove the stubs of the enumeration variables with only a short life cycle; S3: Enter the static assignment statement instrumentation analysis phase, remove the monitoring of enumeration variables with only a short life cycle, and use the AST node analysis again to determine and instrument the assignment statements of all remaining enumeration variables, and record their values; S4: Enter the fuzz testing phase, apply the basic principles of fuzz testing, and conduct extensive testing by continuously mutating the initial seed; define and track the state transfer within the entity program of the protocol to be tested; A state tree node model corresponding to the seed is constructed to evaluate the validity of the seed, and the evaluation results are fed back to the fuzz testing process to guide the subsequent test case generation and selection.

2. The protocol fuzz testing method based on long life cycle enumeration variable state according to claim 1 is characterized in that: The specific steps of step S1 include: S1.1: Correctly deploy the complete file of the protocol entity program to be tested in the local environment computer, compile the protocol entity program to be tested and capture all the compilation instructions to finally generate compile_commands.json; S1.1.1: Deploy the complete file of the protocol entity program to be tested correctly in the local environment computer, configure the environment and dependencies required by the protocol entity program to be tested, and use make related instructions to try to compile the complete file. After ensuring that the compilation can be completed, use make clean to clear the compilation; S1.1.2: Compile again, and use bear to capture all compilation instructions to generate a complete compile_commands.json file, which describes the external dependencies and compilation instructions of each .c file; S1.2: For all entity program files of the deployed protocol to be tested, use clang and compile_commands.json to generate the corresponding abstract syntax tree AST; S1.3: The instrumentation locates the direct declaration locations of all non-global enumeration value types by analyzing the abstract syntax tree AST of each file source code.

3. The protocol fuzzy testing method based on long life cycle enumeration variable state according to claim 2 is characterized in that: The specific steps of step S1.3 include: S1.3.1: Create a small cpp tool to analyze the abstract syntax tree AST in the protocol entity program to be tested one by one, detect and report all enumeration type variable declarations in non-global scopes in the C / C++ protocol entity program to be tested. First, define the abstract syntax tree AST enumeration type declaration statement iterator EnumVarDeclVisitor class. The enumeration type declaration statement iterator EnumVarDeclVisitor class inherits the clang built-in visit assignment statement callback function RecursiveASTVisitor template class; S1.3.2: In the EnumVarDeclVisitor class, the method VisitVarDecl is rewritten to call back the VisitVarDecl method. The VisitVarDecl method is called when traversing all variable declaration statements in the abstract syntax tree AST ... It first determines whether the declaration is in the top-level scope, that is, a global variable, and exits if so; Determine whether the declared variable is a certain enumeration type variable, if not, exit; Prints a report of the non-global enumeration variable declaration locations found, including the file path, name, and line number; S1.3.3: Traverse all nodes in the abstract syntax tree AST to match and execute the functions in the EnumVarDeclVisitor class, create a first file, and print the matching declarations to the first file; S1.3.4: Use Python to complete a script, which reads the first file one by one; for each line, it inserts a special statement DECLARE_LIVE_HELPER after the statement in the same line of its source code, and the special statement DECLARE_LIVE_HELPER includes the name name of the declared variable and the address name_ptr of the declared variable.

4. The protocol fuzz testing method based on long life cycle enumeration variable state according to claim 1 is characterized in that: The specific steps of step S2 include: S2.1: recompile the protocol entity program to be tested using the source file after the instrumentation process in step S1. At this time, the file has completed the instrumentation process in step S1, that is, the special statement DECLARE_LIVE_HELPER is written in several file locations; S2.2: Start pre-testing, run the protocol entity program to be tested and wait for connection as a server, open a new local window as a client, connect to the server, and send some preset messages to simulate the normal data exchange process with the server; repeat the connection and communication multiple times to make the special statement DECLARE_LIVE_HELPER obtain more information; S2.3: Analyze the printed information to mark obvious short-life variables; take the time when the client sends any information to the server as the boundary, extract the printed debugging information area during any two times when the client sends messages to the server for separate analysis, and if it is found that the address of a variable is created during this period and is prompted to be destroyed in the same area, mark it as a short-life variable, otherwise mark it as a long-life variable and no longer pay attention to it; if a variable is marked as a short-life variable, and it is found to be a long-life variable when analyzing other intervals, mark it as a long-life variable; S2.4: Output and record the declaration file names and line numbers of all variables that are completely analyzed and marked as short-lived, so as to facilitate subsequent processing and eliminate the monitoring needs of these variables.

5. The protocol fuzz testing method based on long life cycle enumeration variable state according to claim 1 is characterized in that: The specific steps of the static assignment statement instrumentation analysis phase in step S3 include: S3.1: Analyze the abstract syntax tree AST of each file source code to locate the assignment statement positions of all non-global enumeration value types for the instrumentation, create a second file, and output the positions to the second file; S3.2: Use a python script to read each line of the second file, open the corresponding line of the response file, and insert the instrumentation statement _Call_Instrument after the ";" of the expression in the same line. The instrumentation statement _Call_Instrument includes a globally incremented instrumentation idx and an assignment statement var, and the assignment statement var is the LHS of the current assignment statement.

6. The protocol fuzz testing method based on long life cycle enumeration variable state according to claim 5 is characterized in that: The specific steps of step S3.1 include: S3.1.1: Use the EnumAssignmentVisitor class, an enumeration type assignment statement iterator, to define a method for traversing the abstract syntax tree AST nodes. This class inherits RecursiveASTVisitor and overrides the VisitBinaryOperator method in the EnumVarDeclVisitor class, an enumeration type declaration statement iterator. The VisitBinaryOperator callback function is called when traversing all assignment type statements in the abstract syntax tree AST. The judgment process of this function is as follows: 4) For the current assignment statement LHS = RHS, take out the left expression LHS of the assignment statement; 5) Determine whether LHS is an enumeration type or a member expression. If neither is true, exit. If it is an enumeration type, execute step 7. If it is a member expression, execute step 6. 6) Loop to make LHS point to its child nodes until there are no child nodes. At this time, determine whether LHS is an enumeration type. If so, execute step 7), otherwise exit; 7) Determine whether the declaration line number of the current LHS is equal to one of the line numbers recorded in step S2.

4. Only if there is no match, the target line is considered to be found, and the information of the line is printed; S3.1.2: Recursively perform the algorithm analysis of step S3.1.1 on all files in the project; and output the final result to the second file.

7. The protocol fuzzy testing method based on long life cycle enumeration variable state according to claim 1 is characterized in that: The specific steps of step S4 include: S4.1: recompile the protocol entity program to be tested using the source file after the instrumentation process in step S1; at this point, instrumentation statements _Call_Instrument have been inserted into several file locations to track state transfers and variable changes; S4.2: Perform fuzz test pre-test from at least one seed. First, select any seed from the seed library, start the protocol entity program to be tested, and send the seed to the protocol entity program to be tested for processing. During the seed execution process, the instrumentation statement _Call_Instrument is automatically called and a state transition tree is automatically created. S4.3: Fuzz testing officially begins. In each test, a state is selected from the state transition tree as the current fuzzy state. When selecting seeds, the Markov chain principle is followed, and the seeds with the least number of visits in global access are given priority. S4.4: randomly select a seed associated with this state, start the entity program of the protocol to be tested, and send the seed for testing; S4.4: For the current test seed, define multiple mutation operators, including bit flip, byte flip, double byte flip, random insertion, random deletion, and random splicing; each time a mutation occurs, select several operators to randomly combine and apply them to the original seed to obtain a new seed, and send the new seed for testing; S4.5: After the execution is completed, the execution status is analyzed and the step returns to S4.4 to mutate until the upper limit of 1000 times is reached.

8. The protocol fuzzy testing method based on long life cycle enumeration variable state according to claim 7 is characterized in that: The specific steps of step S4.2 include: S4.2.1: Calculate the new state node flag node_id; the protocol entity program to be tested receives the message sent by the main test process during operation, and in normal processing, it will run the instrumentation statement _Call_Instrument at the instrumentation location and construct a node flag node_id. The node flag node_id construction method is as follows: node_id=(idx<<6)+var, Among them, << means moving to the left, idx means the globally incremented stub idx, var means the assignment statement var, and the assignment statement var is the LHS of the current assignment statement; S4.2.2: Construct new nodes and edges; when the first fuzzy starts, the current state is set to 0 by default. During the execution of the instrumentation statement _Call_Instrument, an edge from node 0 pointing to node marker node_id is constructed, node marker node_id is used as a child node of the current node, and the current state is set to node marker node_id; S4.2.3: Insert the newly discovered edges and nodes into the state transition tree of the current seed, which will facilitate analysis after the test is completed.

9. The protocol fuzz testing method based on long life cycle enumeration variable state according to claim 7 is characterized in that: The specific steps of step S4.5 include: S4.5.1: Analyze coverage; analyze the bitmap of shared memory to determine whether there is a new coverage edge. If there is a new coverage edge, insert the mutated seed into the seed library; S4.5.2: Analyze the state tree; analyze the current state transition constructed with the help of the instrumentation statement _Call_Instrument, record the current state transition in the global state, and update the number of visits to each state; at the same time, if there is a new state node, insert the corresponding seed into the seed library; S4.5.3: Update the seed execution status; if the mutated new seed is finally saved to the seed library, the state tree constructed with the help of the instrumentation statement _Call_Instrument will be initialized and saved for it, and the seed will be linked to each node in the state tree.

10. A system comprising the protocol fuzz testing method based on long life cycle enumeration variable state according to claim 1, characterized in that: It includes static analysis module, dynamic analysis module, network IO execution module and mutation feedback module; The static analysis module has two phases of work. The first phase is to insert the declaration position of the enumeration variable. It starts working in the fuzz test preparation phase. By analyzing the abstract syntax tree AST of the protocol entity program to be tested, it identifies and marks the declaration position of all enumeration type variables and performs necessary code insertion operations. The second phase is to insert the assignment statement position. After the dynamic analysis module is completed, the analysis results are used to selectively insert the assignment statement positions of some enumeration variables. The dynamic analysis module starts working after the static analysis module completes the stubbing of the enumeration variable declaration location. It dynamically monitors the actual life cycle of the enumeration variable by simulating the interaction between the client and the server in the normal communication process, identifies the variables with a short life cycle, and marks them as unmonitored objects. The network IO execution module, together with the mutation feedback module, completes the fuzz test and is responsible for processing the sending task of the mutation seed. It listens to the request of the mutation feedback module and works, and uses the Forksever mechanism to process the message as the seed to connect and send the message to the server program under test; The mutation feedback module works in formal fuzz testing, using a random combination of mutation operators to automatically mutate the original seed to generate a new seed. At the same time, the network IO execution module is started to send the new seed for execution. After confirming that the execution is complete, the coverage information and the state tree structure are analyzed to determine whether to save the new seed.

Images