A Protocol Fuzzy Testing Method and System Based on Long-Lifetime Enumerated Variable States

Abstract

This invention relates to a protocol fuzzing method and system based on the states of long-lifecycle enumerated variables. The method includes the following steps: S1: Static enumeration declaration statement instrumentation analysis stage; S2: Short-lifecycle enumeration variable dynamic analysis stage; S3: Static assignment statement instrumentation analysis stage; S4: Fuzzing stage. The system includes a static analysis module, a dynamic analysis module, a network I / O module, and a mutation feedback module. This invention captures the allocation and use of enumeration type variables in the source code of the protocol entity program under test through static analysis. State transitions are characterized by monitoring changes in the value range of these enumeration variables, and a corresponding state tree structure is constructed, thereby enabling stateful gray-box fuzzing of any protocol entity program under test without additional manual analysis.

Description

Technical Field

[0001] This invention belongs to the field of fuzz testing technology, and specifically relates to a protocol fuzz testing method and system based on long-lifecycle enumerated variable states. Background Technology

[0002] As a set of rules agreed upon by both parties in network communication, network protocols explicitly define the format, methods, and error verification mechanisms for data transmission. Their core purpose is to ensure error-free and reliable data exchange between different devices and systems. Although these protocols aim to guarantee the security and consistency of communication, any complex software implementation can introduce vulnerabilities. Furthermore, with further iterations of protocols, more complex branches are introduced, increasing the likelihood of vulnerabilities. Attackers can exploit these vulnerabilities to carry out various attacks, such as data leakage, data tampering, denial-of-service (DoS) attacks, and remote code execution (RCE), thereby threatening the security and stability of the system. A well-known example is the critical vulnerability Heartbleed. In recent years, significant progress has been made in the field of protocol fuzzing, with research focusing primarily on syntax-based generation methods. These methods greatly improve testing efficiency by utilizing information such as coverage feedback to guide test case generation and drive fuzzing towards maximizing coverage.

[0003] Chinese patent CN118784340A discloses a method for multi-dimensional monitoring using state coverage during testing. This method evaluates 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 each state. It uses these metrics to balance the number of test cases for long and short path transitions, ensuring a thorough yet comprehensive testing process to enhance vulnerability discovery performance. The method uses the response code of the protocol under test as the state.

[0004] Chinese patent CN117478566A discloses an innovative field-aware gray-box text protocol fuzzing technology and system. This invention first uses potential delimiters to segment the seed message into multiple fields and records the possible different values ​​for each field. Furthermore, based on the diversity and rarity of each field's values, a differentiated mutation intensity strategy is customized for each field. This method optimizes the efficiency of randomly generating effective test cases by attempting to understand the protocol text message format. However, this method also uses the response code of the protocol under test as the status.

[0005] In summary, in the field of fuzz testing for stateful protocols, existing technologies rely on the response codes of specific protocols to aid in state definition. This leads to the following problems:

[0006] 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;

[0007] For some protocols, the response code is not sufficient to characterize the internal state of the protocol;

[0008] It is not applicable to protocols that do not have a response code mechanism at all, which limits its versatility and scope of application. Summary of the Invention

[0009] The technical problem this invention aims to solve is to provide a protocol fuzzing method and system based on the states of long-lifecycle enumerated variables. This method captures the allocation and use of enumerated type variables within the source code of the protocol entity under test through static analysis. State transitions are characterized by monitoring changes in the value ranges of these enumerated variables, and a corresponding state tree structure is constructed. This enables stateful gray-box fuzzing of any protocol entity under test without additional manual analysis.

[0010] This invention provides a protocol fuzzing method based on the state of long-lifecycle enumerated variables, comprising the following steps:

[0011] S1: Enter the static enumeration declaration statement instrumentation analysis stage. Deploy the protocol entity program under test locally, then compile the protocol entity program under test, and use clang to generate the corresponding abstract syntax tree (AST) for all files of the locally deployed protocol entity program under test. Analyze the AST nodes to determine and instrument all enumeration type declarations.

[0012] S2: Enter the dynamic analysis stage of short-lifetime enumeration variables. Use instrumentation on the declaration statement of the enumeration type to analyze the lifetime of the declared variable and remove the instrumentation of enumeration variables that only have short lifetimes.

[0013] S3: Enter the static assignment statement instrumentation analysis phase, remove the monitoring of enumeration variables with only short lifespans, and use the analysis abstract syntax tree (AST) nodes again to determine and instrument the assignment statements of all remaining enumeration variables, and record their values.

[0014] S4: Enter the fuzzing phase, apply the basic principles of fuzzing, conduct extensive testing by continuously mutating the initial seed; define and track the state transitions within the protocol entity program under test; construct the state tree node model corresponding to the seed to evaluate the seed's effectiveness, and feed the evaluation results back to the fuzzing process to guide the generation and selection of subsequent test cases.

[0015] Preferably, step S1 includes the following steps:

[0016] S1.1: Correctly deploy the complete file of the protocol entity program under test on the local computer environment, compile the protocol entity program under test and capture all compilation instructions to finally generate compile_commands.json;

[0017] S1.1.1: After correctly deploying the complete file of the protocol entity program under test on the local computer environment, configuring the environment and dependencies required by the protocol entity program under test, use the make-related commands to try to compile the complete file. After ensuring that the compilation can be completed, use make clean to clean up the compilation.

