A Protocol Fuzzy Testing Method and System Based on Fine-Grained State Partitioning and Selection

Abstract

This invention relates to a fuzz testing method and system for stateful protocols based on response information. The method includes the following steps: S1: Fuzz test preprocessing stage; S2: Basic state identification stage; S3: Two-layer state subdivision stage; S4: State evaluation and selection stage; S5: Fuzz test execution stage; S6: Feedback analysis stage. The system includes a state partitioning module, a state evaluation module, a test execution module, and a feedback analysis module. This invention significantly improves the efficiency and accuracy of protocol fuzz testing through a two-layer state identification and dynamic evaluation mechanism. Regarding state identification, a basic state identifier is first constructed based on a combination of response codes and control fields. Then, state subdivision is achieved through path feature analysis, effectively avoiding state confusion and redundancy. Regarding state evaluation, by analyzing the topological characteristics, historical gains, and transition probabilities of nodes, focused testing of key control nodes is achieved.

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 fine-grained state partitioning and selection. Background Technology

[0002] As a set of rules agreed upon by both parties in network communication, network protocols specify the format, methods, and error verification mechanisms for data transmission, ensuring 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. In recent years, significant progress has been made in the field of protocol fuzzing, with research focusing primarily on stateful gray-box fuzzing methods. These methods, by introducing state-aware mechanisms to guide test case generation, greatly improve testing efficiency and state space exploration, and drive fuzzing towards more accurate state exploration.

[0003] Chinese patent CN117478566A proposes an intelligent fuzzy testing scheme for text protocols. This scheme segments fields by identifying delimiters in the message, establishes a distribution feature library of field values, and adjusts the application strength of the mutation strategy based on the richness and rarity of field values. This field-aware approach improves the relevance of test case generation. However, the state representation method used in this method lacks in-depth analysis of the protocol's internal execution characteristics, making it difficult to accurately identify and distinguish the true protocol states, easily leading to incorrect state classification. Furthermore, the state selection strategy fails to fully consider the characteristics and functions of state nodes, affecting the rational allocation of test resources.

[0004] Chinese patent CN118784340A proposes a state monitoring mechanism based on multi-dimensional indicators. This method comprehensively considers the testing frequency of states, the number of reachable paths, and testing effectiveness, using these indicators to balance state selection strategies and achieve balanced testing of paths at different depths. While this method has made some progress in optimizing state selection, its definition of states still adopts a relatively traditional approach, failing to deeply analyze and subdivide the internal state characteristics of the protocol. This coarse-grained state representation limits the accuracy of testing, and even with a good state selection strategy, it is difficult to fully realize its potential for vulnerability discovery. This limitation illustrates the necessity of a more detailed classification of protocol states.

[0005] In summary, in the field of fuzz testing for stateful protocols, existing technologies have problems in state awareness and the selection and scheduling of state nodes:

[0006] The granularity of state segmentation is too coarse. Current technologies primarily rely on protocol response codes to define states. This simplistic approach fails to accurately reflect the internal state characteristics of the protocol, leading to two problems: First, because the correspondence between response codes and actual states is not one-to-one, the system may incorrectly classify states with essentially the same but different response codes into different categories, resulting in unnecessary consumption of testing resources. Second, different internal states may generate the same response code; this state confusion reduces the relevance and effectiveness of testing.

[0007] The state selection algorithm has shortcomings. While existing methods propose various state evaluation metrics for state selection, they fail to fully consider the topological characteristics and functional roles of state nodes within the protocol state machine. This limitation prevents the optimal allocation of test resources based on the actual importance of nodes, thus impacting the overall efficiency of the test. Summary of the Invention

[0008] The technical problem to be solved by this invention is to provide a protocol fuzzing test method and system based on fine-grained state division and selection. By designing a two-layer state recognition mechanism and combining it with an optimized state selection strategy, the efficiency and accuracy of protocol fuzzing test are effectively improved.

[0009] This invention provides a protocol fuzzy testing method based on fine-grained state partitioning and selection, comprising the following steps:

[0010] S1: Fuzz testing preprocessing stage; deploy the protocol entity program to be tested and configure the initial seed set;

[0011] S2: Basic State Identification Phase; Receive complete feedback information from each initial seed in the initial seed set, including the final coverage edge information and the response message sequence returned by the protocol entity program under test, establish the correspondence between sent messages and response messages, extract the response code from the response message, and construct a joint state identifier by combining it with the control field of the corresponding sent message. At the same time, use the information to construct and maintain a global state transition graph; and use all initial seeds in the initial seed set as test seeds.

[0012] S3: Two-layer state subdivision stage; Select the seeds stored in each state to form the corresponding state seed set and replay the relevant message sequence to guide the server to the target state. Then send a specially constructed probe message and collect the response code and execution path feedback information generated during the test. Perform preliminary classification of seeds according to the response code, and then use the locality-sensitive hashing algorithm to analyze the path characteristics of each seed. By comparing the similarity of path increments, seeds with similar path characteristics are grouped into the same subdivision state.

[0013] S4: State evaluation and selection phase; comprehensively evaluate state nodes, systematically analyze the topology of the global state transition graph to identify erroneous state nodes and key control nodes, and conduct a comprehensive analysis by combining the in-degree characteristics, transition probabilities and improved medium-degree centrality index of the nodes.

[0014] S5: Fuzz test execution phase; Based on the evaluation results of step S4, select the target state and seed, and randomly mutate them to continuously generate new seeds; Use the mutated new seeds to execute the protocol entity program under test, and collect the coverage information and response message sequence during its execution process. Then, use the analysis mechanism established in steps S2 and S3, including state identifier extraction and path feature analysis, to characterize the state features of the new execution results.

[0015] S6: Feedback Analysis Phase; Systematically analyze the test execution results and maintain global state information.

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

[0017] S1.1: Deploy the complete files of the protocol entity program to be tested, configure the environment and dependencies required by the protocol entity program to be tested, and then compile it using the afl-gcc instrumentation compilation tool;

[0018] S1.1.1: Correctly deploy the complete file of the protocol entity program under test on the local computer environment, and configure the environment and dependencies required for its operation; use the compilation tool to pre-compile the protocol entity program under test, and identify and distinguish each basic block in the code during the compilation process; where, a basic block refers to a linear sequence of instructions in the program, which has the characteristics of a single entry point and a single exit point;

[0019] S1.1.2: The instrumentation compilation tool is used to instrument the protocol entity program under test. Monitoring code is inserted at the entry point of each basic code block, and a unique random identifier value is assigned to each basic block. When the program execution switches from one basic block to another, the random identifier values ​​of the two basic blocks are combined into the identifier of the edge. By recording and counting the identifiers of these edges, the covered code paths during the program execution can be accurately tracked, providing necessary coverage feedback for subsequent analysis. Here, "edge" and "coverage edge" specifically refer to the jump behavior of the basic blocks monitored during the runtime of the protocol entity program under test.

[0020] S1.2: Prepare the initial seed library; start the executable file of the protocol entity program under test locally, and conduct multiple rounds of normal communication with it by simulating a client locally; capture communication traffic using a network packet analysis tool during the communication process, and extract the message data sent by the client as the initial seed; start fuzz testing with at least one valid initial seed;

[0021] S1.2.1: Start a network packet analysis tool locally to continuously monitor the local network interface to capture communication traffic;

