Network protocol fuzzy test method and system based on protocol process state machine

Abstract

The invention relates to the technical field of network protocol testing, in particular to a network protocol fuzzy testing method and system based on a protocol process state machine, and the method comprises the steps: carrying out the static analysis of a network protocol source code, and recognizing a state variable in the source code; according to the method, the change of a network protocol state variable is tracked and detected by performing instrumentation on the state variable, a process state in a network protocol is obtained, a protocol process state machine for mapping a protocol state space and a code space is constructed according to the process state, and a network protocol key state is selected and a targeted test is performed. According to the method, the additional process state is obtained by using the state variable identified in the source code, the mapping between the state space and the code space is established to construct the protocol process state machine, and the weight is distributed for each state to realize the fuzzy test of the key state, so that the method has a better application prospect in the field of network protocol test.

Description

Technical Field

[0001] The present invention relates to the technical field of network protocol testing, and in particular to a network protocol fuzzy testing method and system based on a protocol process state machine. Background Art

[0002] Network protocols are an important part of network communication systems, supporting the interaction and communication between different entities in the network. Their security deserves more attention and research. Vulnerability discovery is an important method for detecting software security issues. The technical development of network protocol program vulnerability discovery has gone through many stages, from classic black-box fuzz testing to feedback-based gray-box fuzz testing, and then to hybrid testing technology combined with program analysis. Fuzz testing is widely used in modern vulnerability discovery work with its high efficiency and low false positive rate, and has achieved remarkable results in the field of software security. Fuzz testing involves introducing random input data into the target program and monitoring anomalies (such as crashes and assertion failures) to identify potential security vulnerabilities, including memory leaks. The earliest popular black-box fuzz testing tools for network protocols are Peach and Boofuzz, which require the specification of network protocol message formats and the design of test case generation strategies. With the development of intelligent feedback fuzz testing, some gray-box fuzz testing tools, such as AFL, have received more attention. For protocol fuzz testing, the main approach is to modify AFL to adapt to the interactive characteristics of network protocols and study general instrumentation technology to adapt to AFL. The typical tool is AFLNet.

[0003] However, most of the existing gray-box fuzz testing tools still have deficiencies in protocol state expression schemes. AFLNet uses response codes in response messages to represent service states, but this approach cannot produce completely reliable states. StateAFL uses memory information to represent the service state of a program, but directly mapping complex memory states to service states can cause problems. NSFuzz proposes a lightweight state representation scheme, but it does not link the state space to the code space. Although some existing tools have regarded protocol states as important information, they lack the organic integration of coverage-oriented strategies to jointly guide fuzz testing, and remain relatively independent without relevant analysis, cannot accurately represent the protocol state table, and cannot effectively test critical states. Summary of the invention

[0004] To this end, the present invention provides a network protocol fuzz testing method and system based on a protocol process state machine to solve the problems of inaccurate state representation and inability to test key states in current fuzz testing. The state variables identified in the source code are used to obtain additional process states, and a mapping between the state space and the code space is established to construct a protocol process state machine. A weight is assigned to each state to achieve fuzz testing of key states.

[0005] According to the design scheme provided by the present invention, on the one hand, a network protocol fuzz testing method based on a protocol process state machine is provided, comprising:

[0006] Performing static analysis on the network protocol source code and identifying state variables in the source code, wherein the state variables are program variables that characterize the state of the network protocol;

[0007] Track and detect changes in network protocol state variables by inserting state variables, obtain process states in the network protocol, and construct a protocol process state machine for mapping protocol state space and code space based on the process states, wherein the process states are code state transitions based on changes in state variables;

[0008] Select the key status of the network protocol according to the protocol status weight, and conduct targeted tests on the key status of the network protocol.

[0009] As a network protocol fuzzy testing method based on a protocol process state machine of the present invention, further, a static analysis is performed on the network protocol source code, and state variables in the source code are identified, including:

[0010] Perform static analysis on the source code and obtain the event processing loop using the call stack backtrace information when reading messages from the protocol source code;

[0011] The state variables in the source code are identified and annotated, and a unique string identifier is assigned to each state variable, which is output in the form of a state list. The state variables include: event processing loop program variables, program variables read / written in message processing functions, enumeration / integer global variables written by constants, and member variables in structures.