[0018] S1.1.2: Compile again, using bear to capture all compilation instructions to generate a complete compile_commands.json file, which describes the external dependencies and compilation instructions for each .c file;

[0019] S1.2: For all deployed protocol entity program files, use clang and compile_commands.json to generate the corresponding Abstract Syntax Tree (AST);

[0020] S1.3: Instrumentation is performed by analyzing the Abstract Syntax Tree (AST) of the source code of each file to locate the direct declaration location of all non-global enumeration value types.

[0021] Preferably, step S1.3 includes the following steps:

[0022] S1.3.1: Create a small C++ tool to analyze the Abstract Syntax Tree (AST) of the protocol entity program under test one by one, and detect and report all enumeration type variable declarations in the non-global scope in the C / C++ protocol entity program under test. First, define the EnumVarDeclVisitor class, which is an iterator for enumeration type declaration statements in the AST. The EnumVarDeclVisitor class inherits the clang built-in access assignment statement callback function RecursiveASTVisitor template class.

[0023] S1.3.2: In the EnumVarDeclVisitor class, which iterates over the enumeration type declaration statement iterator, the VisitVarDecl method is overridden. The VisitVarDecl callback function is called when traversing all variable declaration statements in the Abstract Syntax Tree (AST). The decision process for the VisitVarDecl callback function is as follows:

[0024] It first determines whether the declaration is in the top-level scope, i.e., a global variable; if so, it exits.

[0025] Check if the declared variable is a specific enumeration type variable; if not, exit.

[0026] The print report found the locations of non-global enumeration variable declarations, including the file path, name, and line number;

[0027] S1.3.3: Traverse all nodes in the Abstract Syntax Tree (AST) to match the functions in the EnumVarDeclVisitor class that execute enumeration type declaration statements, create a first file, and print the matched declarations to the first file;

[0028] S1.3.4: Use Python to complete a script that reads the first file one by one; for each line, it inserts a special statement DECLARE_LIVE_HELPER after the statement on the same line of its source code. The special statement DECLARE_LIVE_HELPER includes the name of the declared variable name and the address of the declared variable name_ptr.

[0029] Preferably, step S2 includes the following steps:

[0030] S2.1: Recompile the protocol entity program under test using the source file after instrumentation in step S1. At this time, the file has been instrumented by step S1, that is, the special statement DECLARE_LIVE_HELPER is written in several file positions.

[0031] S2.2: Start pre-testing, run the protocol entity program under test and wait for connection as a server, open a new window locally 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 allow the special statement DECLARE_LIVE_HELPER to obtain more information;

[0032] S2.3: Analyze the printed information to mark obvious short-lived variables; taking the client sending any message to the server as the boundary, extract the printed debugging information area between any two client-server message transmissions and analyze it separately. If the address of a variable is found to be created during this period and destroyed in the same area, mark it as a short-lived variable; otherwise, mark it as a long-lived variable and no longer pay attention to it; if a variable is marked as a short-lived variable, and it is found to be a long-lived variable when analyzing other intervals, mark it as a long-lived variable.

[0033] S2.4: Output the filenames and line numbers of all variable declarations that have been fully analyzed and marked as having a short lifespan, so as to facilitate subsequent processing and exclusion of monitoring needs for these variables.

[0034] Preferably, the specific steps of the static assignment statement instrumentation analysis stage in step S3 include:

[0035] S3.1: By analyzing the Abstract Syntax Tree (AST) of the source code of each file, the positions of assignment statements for all non-global enumeration value types are located by instrumentation, a second file is created, and the positions are output to the second file;

[0036] S3.2: Use a Python script to read each line of the second file, open the corresponding line of the response file, and insert an instrumentation statement _Call_Instrument after the semicolon ";" in the same line expression. The instrumentation statement _Call_Instrument includes a globally incrementing instrumentation idx and an assignment statement var, where the assignment statement var is the LHS of the current assignment statement.

[0037] Preferably, step S3.1 includes the following steps:

[0038] S3.1.1: The EnumAssignmentVisitor class, which iterates over assignment statements of enumeration types, is used to define the method for traversing nodes of the Abstract Syntax Tree (AST). This class inherits from RecursiveASTVisitor. The VisitBinaryOperator method is overridden in the EnumVarDeclVisitor class to access assignment statement callbacks. This VisitBinaryOperator is called when traversing all assignment statements in the AST. The function's decision-making process is as follows:

[0039] 4) For the current assignment statement LHS = RHS, retrieve the left-hand expression LHS of the assignment statement;

[0040] 5) Determine if LHS is an enumeration type or a member expression. If neither, exit. If it is an enumeration type, proceed to step 7). If it is a member expression, proceed to step 6).

[0041] 6) Loop through LHS to point to its child nodes until there are no child nodes. At this point, check if LHS is an enumeration type. If it is, proceed to step 7); otherwise, exit.

[0042] 7) Determine whether the current LHS declaration line number is equal to one of the line numbers recorded in step S2.4. Only if there is no match is it considered that the target line has been found, and the information of that line is output and printed.

[0043] 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.

[0044] Preferably, step S4 includes the following steps:

[0045] S4.1: Recompile the protocol entity program under test using the source file after instrumentation in step S1; at this time, the instrumentation statement _Call_Instrument has been inserted in several file locations to track state transitions and variable changes;

[0046] S4.2: Start fuzzing pre-testing from at least one seed. First, select any seed from the seed library, start the protocol entity program under test, and send the seed to the protocol entity program under test for processing. During the execution of the seed, the instrumentation statement _Call_Instrument will be automatically called and a state transition tree will be automatically created.

[0047] S4.3: Start fuzz testing. In each test, select a state from the state transition tree as the current fuzzy state. When selecting a seed, follow the Markov chain principle and prioritize the seed that has been visited the fewest times in global access.

[0048] S4.4: Randomly select the associated and saved seed in this state, start the protocol entity program under test, and send the seed for testing;

[0049] S4.4: For the current test seed, define a variety of mutation operators, including: bit flip, byte flip, double byte flip, random insertion, random deletion, and random concatenation; each time mutation occurs, select several operators to be randomly combined and applied to the original seed to obtain a new seed, and send the new seed for testing;

[0050] S4.5: After execution, analyze the execution status and return to S4.4 to perform mutation until the maximum number of times is 1000.

[0051] Preferably, step S4.2 includes the following specific steps:

[0052] S4.2.1: Calculate the new state node flag node_id; When the protocol entity program under test receives a message sent by the main test process during runtime, it will run the instrumentation statement _Call_Instrument at the instrumentation point during normal processing and construct a node flag node_id. The node flag node_id is constructed as follows:

[0053] node_id=(idx<<6)+var,

[0054] Where << means to move left, idx means to be a globally incrementing instrumentation idx, and var means to be an assignment statement var, which is the LHS of the current assignment statement;

[0055] S4.2.2: Construct new nodes and edges; at the start of the first fuzzy operation, the current state is 0 by default. During the execution of the instrumentation statement _Call_Instrument, an edge is constructed pointing from node 0 to the node flag node_id, the node flag node_id is made into a child node of the current node, and the current state is set to the node flag node_id.

[0056] 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.

[0057] Preferably, step S4.5 includes the following steps:

[0058] S4.5.1: Analyze coverage; Analyze the bitmap of shared memory to determine if there are any new covering edges. If there are new covering edges, insert the mutated seed into the seed library.

[0059] S4.5.2: Analyze the state tree; analyze the current state transitions built with the help of the instrumentation statement _Call_Instrument, record the current state transitions in the global database, and update the access count of each state; at the same time, if there is a new state node, insert the corresponding seed into the seed library;

[0060] S4.5.3: Update seed execution status; if the mutated new seed is eventually saved to the seed library, initialize and save the state tree built with the help of the instrumentation statement _Call_Instrument, and link the seed to every node in the state tree.

[0061] A system for protocol fuzz testing based on long-lifecycle enumerated variable states includes a static analysis module, a dynamic analysis module, a network I / O execution module, and a mutation feedback module.

[0062] The static analysis module works in two phases. The first phase is instrumentation of enumeration variable declarations, which begins during the fuzzing preparation phase. By analyzing the Abstract Syntax Tree (AST) of the protocol entity program under test, it identifies and marks the declaration locations of all enumeration type variables and performs necessary code instrumentation. The second phase is instrumentation of assignment statements, which, after the dynamic analysis module has completed its work, uses its analysis results to selectively instrument some of the assignment statement locations of enumeration variables.

[0063] The dynamic analysis module starts working after the static analysis module completes the instrumentation of the enumeration variable declaration positions; by simulating the client-server interaction in the normal communication process, it dynamically monitors the actual life cycle of the enumeration variables, identifies variables with short life cycles, and marks them as unmonitored objects.

[0064] The network I / O execution module, together with the mutation feedback module, performs complete fuzz testing. It is responsible for handling the task of sending mutation seeds. It listens for requests from the mutation feedback module and works accordingly, using the Forksever mechanism to process messages as seeds for connection and message sending to the server program under test.

[0065] The mutation feedback module works during formal fuzz testing. It uses a random combination of mutation operators to automatically mutate from the original seed to generate a new seed. At the same time, it starts the network I / O execution module to send the new seed for execution. After confirming that the execution is complete, it analyzes the coverage information and the construction of the state tree to determine whether to save the new seed.

[0066] The present invention has the following technical effects:

[0067] 1. This invention captures the allocation and use of enumeration type variables in the source code of the protocol entity program under test through static analysis. By monitoring the changes in the value range of these enumeration variables to characterize state transitions and constructing a corresponding state tree structure, stateful gray-box fuzzy testing of any protocol entity program under test can be achieved without additional manual analysis.

[0068] 2. This invention can automatically detect assignment statements of enumerated variables within the program of the protocol entity under test and accurately instrument them. During runtime, the system can automatically construct a state transition tree to understand and simulate the state machine of the protocol entity program under test. This method not only allows the system to explore deeper branch paths but also triggers more potential program vulnerabilities, greatly improving detection efficiency and accuracy. It further enhances the system's intelligence level, enabling efficient identification and utilization of new state transition paths even in complex stateful protocol environments, thereby achieving more comprehensive code coverage and a higher vulnerability discovery rate.