[0022] S1.2.2: Start a test protocol entity program locally as a server, and start a client program separately; simulate normal communication process according to RFC specification documents to conduct tests; during this process, network packet analysis tools capture the message sequence sent by the client, combine multiple captured messages in chronological order and divide them with a specific delimiter to form a usable initial seed;

[0023] S1.2.3: Repeat step S1.2.2 as needed to obtain initial seeds for multiple different scenarios, forming an initial seed set.

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

[0025] S2.1: Receive complete feedback information for each initial seed in step S1, including the final coverage edge information and the sequence of response messages returned by the protocol entity program under test; identify the response code for each response message and extract control field information from the corresponding sent message;

[0026] S2.2: Construct state identifiers and update state transition information; construct state identifiers jointly based on the extracted response codes and control field information, and use them to construct and maintain relevant information of the global state transition graph;

[0027] S2.3: Determine the seed persistence strategy; based on the execution effect of the current test seed, persist or delete it. For test seeds that need to be saved, add them to the persistent seed library and associate them with the seed set of all nodes on their state transition path.

[0028] Preferably, the specific steps of step S2.1 include:

[0029] S2.1.1: Establish the correspondence between sent messages and response messages; each sent message corresponds to one response message;

[0030] S2.1.2: Retrieve the response code for each response message. Execute the callback function GetCode for each response message. The GetCode function extracts and processes certain fields from any response message, ultimately hashing them into an integer variable, which is then used as the response code for that response message.

[0031] S2.1.3: Extract the control field of each sent message; execute the callback function GetControl for each message in the test seed. The callback function GetControl extracts and processes certain fields from any sent message and finally returns a character variable, which is regarded as the control field of the sent message.

[0032] Preferably, the specific steps of step S2.2 include:

[0033] S2.2.1: Construct a joint state identifier; for each group of sent messages and corresponding response messages, construct a tuple <Control_Byte, Response_code> as a state identifier, where Control_Byte is the control field of the sent message and Response_code is the response code of the response message;

[0034] S2.2.2: Define and construct a global state transition graph. The system maintains a global directed graph structure to represent the state space of the protocol entity program under test; each state node v is uniquely identified by a tuple <Control_Byte, Response_code>, where Control_Byte is the message control field that triggers the state, and Response_code is the corresponding response code; the state node also records the cumulative number of times it has been accessed and maintains a seed set that can reach the state; and node 0 represents the initial state of the protocol entity program under test.

[0035] S2.2.3: Maintain state transition relationships; perform time-series processing on the message sequences in the test seed; for each group of sent and responded messages, construct its state identifier tuple <Control_Byte, Response_code>; therefore, one test seed corresponds to several state identifier tuples <Control_Byte, Response_code>; check each state identifier tuple <Control_Byte, Response_code>, if it has not been recorded, create the corresponding state node in the global state transition graph; then the system establishes directed edges between each pair of adjacent state nodes and updates the node's access count, seed set, and transition frequency statistics.

[0036] Preferably, step S2.3 includes the following steps:

[0037] S2.3.1: Determine whether the test seed needs to be saved; check whether a new overlay edge is triggered for the first time, a new state node is discovered for the first time, or a new state transition path is generated for the first time during the execution of the test seed. When a new overlay edge is triggered for the first time, a new state node is discovered for the first time, or a new state transition path is generated for the first time, mark the test seed as a state to be saved.

[0038] S2.3.2: Perform seed persistence; for a marked test seed, add its complete content to the persistent seed library for storage; at the same time, associate the test seed with all state nodes on its state transition path to ensure that the seed set of each related node contains the test seed. Through this association mechanism, a dedicated seed set is established and maintained for each state node. Seeds in the seed set have the ability to set the state of the protocol entity program under test to the corresponding state by replaying part of the message sequence.

[0039] Preferably, step S3 includes the following steps:

[0040] S3.1: Execution state replay and probing; For state nodes that need to be subdivided, replay test their seed set; By replaying the messages in the seed until the state of the protocol entity program under test is set to the current state, calculate the currently executed overlay edge information, and then send specific probe messages to collect new execution overlay edge information, and then calculate the path increment feature and response code.

[0041] S3.1.1: Select subdivision state nodes; periodically monitor global state nodes, and when the number of unprocessed seeds in a certain state node exceeds the preset threshold of 50 seeds, mark it as a state to be subdivided;

[0042] S3.1.2: Replay Seeds: For each seed of the state to be subdivided, replay its message sequence until the protocol entity program under test is guided to the current state; record the complete coverage edge information at this time as the baseline path P_pre, and then send a specially constructed message to all seeds. At this time, obtain the current complete coverage edge information P_cur and the current response code information, and then use the baseline path P_pre and the complete coverage edge information P_cur to calculate the incremental path P_m;

[0043] S3.1.3: Calculate the path increment; analyze the difference between the baseline path P_pre and the complete coverage edge information P_cur, and calculate the incremental path P_m;

[0044] An empty bitmap array is created, and then each byte in the baseline path P_pre and the complete coverage edge information P_cur is compared one by one. When a difference is found in the i-th byte, the system sets the (i&7)-th bit of the (i>>3)-th byte in the bitmap to 1, thus obtaining the incremental path P_m.

[0045] S3.2: Perform the first-level division based on the response code; analyze the response codes of all seeds to the same special probe message, classify seeds with the same response code into the same sub-state, and thus complete the first-level state subdivision;

[0046] S3.3: Perform the second-level partitioning based on the incremental path. For the state seed set in each sub-state, perform the second-level partitioning using the locality-sensitive hashing algorithm based on the incremental path P_m calculated in S3.1.

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

[0048] S4.1: Global State Evaluation and Selection; Analyze the characteristics of each node in the global state transition graph and evaluate and score them; Before each round of fuzz testing, comprehensively score the nodes based on their topological characteristics, historical gains, and state characteristics, and select a suitable state for the next round of testing.

[0049] S4.1.1: Simple state selection; When the number of fuzz tests is less than 10,000, a simple state selection strategy is used, that is, polling and selecting each node in the current global state graph to ensure sufficient exploration of the state space of the protocol entity program under test in the early stage of fuzz testing; otherwise, proceed to step S4.1.2.

[0050] S4.1.2: Calculate the time decay benefit; For each state node, a time decay mechanism is introduced to evaluate its historical test benefits; This mechanism assigns a weight to historical findings that decreases over time, giving more recent test findings higher evaluation value. The specific calculation formula is as follows:

[0051]

[0052] Where γ is 0.95 as the time decay coefficient, n is the current test round, t is the index of the historical round, paths_discovered(v,t) represents the number of new seeds discovered by state node v in the t-th test, and selected_times(v) represents the total number of times state node v is selected for fuzz testing;

[0053] S4.1.3: Identify erroneous states; count the in-degree of each state node, calculate the number of transition edges from all other state nodes to that node, and divide it by the total number of state nodes to obtain the in-degree ratio; when the in-degree ratio of a state node exceeds 0.7, the node is judged as a potential erroneous state, and its scoring weight is reduced to 0.3 times, thereby reducing the tendency to test such states.

[0054] S4.1.4: Analyze transition probabilities; calculate the transition frequency between all state nodes, statistically analyze all possible transition targets of state node v and their corresponding transition counts, and then calculate its transition probability score; the specific calculation formula is as follows:

[0055]

[0056] Where V is the set of state nodes, and trans(i,v) represents the number of historical transitions from state node i to state node v. This represents the total number of transitions to all child state nodes that state node i can transition to;