[0012] As a network protocol fuzz testing method based on a protocol process state machine of the present invention, further, the call stack backtracking information when the protocol source code is used to read the message is used to obtain the event processing loop, including:

[0013] Set a breakpoint at the program input class system call;

[0014] In the network protocol service processing stage, if a breakpoint is triggered, the current protocol program function call stack information is used as auxiliary information to identify the event processing loop; and all loop structures containing I / O operations are collected, and a mapping relationship is established through the functions to which the loop structures belong;

[0015] Based on the stack backtrace information, all functions are matched layer by layer in the mapping relationship from the bottom function of the function call stack, and the loop structure contained in the first matched function is used as the event processing loop.

[0016] As a network protocol fuzzy testing method based on a protocol process state machine of the present invention, further, by inserting a state variable to track and detect changes in the network protocol state variable, it includes:

[0017] Perform instrumentation on the state variable write operation in the network protocol source code, and map the write value of the state variable to the shared memory block between the fuzz test and the network protocol source code under test;

[0018] An XOR operation is performed on the hash value identified by the state variable string and the new value to be written, and the XOR value is used as an index for updating the shared memory block, so as to utilize the change of the shared memory block to record the state transfer process of the network protocol state variable.

[0019] As a network protocol fuzz testing method based on a protocol process state machine of the present invention, further, a state machine is constructed according to the process state to map the state space and the code space, including:

[0020] A state machine is constructed based on feedback codes or state variables, and the state machine is expanded into a directed graph structure, and the state nodes are expanded into a six-tuple representation, so as to establish a mapping relationship between the state space and the code space using the directed graph structure;

[0021] Among them, the directed graph structure is expressed as<S,E,∑:S→{re_mes}> , S is the set of protocol states, E is the set of states and corresponding program variables, ∑ is the mapping between recorded messages and corresponding states, re_mes is the request message, and the six-tuple of state nodes is represented as<depth,pnode,statetrans_paths,covered_bits,selscted_time,fuzzed_times> , depth represents the depth of the state node; pnode represents the forward state node of the state node; statetrans_paths represents the number of state transition paths explored in the current state; covered_bits represents the program bitmap covered by the current state; selected_times represents the number of times the state is selected; fuzzed_times represents the number of times the state is tested.

[0022] As a network protocol fuzzy testing method based on a protocol process state machine of the present invention, further, a key state of the network protocol is selected according to the state weight, including:

[0023] The state weight is calculated based on the depth of the state node, the number of state transition paths explored in the current state, the program bitmap covered by the current state, the number of times the state is selected, and the number of times the state is tested;

[0024] The state weight is used as the probability of the state being selected, and the key state of the network protocol is obtained based on the probability.

[0025] As a network protocol fuzzy testing method based on a protocol process state machine of the present invention, further, calculating the state weight also includes:

[0026] Set the threshold value of the number of times a state is selected and the number of times a state is tested. If the number of times a state is selected and / or the number of times a state is tested is greater than the threshold value, the weight of the state is set to a constant;

[0027] And in the state weight calculation, if the data volume value reaches the specified level, the state node depth, the number of state transition paths explored in the current state, the number of times the state is selected, and the number of times the state is tested will be downgraded.

[0028] On the other hand, the present invention also provides a network protocol fuzzy testing system based on a protocol process state machine, comprising: a static analysis module, a plug-in tracking module, a state machine construction module and a targeted testing module, wherein:

[0029] A static analysis module, used to perform static analysis on the network protocol source code and identify state variables in the source code, wherein the state variables are program variables that characterize the state of the network protocol;

[0030] The plug-in tracking module is used to track and detect changes in network protocol state variables by plugging state variables to obtain the process state in the network protocol;

[0031] A state machine construction module, used to construct a protocol process state machine for mapping the protocol state space and the code space according to the process state, wherein the process state is a code state conversion performed according to a change in a state variable;

[0032] The targeted testing module is used to select the key states of the network protocol according to the protocol state weights and perform targeted testing on the key states of the network protocol.

[0033] Beneficial effects of the present invention:

[0034] The present invention obtains event processing loops and state variables by statically analyzing the source code of the protocol program, and can derive a more fine-grained state representation scheme, detect the state variables to track their subsequent changes, and obtain detailed protocol states and inter-process information by tracking the state variables. A protocol process state machine integrating the state space and the code space is constructed, which integrates the state space and the code space to effectively guide the fuzz testing process, and assigns weights to the states to select key states and perform targeted fuzz testing. The present invention has good application prospects in the field of network protocol testing. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 This is a schematic diagram of the network protocol fuzzy testing process based on the protocol process state machine in the embodiment;

[0036] Figure 2 The following is a schematic diagram of the test tool architecture in the embodiment. DETAILED DESCRIPTION

[0037] In order to make the purpose, technical solutions and advantages of the present invention clearer and more understandable, the present invention is further described in detail below in conjunction with the accompanying drawings and technical solutions.

[0038] Network protocols are important components in network communication systems, supporting interactive communication between different entities in the network. Their security deserves more attention and research. Fuzz testing is widely used in modern vulnerability mining due to its high efficiency and low false positive rate, and has achieved many results in the field of software security. Existing fuzz testing has problems such as inaccurate state representation and inability to test key states. For this reason, the embodiments of the present invention refer to Figure 1 As shown, a network protocol fuzz testing method based on a protocol process state machine is provided, comprising:

[0039] S101, statically analyzing the network protocol source code and identifying state variables in the source code, where the state variables are program variables that characterize the state of the network protocol.

[0040] Specifically, the source code can be statically analyzed, and the event processing loop can be obtained by using the call stack backtrace information when the protocol source code reads the message; the state variables in the source code are identified and marked, and a unique string identifier is assigned to each state variable, which is output in the form of a state list. The state variables include: event processing loop program variables, program variables read / written in message processing functions, enumeration / integer global variables written by constants, and member variables in structures.

[0041] The protocol program has clear phase characteristics during operation. Taking the TCP-based server protocol program as an example, its life cycle is roughly divided into three stages: service initialization stage, service processing stage, and cleanup stage. Based on this research, most of the work is concentrated on the service processing stage, processing and responding to request messages through network connections. In specific protocols, the processing stage usually uses an event processing loop. In this loop, the socket is used to read the request message, perform subsequent parsing and transaction processing, and then write the response message to the socket for communication. The protocol service program communicates with the client by continuously executing this loop until the connection is disconnected.

[0042] For stateful protocol programs, the state will be transferred multiple times when implementing event processing. Through extensive analysis, developers use enumeration types or integer constants to identify protocol states when implementing protocol programs. In addition, such variables exist in protocol programs as global variables or structure member variables.

[0043] Therefore, these key variables in the protocol program can characterize the protocol status. For example, when Bftpd receives a PASS request message, it will first determine whether the message can be processed in the current state. In the embodiment of this case, the password field in the request message is used as a parameter to call the processing function only after passing the status check, otherwise an error response will be returned directly. When the user completes the login and the password is correct, Bftpd will update the variable state, which is a global variable representing the status, and the updated variable is a member variable of the enumeration type. It is worth noting that this variable is always read or updated in the event processing loop. In addition, the solution of using program variables to represent the protocol status is more reasonable than using response codes. The response code returned by Bftpd in different states is 503, which cannot well represent the program process and distinguish the status.

[0044] To this end, the call stack backtrace information when reading the message from the protocol source code is used to obtain the event processing loop, which can be designed to include:

[0045] Set a breakpoint at the program input class system call;

[0046] In the network protocol service processing stage, if a breakpoint is triggered, the current protocol program function call stack information is used as auxiliary information to identify the event processing loop; and all loop structures containing I / O operations are collected, and a mapping relationship is established through the functions to which the loop structures belong;

[0047] Based on the stack backtrace information, all functions are matched layer by layer in the mapping relationship from the bottom function of the function call stack, and the loop structure contained in the first matched function is used as the event processing loop.

[0048] In the process of identifying the event processing loop, it is necessary to distinguish it from the loops of other network service programs, and exclude the interference of nested loops in the event processing loop. Therefore, the call stack backtrace information when the protocol program reads the message is used to identify the event processing loop. The event processing loop identification algorithm is shown in Algorithm 1.