[0069] 3. This invention uses the changes in the values ​​of enumerated variables within the protocol entity under test as the core indicator of its internal state. This method enables efficient and indiscriminate fuzz testing for both protocol entities with and without response codes. This approach breaks away from the dependence of traditional testing methods on response codes specific to certain protocol types, providing broader and more universal applicability. Attached Figure Description

[0070] Figure 1This is a schematic diagram of the protocol fuzzing method and system overall framework for the long-lifecycle enumeration variable state of the present invention.

[0071] Figure 2 This is a state tree construction diagram automatically created during fuzz testing. Detailed Implementation

[0072] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be described in detail below with reference to the accompanying drawings.

[0073] like Figure 1 As shown, the protocol fuzzing method based on long-lifecycle enumerated variable states includes the following steps:

[0074] S1: Enter the static enumeration declaration statement instrumentation analysis stage. Deploy the protocol entity program under test locally, then compile the protocol entity program under test, and use clang to generate the corresponding abstract syntax tree (AST) for all files of the locally deployed protocol entity program under test. Analyze the AST nodes to determine and instrument all enumeration type declarations. The main purpose of this stage is to identify and mark all enumeration type declarations in the program to prepare for the analysis in step S2.

[0075] S1.1: Correctly deploy the complete file of the protocol entity program under test on the local computer environment, compile the protocol entity program under test and capture all compilation instructions to finally generate compile_commands.json;

[0076] S1.1.1: After correctly deploying the complete file of the protocol entity program under test on the local computer environment, configuring the environment and dependencies required by the protocol entity program under test, use the make-related commands to try to compile the complete file. After ensuring that the compilation can be completed, use make clean to clean up the compilation.

[0077] S1.1.2: Compilation is performed again, using bear to capture all compilation instructions to generate a complete `compile_commands.json` file. This file describes the external dependencies and compilation instructions for each `.c` file; clang only performs abstract syntax tree (AST) analysis on a single file. However, in real-world projects, there may be complex cross-file definitions or function calls between files. Using the information provided by `compile_commands.json`, clang can correctly resolve these cross-file references during analysis, ensuring complete context information is obtained. Furthermore, for large projects, not all files are fully used in every compilation. Projects typically contain many unit test files or other files with specific compilation requirements. `compile_commands.json` explicitly indicates which files are actually needed during compilation, allowing analysis tools to focus on these critical files, improving efficiency and reducing unnecessary computational overhead.

[0078] S1.2: For all deployed protocol entity program files, use clang and compile_commands.json to generate the corresponding Abstract Syntax Tree (AST);

[0079] S1.3: Instrumentation is performed by analyzing the Abstract Syntax Tree (AST) of the source code of each file to locate the direct declaration location of all non-global enumeration value types.

[0080] S1.3.1: Create a small C++ tool to analyze the Abstract Syntax Tree (AST) of the protocol entity program under test one by one, and detect and report all enumeration type variable declarations in the non-global scope in the C / C++ protocol entity program under test. First, define the EnumVarDeclVisitor class, which is an iterator for enumeration type declaration statements in the AST. The EnumVarDeclVisitor class inherits the clang built-in access assignment statement callback function RecursiveASTVisitor template class.

[0081] S1.3.2: In the EnumVarDeclVisitor class, which iterates over the enumeration type declaration statement iterator, the VisitVarDecl method is overridden. The VisitVarDecl callback function is called when traversing all variable declaration statements in the Abstract Syntax Tree (AST). The decision process for the VisitVarDecl callback function is as follows:

[0082] 1) It first determines whether the declaration is in the top-level scope, i.e., a global variable; if so, it exits.

[0083] 2) Determine if the declared variable is a specific enumeration type variable; if not, exit.

[0084] 3) Print the report to find the declaration locations of non-global enumeration variables, including the file path, name, and line number;

[0085] S1.3.3: Traverse all nodes in the Abstract Syntax Tree (AST) to match the functions in the EnumVarDeclVisitor class that execute enumeration type declaration statements, create a first file, and print the matched declarations to the first file. The analysis in step S1.3.2 can only be applied to a single file; it is necessary to recursively read all files in the entire project for analysis. The first file is Dec.txt.

[0086] S1.3.4: Use Python to complete a script that reads the first file line by line. For each line, it inserts a special statement `DECLARE_LIVE_HELPER` after the statement on the same line in its source code. `DECLARE_LIVE_HELPER` includes the name of the declared variable `name` and the address of the declared variable `name_ptr`. In use, `DECLARE_LIVE_HELPER` is denoted as `DECLARE_LIVE_HELPER(name, &name_ptr)`. When an enumeration declaration statement `CON_FUNC_RETURN ret` is encountered, `DECLARE_LIVE_HELPER("ret", &ret)` is written after it on the same line. When the enumeration declaration statement itself is used as a parameter of a function defined as `int Set_mode(EnumType mode)`, `DECLARE_LIVE_HELPER("mode", &mode)` is written to the first line of that function.

[0087] S2: Enter the dynamic analysis phase for short-lived enumeration variables. This phase utilizes instrumentation on the declaration statements of enumeration types to analyze the lifetime of the declared variables and removes instrumentation on enumeration variables with only short lifetimes. In this phase, the program runs and dynamically analyzes the lifetime length of each specific enumeration variable. Instrumentation code for enumeration variables with only short lifetimes (such as local variables) is removed to reduce unnecessary performance overhead and lower complexity. Through actual execution, this phase can determine which enumeration variables have short lifetimes and are not key variables affecting complex interaction logic.