[0057] S4.1.5: Evaluate the mediumity centrality of nodes; introduce mediumity centrality calculation to evaluate the importance of a state node in the global state transition graph. The mediumity centrality score of a node is updated every 10 rounds of state selection. Its importance is quantified by calculating the frequency of the state node's appearance in the shortest path from the initial state to other states; the specific calculation formula is as follows:

[0058]

[0059] Where σst(v) represents the number of paths from the initial state 0 to any other state that contain node v, and σst represents the total number of shortest paths from the initial state to other states, i.e. the total number of state nodes.

[0060] S4.1.6: Final Score Calculation; Taking into account the evaluation results of the aforementioned dimensions, the final score is calculated for each state node. The specific calculation formula is as follows:

[0061] Score(v)=R(v)·α(v)·(1+BC(v))+Score trans (v)

[0062] Where R(v) is the time-decayed historical gain value calculated in the previous step, the coefficient α(v) takes the value of 0.3 only when the in-degree ratio of a node exceeds 0.7, otherwise it takes the value of 1.0; BC(v) represents the improved mediumity centrality score of the node, which is used to reflect the importance of the node in the state transition; Score_trans(v) is the transition probability score of the node.

[0063] After obtaining the original scores of all nodes, normalization is performed: the sum of the scores of all nodes is calculated, and then the score of each node is divided by the sum to obtain the normalized probability distribution; based on this probability distribution, the roulette wheel selection algorithm is used to determine the target state of the next round of testing, so that the state with a higher score has a greater probability of being selected, while ensuring that the state with a lower score still has a chance to be explored.

[0064] S4.2: Specific sub-state seed selection; Check if there are any new seeds that have not yet been fuzz tested under the selected suitable state. If so, these new seeds are selected for testing first. If there are no new seeds, the system randomly selects a sub-state under the state based on a uniform probability distribution, and then randomly selects a seed from the selected sub-states as the test object. After completing the seed selection, determine the specific message for fuzz testing. Analyze the complete state transition path of the seed and determine the message sequence required to guide the protocol entity program under test to the target state. Then, select the next message at the corresponding state transition point in the sequence as the fuzz test object. Pass the selected seed and the specific message location information that needs to be fuzz tested to step S1 as input parameters for a new round of fuzz testing.

[0065] Preferably, step S5 includes the following steps:

[0066] S5.1: Enter the formal fuzz testing phase; in each round of testing, select the target state and its corresponding seed for testing based on the evaluation results of step S4.

[0067] S5.2: Generate a test seed from the currently selected seed using a mutation strategy based on a genetic algorithm;

[0068] S5.2.1: Determine the fuzzy region; Since a single seed consists of multiple messages, this stage first obtains the target seed to be tested and the specific message positions that need to be fuzz tested through the interface of step S4; In the subsequent mutation process, the specific message is mutated and the mutated message is replaced back to the original position, thereby constructing a new test seed.

[0069] S5.2.2: Enter the deterministic mutation stage; according to a preset fixed order, perform mutation operations on each byte position of the target message in sequence, including bit-by-bit flipping, byte-by-byte flipping, and byte-by-byte replacement of special values.

[0070] S5.2.3: Enter the nondeterministic mutation stage; randomly select and combine multiple mutation operators to mutate the target message. The mutation operators include random position insertion, random block deletion, and block splicing and reassembly. In each round of mutation, the combination of operators used and the mutation position are randomly determined to generate a new test message.

[0071] S5.3: Start the protocol entity program under test, send the mutated test seed for testing, collect the execution results, including program coverage data and the complete response message returned by the protocol entity program under test, and pass the feedback information to step S2 for analysis through the interface;

[0072] S5.3.1: Start the protocol entity program under test. The test seed to be sent consists of the mutated target message and other unmutated original messages in sequence. Establish a network connection with the protocol entity program under test and send the messages one by one in the order of the messages. For each message, after the message is sent, periodically check the edge coverage feedback of the protocol entity program under test. When the edge coverage information of two consecutive checks is consistent, it is determined that the message has been completely processed, and then the next message in the sequence is sent until all messages in the test seed have been sent.

[0073] S5.3.2: After all messages in the test seed have been sent and received, the system organizes the test execution results, including the final coverage edge information and the complete response message sequence, and passes this feedback information to step S2 for analysis through the interface;

[0074] S5.4: Repeat steps S5.2 to S5.3 until the preset mutation limit is reached; then return to step S5.1 to select a new state and seed for the next round of fuzz testing.

[0075] A system for protocol fuzz testing based on fine-grained state partitioning and selection includes a state partitioning module, a state evaluation module, a test execution module, and a feedback analysis module; the modules work together to achieve efficient fuzz testing of the protocol entity program under test.

[0076] The fuzz testing preprocessing module is responsible for deploying the protocol entity program to be tested.

[0077] State segmentation module: This module is responsible for implementing a two-layer state recognition mechanism, including a basic feature extraction unit and a state subdivision processing unit. The basic feature extraction unit is responsible for extracting response codes and control field information from the interaction process to construct the initial state identifier. The state subdivision processing unit works periodically to further subdivide the state through path analysis and similarity clustering.

[0078] State Evaluation Module: This module is responsible for the systematic analysis and evaluation of the global state transition graph and guides the allocation of fuzzing resources. In the initial stage of fuzzing, this module uses random polling to select state nodes, ensuring sufficient exploration of the initial state space. After accumulating enough test samples, the module switches to a heuristic evaluation mechanism. It identifies erroneous state nodes and key control nodes by analyzing the topological structure of the state transition graph, and performs a comprehensive analysis combining node in-degree characteristics, transition probabilities, and an improved degree centrality index. During the scoring process, a time decay mechanism is introduced to calculate the historical gains of nodes and combines them with node feature scores, ultimately generating a score for each state node reflecting its importance. Through this mechanism combining random exploration and heuristic evaluation, this module provides a reliable decision-making basis for the rational allocation of test resources.

[0079] Test Execution Module: This module is responsible for executing the specific fuzz testing process. Based on the target state and seed provided by the state evaluation module, this module performs mutation tests on the specified target messages. During the mutation process, new test seeds are generated by randomly combining multiple mutation operators, while keeping other messages in the test seeds unchanged. For each mutated test seed, the module starts the protocol entity program under test and sends the message sequence in order.

[0080] Feedback Analysis Module: This module is responsible for systematically analyzing the test execution results and maintaining global state information. This module collects the program execution path and response characteristics of each test, analyzes the state transition sequence, and updates the statistical data of node access frequency and transition probability in the global state transition graph.

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

[0082] 1. By employing a two-layer state recognition and dynamic evaluation mechanism, the efficiency and accuracy of protocol fuzz testing are significantly improved. In terms of state recognition, the system first constructs a basic state identifier based on a combination of response codes and control fields, and then achieves state subdivision through path feature analysis, effectively avoiding state confusion and redundancy. In terms of state evaluation, the system analyzes the topological characteristics, historical gains, and transition probabilities of nodes to enable focused testing of key control nodes.

[0083] 2. This invention achieves fully automated testing. Through the collaborative work of multiple modules, the system can automatically complete the entire process from state identification and evaluation to test execution, significantly reducing testing costs and the need for manual intervention. Simultaneously, the system employs a locality-sensitive hashing algorithm for state subdivision, quickly identifying similar paths and avoiding the performance overhead of directly calculating path similarity. This efficient automation mechanism enables the invention to maintain stable testing efficiency in low-speed network protocol fuzzy testing environments. Attached Figure Description