[0049] First, when the network protocol program completes initialization and enters the service processing phase, a breakpoint is set at the input class system call in the program. When a subsequent message triggers a breakpoint, the current protocol program function call stack information is saved as auxiliary information for identifying loops. During the identification process, all loop structures containing I / O operations are collected and a mapping relationship is established with the functions to which they belong. Afterwards, based on the stack backtrace information, all functions are matched layer by layer from the bottom function of the function call stack in the mapping, and the loop structure contained in the first matched function is used as the event processing loop. This is because the call stack backtrace information only records the function calls in the service processing phase, which can avoid loop interference in the initialization phase. Moreover, bottom-up function matching identifies the outermost loop and eliminates the influence of nested loops.

[0050]

[0051]

[0052] Since static analysis lacks program runtime information, there may be false positives in the process of state variable identification. Based on the analysis of the protocol program, the characteristics of the state variables are summarized, and heuristic rules can be used to reduce false positives. The specific rules can be summarized as follows:

[0053] 1) The operation of state variables in the protocol program is always performed in the event processing loop, so only the program variables in this loop are analyzed to narrow the scope and reduce false alarms.

[0054] 2) Protocol state variables are read or written in the event processing loop or message processing function, so only the variables that are loaded and stored are recorded.

[0055] 3) Protocol state variables are usually global variables of enumeration type or integer type and member variables in structures, and are usually assigned constants. Therefore, only enumeration or integer global variables written by constants and member variables in structures are retained.

[0056] After the state variables are identified, a unique string identifier is assigned to each variable and output in a list for subsequent tracking. However, for protocol programs developed based on event notification libraries, event processing loops are usually in library functions, providing assistance for manual annotation. Using the annotation API to annotate key information can not only refine the identified state variables and implement state-sensitive operations of different granularities, but also accurately annotate state variables based on protocol knowledge.

[0057] S102. Track and detect changes in network protocol state variables by inserting state variables, obtain process states in the network protocol, and construct a protocol process state machine for mapping protocol state space and code space based on the process states, wherein the process states are code state transitions based on changes in state variables.

[0058] Specifically, tracking and detecting changes in network protocol state variables by instrumenting the state variables may include:

[0059] Perform instrumentation on the write operation of the state variables in the network protocol source code, and map the write value of the state variable to the shared memory block of the fuzz test and the network protocol source code under test;

[0060] An XOR operation is performed on the hash value identified by the state variable string and the new value to be written, and the XOR value is used as an index for updating the shared memory block, so as to utilize the change of the shared memory block to record the state transfer process of the network protocol state variable.

[0061] In order to pass the value of the state variable to the fuzz tester in real time, the state variable write operation in the source code is instrumented during the compilation phase to facilitate subsequent state collection. At the same time, the written value of the state variable is mapped to the shared memory of the fuzz tester and the protocol program under test, and the shared memory block is recorded as share_state. The specific mapping calculation method can be expressed as follows:

[0062]

[0063] Among them, var_id represents the string identifier of the state variable, which is subsequently hashed. The hash value and the new value to be written are XORed, and the resulting XOR value is used as the index to update the shared memory block. At the same time, the index can be calculated based on the previous value of the state variable to restore the corresponding value in the shared memory. Different state variables will produce different hash values, which also correspond to different areas in the shared memory. Every time the value of the state variable changes, it will cause a change in the shared memory, thereby recording a more detailed state transfer process of the protocol program. The program after the stub will be processed as the final program to build a state machine model and perform mutation operations.

[0064] In the process of constructing the state machine, the current gray box fuzz tester usually uses simple feedback codes or unprocessed program variables, which lack the connection with the program code space. The two types of feedback information are relatively independent and cannot work well together to guide the fuzz test. In the embodiment of this case, the state machine M is structurally expanded, and an enhanced protocol state machine is designed to establish a mapping relationship between the state space and the program space, and the fine-grained program state represented by the program variables is used to add more process information between states.