[0088] S2.1: Recompile the protocol entity program under test using the source file after instrumentation in step S1. At this point, the file has already undergone instrumentation in step S1, specifically by adding the special statement `DECLARE_LIVE_HELPER` to several file locations. `DECLARE_LIVE_HELPER(name,&name_ptr)` is a custom 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 as follows: it declares an instance variable of the class `live_helper`, storing the `name` and `name_ptr` information, and marking it as `__attribute__(cleanup)`. `__attribute__(cleanup)` is an extended attribute supported by the GCC and clang compilers, used to specify a cleanup function that is automatically called when the lifetime of the declared variable ends. In the custom cleanup function, the saved `name` and address are printed. By comparing the addresses, the declaration location and the end-of-life location of a variable can be determined. Both __FILE__ and __LINE__ are used to store line numbers for analysis.

[0089] S2.2: Start pre-testing, run the protocol entity program under test and wait for connection as a server, open a new window locally 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 allow the special statement DECLARE_LIVE_HELPER to obtain more information;

[0090] S2.3: Analyze the printed information to mark obvious short-lived variables; taking the client sending any message to the server as the boundary, extract the printed debugging information area between any two client-server message transmissions and analyze it separately. If the address of a variable is found to be created during this period and destroyed in the same area, mark it as a short-lived variable; otherwise, mark it as a long-lived variable and no longer pay attention to it; if a variable is marked as a short-lived variable, and it is found to be a long-lived variable when analyzing other intervals, mark it as a long-lived variable.

[0091] S2.4: Output the filenames and line numbers of all variable declarations that have been fully analyzed and marked as having a short lifespan, so as to facilitate subsequent processing and exclusion of monitoring needs for these variables.

[0092] S3: Enter the static assignment statement instrumentation analysis phase. Remove monitoring of only short-lived enumeration variables. Again, analyze the Abstract Syntax Tree (AST) nodes to identify and instrument the assignment statements for all remaining enumeration variables, and record their values. Based on step S2, further optimize the instrumentation results of step S1 using dynamically obtained short-lived enumeration variable information, removing monitoring of non-critical enumeration variables. Then, analyze the AST nodes again to locate and instrument the assignment statements for all critical enumeration variables, recording their values. This phase builds upon the analysis results of the previous two phases, focusing on the enumeration variables that truly require attention and accurately marking their assignment positions, providing support for subsequent fuzz testing.

[0093] S3.1: By analyzing the Abstract Syntax Tree (AST) of the source code of each file, the positions of assignment statements for all non-global enumeration value types are located by instrumentation. A second file is created and the positions are output to the second file; the second file is ins.txt.

[0094] S3.1.1: The EnumAssignmentVisitor class, which iterates over assignment statements of enumeration types, is used to define the method for traversing nodes of the Abstract Syntax Tree (AST). This class inherits from RecursiveASTVisitor. The VisitBinaryOperator method is overridden in the EnumVarDeclVisitor class to access assignment statement callbacks. This VisitBinaryOperator is called when traversing all assignment statements in the AST. The function's decision-making process is as follows:

[0095] 4) For the current assignment statement LHS = RHS, retrieve the left-hand expression LHS of the assignment statement;

[0096] 5) Determine if LHS is an enumeration type or a member expression. If neither, exit. If it is an enumeration type, proceed to step 7). If it is a member expression, proceed to step 6).

[0097] 6) Loop through LHS to point to its child nodes until there are no child nodes. At this point, check if LHS is an enumeration type. If it is, proceed to step 7); otherwise, exit.

[0098] 7) Determine whether the current LHS declaration line number is equal to one of the line numbers recorded in step S2.4. Only if there is no match is it considered that the target line has been found, and the information of that line is output and printed.

[0099] S3.1.2: Recursively execute the algorithm analysis of step S3.1.1 on all files in the project; and output the final result to the second file.

[0100] S3.2: Use a Python script to read each line of the second file, open the corresponding line of the response file, and insert an instrumentation statement _Call_Instrument after the semicolon ";" in the same line expression. The instrumentation statement _Call_Instrument includes a globally incrementing instrumentation idx and an assignment statement var, where the assignment statement var is the LHS of the current assignment statement.

[0101] S4: Entering the fuzzing phase, applying the basic principles of fuzzing, and based on the instrumented code obtained in step S3, extensive testing is conducted by continuously mutating the initial seed data; defining and tracking the state transitions within the protocol entity program under test; constructing a state tree node model corresponding to the seed to evaluate the seed's effectiveness, and feeding the evaluation results back to the fuzzing process to guide subsequent test case generation and selection. Because step S3 accurately located the assignment statements of key enumeration variables, the value changes and state transitions of these variables can be tracked in real time during testing. This allows for the construction of a state transition tree model corresponding to specific test cases to evaluate the effectiveness of the current test seed. The evaluation results are then fed back to the testing engine to guide the generation and selection of subsequent test cases, achieving automated and intelligent testing. This phase fully utilizes the system analysis of the previous three phases, conducting efficient fuzzing around the core enumeration state changes.