[0084] Figure 1 This is a schematic diagram of the overall system framework of the present invention;

[0085] Figure 2 A diagram illustrating the state subdivision method for a two-level state subdivision stage. Detailed Implementation

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

[0087] like Figure 1 As shown, the protocol fuzz testing method based on fine-grained state partitioning and selection includes the following steps:

[0088] S1: Fuzz testing preprocessing stage; deploy the protocol entity program to be tested and configure the initial seed set;

[0089] S1.1: Deploy the complete files of the protocol entity program to be tested, configure the environment and dependencies required by the protocol entity program to be tested, and then compile it using the afl-gcc instrumentation compilation tool;

[0090] S1.1.1: Correctly deploy the complete file of the protocol entity program under test on the local computer environment, and configure the environment and dependencies required for its operation; use the compilation tool to pre-compile the protocol entity program under test, and identify and distinguish each basic block in the code during the compilation process; where, a basic block refers to a linear sequence of instructions in the program, which has the characteristics of a single entry point and a single exit point;

[0091] S1.1.2: The instrumentation compilation tool is used to instrument the protocol entity program under test. Monitoring code is inserted at the entry point of each basic code block, and a unique random identifier value is assigned to each basic block. When the program execution switches from one basic block to another, the random identifier values ​​of the two basic blocks are combined into the identifier of the edge. By recording and counting the identifiers of these edges, the covered code paths during the program execution can be accurately tracked, providing necessary coverage feedback for subsequent analysis. Here, "edge" and "coverage edge" specifically refer to the jump behavior of the basic blocks monitored during the runtime of the protocol entity program under test.

[0092] S1.2: Prepare the initial seed library; start the executable file of the protocol entity program under test locally, and conduct multiple rounds of normal communication with it by simulating a client locally; capture communication traffic using a network packet analysis tool during the communication process, and extract the message data sent by the client as the initial seed; start fuzz testing with at least one valid initial seed;

[0093] S1.2.1: Start a network packet analysis tool locally to continuously monitor the local network interface to capture communication traffic;

[0094] S1.2.2: Start a test protocol entity program locally as a server, and start a client program separately; simulate normal communication process according to RFC specification documents to conduct tests; during this process, network packet analysis tools capture the message sequence sent by the client, combine multiple captured messages in chronological order and divide them with a specific delimiter to form a usable initial seed;

[0095] S1.2.3: Repeat step S1.2.2 as needed to obtain multiple initial seeds for different scenarios, forming an initial seed set. Although fuzz testing requires at least one valid seed to begin, a diverse set of initial seeds can provide broader test coverage.

[0096] S2: Basic State Identification Phase; Receive complete feedback information from each initial seed in the initial seed set, including the final coverage edge information and the response message sequence returned by the protocol entity program under test, establish the correspondence between sent messages and response messages, extract the response code from the response message, and construct a joint state identifier by combining it with the control field of the corresponding sent message. At the same time, use the information to construct and maintain a global state transition graph; and use all initial seeds in the initial seed set as test seeds.

[0097] S2.1: Receive complete feedback information for each initial seed in step S1, including the final coverage edge information and the sequence of response messages returned by the protocol entity program under test; identify the response code for each response message and extract control field information from the corresponding sent message;

[0098] S2.1.1: Establish the correspondence between sent messages and response messages; each sent message corresponds to one response message; the system adopts a one-to-one mapping method, that is, each sent message corresponds to one response message.

[0099] S2.1.2: Retrieve the response code for each response message. For each response message, execute the callback function GetCode. The GetCode function extracts and processes certain fields from any response message, ultimately hashing them into an integer variable, which is then used as the response code for that response message. For example, in RTSP protocol testing, one type of implementation might return "200 OK...." or "405 Method ERROR....". In this case, the GetCode function would extract the first integer value of the message, 200 or 405, as the response code.

[0100] S2.1.3: Extract the control field of each transmitted message; execute the callback function GetControl for each message in the seed. The callback function GetControl extracts certain fields from any transmitted message and processes them, finally returning a character variable, which is regarded as the control field of the transmitted message. Taking the RTSP protocol as an example, for a message of the form "OPTIONS rtsp: / 127.0.0.1:8554 / mystream RTSP / 1.0CSeq....", the callback function GetControl extracts the first field "OPTIONS" as the control field. In addition, to prevent state space expansion caused by mutation, the callback function GetControl must predefine a set of legal control fields. In the RTSP protocol, legal control fields include: OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN, ANNOUNCE, RECORD, REDIRECT, and SET_PARAMETER. When the system encounters a control field that is not in this set, it is uniformly marked as "Unknown", thereby avoiding unnecessary expansion of the state space.

[0101] S2.2: Construct state identifiers and update state transition information; construct state identifiers jointly based on the extracted response codes and control field information, and use them to construct and maintain relevant information of the global state transition graph;

[0102] S2.2.1: Construct a joint state identifier; for each set of sent messages and corresponding response messages, construct a tuple <Control_Byte, Response_code> as a state identifier, where Control_Byte is the control field of the sent message and Response_code is the response code of the response message; check the global state transition graph, and if there is no duplicate state identifier, create a new state node; the global state transition tree is a directed graph gradually constructed by the system during fuzz testing, and initially only the initial state node 0 represents the initial state of the protocol entity program under test;

[0103] S2.2.2: Define and construct a global state transition graph. The system maintains a global directed graph structure to represent the state space of the protocol entity program under test; each state node v is uniquely identified by a tuple <Control_Byte, Response_code>, where Control_Byte is the message control field that triggers the state, and Response_code is the corresponding response code; the state node also records the cumulative number of times it has been accessed and maintains a seed set that can reach the state; and node 0 represents the initial state of the protocol entity program under test.

[0104] S2.2.3: Maintain state transition relationships; perform time-series processing on the message sequences in the test seed; for each group of sent and responded messages, construct its state identifier tuple <Control_Byte, Response_code>; therefore, one test seed corresponds to several state identifier tuples <Control_Byte, Response_code>; check each state identifier tuple <Control_Byte, Response_code>, if it has not been recorded, create the corresponding state node in the global state transition graph; then the system establishes directed edges between each pair of adjacent state nodes and updates the node's access count, seed set, and transition frequency statistics.

[0105] For all message sequences in the seed, each group of sent and responded messages is processed in chronological order to construct a corresponding binary tuple <Control_Byte, Response_code> state identifier. The system performs the following operations on each state identifier: First, it checks and ensures that the state identifier has a corresponding node in the global state transition graph, and updates the access count of the node. Then, for each pair of consecutive state identifiers, a directed edge is established between the previous state node and the next state node, and the frequency statistics of transition to the next state node are recorded and updated in the previous state node.

[0106] Taking the RTSP protocol as an example, consider a test sequence containing four messages: First, an OPTIONS message is sent to establish a connection, receiving a response code 200; then, a SETUP message is sent to configure transmission parameters, receiving a response code 200; next, a PLAY message is sent to start playback, receiving a response code 200; finally, a mutated message "SETUPabcde" is sent, receiving an error response code 405. The system converts this sequence into a state transition path: 0-><OPTIONS,200> -><SETUP,200> -><PLAY,200> -><UnKnow,405> During this process, the system not only created corresponding state nodes, but also established directed edges reflecting state transition relationships, and recorded the number of visits to each node and the transition frequency of the edges;