[0065] First, expand the state machine M into a directed graph structure<S,E,∑:S→{re_mes}> , where ∑ is the mapping between recorded messages and corresponding states. If the program state is v before re_mes is sent, then the corresponding program variable var_id that has changed will be added to S, v→var_id will be added to E, and the mapping relationship will be added to ∑. Secondly, expand the state node to<depth,pnode,statetrans_paths,covered_bits,selscted_time,fuzzed_times> Among them, depth∈N represents the depth of the state; pnode∈S represents the forward state node of the state; statetrans_paths∈N represents the number of state transition paths explored when the state is in the state; covered_bits∈M represents the program bitmap covered by the state, where M is a two-dimensional matrix; selected_times∈N represents the number of times the state is selected; and fuzzed_times∈N represents the number of times the state is tested.

[0066] In the protocol state diagram, the current state node v∈S, its depth is recorded as the distance d(v,v0) to the entry node v0. Based on the research, the state node with a larger depth value is more difficult to explore. The shared memory block shared_state is collected based on the state variables. Each time the fuzz tester receives the plug-in feedback of the protocol under test, it will record the shared memory of the current program variables, organize and perform hash operations, and use the hash value at this time as the overall state of the current protocol program. Each hash value is stored in a queue. As request messages are continuously sent, a set of state sequences state_sequence is obtained after the test case is executed. By comparing different state sequences, the state variable identifier var_id corresponding to the shared memory block shared_state that has changed is obtained, and then the function unique is used to compare the number of different hash values, thereby obtaining statetrans_paths, i.e. unique(hash(var_id)).

[0067] statetrans_paths refers to the state transition path that can be found when a certain state v is selected. The larger the value, the more transition paths can be explored for the current state. Then the correlation between this state and other states is higher, which also means that this state is more important and deserves special attention. covered_bits represents the edge coverage bitmap that can be reached when exploring this state, and each state retains its own independent bitmap. During the fuzz test, the program coverage after the test case is executed in this state is recorded, and the bitmap coverage of each node of the state machine is calculated. As the test progresses, the mapping between the protocol program space and the state space is continuously improved.

[0068] From the above, we can get that for a known protocol state v, we can get the coverage covered_bits that can be triggered by the state. The larger the value, the larger the corresponding program space, and the greater the exploration value of the state. By supplementing the number of times the state is selected selected_times and the number of times it is tested fuzzed_times, we can balance state exploration and utilization and conduct tests more reasonably.

[0069] S103: Select the key state of the network protocol according to the protocol state weight, and perform targeted testing on the key state of the network protocol.

[0070] Specifically, the key states of the network protocol are selected and can be designed to include:

[0071] The state weight is calculated based on the depth of the state node, the number of state transition paths explored in the current state, the program bitmap covered by the current state, the number of times the state is selected, and the number of times the state is tested;

[0072] The state weight is used as the probability of the protocol state being selected, and the key state of the network protocol is obtained based on the probability.

[0073] In order to find the key state, a weight calculation method for the state is designed, and a heuristic algorithm is used to allocate energy to the key state. The weight calculation is based on the following understanding:

[0074] (1) The deeper the network communication level, the harder it is to test the code. The state has forward dependencies, and as the level of communication increases, the required message sequence becomes more difficult to construct, making it more difficult to fully test and more likely to have potential vulnerabilities.

[0075] (2) States located at key positions in the state machine are associated with more state transition paths, and exploring such states is more likely to trigger unknown coverage.

[0076] (3) The larger the program space affected by the state, the more complex the functions to be implemented will be. The larger the program space and the more complex the code implementation, the more difficult it will be to fully test it, so more attention should be paid to it.

[0077] (4) When exploring program states, it is necessary to consider the exploration of new states to avoid imperfect state machine structures.

[0078] Based on the above principles, for state v i , the calculation formula of its state weight can be expressed as:

[0079]

[0080] The calculated weight is used as the probability of the state being selected. The deeper the state is, the larger the associated path is, and the larger the corresponding program space is, the greater the weight value is. At the same time, states that are selected and tested more times will have corresponding restrictions. To this end, a threshold value for the number of times a state is selected and the number of times a state is tested can be set. If the number of times a state is selected and / or the number of times a state is tested is greater than the threshold value, the state weight is set to a constant; and in the state weight calculation, if the data volume value reaches a specified level, the state node depth, the number of state transition paths explored in the current state, the number of times a state is selected, and the number of times a state is tested are downgraded to facilitate the calculation of high-order selection time.