[0102] S4.1: Recompile the protocol entity program under test using the source file after instrumentation in step S1; at this time, the instrumentation statement _Call_Instrument has been inserted in several file locations to track state transitions and variable changes;

[0103] S4.2: Start fuzzing pre-testing from at least one seed. First, select any seed from the seed library, start the protocol entity program under test, and send the seed to the protocol entity program under test for processing. During the execution of the seed, the instrumentation statement _Call_Instrument will be automatically called and a state transition tree will be automatically created.

[0104] S4.2.1: Calculate the new state node flag node_id; When the protocol entity program under test receives a message sent by the main test process during runtime, it will run the instrumentation statement _Call_Instrument at the instrumentation point during normal processing and construct a node flag node_id. The node flag node_id is constructed as follows:

[0105] node_id=(idx<<6)+var,

[0106] Where << means to move left, idx means to be a globally incrementing instrumentation idx, and var means to be an assignment statement var, which is the LHS of the current assignment statement;

[0107] S4.2.2: Construct new nodes and edges; at the start of the first fuzzy operation, the current state is 0 by default. During the execution of the instrumentation statement _Call_Instrument, an edge is constructed pointing from node 0 to the node flag node_id, the node flag node_id is made into a child node of the current node, and the current state is set to the node flag node_id.

[0108] like Figure 2 As shown, this is the global state tree, where the preorder traversal sequence from any root to a leaf node represents the state transitions experienced by a certain seed during a fuzzy test, as follows. Figure 2 The path in.

[0109] By establishing a global state tree, the state transition process can be analyzed. Most importantly, using a state tree, in each fuzzing process, an arbitrary state (`State`) can be selected. This state stores several seeds, each containing a definite message (`msg`) associated with that state. The state of the protocol entity under test is `State` up to the point where `msg` is sent. Based on this, code at deeper state levels can be further fuzzed. Without a global state tree, each fuzzing process would always start from state 0, which significantly hinders the exploration of the deep space of stateful protocols.

[0110] 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.

[0111] S4.3: Start fuzz testing. In each test, select a state from the state transition tree as the current fuzzy state. When selecting a seed, follow the Markov chain principle and prioritize the seed that has been visited the fewest times in global access.

[0112] S4.4: Randomly select the associated and saved seed in this state, start the protocol entity program under test, and send the seed for testing;

[0113] S4.4: For the current test seed, define a variety of mutation operators, including: bit flip, byte flip, double byte flip, random insertion, random deletion, and random concatenation; each time mutation occurs, select several operators to be randomly combined and applied to the original seed to obtain a new seed, and send the new seed for testing;

[0114] S4.5: After execution, analyze the execution status and return to S4.4 to perform mutation until the maximum number of times is 1000.

[0115] S4.5.1: Analyze coverage; Analyze the bitmap of shared memory to determine if there are any new covering edges. If there are new covering edges, insert the mutated seed into the seed library.

[0116] S4.5.2: Analyze the state tree; analyze the current state transitions built with the help of the instrumentation statement _Call_Instrument, record the current state transitions in the global database, and update the access count of each state; at the same time, if there is a new state node, insert the corresponding seed into the seed library;

[0117] S4.5.3: Update seed execution status; if the mutated new seed is eventually saved to the seed library, initialize and save the state tree built with the help of the instrumentation statement _Call_Instrument, and link the seed to every node in the state tree.

[0118] To demonstrate the effectiveness of the method in this embodiment, a 24-hour fuzzing test was conducted in the same experimental environment. The experiment selected AFL-Net, the most advanced stateful fuzzing tool currently available, and LibFuzzer, a stateless fuzzing tool supported by Google, as control groups. The test set consisted of the widely used open-source protocols Live555 and OpenSSL, testing the same protocol entity program. Each experiment lasted 24 hours. To reduce the impact of randomness in fuzzing, all experiments were repeated three times, and the results were averaged. On RTSP coverage edges, HYFuzzer covered 2.5% more paths than AFL-Net and 2.6% more paths than LibFuzzer. In terms of crashes, HYFuzzer crashed 28% more times than AFL-Net and 10% more times than LibFuzzer. In OpenSSL, HYFuzzer crashed 5.6% more times than AFL-Net and 2.8% more times than LibFuzzer. None of the three fuzzers triggered any crashes within 24 hours.

[0119] In summary, any of the methods or steps described above can be stored as computer instructions or programs in various types of computer memory, and the computer instructions or programs can be recognized by various types of computer processors to implement any of the above methods or steps.

[0120] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Various modifications and improvements made by those skilled in the art to the technical solutions of the present invention without departing from the spirit of the present invention should fall within the protection scope defined by the claims of the present invention.

Claims

1. A protocol fuzzing method based on long-lifecycle enumerated variable states, characterized in that: Includes the following steps: S1: Enter the static enumeration declaration statement instrumentation analysis stage. Deploy the protocol entity program under test locally, then compile the protocol entity program under test, and use clang to generate the corresponding abstract syntax tree (AST) for all files of the locally deployed protocol entity program under test. Analyze the AST nodes to determine and instrument all enumeration type declarations. S2: Enter the dynamic analysis stage of short-lifetime enumeration variables. Use instrumentation on the declaration statement of the enumeration type to analyze the lifetime of the declared variable and remove the instrumentation of enumeration variables that only have short lifetimes. S3: Enter the static assignment statement instrumentation analysis phase, remove the monitoring of enumeration variables with only short lifespans, and use the analysis abstract syntax tree (AST) nodes again to determine and instrument the assignment statements of all remaining enumeration variables, and record their values. S4: Enter the fuzzing phase, apply the basic principles of fuzzing, and conduct extensive testing by continuously mutating the initial seed; define and track the state transitions within the protocol entity program under test. A state tree node model corresponding to the seed is constructed to evaluate the effectiveness of the seed, and the evaluation results are fed back to the fuzz testing process to guide the subsequent generation and selection of test cases.