[0107] S2.3: Determine the seed persistence strategy; based on the execution effect of the current test seed, persist or delete it. For test seeds that need to be saved, add them to the persistent seed library and associate them with the seed set of all nodes on their state transition path.

[0108] S2.3.1: Determine whether the seed needs to be saved; check whether a new covering edge is triggered for the first time, a new state node is discovered for the first time, or a new state transition path is generated for the first time during the seed execution process. When a new covering edge is triggered for the first time, a new state node is discovered for the first time, or a new state transition path is generated for the first time, mark the seed as a state to be saved.

[0109] S2.3.2: Perform seed persistence; for a marked seed, add its complete content to the persistent seed library for storage; at the same time, associate the seed with all state nodes on its state transition path to ensure that the seed set of each related node contains the seed. Through this association mechanism, a dedicated seed set is established and maintained for each state node. Seeds in the seed set have the ability to set the state of the protocol entity program under test to the corresponding state by replaying part of the message sequence.

[0110] like Figure 2 As shown, S3: Two-layer state subdivision stage; Select the seeds stored in each state to form the corresponding state seed set and replay the relevant message sequence to guide the server to the target state. Then send a specially constructed probe message and collect the response code and execution path feedback information generated during the test. Perform preliminary classification of seeds according to the response code, and then use the locality-sensitive hashing algorithm to analyze the path characteristics of each seed. By comparing the similarity of path increments, seeds with similar path characteristics are grouped into the same subdivision state.

[0111] The specific steps of step S3 include:

[0112] S3.1: Execution state replay and probing; For state nodes that need to be subdivided, replay test their seed set; By replaying the messages in the seed until the state of the protocol entity program under test is set to the current state, calculate the currently executed overlay edge information, and then send specific probe messages to collect new execution overlay edge information, and then calculate the path increment feature and response code.

[0113] S3.1.1: Select subdivision state nodes; periodically monitor global state nodes, and when the number of unprocessed seeds in a certain state node exceeds the preset threshold of 50 seeds, mark it as a state to be subdivided;

[0114] S3.1.2: Replay Seeds: For each seed of the state to be subdivided, replay its message sequence until the protocol entity program under test is guided to the current state; record the complete coverage edge information at this time as the base path P_pre, and then send the same specially constructed message to all seeds. At this time, obtain the current complete coverage edge information P_cur and the current response code information, and then use the base path P_pre and the complete coverage edge information P_cur to calculate the incremental path P_m; the specially constructed message is taken from the random message of the random initial seed, and the messages of the initial seed should be guaranteed to be valid as much as possible.

[0115] S3.1.3: Calculate the path increment; analyze the difference between the baseline path P_pre and the complete coverage edge information P_cur, and calculate the incremental path P_m;

[0116] An empty bitmap array is created, and then each byte in the baseline path P_pre and the complete coverage edge information P_cur is compared one by one. When a difference is found in the i-th byte, the system sets the (i&7)-th bit of the (i>>3)-th byte in the bitmap to 1, resulting in the incremental path P_m. In this way, the system encodes the path differences into a compact binary bitmap, providing a foundation for subsequent similarity analysis. The algorithm is formally described as follows:

[0117] P m [i>>3]|=(1<<(i&7)),if P cur [i]≠P pre [i]

[0118] Here, `i>>3` means shifting `i` right by 3 bits, and this operation is used to calculate the index of the target byte in the bitmap. `i&7` represents a bitwise AND operation, which is used to determine the position of the specific bitwise operation.

[0119] S3.2: First-level state subdivision based on response codes; analyzing the response codes of all seeds to the same specific probe message, seeds with the same response code are classified into the same sub-state, thus completing the first level of state subdivision; specifically, the system analyzes the response codes of all seeds to the same specific probe message, classifying seeds with the same response code into the same sub-state, thus completing the first level of state subdivision. This subdivision mechanism is based on the following principle: when two seeds are identified as the same basic state but generate different response codes to the same probe message, it indicates that these two seeds actually correspond to different internal states of the protocol entity program under test. Therefore, the system achieves preliminary subdivision of the state space through the differences in response codes.

[0120] S3.3: Perform the second-level partitioning based on the incremental path. For the state seed set in each sub-state, perform the second-level partitioning using the locality-sensitive hashing algorithm based on the incremental path P_m calculated in S3.1.

[0121] The main advantage of introducing the Locality Sensitive Hashing (LSH) algorithm is that traditional path similarity analysis requires calculating the Hamming distance for each pair of seeds, and its computational complexity increases quadratically with the number of seeds, resulting in significant performance overhead in large-scale testing scenarios. In contrast, LSH uses a voting mechanism among multiple hash buckets to map seeds of similar paths to the same bucket with a high probability, enabling the system to complete similarity clustering in linear time. Furthermore, by adjusting the number of hash buckets and the similarity threshold, the system can flexibly balance clustering accuracy and computational efficiency.

[0122] S4: State evaluation and selection phase; comprehensively evaluate state nodes, systematically analyze the topology of the global state transition graph to identify erroneous state nodes and key control nodes, and conduct a comprehensive analysis by combining the in-degree characteristics, transition probabilities and improved medium-degree centrality index of the nodes.

[0123] S4.1: Global State Evaluation and Selection; Analyze the characteristics of each node in the global state transition graph and evaluate and score them; Before each round of fuzz testing, comprehensively score the nodes based on their topological characteristics, historical gains, and state characteristics, and select a suitable state for the next round of testing.

[0124] S4.1.1: Simple state selection; When the number of fuzz tests is less than 10,000, a simple state selection strategy is used, that is, polling and selecting each node in the current global state graph to ensure sufficient exploration of the state space of the protocol entity program under test in the early stage of fuzz testing; otherwise, proceed to step S4.1.2.

[0125] S4.1.2: Calculate Time Decay Benefits; For each state node, a time decay mechanism is introduced to evaluate its historical test benefits. This mechanism assigns a decreasing weight to historical findings over time, giving more recent test findings a higher evaluation value. This design is based on the following considerations: While early findings expand the basic test space, their reference value for current decisions decreases over time; in contrast, recent findings often reflect deeper program behavior, and these new findings will become breakthroughs for further exploration. Through this dynamic weight adjustment mechanism, the system can more accurately evaluate the current value of state nodes, thereby optimizing the allocation of test resources. The specific calculation formula for assigning a decreasing weight to historical findings over time is as follows:

[0126]

[0127] Where γ is 0.95 as the time decay coefficient, n is the current test round, t is the index of the historical round, paths_discovered(v,t) represents the number of new seeds discovered by state node v in the t-th test, and selected_times(v) represents the total number of times state node v is selected for fuzz testing;

[0128] S4.1.3: Identify Error States; Count the in-degree of each state node, calculate the number of transition edges from all other state nodes to that node, and divide this number by the total number of state nodes to obtain the in-degree ratio; when the in-degree ratio of a state node exceeds 0.7, the node is identified as a potential error state, and its scoring weight is reduced to 0.3 times, thereby reducing the tendency to test such states; this determination is based on the following observation: in protocol implementations, error handling usually adopts a unified termination logic, so error states often become the convergence point of a large number of state transitions. Although these states have a high in-degree, their internal logic is relatively simple, and continued testing is unlikely to discover new program behaviors. Therefore, the system reduces its scoring weight to 0.3 times, allocating more testing resources to normal state nodes that may contain complex interaction logic.