[0081] like Figure 2 As shown in the figure, the architecture of the fuzz testing tool ZFuzz in this case mainly includes the identification and tracking part of the protocol state variables, the construction part of the protocol process state machine and the state selection part. In the protocol state variable identification and tracking part, the target program source code is processed through automated analysis and manual annotation API to obtain the event processing loop and state variable list of the protocol program. In the variable tracking stage, the compilation and instrumentation engine will first parse the manual annotation information, and then generate the corresponding information output, and at the same time, the target program is instrumented according to the state variable list. The fuzz tester can obtain both state feedback information and coverage feedback information during execution. In the protocol state machine construction part, the existing protocol gray box fuzz testing tools usually only contain simple state information for the construction of the protocol state machine model. For example, AFLNet uses the response code in the response message, and SGFuzz uses enumeration type variables as state variables but lacks filtering. As a result, the existing state machine has problems such as rough state, inaccurate representation, and only considers accessibility. In the actual state machine implementation process, there is no association information with the protocol program space, that is, the program state and code coverage are independent of each other and lack association and coordination. Therefore, the protocol process state machine is used to expand the state machine structure, map the program space and the state space, and coordinate the protocol state variables to achieve more detailed state design and inter-process information improvement.

[0082] Furthermore, based on the above method, an embodiment of the present invention also provides a network protocol fuzz testing system based on a protocol process state machine, comprising: a static analysis module, a plug-in tracking module, a state machine construction module and a targeted testing module, wherein:

[0083] A static analysis module, used to perform static analysis on the network protocol source code and identify state variables in the source code, wherein the state variables are program variables that characterize the state of the network protocol;

[0084] The plug-in tracking module is used to track and detect changes in network protocol state variables by plugging state variables to obtain the process state in the network protocol;

[0085] A state machine construction module, used to construct a protocol process state machine for mapping the protocol state space and the code space according to the process state, wherein the process state is a code state conversion performed according to a change in a state variable;

[0086] The targeted testing module is used to select the key states of the network protocol according to the protocol state weights and perform targeted testing on the key states of the network protocol.

[0087] Unless otherwise specifically stated, the relative steps, numerical expressions and values ​​of the components and steps set forth in these embodiments do not limit the scope of the present invention.

[0088] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the system disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0089] The units and method steps of each example described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. A person of ordinary skill in the art may use different methods to implement the described functions for each specific application, but such implementation is not considered to be beyond the scope of the present invention.

[0090] Those skilled in the art will appreciate that all or part of the steps in the above method can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium, such as a read-only memory, a disk or an optical disk. Optionally, all or part of the steps in the above embodiment can also be implemented using one or more integrated circuits, and accordingly, each module / unit in the above embodiment can be implemented in the form of hardware or in the form of software function modules. The present invention is not limited to any specific form of combination of hardware and software.

[0091] Finally, it should be noted that the above-described embodiments are only specific implementations of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them. The protection scope of the present invention is not limited thereto. Although the present invention is described in detail with reference to the above-described embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the above-described embodiments within the technical scope disclosed by the present invention, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A network protocol fuzz testing method based on a protocol process state machine, characterized in that: Include: Performing static analysis on the network protocol source code and identifying state variables in the source code, wherein the state variables are program variables that characterize the state of the network protocol; Track and detect changes in network protocol state variables by inserting state variables, obtain process states in the network protocol, and construct a protocol process state machine for mapping protocol state space and code space based on the process states, wherein the process states are code state transitions based on changes in state variables; The key states of the network protocols are selected according to the protocol state weights, and targeted tests are performed on the key states of the network protocols. The protocol state weights are used to describe the value of each network protocol state during the fuzzy testing process.

2. The network protocol fuzz testing method based on the protocol process state machine according to claim 1 is characterized in that: Perform static analysis on the network protocol source code and identify state variables in the source code, including: Perform static analysis on the source code and obtain the event processing loop using the call stack backtrace information when reading messages from the protocol source code; The state variables in the source code are identified and annotated, and a unique string identifier is assigned to each state variable, which is output in the form of a state list. The state variables include: event processing loop program variables, program variables read / written in message processing functions, enumeration / integer global variables written by constants, and member variables in structures.