2. The protocol fuzzing method based on long-lifecycle enumerated variable states according to claim 1, characterized in that: The specific steps of step S1 include: S1.1: Correctly deploy the complete file of the protocol entity program under test on the local computer environment, compile the protocol entity program under test and capture all compilation instructions to finally generate compile_commands.json; S1.1.1: After correctly deploying the complete file of the protocol entity program under test on the local computer environment, configuring the environment and dependencies required by the protocol entity program under test, use the make-related commands to try to compile the complete file. After ensuring that the compilation can be completed, use make clean to clean up the compilation. S1.1.2: Compile again, using bear to capture all compilation instructions to generate a complete compile_commands.json file, which describes the external dependencies and compilation instructions for each .c file; S1.2: For all deployed protocol entity program files, use clang and compile_commands.json to generate the corresponding Abstract Syntax Tree (AST); S1.3: Instrumentation is performed by analyzing the Abstract Syntax Tree (AST) of the source code of each file to locate the direct declaration location of all non-global enumeration value types.

3. The protocol fuzzing method based on long-lifecycle enumerated variable states according to claim 2, characterized in that: The specific steps of step S1.3 include: S1.3.1: Create a small C++ tool to analyze the Abstract Syntax Tree (AST) of the protocol entity program under test one by one, and detect and report all enumeration type variable declarations in the non-global scope in the C / C++ protocol entity program under test. First, define the EnumVarDeclVisitor class, which is an iterator for enumeration type declaration statements in the AST. The EnumVarDeclVisitor class inherits the clang built-in access assignment statement callback function RecursiveASTVisitor template class. S1.3.2: In the EnumVarDeclVisitor class, which iterates over the enumeration type declaration statement iterator, the VisitVarDecl method is overridden. The VisitVarDecl callback function is called when traversing all variable declaration statements in the Abstract Syntax Tree (AST). The decision process for the VisitVarDecl callback function is as follows: It first determines whether the declaration is in the top-level scope, i.e., a global variable; if so, it exits. Check if the declared variable is a specific enumeration type variable; if not, exit. The print report found the locations of non-global enumeration variable declarations, including the file path, name, and line number; S1.3.3: Traverse all nodes in the Abstract Syntax Tree (AST) to match the functions in the EnumVarDeclVisitor class that execute enumeration type declaration statements, create a first file, and print the matched declarations to the first file; S1.3.4: Use Python to complete a script that reads the first file one by one; for each line, it inserts a special statement DECLARE_LIVE_HELPER after the statement on the same line of its source code. The special statement DECLARE_LIVE_HELPER includes the name of the declared variable name and the address of the declared variable name_ptr.

4. The protocol fuzzing method based on long-lifecycle enumerated variable states according to claim 1, characterized in that: The specific steps of step S2 include: S2.1: Recompile the protocol entity program under test using the source file after instrumentation in step S1. At this time, the file has been instrumented by step S1, that is, the special statement DECLARE_LIVE_HELPER is written in several file positions. S2.2: Start pre-testing, run the protocol entity program under test and wait for connection as a server, open a new window locally 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 allow the special statement DECLARE_LIVE_HELPER to obtain more information; S2.3: Analyze the printed information to mark obvious short-lived variables; taking the client sending any message to the server as the boundary, extract the printed debugging information area between any two client-server message transmissions and analyze it separately. If the address of a variable is found to be created during this period and destroyed in the same area, mark it as a short-lived variable; otherwise, mark it as a long-lived variable and no longer pay attention to it; if a variable is marked as a short-lived variable, and it is found to be a long-lived variable when analyzing other intervals, mark it as a long-lived variable. S2.4: Output the filenames and line numbers of all variable declarations that have been fully analyzed and marked as having a short lifespan, so as to facilitate subsequent processing and exclusion of monitoring needs for these variables.

5. The protocol fuzzing method based on long-lifecycle enumerated variable states according to claim 4, characterized in that: The specific steps of the static assignment statement instrumentation analysis phase in step S3 include: S3.1: By analyzing the Abstract Syntax Tree (AST) of the source code of each file, the positions of assignment statements for all non-global enumeration value types are located by instrumentation, a second file is created, and the positions are output 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 an instrumentation statement _Call_Instrument after the semicolon ";" in the same line expression. The instrumentation statement _Call_Instrument includes a globally incrementing instrumentation idx and an assignment statement var, where the assignment statement var is the LHS of the current assignment statement.