[0129] S4.1.4: Analyze Transition Probability; The system calculates the transition frequency between all state nodes and assigns a score reward to nodes based on the rarity of their transitions. This design is based on the following principle: In mutation-based fuzzing, due to the randomness of mutation operations and the complexity of message structures, the probability of a mutated message generating an erroneous response is much higher than the probability of generating a valid message. Therefore, state paths that maintain a low transition frequency during testing are more likely to reflect correct state transition behavior. By increasing the score of state nodes corresponding to these rare paths, the system can better guide testing resources towards these valuable exploration directions. The system calculates the transition frequency between all state nodes, statistically analyzes all possible transition targets of state node v and their corresponding transition counts, and then calculates its transition probability score; the specific calculation formula is as follows:

[0130]

[0131] Where V is the set of state nodes, and trans(i,v) represents the number of historical transitions from state node i to state node v. This represents the total number of transitions to all child state nodes that state node i can transition to;

[0132] S4.1.5: Evaluate the mediumity centrality of nodes; introduce mediumity centrality calculation to evaluate the importance of a state node in the global state transition graph. The mediumity centrality score of a node is updated every 10 rounds of state selection. Its importance is quantified by calculating the frequency of the state node's appearance in the shortest path from the initial state to other states; the specific calculation formula is as follows:

[0133]

[0134] Where σst(v) represents the number of paths from the initial state 0 to any other state that contain node v, and σst represents the total number of shortest paths from the initial state to other states, i.e. the total number of state nodes.

[0135] S4.1.6: Final Score Calculation; Taking into account the evaluation results of the aforementioned dimensions, the final score is calculated for each state node. The specific calculation formula is as follows:

[0136] Score(v)=R(v)·α(v)·(1+BC(v))+Score trans (v)

[0137] Where R(v) is the time-decayed historical gain value calculated in the previous step, the coefficient α(v) takes the value of 0.3 only when the in-degree ratio of a node exceeds 0.7, otherwise it takes the value of 1.0; BC(v) represents the improved mediumity centrality score of the node, which is used to reflect the importance of the node in the state transition; Score_trans(v) is the transition probability score of the node.

[0138] After obtaining the original scores of all nodes, normalization is performed: the sum of the scores of all nodes is calculated, and then the score of each node is divided by the sum to obtain the normalized probability distribution; based on this probability distribution, the roulette wheel selection algorithm is used to determine the target state of the next round of testing, so that the state with a higher score has a greater probability of being selected, while ensuring that the state with a lower score still has a chance to be explored.

[0139] S4.2: Specific sub-state seed selection; Check if there are any new seeds that have not yet been fuzz tested under the selected suitable state. If so, these new seeds are selected for testing first. If there are no new seeds, the system randomly selects a sub-state under the state based on a uniform probability distribution, and then randomly selects a seed from the selected sub-states as the test object. After completing the seed selection, determine the specific message for fuzz testing. Analyze the complete state transition path of the seed and determine the message sequence required to guide the protocol entity program under test to the target state. Then, select the next message at the corresponding state transition point in the sequence as the fuzz test object. Pass the selected seed and the specific message location information that needs to be fuzz tested to step S1 as input parameters for a new round of fuzz testing.

[0140] S5: Fuzz test execution phase; Based on the evaluation results of step S4, select the target state and seed, and randomly mutate them to continuously generate new seeds; Use the mutated new seeds to execute the protocol entity program under test, and collect the coverage information and response message sequence during its execution process. Then, use the analysis mechanism established in steps S2 and S3, including state identifier extraction and path feature analysis, to characterize the state features of the new execution results.

[0141] S5.1: Enter the formal fuzz testing phase; in each round of testing, select the target state and its corresponding seed for testing based on the evaluation results of step S4.

[0142] S5.2: Generate a new seed from the current test seed using a mutation strategy based on a genetic algorithm;

[0143] S5.2.1: Determine the fuzzy region; Since a single seed consists of multiple messages, this stage first obtains the target seed to be tested and the specific message positions that need to be fuzz tested through the interface of step S4; In the subsequent mutation process, the specific message is mutated and the mutated message is replaced back to the original position, thereby constructing a new test seed.

[0144] S5.2.2: Enter the deterministic mutation stage; according to a preset fixed order, perform mutation operations on each byte position of the target message in sequence, including bit-by-bit flipping, byte-by-byte flipping, and byte-by-byte replacement of special values.

[0145] S5.2.3: Enter the nondeterministic mutation stage; randomly select and combine multiple mutation operators to mutate the target message. The mutation operators include random position insertion, random block deletion, and block splicing and reassembly. In each round of mutation, the combination of operators used and the mutation position are randomly determined to generate a new test message.

[0146] S5.3: Start the protocol entity program under test, send the mutated new seed for testing, collect the execution results, including program coverage data and the complete response message returned by the protocol entity program under test, and pass the feedback information to step S2 for analysis through the interface;

[0147] S5.3.1: Start the protocol entity program under test. The seed to be sent consists of the mutated target message and other unmutated original messages in sequence. Establish a network connection with the protocol entity program under test and send the messages one by one in the order of the messages. For each message, after the message is sent, periodically check the edge coverage feedback of the protocol entity program under test. When the edge coverage information of two consecutive checks is consistent, it is determined that the message has been completely processed, and then the next message in the sequence is sent until all messages in the seed have been sent.

[0148] S5.3.2: After all messages in the seed have been sent and received, the system organizes the test execution results, including the final coverage edge information and the complete response message sequence, and passes this feedback information to step S2 for analysis through the interface;

[0149] S5.4: Repeat steps S5.2 to S5.3 until the preset mutation limit is reached; then return to step S5.1 to select a new state and seed for the next round of fuzz testing.

[0150] S6: Feedback Analysis Phase; Systematically analyze the test execution results and maintain global state information.

[0151] To demonstrate the effectiveness of the method in this embodiment (referred to as SstateFuzzer in the table), a 24-hour fuzz test was conducted in the same experimental environment. The most advanced stateful fuzz testing tool, AFL-Net, was selected as the control group. The test set consisted of the widely used open-source protocols RTSP and DTLS. The same protocol entity was tested, with each experiment lasting 24 hours. To reduce the impact of randomness in fuzz testing, all experiments were repeated three times, and the results were averaged. The experimental results are shown in the table below:

[0152]

[0153] As shown in the table above, for the two widely used protocols RTSP and DTLS, this invention improves code coverage by 2.4% and 6.7% respectively compared to the benchmark tool AFL-NET, and increases the number of vulnerabilities discovered by 16% and 41% respectively, fully demonstrating the significant advantages of this mechanism in state recognition and test guidance.

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