3. The network protocol fuzz testing method based on the protocol process state machine according to claim 2 is characterized in that: The call stack backtrace information when reading messages using the protocol source code is used to obtain the event processing loop, including: Set a breakpoint at the program input class system call; In the network protocol service processing stage, if a breakpoint is triggered, the current protocol program function call stack information is used as auxiliary information to identify the event processing loop; And collect all loop structures containing I / O operations, and establish mapping relationships through the functions to which the loop structures belong; Based on the stack backtrace information, all functions are matched layer by layer in the mapping relationship from the bottom function of the function call stack, and the loop structure contained in the first matched function is used as the event processing loop.

4. The network protocol fuzz testing method based on the protocol process state machine according to claim 1 is characterized in that: Track and detect changes in network protocol state variables by instrumenting them, including: Perform instrumentation on the state variable write operation in the network protocol source code, and map the write value of the state variable to the shared memory block between the fuzz test and the network protocol source code under test; An XOR operation is performed on the hash value identified by the state variable string and the new value to be written, and the XOR value is used as an index for updating the shared memory block, so as to utilize the change of the shared memory block to record the state transfer process of the network protocol state variable.

5. The network protocol fuzz testing method based on the protocol process state machine according to claim 1 is characterized in that: A protocol process state machine is constructed based on the process state to map the protocol state space and the code space, including: A state machine is constructed based on feedback codes or state variables, and the state machine is expanded into a directed graph structure, and the state nodes are expanded into a six-tuple representation, so as to establish a mapping relationship between the state space and the code space using the directed graph structure; Among them, the directed graph structure is expressed as<S,E,∑:S→{re_mes}> , S is the set of protocol states, E is the set of states and corresponding program variables, ∑ is the mapping between recorded messages and corresponding states, re_mes is the request message, and the six-tuple of state nodes is represented as<depth,pnode,statetrans_paths,covered_bits,selscted_time,fuzzed_times> , depth represents the depth of the state node; pnode represents the forward state node of the state node; statetrans_paths represents the number of state transition paths explored in the current state; covered_bits represents the program bitmap covered by the current state; selected_times represents the number of times the state is selected; fuzzed_times represents the number of times the state is tested.

6. The network protocol fuzz testing method based on the protocol process state machine according to claim 1 is characterized in that: Select key status of network protocols, including: The state weight is calculated based on the depth of the state node, the number of state transition paths explored in the current state, the program bitmap covered by the current state, the number of times the state is selected, and the number of times the state is tested; The state weight is used as the probability of the protocol state being selected, and the key state of the network protocol is obtained based on the probability.

7. The network protocol fuzz testing method based on the protocol process state machine according to claim 6 is characterized in that: Calculating state weights also includes: Set the threshold value of the number of times a state is selected and the number of times a state is tested. If the number of times a state is selected and / or the number of times a state is tested is greater than the threshold value, the weight of the state is set to a constant; And in the state weight calculation, if the data volume value reaches the specified level, the state node depth, the number of state transition paths explored in the current state, the number of times the state is selected, and the number of times the state is tested will be downgraded.

8. A network protocol fuzzy testing system based on a protocol process state machine, characterized in that: Contains: static analysis module, instrumentation tracking module, state machine construction module and targeted testing module, among which, A static analysis module, used to perform static analysis on the network protocol source code and identify state variables in the source code, wherein the state variables are program variables that characterize the state of the network protocol; The plug-in tracking module is used to track and detect changes in network protocol state variables by plugging state variables, and obtain the process state in the network protocol, where the process state is a code state transition performed according to the change in the state variables; A state machine construction module, used for constructing a protocol process state machine for mapping a protocol state space and a code space according to a process state; The targeted testing module is used to select the key states of the network protocol according to the protocol state weights and perform targeted testing on the key states of the network protocol.

9. An electronic device, characterized in that: include: at least one processor, and a memory coupled to the at least one processor; The memory stores a computer program, and the computer program can be executed by the at least one processor to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed, the method according to any one of claims 1 to 7 can be implemented.

Images