6. The protocol fuzzing method based on long-lifecycle enumerated variable states according to claim 5, characterized in that: The specific steps of step S3.1 include: S3.1.1: The EnumAssignmentVisitor class, which iterates over assignment statements of enumeration types, is used to define the method for traversing nodes of the Abstract Syntax Tree (AST). This class inherits from RecursiveASTVisitor. The VisitBinaryOperator method is overridden in the EnumVarDeclVisitor class to access assignment statement callbacks. This VisitBinaryOperator is called when traversing all assignment statements in the AST. The function's decision-making process is as follows: 4) For the current assignment statement LHS = RHS, retrieve the left-hand expression LHS of the assignment statement; 5) Determine if LHS is an enumeration type or a member expression. If neither, exit. If it is an enumeration type, proceed to step 7). If it is a member expression, proceed to step 6). 6) Loop through LHS to point to its child nodes until there are no child nodes. At this point, check if LHS is an enumeration type. If it is, proceed to step 7); otherwise, exit. 7) Determine whether the current LHS declaration line number is equal to one of the line numbers recorded in step S2.

4. Only if there is no match is it considered that the target line has been found, and the information of that line is output and 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 fuzzing method based on long-lifecycle enumerated variable states according to claim 1, characterized in that: The specific steps of step S4 include: S4.1: Recompile the protocol entity program under test using the source file after instrumentation in step S1; at this time, the instrumentation statement _Call_Instrument has been inserted in several file locations to track state transitions and variable changes; S4.2: Start fuzzing pre-testing from at least one seed. First, select any seed from the seed library, start the protocol entity program under test, and send the seed to the protocol entity program under test for processing. During the execution of the seed, the instrumentation statement _Call_Instrument will be automatically called and a state transition tree will be automatically created. S4.3: Start fuzz testing. In each test, select a state from the state transition tree as the current fuzzy state. When selecting a seed, follow the Markov chain principle and prioritize the seed that has been visited the fewest times in global access. S4.4: Randomly select the associated and saved seed in this state, start the protocol entity program under test, and send the seed for testing; For the current test seed, a variety of mutation operators are defined, including: bit flip, byte flip, double byte flip, random insertion, random deletion, and random concatenation. During each mutation, several operators are randomly combined and applied to the original seed to obtain a new seed, which is then sent for testing. S4.5: After execution, analyze the execution status and return to S4.4 to perform mutation until the maximum number of times is 1000.

8. The protocol fuzzing method based on long-lifecycle enumerated variable states according to claim 7, characterized in that: The specific steps of step S4.2 include: S4.2.1: Calculate the new state node flag node_id; When the protocol entity program under test receives a message sent by the main test process during runtime, it will run the instrumentation statement _Call_Instrument at the instrumentation point during normal processing and construct a node flag node_id. The node flag node_id is constructed as follows: node_id = (idx << 6) + var Where << means to move left, idx means to be a globally incrementing instrumentation idx, and var means to be an assignment statement var, which is the LHS of the current assignment statement; S4.2.2: Construct new nodes and edges; at the start of the first fuzzy operation, the current state is 0 by default. During the execution of the instrumentation statement _Call_Instrument, an edge is constructed pointing from node 0 to the node flag node_id, the node flag node_id is made into a child node of the current node, and the current state is set to the node flag 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 fuzzing method based on long-lifecycle enumerated variable states according to claim 7, characterized in that: The specific steps of step S4.5 include: S4.5.1: Analyze coverage; Analyze the bitmap of shared memory to determine if there are any new covering edges. If there are new covering edges, insert the mutated seed into the seed library. S4.5.2: Analyze the state tree; analyze the current state transitions built with the help of the instrumentation statement _Call_Instrument, record the current state transitions in the global database, and update the access count of each state; at the same time, if there is a new state node, insert the seed corresponding to the state node into the seed library; S4.5.3: Update seed execution status; if the mutated new seed is eventually saved to the seed library, initialize and save the state tree built with the help of the instrumentation statement _Call_Instrument, and link the seed to every node in the state tree.

10. A system comprising the protocol fuzzing method based on long-lifetime enumerated variable states as described in claim 1, characterized in that: It includes a static analysis module, a dynamic analysis module, a network I / O execution module, and a mutation feedback module; The static analysis module works in two phases. The first phase is instrumentation of enumeration variable declarations, which begins during the fuzzing preparation phase. It analyzes the Abstract Syntax Tree (AST) of the protocol entity program under test, identifies and marks the declaration locations of all enumeration type variables, and performs code instrumentation. The second phase is instrumentation of assignment statements, which is performed after the dynamic analysis module has completed its work. It uses the analysis results to selectively instrument some of the assignment statement locations of enumeration variables. The dynamic analysis module starts working after the static analysis module completes the instrumentation of the enumeration variable declaration positions; by simulating the client-server interaction in the normal communication process, it dynamically monitors the actual life cycle of the enumeration variables, identifies variables with short life cycles, and marks them as unmonitored objects. The network I / O execution module, together with the mutation feedback module, performs complete fuzz testing. It is responsible for handling the task of sending mutation seeds. It listens for requests from the mutation feedback module and works accordingly, using the Forksever mechanism to process messages as seeds for connection and message sending to the server program under test. The mutation feedback module works during formal fuzz testing. It uses a random combination of mutation operators to automatically mutate from the original seed to generate a new seed. At the same time, it starts the network I / O execution module to send the new seed for execution. After confirming that the execution is complete, it analyzes the coverage information and the construction of the state tree to determine whether to save the new seed.

Images