[0155] 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 fuzzy testing method based on fine-grained state partitioning and selection, characterized in that: Includes the following steps: S1: Fuzz test preprocessing stage; Deploy the protocol entity program to be tested and configure the initial seed set; S2: Basic State Identification Phase; Receive complete feedback information from each initial seed in the initial seed set, including the final coverage edge information and the response message sequence returned by the protocol entity program under test, establish the correspondence between sent messages and response messages, extract the response code from the response message, and construct a joint state identifier in combination with the control field of the corresponding sent message. At the same time, use the joint state identifier to construct and maintain the global state transition graph; and use all initial seeds in the initial seed set as test seeds. S3: Two-layer state subdivision stage; Select the seeds stored in each state to form the corresponding state seed set and replay the relevant message sequence to guide the server to the target state. Then send probe messages and collect the response codes and execution path feedback information generated during the test. Perform preliminary classification of seeds according to the response codes, and then use the locality-sensitive hashing algorithm to analyze the path characteristics of each seed. By comparing the similarity of path increments, seeds with similar path characteristics are grouped into the same subdivision state. S4: Status Assessment and Selection Phase; A comprehensive evaluation of state nodes is conducted, and the topology of the global state transition graph is analyzed to identify erroneous state nodes and key control nodes. The analysis is then combined with the node's time decay benefit, in-degree ratio, transition probability, and intermediate degree centrality. S5: Fuzz test execution phase; Based on the evaluation results of step S4, select the target state and seed, and randomly mutate them to continuously generate new seeds; Use the mutated new seeds to execute the protocol entity program under test, and collect the coverage information and response message sequence during its execution process. Then, use the analysis mechanism established in steps S2 and S3, including state identifier extraction and path feature analysis, to characterize the state features of the new execution results. S6: Feedback Analysis Phase; Systematically analyze the test execution results and maintain global state information; The specific steps of step S4 include: S4.1: Global State Evaluation and Selection; Analyze the characteristics of each node in the global state transition graph and evaluate and score them; Before each round of fuzz testing, comprehensively score the nodes based on their time decay benefit, in-degree ratio, transition probability, and intermediate degree centrality, and select a suitable state for the next round of testing. S4.1.1: Simple state selection; When the number of fuzz tests is less than 10,000, a simple state selection strategy is used, that is, polling and selecting each node in the current global state graph to ensure sufficient exploration of the state space of the protocol entity program under test in the early stage of fuzz testing; otherwise, proceed to step S4.1.

2. S4.1.2: Calculate the time decay benefit; For each state node, a time decay mechanism is introduced to evaluate its historical test benefits; This mechanism assigns a weight to historical findings that decreases over time, giving more recent test findings higher evaluation value. The specific calculation formula is as follows: Where γ is set to 0.95 as the time decay coefficient, n is the current test round, t is the index of the historical round, and paths_discovered(v,t) represents the number of new seeds discovered by state node v in the t-th test round. selected_times(v) represents the total number of times state node v was selected for fuzz testing; S4.1.3: Identify erroneous states; Calculate the in-degree ratio of each state node, count the number of transition edges from all other state nodes to that node, and divide it by the total number of state nodes to obtain the in-degree ratio; When the in-degree ratio of a certain state node exceeds 0.7, the node is judged as a potential erroneous state, and its scoring weight is reduced to 0.3 times, thereby reducing the testing tendency for such states. S4.1.4: Analyze transition probabilities; calculate the transition frequency between all state nodes, statistically analyze all possible transition targets of state node v and their corresponding transition counts, and then calculate its transition probability score; the specific calculation formula is as follows: Where V is the set of state nodes, and trans(i,v) represents the number of historical transitions from state node i to state node v. This represents the total number of transitions to all child state nodes that state node i can transition to; S4.1.5: Evaluate the mediumity centrality of nodes; introduce mediumity centrality calculation to evaluate the importance of a state node in the global state transition graph. The mediumity centrality score of a node is updated every 10 rounds of state selection. Its importance is quantified by calculating the frequency of the state node's appearance in the shortest path from the initial state to other states; the specific calculation formula is as follows: Where, σ st (v) represents the number of shortest paths from the initial state 0 to any other state that contain node v, σ st This represents the total number of shortest paths from the initial state to other states, i.e., the total number of state nodes; S4.1.6: Final Score Calculation; Calculate the final score for each state node using the following formula: Score(v)=R(v)·α(v)·(1+BC(v))+Score trans (v) Where R(v) is the time decay gain calculated in the previous step, the coefficient α(v) takes a value of 0.3 only when the in-degree ratio of a node exceeds 0.7, otherwise it takes a value of 1.0; BC(v) represents the degree centrality score of the node, which is used to reflect the importance of the node in the state transition; Score trans (v) is the node's transition probability score; After obtaining the original scores of all nodes, normalization is performed: the sum of the scores of all nodes is calculated, and then the score of each node is divided by the sum to obtain the normalized probability distribution; based on this probability distribution, the roulette wheel selection algorithm is used to determine the target state of the next round of testing, so that the state with a higher score has a greater probability of being selected, while ensuring that the state with a lower score still has a chance to be explored. S4.2: Specific sub-state seed selection; Check if there are any new seeds that have not yet been fuzz tested under the selected suitable state. If so, prioritize these new seeds for testing. If there are no new seeds, the system randomly selects a sub-state under this state based on a uniform probability distribution, and then randomly selects a seed from the selected sub-states as the test object. After completing the seed selection, determine the specific message for fuzz testing. Analyze the complete state transition path of the seed and determine the message sequence required to guide the protocol entity program under test to the target state. Then, select the next message at the corresponding state transition point in the sequence as the fuzz test object. Pass the selected seed and the specific message location information that needs to be fuzz tested to step S5 as input parameters for a new round of fuzz testing.

2. The protocol fuzzy testing method based on fine-grained state partitioning and selection according to claim 1, characterized in that: The specific steps of step S1 include: S1.1: Deploy the complete files of the protocol entity program to be tested, configure the environment and dependencies required by the protocol entity program to be tested, and then compile it using the afl-gcc instrumentation compilation tool; S1.1.1: Correctly deploy the complete file of the protocol entity program under test on the local computer environment, and configure the environment and dependencies required for its operation; use the compilation tool to pre-compile the protocol entity program under test, and identify and distinguish each basic block in the code during the compilation process; where, a basic block refers to a linear sequence of instructions in the program, which has the characteristics of a single entry point and a single exit point; S1.1.2: The instrumentation compilation tool is used to instrument the protocol entity program under test. Monitoring code is inserted at the entry point of each basic code block, and a unique random identifier value is assigned to each basic block. When the program execution switches from one basic block to another, the random identifier values ​​of the two basic blocks are combined into the identifier of the edge. By recording and counting the identifiers of these edges, the covered code paths during the program execution can be accurately tracked, providing necessary coverage feedback for subsequent analysis. Here, "edge" and "coverage edge" specifically refer to the jump behavior of the basic blocks monitored during the runtime of the protocol entity program under test. S1.2: Prepare the initial seed library; start the executable file of the protocol entity program under test locally, and conduct multiple rounds of normal communication with it by simulating a client locally; capture communication traffic using a network packet analysis tool during the communication process, and extract the message data sent by the client as the initial seed; start fuzz testing with at least one valid initial seed; S1.2.1: Start a network packet analysis tool locally to continuously monitor the local network interface to capture communication traffic; S1.2.2: Start a test protocol entity program locally as a server, and start a client program separately; simulate the normal communication process according to the RFC specification document to conduct the test; during this process, the network packet analysis tool captures the message sequence sent by the client, combines the captured multiple messages in chronological order and separates them with a delimiter to form a usable initial seed; S1.2.3: Repeat step S1.2.2 as needed to obtain initial seeds for multiple different scenarios, forming an initial seed set.

