Test drive generation method and device based on protocol message graph, equipment and medium
By constructing a protocol message graph and performing message clustering, a fuzz test driver is generated, which solves the problems of low accuracy and insufficient inductive ability of protocol test drivers in the absence of public specifications, and improves the efficiency of protocol fuzz testing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-18
- Publication Date
- 2026-03-13
AI Technical Summary
In the absence of publicly available specifications, protocol test-driven methods suffer from low accuracy in inferring message format and insufficient cross-message generalization capabilities, resulting in inefficient protocol fuzzy testing.
By introducing a protocol message graph, network traffic is analyzed to construct the protocol message graph, and message clustering is performed to generate a fuzz test driver, thereby improving the vulnerability discovery efficiency of protocol fuzz testing.
It improves the vulnerability discovery efficiency of fuzz testing for protocols without publicly available specification documents, and enhances the accuracy of message format inference and cross-message induction capabilities.
Smart Images
Figure CN121664469A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer program vulnerability detection technology, and in particular to a test driver generation method, apparatus, device, and medium based on protocol message graphs. Background Technology
[0002] In modern information systems, network protocols serve as the crucial link for interoperability between different devices, systems, and applications, carrying the core tasks of data exchange and control command transmission. From internet communication to industrial control systems (ICS), from the Internet of Things (IoT) to vehicle-to-everything (V2X), the widespread deployment of protocols has greatly promoted the development of informatization and intelligentization. However, with the continuous increase in the number and complexity of protocols, security vulnerabilities in protocol implementations have become increasingly prominent, and protocol vulnerabilities frequently become important entry points for attackers to intrude and cause damage. Therefore, how to systematically test the security and reliability of network protocol implementations has become an important research direction in the fields of network security and software engineering.
[0003] Currently, in the absence of publicly available specifications, Protocol Reverse Engineering (PRE) has been proposed to infer protocol formats, field boundaries, dependencies, and state machine models from actual communication traffic. Typical methods include clustering based on statistical features and pattern recognition based on machine learning. These methods aim to automatically infer descriptions similar to protocol specifications, thereby supporting the construction of fuzz test drivers. However, existing methods have two main limitations: low accuracy in message format inference: protocol messages often contain complex nested structures and cross-field dependencies, making accurate segmentation difficult with simple boundary detection or clustering alone. Lack of cross-message generalization ability: different types of messages often share certain fields or dependencies; without effective cross-message abstraction and template generation, the final test driver often lacks sufficient generalization ability. Therefore, how to efficiently and accurately extract protocol semantic information from network traffic and transform it into a test driver that can be directly used for fuzz testing has become a key research challenge.
[0004] Therefore, there is an urgent need for a test driver generation method based on protocol message graphs to generate fuzz test drivers that can perform vulnerability discovery on protocols. Summary of the Invention
[0005] This invention provides a test driver generation method, apparatus, device, and medium based on protocol message graphs to address the problems of low accuracy in message format inference and insufficient cross-message induction capabilities in existing protocol test drivers when there is a lack of publicly available specifications. For protocol fuzzing without publicly available specification documents, this invention introduces a protocol message graph as a guide, performs message clustering based on the protocol message graph, and obtains message groups containing protocol messages, their corresponding protocol message formats, and descriptions of their corresponding protocol message fields. Finally, a fuzzing driver is generated based on these message groups, and fuzzing of the protocol is performed using this driver, thereby improving the vulnerability discovery efficiency of protocol fuzzing without publicly available specification documents.
[0006] This invention provides a test-driven generation method based on protocol message graphs, comprising the following steps.
[0007] The protocol message is determined based on network traffic; where network traffic is the raw network tracking data stream transmitted over the network, and the protocol message is structured information composed of multiple fields with different attributes. A protocol message graph is constructed based on protocol messages; where a protocol message graph is constructed after analyzing protocol messages, based on the dependencies between specific structures and protocol fields in the protocol messages, and there is a one-to-one correspondence between protocol messages and protocol message graphs; Message clustering is performed based on the protocol message graph to obtain message groups; among them, the message group contains protocol messages, the protocol message format corresponding to the protocol messages, and the protocol message field description corresponding to the protocol messages. A fuzz test driver is generated based on the protocol message, protocol message format, and protocol message field description; the fuzz test driver is used to perform fuzz testing on the protocol, which is a document without a publicly available specification.
[0008] According to the present invention, a test-driven generation method based on protocol message graphs determines protocol messages based on network traffic, including: Obtain network traffic; Network traffic is pre-parsed according to specific communication protocol rules and formats to obtain protocol messages.
[0009] According to the present invention, a test-driven generation method based on a protocol message graph is provided, which constructs a protocol message graph based on protocol messages, including: Alignment analysis is performed on the protocol messages to obtain candidate fields; The message format is inferred from the candidate fields to obtain the protocol message graph.
[0010] According to a test-driven generation method based on protocol message graphs provided by the present invention, alignment analysis is performed on protocol messages to obtain candidate fields, including: The protocol message is converted into a byte sequence, and the similarity matrix of the byte sequences is determined; the similarity matrix is calculated based on any two byte sequences. The byte sequences are aligned based on the similarity matrix to obtain the multi-sequence alignment result; Column-level analysis is performed on the multi-sequence alignment results to obtain candidate fields.
[0011] According to a test-driven generation method based on a protocol message graph provided by the present invention, message format inference is performed on candidate fields to obtain a protocol message graph, including: Obtain the initial message graph structure; The candidate fields are parsed to obtain structured byte blocks; where the structured byte blocks represent nodes in the protocol message graph. By merging nodes in the structured byte blocks, the message graph boundary is obtained; The protocol message graph is obtained by inferring the message format based on the initial message graph structure, structured byte blocks, and message graph boundaries.
[0012] According to the present invention, a test-driven generation method based on a protocol message graph is provided, which performs message clustering based on the protocol message graph to obtain message groups, including: Traverse the protocol message graph and identify message headers; Message headers are clustered according to their message paths in the protocol message graph to obtain message groups.
[0013] According to the present invention, a test driver generation method based on protocol message graphs generates a fuzz test driver based on protocol messages, protocol message formats, and protocol message field descriptions, including: Based on the protocol message, protocol message format, and protocol message field description, format analysis and element extraction are performed to obtain the data model; A fuzz test driver is generated based on the data model, the protocol's state model, and the protocol's action model.
[0014] The present invention also provides a test driver generation device based on protocol message graph, comprising the following modules.
[0015] The protocol message determination module is used to determine the protocol message based on network traffic; where network traffic is the raw network tracking data stream transmitted over the network, and the protocol message is structured information composed of multiple fields with different attributes. The message graph construction module is used to construct protocol message graphs based on protocol messages. A protocol message graph is constructed by analyzing protocol messages and based on the dependencies between specific structures and protocol fields in the protocol messages. There is a one-to-one correspondence between protocol messages and protocol message graphs. The message group acquisition module is used to cluster messages based on the protocol message graph to obtain a message group; wherein, the message group contains protocol messages, the protocol message format corresponding to the protocol messages, and the protocol message field description corresponding to the protocol messages. The driver generation module is used to generate a fuzz test driver based on the protocol message, protocol message format, and protocol message field description; wherein, the fuzz test driver is used to perform fuzz testing on the protocol, which is a document without a publicly available specification.
[0016] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement any of the above-described test driver generation methods based on protocol message graphs.
[0017] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements any of the above-described test driver generation methods based on protocol message graphs.
[0018] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements any of the above-described test driver generation methods based on protocol message graphs.
[0019] This invention provides a test-driven generation method, apparatus, device, and medium based on protocol message graphs. The method determines protocol messages based on network traffic; where network traffic refers to raw network trace data streams transmitted over the network, and protocol messages are structured information composed of multiple fields with different attributes. A protocol message graph is constructed based on the protocol messages; where a protocol message graph is constructed after analyzing the protocol messages based on the dependencies between specific structures and protocol fields within the protocol messages, and there is a one-to-one correspondence between protocol messages and protocol message graphs. Message clustering is performed based on the protocol message graphs to obtain message groups; where each message group contains protocol messages, their corresponding protocol message formats, and their corresponding protocol message field descriptions. A fuzz test driver is generated based on the protocol messages, their protocol message formats, and their protocol message field descriptions; where the fuzz test driver is used to perform fuzz testing on the protocol, and the protocol is a document without publicly available specifications. The technical solution of this invention addresses the problems of low accuracy in message format inference and insufficient cross-message induction capabilities in existing technologies when protocol test drivers lack publicly available specifications. For protocol fuzzing without publicly available specification documents, this invention introduces a protocol message graph as a guide, performs message clustering based on the protocol message graph, and obtains message groups containing protocol messages, their corresponding protocol message formats, and descriptions of their corresponding protocol message fields. Finally, a fuzzing driver program is generated based on these message groups, and fuzzing of the protocol is performed using this driver program, thereby improving the vulnerability discovery efficiency of protocol fuzzing without publicly available specification documents. Attached Figure Description
[0020] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0021] Figure 1 This is a flowchart illustrating the test-driven generation method based on protocol message graphs provided by the present invention.
[0022] Figure 2 This is a schematic diagram of the structure of the test driver generation device based on protocol message graph provided by the present invention.
[0023] Figure 3 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation
[0024] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.
[0025] The following is combined Figure 1 The present invention describes a test driver generation method based on protocol message graphs. This method is applicable to the generation of fuzzy test drivers based on protocol message graphs. The execution subject of this method can be an electronic device or a test driver generation device based on protocol message graphs installed in the electronic device. The test driver generation device based on protocol message graphs can be implemented by software, hardware, or a combination of both. Figure 1 This is a flowchart illustrating the test-driven generation method based on protocol message graphs provided by the present invention, as shown below. Figure 1 As shown, the method includes the following steps 101, 102, 103 and 104.
[0026] Step 101: Determine the protocol message based on the network traffic; where network traffic is the raw network tracking data stream transmitted over the network, and the protocol message is structured information composed of multiple fields with different attributes.
[0027] In this step, network traffic refers to the raw network tracing data stream obtained by tracing the network transmission process during network transmission. Protocol messages are structured information composed of multiple fields with different attributes.
[0028] Specifically, during network transmission, network traffic is tracked and analyzed to obtain protocol messages.
[0029] In one specific embodiment, determining the protocol message based on network traffic includes: acquiring network traffic; and pre-parsing the network traffic according to specific communication protocol rules and a specific communication protocol rule format to obtain the protocol message.
[0030] Specifically, during network transmission, network traffic is obtained by tracking the network transmission process. Then, the network traffic is pre-parsed according to specific communication protocol rules and formats to obtain protocol messages.
[0031] Step 102: Construct a protocol message graph based on the protocol messages; where the protocol message graph refers to the graph constructed after analyzing the protocol messages, based on the dependencies between specific structures and protocol fields in the protocol messages, and there is a one-to-one correspondence between the protocol messages and the protocol message graph.
[0032] In this step, the protocol message graph is a graph drawn by analyzing the protocol messages and based on the specific structure of the protocol and the dependencies between protocol fields. The structure, field order, and dependencies between fields are unique for each protocol; therefore, each protocol has a corresponding unique protocol message graph. Nodes in the protocol message graph typically represent fields or data units of the message, while edges represent dependencies or logical relationships between fields. Dependencies between fields can usually be obtained using a message graph model. This model is a pre-trained model, and in fuzzing or other security tests, the dependencies between adjacent fields can be used to construct reasonable input patterns to help discover vulnerabilities. For example, certain combinations of fields may trigger errors or vulnerabilities in protocol processing; this embodiment does not limit this.
[0033] Specifically, after obtaining the protocol message, alignment analysis is performed on the protocol message to parse the structural information in the protocol message, a message graph model is generated based on the structural message, and the protocol format is derived by analyzing the structure, field order and the relationship between fields. Based on the protocol format and the message graph model, a protocol message graph is constructed.
[0034] In one specific embodiment, constructing a protocol message graph based on protocol messages includes: performing alignment analysis on the protocol messages to obtain candidate fields; and performing message format inference on the candidate fields to obtain the protocol message graph.
[0035] In this step, the alignment analysis processing can be, for example, multi-sequence alignment processing with an enhancement strategy. Multi-sequence alignment processing with an enhancement strategy can automatically identify protocol messages in the case of unknown protocol scenarios, identify the specific structure of the protocol message, the dependencies between protocol fields, and the field attributes of the protocol fields, etc. This embodiment does not limit this.
[0036] Specifically, after obtaining the protocol message, it is often composed of multiple fields with different attributes, such as static fields, dynamic fields, or variable-length fields. Accurately identifying these field attributes is crucial for building an accurate data model. To achieve this, alignment analysis can be performed on the protocol message to reveal common sequence patterns among different samples, thereby detecting variable or length-related fields.
[0037] The advantage of this setup is that it improves the accuracy of protocol message identification by aligning protocol messages through multi-sequence alignment analysis with enhanced strategies. This addresses the problem that existing methods rely on pairwise alignment algorithms, which have significant limitations. When local changes occur, the lack of global structural constraints may lead to misalignment, thereby reducing the accuracy of field identification.
[0038] In one specific embodiment, alignment analysis is performed on the protocol message to obtain candidate fields, including: converting the protocol message into a byte sequence and determining the similarity matrix of the byte sequence; wherein the similarity matrix is calculated based on any two byte sequences; aligning the byte sequences according to the similarity matrix to obtain a multi-sequence alignment result; and performing column-level analysis on the multi-sequence alignment result to obtain candidate fields.
[0039] In this step, the alignment analysis of multiple sequences with enhancement strategies specifically employs multiple sequence alignment (MSA) technology. MSA is an extension of two-sequence alignment in bioinformatics, capable of aligning all sequences at once and automatically identifying the message structure and candidate field attributes of protocol messages. Furthermore, to reduce the computational complexity of MSA and improve alignment accuracy, progressive methods and iterative optimizations are employed; however, this embodiment does not limit these methods.
[0040] Specifically, all protocol messages are converted into byte sequences, and pairwise similarity matrices are calculated for each sequence to obtain a similarity matrix. Then, for all similarity matrices, a progressive alignment process is used, prioritizing the comparison of the most similar messages and gradually adding other sequences to align the byte sequences, thus constructing a multi-sequence alignment result. Finally, an iterative optimization strategy is used to perform column-level analysis on the multi-sequence alignment result to obtain candidate fields.
[0041] The advantage of this setup is that by performing column-level analysis, the stability of candidate fields can be evaluated, thereby improving the accuracy of structural identification of protocol messages.
[0042] In one specific embodiment, to facilitate the subsequent construction of an efficient and generalizable data model, after identifying the message structure of the protocol messages, column-level analysis is further performed on the multi-sequence alignment results. Specifically, statistical features of each column are extracted from the alignment matrix of the multi-sequence alignment results, such as structural attributes like byte stability, offset position, field length, and range of variation. Based on structural attributes such as byte stability, offset position, field length, and range of variation, candidate fields are divided into three categories: fixed fields (F), representing parts that remain unchanged in all messages; dynamic fields (D), representing parts with different values but fixed lengths; and variable-length fields (V), used to represent fields whose length changes with the message. Through this structured abstraction and annotation process, a good data model can be automatically generated subsequently.
[0043] In one specific embodiment, message format inference is performed on candidate fields to obtain a protocol message graph, including: obtaining an initial message graph structure; parsing the message structure of candidate fields to obtain structured byte blocks; wherein, the structured byte blocks represent nodes in the protocol message graph; merging nodes in the structured byte blocks to obtain message graph boundaries; and inferring message format based on the initial message graph structure, structured byte blocks, and message graph boundaries to obtain the protocol message graph.
[0044] In this step, the message graph structure is initialized as a pre-built directed graph structure that has not been filled with candidate fields after parsing according to the protocol message. This embodiment does not limit this.
[0045] Specifically, a pre-initialized message graph structure is obtained. After obtaining candidate fields, message structure parsing is performed on the candidate fields to obtain multiple structured byte blocks. These structured byte blocks are treated as nodes in the protocol message graph. Subsequently, a directed edge is established between every two consecutive structured byte blocks, which serves as the message graph boundary, thus constructing a complete protocol message graph. The protocol message graph records each node and the message graph boundary, containing relevant information about the protocol message for inferring the data packet format. Then, based on heuristic rules, the initial fine-grained nodes in the nodes are progressively aggregated into candidate field units, and the complete message format is inferred.
[0046] The advantage of this setup is that it allows for the inference of message format, thereby improving the stability and accuracy of protocol understanding.
[0047] For example, when obtaining nodes in the protocol message graph, the main process involves mapping the message structure in the candidate fields to the protocol message graph. This process transforms each structured byte block in the candidate fields after protocol message analysis into a node in the protocol message graph. These nodes are connected by message graph boundaries, the direction of which reflects the sequential relationship between structured byte blocks. Each message graph boundary is assigned a weight, the value of which represents the number of times the byte sequence appears. Specifically, first, an empty initial message graph structure is created, a root node is defined and added to the graph as the starting point for all messages. Simultaneously, some empty dictionaries are initialized to store information related to the structured byte blocks after protocol message parsing. Each message structure is traversed and parsed into a sequence of structured byte blocks, and the list of parsed structured byte blocks is saved in the dictionary `parsed_messages`, where `idx` is the index of the protocol message. Then, each structured byte block is traversed and added to the initial message graph structure, where the index of the structured byte block, i.e., the byte position `pos`, starts from 1, and the position of the structured byte block is used as the node label `Byte{pos}:{byte}`. Simultaneously, a message graph boundary is created from the previous byte block node to the current byte block node and added to the initialized message graph structure. If the message graph boundary does not yet exist in `edge_weights`, its weight is initialized to 0; otherwise, the weight of the message graph boundary is increased each time it appears. The current node is updated to be the previous node of the next byte. This process is iterated until the last structured byte block of the message, and the number of nodes at each position and the number of message graph boundaries between positions are recorded as the weight information of the message graph boundaries. Finally, the protocol message graph and related information such as message format are output.
[0048] In one specific embodiment, after obtaining the protocol message graph, the field boundaries are further automatically inferred, similar nodes are merged, and the message format is determined. Specifically, this is achieved by analyzing the topological continuity and structural consistency of the protocol message graph and applying heuristic rules to groups of nodes with similar structures or behavioral patterns.
[0049] For example, suppose the protocol message graph G=(V, E), where V represents the set of nodes and E represents the set of message graph boundaries, where each i-th node position represents a node... {V} represents a message fragment. Let $e{ij}$ represent the node at position $i$. Each message graph boundary $e{ij}$ represents the adjacency relationship between fields at positions $i$ and $j$, and is associated with a weight $omega(e{ij})$ to represent the weight information of the message graph boundary. The merging function is defined as follows: (1)
[0050] In formula (1), Indicates the positions of two consecutive nodes and They can be combined. In formula (1), under other circumstances, The value is 0, in the case that the conditions are met. It is 1, that is, if and only if Under the condition that the following formula (2) is satisfied, It is 1; otherwise, If the value is 0, the node does not meet the conditions for merging.
[0051] In formula (2), during the node merging process, whether to merge two adjacent nodes... and It depends on their topological relationship and edge weight characteristics in the protocol message graph G=(V,E). The three heuristic constraints are shown in Equation (2): If the nodes at positions i are... out-degree If the value of 1 indicates that the node is connected to only one successor node and there are no branches in the structure, the merging process ensures that it follows a single link, thus avoiding erroneous crossings of branch nodes or multi-path regions. If the nodes at position j are... in-degree A value of 1 indicates that it is pointed to by only a single predecessor node and is not shared by multiple paths. This constraint ensures that the merging result does not disrupt the structural consistency of the message graph and avoids incorrect aggregation of fields from different paths. If adjacent edges and The weights are equal. Different node positions indicate that they share similar co-occurrence patterns or structural stability across multiple message samples. This condition ensures that merged nodes belong to the same structural unit or field fragment, rather than different semantic regions. Two nodes can be considered to belong to the same candidate field only if they simultaneously satisfy all three heuristic constraints. Finally, a structured representation of each data packet is constructed using the merged nodes. The generated format dictionary captures the detailed structure, with each candidate field defined by its start and end positions, value, and descriptive comments, thus providing a comprehensive and accurate message format.
[0052] Step 103: Cluster messages based on the protocol message graph to obtain message groups; among them, the message groups contain protocol messages, the protocol message formats corresponding to the protocol messages, and the protocol message field descriptions corresponding to the protocol messages.
[0053] Specifically, after obtaining the protocol message graph, the message headers in the protocol message graph are identified based on the message graph paths in the protocol message graph to obtain message groups. The identified message header structural features are then clustered to facilitate the identification of message types, thereby automatically constructing a representative data model.
[0054] In one specific embodiment, message clustering based on the protocol message graph to obtain message groups includes: traversing the protocol message graph and identifying message headers; and clustering message headers according to their message paths in the protocol message graph to obtain message groups.
[0055] Specifically, for message header identification, it is assumed that the nodes of the message graph G(V,G) are... and Weight of edges For weight information Perform normalization. Simultaneously calculate... The set of sparse distributions of each set of edges corresponding to a node. Further, the influence, i.e., concentration, of the candidate fields is obtained as shown in formula (3).
[0056] In formula (3), Indicates the influence of candidate fields. This represents the sparse distribution corresponding to the boundary s of the message graph. This represents the set of message graph boundaries. If the weight distribution of a message graph boundary is highly concentrated, then... A value close to 1 indicates strong structural saliency in the protocol message graph; otherwise, it indicates significant variability in the domain. Furthermore, the Jensen-Shannon divergence is used to measure the degree of abrupt change between adjacent distributions, thereby enabling the detection of potential delimiters marking boundaries in the message header, as shown in Equation (4).
[0057] In formula (4), Indicates a potential delimiter. express The set of sparse distributions of each set of edges corresponding to a node, and finally, through contributions to the structure. and mutations Weighted fusion is performed to determine candidate nodes for the boundary, which will be further used to correct alignment deviations in the messages as shown in Equation (5).
[0058] (5) In formula (5), Indicates alignment deviation. Indicates the structural contribution weight. Indicates the contribution weight of mutations. This indicates the offset between the candidate header node and the message length.
[0059] In a specific implementation, for path-sensitive clustering, firstly, the node set is obtained as {(i, S_{i})|i=1,...,l} based on the message graph G(V,E), where i represents the node position, for example, it can be the pos index, such as 'Pos2:01' representing node position 2, where the position field takes the value '01'. For each node position in the protocol message graph, a unique code is assigned based on the sorted value sequence. Assume that each protocol message m is represented by the field sequence m=[f1,f2,...,fl], and f_{i} belongs to S_{i}. For each field f_{i} in the message, its code c_{i} is found, and the path is output as =[c_{1},c_{2},...,c_{l}]. Considering that the information identifying the message type is contained in the message header, and the header structure features are stable, but the data payload varies greatly, it will affect the clustering results. Therefore, message clustering analysis is performed on the message header based on the message path. Considering the unknown number of specialized message types in practical applications, density-based clustering DBSCAN is used to divide messages into multiple type groups based on candidate message headers identified in the message header. Each group shares a similar header path. Finally, for each message group, the original message and its corresponding format sequence are returned, thereby supporting intra-message group analysis to generate a data model. This embodiment does not impose limitations on this process.
[0060] For example, message clustering is a key step in generating high-quality data models. By classifying the header structure features of identified message headers, different message types can be accurately distinguished. Existing traditional clustering methods often rely on keyword matching or sequence similarity for type classification. When protocol messages lack explicit keywords or fields have strong variability, these methods are prone to failure, leading to chaotic type classification and limiting the accurate construction and expansion of data models. To address existing problems, it has been observed in protocol message graphs that messages with similar or identical types tend to display comparable path structures. Therefore, message clustering based on protocol message graphs can fully utilize the header structure features of message headers to improve the ability to identify message types in protocol messages. First, based on the difference in parallel edge weight distribution between consecutive field nodes in the protocol message graph, an edge weight mutation detection model is proposed to identify message headers. Based on this, DBSCAN is used to cluster messages according to the path of the message header in the message graph for automatic data model generation. This embodiment does not limit the scope of this method.
[0061] Step 104: Generate a fuzz test driver based on the protocol message, protocol message format, and protocol message field description; wherein, the fuzz test driver is used to perform fuzz testing on the protocol, which is a document without a publicly available specification.
[0062] Specifically, based on the obtained message groups, the payload structure of each message group is further analyzed, including the protocol messages, protocol message formats, and protocol message field descriptions. This allows for the refinement of the data model based on the payload structure, thereby generating a fuzz test driver program.
[0063] In one specific embodiment, generating a fuzz test driver based on protocol messages, protocol message formats, and protocol message field descriptions includes: performing format analysis and element extraction based on protocol messages, protocol message formats, and protocol message field descriptions to obtain a data model; and generating a fuzz test driver based on the data model, the protocol's state model, and the protocol's action model.
[0064] Specifically, the data model is obtained by performing format analysis and element extraction based on the protocol message, protocol message format, and protocol message field description; and a fuzz test driver is generated based on the data model, the protocol state model, and the protocol action model.
[0065] For example, after obtaining the message group, all message formats within the group are marked, and the differences are identified. If format differences exist, multi-template extraction (i.e., element extraction) is performed to obtain a data model. If there is only one format, only one data model template needs to be extracted; if there are multiple different formats, multiple data models are extracted. After obtaining the data model, it is converted to XML to obtain an XML file. A state model for each stage of the predefined protocol is defined, along with an action model for each state. Finally, a fuzz test driver program is generated based on the XML file derived from the data model, the state model, and the action model. This embodiment does not limit the scope of the implementation.
[0066] This invention provides a test-driven generation method based on protocol message graphs. The method determines protocol messages based on network traffic; where network traffic refers to the raw network trace data stream transmitted over the network, and the protocol message is structured information composed of multiple fields with different attributes. A protocol message graph is constructed based on the protocol messages; where the protocol message graph is constructed after analyzing the protocol messages, based on the dependencies between specific structures and protocol fields within the protocol messages, and there is a one-to-one correspondence between protocol messages and protocol message graphs. Message clustering is performed based on the protocol message graph to obtain message groups; where each message group contains a protocol message, its corresponding protocol message format, and its corresponding protocol message field description. A fuzz test driver is generated based on the protocol messages, protocol message formats, and protocol message field descriptions; where the fuzz test driver is used to perform fuzz testing on the protocol, and the protocol is a document without publicly available specifications. The technical solution of this invention addresses the problems of low accuracy in message format inference and insufficient cross-message induction capabilities in existing technologies when protocol test drivers lack publicly available specifications. For protocol fuzzing without publicly available specification documents, this invention introduces a protocol message graph as a guide, performs message clustering based on the protocol message graph, and obtains message groups containing protocol messages, their corresponding protocol message formats, and descriptions of their corresponding protocol message fields. Finally, a fuzzing driver program is generated based on these message groups, and fuzzing of the protocol is performed using this driver program, thereby improving the vulnerability discovery efficiency of protocol fuzzing without publicly available specification documents.
[0067] The test driver generation apparatus based on protocol message graphs provided by the present invention will be described below. The test driver generation apparatus based on protocol message graphs described below can be referred to in correspondence with the test driver generation method based on protocol message graphs described above.
[0068] Figure 2 This is a schematic diagram of the test driver generation device based on protocol message graph provided by the present invention, with reference to... Figure 2 As shown, the test driver generation device 200 based on protocol message graphs includes: a protocol message determination module 201, a message graph construction module 202, a message group acquisition module 203, and a driver generation module 204; wherein, The protocol message determination module 201 is used to determine the protocol message based on the network traffic; wherein, the network traffic is the raw network tracking data stream transmitted on the network, and the protocol message is structured information composed of multiple fields with different attributes; The message graph construction module 202 is used to construct a protocol message graph based on protocol messages; wherein, the protocol message graph refers to the graph constructed after analyzing the protocol messages, based on the dependency relationship between specific structures and protocol fields in the protocol messages, and there is a one-to-one correspondence between the protocol messages and the protocol message graph; The message group acquisition module 203 is used to perform message clustering based on the protocol message graph to obtain a message group; wherein, the message group contains protocol messages, the protocol message format corresponding to the protocol messages, and the protocol message field description corresponding to the protocol messages. The driver generation module 204 is used to generate a fuzz test driver based on the protocol message, the protocol message format, and the protocol message field description; wherein, the fuzz test driver is used to perform fuzz testing on the protocol, which is a document without a publicly available specification.
[0069] In one example embodiment, the protocol message determination module 201 is specifically used to: acquire network traffic; pre-parse the network traffic according to specific communication protocol rules and specific communication protocol rule formats to obtain protocol messages.
[0070] In one example embodiment, the message graph construction module 202 is specifically used to: construct a protocol message graph based on protocol messages, including: performing alignment analysis on the protocol messages to obtain candidate fields; and performing message format inference on the candidate fields to obtain the protocol message graph.
[0071] In one example embodiment, the message graph construction module 202 performs alignment analysis on the protocol message to obtain candidate fields. Specifically, it is used to: convert the protocol message into a byte sequence and determine the similarity matrix of the byte sequence; wherein the similarity matrix is calculated based on any two byte sequences; align the byte sequences according to the similarity matrix to obtain a multi-sequence alignment result; and perform column-level analysis on the multi-sequence alignment result to obtain candidate fields.
[0072] In one example embodiment, the message graph construction module 202 performs message format inference on candidate fields to obtain a protocol message graph. Specifically, it is used to: obtain an initial message graph structure; parse the message structure of candidate fields to obtain structured byte blocks; wherein the structured byte blocks represent nodes in the protocol message graph; merge nodes in the structured byte blocks to obtain the message graph boundary; and perform message format inference based on the initial message graph structure, structured byte blocks, and message graph boundary to obtain the protocol message graph.
[0073] In one example embodiment, the message group obtaining module 203 is specifically used to: traverse the protocol message graph and identify message headers; and cluster message headers according to their message paths in the protocol message graph to obtain message groups.
[0074] In one example embodiment, the driver generation module 204 is specifically used to: perform format analysis and element extraction based on the protocol message, protocol message format, and protocol message field description to obtain a data model; and generate a fuzz test driver based on the data model, the protocol state model, and the protocol action model.
[0075] The apparatus of this embodiment can be used to execute the method of any embodiment in the side embodiment of the test-driven generation method based on protocol message graph. Its specific implementation process and technical effects are similar to those in the side embodiment of the test-driven generation method based on protocol message graph. For details, please refer to the detailed description in the side embodiment of the test-driven generation method based on protocol message graph, which will not be repeated here.
[0076] Figure 3 This is a schematic diagram of the structure of the electronic device provided by the present invention, such as... Figure 3 As shown, the electronic device may include: a processor 310, a communications interface 320, a memory 330, and a communications bus 340, wherein the processor 310, the communications interface 320, and the memory 330 communicate with each other through the communications bus 340. The processor 310 can call logical instructions in the memory 330 to execute a test driver generation method based on a protocol message graph. This method includes: determining protocol messages based on network traffic; wherein the network traffic is the raw network trace data stream transmitted over the network, and the protocol message is structured information composed of multiple fields with different attributes; constructing a protocol message graph based on the protocol messages; wherein the protocol message graph is constructed after analyzing the protocol messages based on the dependencies between specific structures and protocol fields in the protocol messages, and there is a one-to-one correspondence between the protocol messages and the protocol message graph; performing message clustering based on the protocol message graph to obtain message groups; wherein the message groups contain protocol messages, the corresponding protocol message formats, and the corresponding protocol message field descriptions; and generating a fuzz test driver based on the protocol messages, protocol message formats, and protocol message field descriptions; wherein the fuzz test driver is used to perform fuzz testing on the protocol, and the protocol is a document without publicly available specifications.
[0077] Furthermore, the logical instructions in the aforementioned memory 330 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0078] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the test driver generation method based on the protocol message graph provided by the above methods. The method includes: determining protocol messages based on network traffic; wherein, network traffic is the raw network tracking data stream transmitted on the network, and the protocol message is structured information composed of multiple fields with different attributes; constructing a protocol message graph based on the protocol messages; wherein, the protocol message graph is constructed after analyzing the protocol messages based on the dependencies of specific structures and protocol fields in the protocol messages, and there is a one-to-one correspondence between the protocol messages and the protocol message graph; performing message clustering based on the protocol message graph to obtain message groups; wherein, the message group contains protocol messages, protocol message formats corresponding to the protocol messages, and protocol message field descriptions corresponding to the protocol messages; generating a fuzz test driver based on the protocol messages, protocol message formats, and protocol message field descriptions; wherein, the fuzz test driver is used to perform fuzz testing on the protocol, and the protocol is a document without publicly available specifications.
[0079] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the test driver generation method based on the protocol message graph provided by the above methods. This method includes: determining protocol messages based on network traffic; wherein the network traffic is the raw network trace data stream transmitted over the network, and the protocol message is structured information composed of multiple fields with different attributes; constructing a protocol message graph based on the protocol messages; wherein the protocol message graph is constructed after analyzing the protocol messages based on the dependencies between specific structures and protocol fields in the protocol messages, and there is a one-to-one correspondence between the protocol messages and the protocol message graph; performing message clustering based on the protocol message graph to obtain message groups; wherein the message groups contain protocol messages, protocol message formats corresponding to the protocol messages, and protocol message field descriptions corresponding to the protocol messages; generating a fuzz test driver based on the protocol messages, protocol message formats, and protocol message field descriptions; wherein the fuzz test driver is used to perform fuzz testing on the protocol, and the protocol is a document without publicly available specifications.
[0080] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.
[0081] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.
[0082] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.
Claims
1. A test-driven generation method based on protocol message graphs, characterized in that, include: The protocol message is determined based on network traffic; wherein the network traffic is the raw network tracking data stream transmitted over the network, and the protocol message is structured information composed of multiple fields with different attributes. A protocol message graph is constructed based on the protocol messages; wherein, the protocol message graph is constructed after analyzing the protocol messages, based on the dependencies of specific structures and protocol fields in the protocol messages, and there is a one-to-one correspondence between the protocol messages and the protocol message graph; Based on the protocol message graph, message clustering is performed to obtain message groups; wherein, the message group contains the protocol message, the protocol message format corresponding to the protocol message, and the protocol message field description corresponding to the protocol message; A fuzz test driver is generated based on the protocol message, the protocol message format, and the protocol message field description; wherein, the fuzz test driver is used to perform fuzz testing on the protocol, which is a document without publicly available specifications.
2. The test-driven generation method based on protocol message graphs according to claim 1, characterized in that, The method of determining protocol messages based on network traffic includes: Obtain the network traffic; The network traffic is pre-parsed according to specific communication protocol rules and specific communication protocol rule formats to obtain the protocol message.
3. The test-driven generation method based on protocol message graphs according to claim 1, characterized in that, The construction of the protocol message graph based on the protocol messages includes: The protocol messages are subjected to alignment analysis to obtain candidate fields; The message format is inferred from the candidate fields to obtain the protocol message graph.
4. The test-driven generation method based on protocol message graphs according to claim 3, characterized in that, The alignment analysis of the protocol message yields candidate fields, including: The protocol message is converted into a byte sequence, and a similarity matrix of the byte sequences is determined; wherein, the similarity matrix is calculated based on any two of the byte sequences; The byte sequences are aligned according to the similarity matrix to obtain multi-sequence alignment results; The candidate fields are obtained by performing column-level analysis on the multi-sequence alignment results.
5. The test-driven generation method based on protocol message graphs according to claim 3, characterized in that, The step of inferring the message format of the candidate fields to obtain the protocol message graph includes: Obtain the initial message graph structure; The candidate fields are parsed to obtain structured byte blocks; wherein the structured byte blocks represent nodes in the protocol message graph. The structured byte blocks are merged to obtain the message graph boundary; The protocol message graph is obtained by inferring the message format based on the initialization message graph structure, the structured byte blocks, and the message graph boundaries.
6. The test-driven generation method based on protocol message graphs according to any one of claims 1-5, characterized in that, The message clustering based on the protocol message graph to obtain message groups includes: Traverse the protocol message graph and identify message headers; The message headers are clustered according to the message paths in the protocol message graph to obtain the message groups.
7. The test-driven generation method based on protocol message graphs according to claim 6, characterized in that, The process of generating a fuzz test driver based on the protocol message, the protocol message format, and the protocol message field description includes: Based on the protocol message, the protocol message format, and the protocol message field description, format analysis and element extraction are performed to obtain a data model; The fuzz test driver is generated based on the data model, the state model of the protocol, and the action model of the protocol.
8. A test-driven generation device based on protocol message graphs, characterized in that, include: The protocol message determination module is used to determine the protocol message based on network traffic; wherein, the network traffic is the raw network tracking data stream transmitted on the network, and the protocol message is structured information composed of multiple fields with different attributes; The message graph construction module is used to construct a protocol message graph based on the protocol message; wherein, the protocol message graph is constructed by analyzing the protocol message and based on the dependency relationship between specific structures and protocol fields in the protocol message, and the protocol message and the protocol message graph have a one-to-one correspondence. The message group acquisition module is used to perform message clustering based on the protocol message graph to obtain a message group; wherein the message group contains the protocol message, the protocol message format corresponding to the protocol message, and the protocol message field description corresponding to the protocol message; A driver generation module is used to generate a fuzz test driver based on the protocol message, the protocol message format, and the protocol message field description; wherein the fuzz test driver is used to perform fuzz testing on the protocol, and the protocol is a document without publicly available specifications.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the test driver generation method based on the protocol message graph as described in any one of claims 1 to 7.
10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the test-driven generation method based on the protocol message graph as described in any one of claims 1 to 7.