3. The protocol fuzzy testing method based on fine-grained state partitioning and selection according to claim 2, characterized in that: The specific steps of step S2 include: S2.1: Receive complete feedback information for each initial seed in step S1, including the final coverage edge information and the sequence of response messages returned by the protocol entity program under test; identify the response code for each response message and extract control field information from the corresponding sent message; S2.2: Construct state identifiers and update state transition information; construct a joint state identifier based on the extracted response code and control field information, and use the joint state identifier to construct and maintain relevant information of the global state transition graph; S2.3: Determine the seed persistence strategy; based on the execution effect of the current test seed, persist or delete it. For test seeds that need to be saved, add them to the persistent seed library and associate them with the seed set of all nodes on their state transition path.

4. The protocol fuzzy testing method based on fine-grained state partitioning and selection according to claim 3, characterized in that: The specific steps of step S2.1 include: S2.1.1: Establish the correspondence between sent messages and response messages; each sent message corresponds to one response message; S2.1.2: Retrieve the response code of each response message; Execute the callback function GetCode for each response message. The callback function GetCode extracts certain fields from any response message and processes them, finally hashing them into an integer variable, and treating this integer variable as the response code of the response message. S2.1.3: Extract the control field of each sent message; execute the callback function GetControl for each message in the test seed. The callback function GetControl extracts and processes certain fields from any sent message and finally returns a character variable, which is regarded as the control field of the sent message.

5. The protocol fuzzy testing method based on fine-grained state partitioning and selection according to claim 4, characterized in that: The specific steps of step S2.2 include: S2.2.1: Construct a joint state identifier; for each group of sent messages and corresponding response messages, construct a tuple <Control_Byte, Response_code> as a state identifier, where Control_Byte is the control field of the sent message and Response_code is the response code of the response message; S2.2.2: Define and construct the global state transition graph; the system maintains a global directed graph structure to represent the state space of the protocol entity program under test; each state node v consists of a tuple. The <Control_Byte, Response_code> is a unique identifier, where Control_Byte is the message control field that triggers this state, and Response_code is the corresponding response code; the state node also records the cumulative number of times it has been accessed and maintains a seed set that can reach this state; and node 0 represents the initial state of the protocol entity program under test. S2.2.3: Maintain state transition relationships; perform time-series processing on the message sequences in the test seed; for each group of sent and responded messages, construct its state identifier tuple <Control_Byte, Response_code>; therefore, one test seed corresponds to several state identifier tuples <Control_Byte, Response_code>; check each state identifier tuple <Control_Byte, Response_code>, if it has not been recorded, create the corresponding state node in the global state transition graph; then the system establishes directed edges between each pair of adjacent state nodes and updates the node's access count, seed set, and transition frequency statistics.

6. The protocol fuzzy testing method based on fine-grained state partitioning and selection according to claim 5, characterized in that: The specific steps of step S2.3 include: S2.3.1: Determine whether the test seed needs to be saved; check whether a new overlay edge is triggered for the first time, a new state node is discovered for the first time, or a new state transition path is generated for the first time during the execution of the test seed. When a new overlay edge is triggered for the first time, a new state node is discovered for the first time, or a new state transition path is generated for the first time, mark the test seed as a state to be saved. S2.3.2: Perform seed persistence; for a marked test seed, add its complete content to the persistent seed library for storage; at the same time, associate the test seed with all state nodes on its state transition path to ensure that the seed set of each related node contains the test seed. Through this association mechanism, a dedicated seed set is established and maintained for each state node. Seeds in the seed set have the ability to set the state of the protocol entity program under test to the corresponding state by replaying part of the message sequence.

7. The protocol fuzzy testing method based on fine-grained state partitioning and selection according to claim 6, characterized in that: The specific steps of step S3 include: S3.1: Execution state replay and probing; For state nodes that need to be subdivided, replay test their seed set; By replaying the messages in the seed until the state of the protocol entity program under test is set to the current state, calculate the currently executed overlay edge information, and then send a probe message to collect new execution overlay edge information, and then calculate the path increment feature and response code; S3.1.1: Select subdivision state nodes; periodically monitor global state nodes, and when the number of unprocessed seeds in a certain state node exceeds the preset threshold of 50 seeds, mark it as a state to be subdivided; S3.1.2: Replay Seeds: For each seed of the state to be subdivided, replay its message sequence until the protocol entity program under test is guided to the current state; record the complete coverage edge information at this time as the baseline path P_pre, and then send the same message to all seeds. At this time, obtain the current complete coverage edge information P_cur and the current response code information, and then use the baseline path P_pre and the complete coverage edge information P_cur to calculate the incremental path P_m; S3.1.3: Calculate the path increment; analyze the difference between the baseline path P_pre and the complete coverage edge information P_cur, and calculate the incremental path P_m; An empty bitmap array is created, and then each byte in the baseline path P_pre and the complete coverage edge information P_cur is compared one by one. When a difference is found in the i-th byte, the system sets the (i&7)-th bit of the (i>>3)-th byte in the bitmap to 1, thus obtaining the incremental path P_m. S3.2: Perform the first-level division based on the response code; analyze the response codes of all seeds to the same special probe message, classify seeds with the same response code into the same sub-state, and thus complete the first-level state subdivision; S3.3: Perform the second-level partitioning based on the incremental path. For the state seed set in each sub-state, perform the second-level partitioning using the locality-sensitive hashing algorithm based on the incremental path P_m calculated in S3.

1.

8. The protocol fuzzy testing method based on fine-grained state partitioning and selection according to claim 1, characterized in that: The specific steps of step S5 include: S5.1: Enter the formal fuzz testing phase; in each round of testing, select the target state and its corresponding seed for testing based on the evaluation results of step S4. S5.2: Generate a test seed from the currently selected seed using a mutation strategy based on a genetic algorithm; S5.2.1: Determine the fuzzy region; Since a single seed consists of multiple messages, this stage first obtains the target seed to be tested and the location of the message that needs to be fuzz tested through the interface of step S4; In the subsequent mutation process, the message is mutated and the mutated message is replaced back to the original position, thereby constructing a new test seed. S5.2.2: Enter the deterministic mutation stage; according to a preset fixed order, perform mutation operations on each byte position of the target message in sequence, including bit-by-bit flipping, byte-by-byte flipping, and byte-by-byte replacement of special values. S5.2.3: Enter the nondeterministic mutation stage; randomly select and combine multiple mutation operators to mutate the target message. The mutation operators include random position insertion, random block deletion, and block splicing and reassembly. In each round of mutation, the combination of operators used and the mutation position are randomly determined to generate a new test message. S5.3: Start the protocol entity program under test, send the mutated test seed for testing, collect the execution results, including program coverage data and the complete response message returned by the protocol entity program under test, and pass the feedback information to step S2 for analysis through the interface; S5.3.1: Start the protocol entity program under test. The test seed to be sent consists of the mutated target message and other unmutated original messages in sequence. Establish a network connection with the protocol entity program under test and send the messages one by one in the order of the messages. For each message, after the message is sent, periodically check the edge coverage feedback of the protocol entity program under test. When the edge coverage information of two consecutive checks is consistent, it is determined that the message has been completely processed, and then the next message in the sequence is sent until all messages in the test seed have been sent. S5.3.2: After all messages in the test seed have been sent and received, the system organizes the test execution results, including the final coverage edge information and the complete response message sequence, and passes this feedback information to step S2 for analysis through the interface; S5.4: Repeat steps S5.2 to S5.3 until the preset mutation limit is reached; then return to step S5.1 to select a new state and seed for the next round of fuzz testing.

Images