A model-based network protocol fuzzing system and testing method

Abstract

The application discloses a model-based network protocol fuzzing test system and a test method, and the test system comprises a model learning module, a fuzzy test module and a debugger; the model learning module comprises a mapper and a learner, the learner interacts with a server through the mapper to obtain a state machine model of the server; the fuzzy test module comprises a generator and a fuzzy tester, the generator analyzes the state machine model obtained by the learner, generates a fuzzy test strategy according to a generation rule; the fuzzy tester performs fuzzy test on the server according to the fuzzy test strategy; and the debugger is used for debugging a protocol implementation input into the server, and the protocol implementation after debugging feeds back information to the fuzzy tester for guiding test case generation. The system and the method disclosed by the application automatically infer a corresponding model of a protocol implementation from the protocol implementation by using a model learning method, generate test cases by using the generated model to guide fuzzy test, and obtain higher code coverage and state coverage.

Description

Technical Field

[0001] This invention relates to the field of network protocol security technology, and in particular to a model-based network protocol fuzz testing system and method. Background Technology

[0002] With the advancement of modern technology, internet technology has developed rapidly. The application of internet technology relies heavily on network communication protocols. To meet the application needs of various scenarios, people have designed and implemented a wide variety of network communication protocols. The design of network communication protocols must ensure their reliability; unreliable protocols can, at best, affect communication quality, and at worst, lead to a loss of communication security. Vulnerabilities in network communication protocol specifications or implementations can cause security problems such as denial-of-service attacks, information leaks, and code execution.

[0003] In recent years, cybersecurity issues have emerged one after another. Network communication protocols have a wide range of applications and are one of the foundations of internet technology. If vulnerabilities appear in these protocols, they can be exploited by malicious actors, causing serious consequences. Therefore, the reliability of network communication protocols is crucial. However, with changing demands, the types of network communication protocols are increasing, and even the same protocol can have different implementations, leading to a greater probability of vulnerabilities in protocol specifications or implementations. To ensure protocol security, reliability analysis has become an indispensable part of protocol design and implementation. Network communication protocol reliability analysis techniques aim to use software security analysis methods to analyze network communication protocols, discover errors, or verify their security, which is of great significance for cybersecurity.

[0004] Network communication protocol specifications are designed by protocol designers. For these protocols to be practically applied, software developers need to write code according to the specifications to implement server, client, and other software – this is protocol implementation. Directly performing security analysis on network communication protocol specifications is difficult because they are abstract concepts. Protocol security requires ensuring both the security of the specification and the security of the implementation. A secure protocol specification does not necessarily guarantee a secure implementation. Software developers may have misinterpretations of the specification, be limited by their development skills, or make careless mistakes. Even if the specification is completely secure, the developed software may still be insecure. Since protocols exist as software in practical applications, software security analysis methods can be used to analyze protocol security.

[0005] Fuzzing is one of the most effective methods in software security analysis. It can automatically generate test cases, send them to the target program for execution, and monitor whether the target program crashes or exhibits other unexpected behaviors. Protocol implementations are essentially software, so fuzzing techniques can be used. Although current fuzzing techniques can find vulnerabilities in protocol implementations, there are still difficulties because: (1) Network communication protocols have large state spaces. Most current fuzzing techniques are code coverage-oriented and do not focus on state coverage, making it difficult for existing techniques to find complex errors deep within the state space. (2) Network communication protocols can only handle messages with specific structures. Fuzzing generates test cases randomly, and a large number of invalid test cases are easily generated during the testing process, resulting in a lot of time being spent running invalid test cases and low testing efficiency. (3) Code coverage-based fuzzing requires code instrumentation at compile time. The instrumented program can record code coverage information and provide feedback at runtime. However, this method is only applicable to open-source protocol implementations. For closed-source protocol implementations, instrumentation cannot be performed at compile time. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides a model-based network protocol fuzzing system and method. This method does not require the source code of the protocol implementation, nor does it require testers to have an in-depth understanding of the protocol specifications or implementation. It automatically infers the corresponding model of the protocol implementation from the protocol implementation using a model learning method, and uses the generated model to guide fuzzing to generate test cases, thereby achieving high code coverage and state coverage.

[0007] To achieve the above objectives, the technical solution of the present invention is as follows:

[0008] A model-based network protocol fuzzing system includes:

[0009] The model learning module includes a mapper and a learner. The learner interacts with the server through the mapper to obtain the server's state machine model.

[0010] The fuzzing module includes a generator and a fuzz tester. The generator analyzes the state machine model obtained by the learner and generates a fuzzing strategy according to the generation rules. The fuzz tester performs fuzzing tests on the server according to the fuzzing strategy generated by the generator.

[0011] An instrumenter is used to instrument the protocol implementation of the input server. During fuzzing, the instrumented protocol implementation will provide feedback information to the fuzzer to guide the generation of test cases.

[0012] In the above scheme, the mapper interacts abstractly with the server, while the learner interacts concretely with the mapper.

[0013] In the above scheme, the mapper is configured with one-to-many mapping and transformation rules between abstract inputs and concrete inputs, and between abstract outputs and concrete outputs. The mapper can convert abstract inputs into concrete inputs and concrete outputs into abstract outputs.

[0014] A model-based network protocol fuzzing method, employing the model-based network protocol fuzzing system described above, includes the following steps:

[0015] Step 1: The model learning module starts and initializes the server. The learner interacts with the server through the mapper and obtains the server's state machine model through the abstract model learning method.

[0016] Step 2: The generator analyzes the server's state machine model obtained by the learner and generates a fuzz testing strategy based on the generation rules.

[0017] Step 3: The instrumenter instrumentes the protocol implementation of the input server;

[0018] Step four: The fuzzer starts and initializes the server, and performs fuzz testing on the server according to the fuzz testing strategy. During the fuzz testing process, the instrumented protocol implementation will provide feedback information to the fuzzer to guide the generation of test cases.

[0019] In the above scheme, in step one, the model learned by the abstract model is a deterministic finite protocol state machine. For the protocol implementation, the model records the state information and state transition information of the protocol implementation.

[0020] In the above scheme, in step one, in each round of interaction, the learner selects an abstract message and inputs it into the mapper. The mapper converts the abstract message into a concrete message according to the conversion rules and inputs it into the server. After receiving the concrete message, the server returns a concrete output to the mapper. The mapper converts the concrete output into an abstract output according to the conversion rules and returns it to the learner. At this time, the learner obtains the abstract output corresponding to the abstract input and updates the model accordingly.

[0021] In the above scheme, the generation rules in step two are automatically generated based on the state transition information in the protocol state machine. The state transition information is the connection relationship between states through the input of a certain message. Specifically, it includes the following types:

[0022] (1) Use all the information in the protocol state machine;

[0023] (2) Only use the edges in the protocol state machine where different state transitions occur;

[0024] (3) Using the shortest path between two states, the shortest path between any two states can be obtained in the protocol state machine. By connecting the outputs on this path, the shortest path connection between messages is obtained.

[0025] Feedback is provided during subsequent fuzzing, providing code coverage information. This feedback allows for analysis of the quality of message ordering rules. The fuzzer prioritizes message ordering rules with higher code coverage and records the corresponding code coverage information for manual optimization.

[0026] In the above scheme, in step three, the instrumenter is implemented based on e9patch and instrumentes the protocol implementation. It directly instrumentes the binary file while ensuring the original logic of the program. Each instrumentation position has a unique identifier, and the identifier is used to record code coverage information when the instrumentation code is executed.

[0027] In the above scheme, in step four, the fuzz testing module generates based on BooFuzz. BooFuzz ​​starts and initializes the server, generates messages according to the generation rules, inputs them into the server, processes the messages, and returns a response message. BooFuzz ​​analyzes the server's status based on the server's response to determine whether the server is operating normally.

[0028] In the above scheme, in step four, the instrumented protocol implementation can obtain its own execution path and record these paths in shared memory. During the fuzzing process, the fuzzer communicates with the server through inter-process communication. In addition to the fuzzer input messages and the server output messages, the fuzzer can also obtain the execution path information in shared memory. When a new execution path appears, it means that the input message at this time can enable the server to execute a path that has never been executed before. The fuzzer will explore this message further, thereby realizing code coverage feedback.

[0029] The fuzzing module can be implemented using either an uninstrumented protocol or an instrumented protocol. If the fuzzing module uses an instrumented protocol, the coverage feedback function will be enabled. During the fuzzing process, code coverage information will be collected and fed back to the fuzzer. The fuzzer will then adjust its test case generation method based on the code coverage feedback information.

[0030] Through the above technical solution, the model-based network protocol fuzzy testing system and method provided by the present invention have the following beneficial effects:

[0031] 1. This invention implements a model learning module based on AALpy, employing model learning technology to automatically infer protocol implementation models. It also implements fuzz testing based on BooFuzz. While BooFuzz's test case generation rules require manual writing, this invention can automatically generate efficient BooFuzz ​​test case generation rules based on the model; simultaneously, it collects feedback information during the fuzz testing process to guide the generation of test cases.

[0032] 2. The model learning module of this invention provides a model for fuzz testing. In the fuzz testing module, in addition to recording test cases that cause memory errors, it also considers situations where protocol behavior violates protocol specifications, and designs an interface for protocol specification detection. For test cases that violate manually defined rules, semantic error detection is performed automatically.

[0033] 3. This invention implements binary program instrumentation based on e9patch and includes a feedback function. During fuzzing, it continuously collects feedback information to guide the generation of test cases. This instrumentation method directly modifies the binary file instead of dynamically instrumenting, resulting in high efficiency. Furthermore, the fuzzing module and the instrumentation module can operate independently; the instrumentation module only needs to run once to obtain the instrumented binary file, and subsequent fuzzing modules do not require the instrumentation module.

[0034] 4. In the method of the present invention, testers do not need to have an in-depth understanding of the target protocol specification, but only need to understand the message format in the protocol. The model learning module can automatically learn the protocol implementation model by interacting with the protocol implementation, and the fuzz testing module can also generate test cases according to the format.

[0035] 5. The method of this invention only requires the binary file of the protocol implementation for testing, without the source code of the protocol implementation. If the binary file is instrumented, fuzzing can also statistically analyze information such as coverage during execution. The learned model has a large amount of state and state transition information, which can guide fuzzing to generate efficient test cases, resulting in high code coverage and state coverage. Attached Figure Description

[0036] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0037] Figure 1 This is a schematic diagram of a model-based network protocol fuzzy testing system disclosed in an embodiment of the present invention;

[0038] Figure 2 This is a flowchart of a model-based network protocol fuzzy testing method disclosed in an embodiment of the present invention. Detailed Implementation

[0039] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0040] This invention provides a model-based network protocol fuzz testing system, such as... Figure 1 As shown, it includes:

[0041] The model learning module includes a mapper and a learner. The learner interacts with the server through the mapper to obtain the server's state machine model.

[0042] The fuzzing module includes a generator and a fuzzer. The generator analyzes the state machine model obtained by the learner and generates a fuzzing strategy according to the generation rules. The fuzzer performs fuzzing tests on the server according to the fuzzing strategy generated by the generator.

[0043] Instrumentation is used to instrument the protocol implementation of the input server. During fuzzing, the instrumented protocol implementation will provide feedback information to the fuzzer to guide the generation of test cases.

[0044] Because specific inputs and outputs are complex and diverse, using concrete interactions for model learning is inefficient and yields a large amount of useless data. To address this issue, this invention uses abstract interactions for abstract model learning. In abstract interactions, the learner interacts with the server through a mapper, rather than directly interacting with the server concretely. Specifically, the mapper interacts abstractly with the server, while the learner interacts concretely with the mapper.

[0045] Abstraction describes message types and mapping relationships. Taking the FTP protocol as an example, given a user named admin, the login message is USER username, where username can be any value, but only admin is valid. Therefore, we can define abstract messages VALID_USER and INVALID_USER, corresponding to valid and invalid users respectively. We also define mapping relationships: the abstract message VALID_USER corresponds to USER admin, and INVALID_USER corresponds to any message with a username other than admin, such as USER a, USER b, etc. During the abstract model learning process, the learner selects an abstract message, such as VALID_USER, and inputs it into the mapper. The mapper, based on the mapping relationship, converts VALID_USER into the concrete message USER admin and inputs it into the server.

[0046] The mapper sets up one-to-many mapping and transformation rules between abstract inputs and concrete inputs, and between abstract outputs and concrete outputs. The mapper can convert abstract inputs into concrete inputs and concrete outputs into abstract outputs.

[0047] A model-based fuzzing method for network protocols employs the model-based fuzzing system described above, such as... Figure 2 As shown, it includes the following steps:

[0048] Step 1: The model learning module starts and initializes the server. The learner interacts with the server through the mapper and obtains the server's state machine model through the abstract model learning method.

[0049] The model learned from the abstract model is a deterministic finite protocol state machine. For the protocol implementation, the model records the state information and state transition information of the protocol implementation.

[0050] Specifically, the learner interacts abstractly with the mapper, rather than directly with the server. In each round of interaction, the learner selects an abstract message and inputs it into the mapper. The mapper, according to the transformation rules, converts the abstract message into a concrete message and inputs it into the server. After receiving the concrete message, the server returns a concrete output to the mapper. The mapper, according to the transformation rules, converts the concrete output into an abstract output and returns it to the learner. At this point, the learner obtains the abstract output corresponding to the abstract input and updates the model accordingly.

[0051] Abstract definitions are the core of the mapper. Since the model learns a deterministic finite state automaton, determinism should be guaranteed during abstract interactions. This requires good abstract definitions, which ensure determinism in the abstract interaction process. Manually written abstractions may not completely guarantee determinism and sometimes need to be processed. This invention implements an uncertainty analysis method that combines automatic and manual analysis to analyze uncertainty and optimize abstractions. After manually writing the abstraction, it is directly used for model learning. If a contradiction occurs in the deterministic finite state machine being learned, the learner throws an exception and records the input abstract message sequence, the specific message sequence, the expected output sequence, and the actual output sequence that caused the contradiction. At this time, the cause of uncertainty may be an improper abstract definition or a specific message triggering a server memory error. To reduce uncertainty, the learner tests the input specific message sequence, traversing the specific messages, selecting one at a time, and choosing other specific messages from the corresponding abstraction to replace it. After each replacement, the new sequence is input into the server, the specific output is recorded, and it is converted into an abstract output through a mapper. If the abstract output of the new sequence differs from the abstract output of the original sequence, the specific messages before and after the replacement should not be placed in the same abstraction, as this would create uncertainty. They are separated from the original abstraction according to their output and placed in different abstractions, with input and output information recorded for manual analysis. If server crashes or other anomalies occur during the interaction, it may be due to a specific message sequence triggering a server memory error. This specific message sequence is directly removed and recorded for further manual error analysis. After uncertainty analysis, specific messages placed in the same abstraction but causing different server behaviors are separated, and the specific messages that triggered server memory errors are removed, resulting in an optimized abstraction. Testers can also continue to manually optimize the abstraction based on the recorded information.

[0052] Step two: The generator analyzes the server's state machine model obtained by the learner and generates a fuzz testing strategy based on the generation rules.

[0053] The definition of generation rules is a key aspect of generation-based fuzzing techniques. Generation rules can be written manually, allowing testers to create rules based on their understanding of the protocol specification to ensure the generated messages meet specific structures. However, writing generation rules that produce messages with specific structures already requires significant manpower. If generating rules to produce well-ordered input sequences, testers need an even deeper understanding of the protocol specification, consuming even more manpower. The more states covered, the more manpower is required, and manual writing cannot guarantee coverage of all states. Furthermore, since protocol implementations may differ from the protocol specification, generation rules written according to the specification may not be entirely applicable to the protocol implementation.

[0054] This invention utilizes a protocol state machine learned from a model to automatically generate rule definitions. The state machine obtained during the model learning phase is a protocol implementation state machine, not a protocol specification state machine; it is more suitable for protocol implementation and may even be more knowledgeable about protocol implementation than someone proficient in the specification. State and state transition information can be obtained from the protocol state machine. The fuzz testing module of this invention is based on BooFuzz, which provides an interface for defining test case generation rules. Previously, testers needed to manually write test case generation rule code; this invention automates the generation of test case rule code. Since BooFuzz ​​provides an interface for defining test case generation rules, the generated rule code can be templated. To achieve automated generation of rule code, a template for generating rule code is written, and the variable parts of the template can be derived from information in the model. The generator analyzes the model and abstracts, filling the required information into the template to obtain the complete generated rule code.

[0055] In the protocol state machine learned from the abstract model, all input and output information is abstract. Similarly, in BooFuzz's test case generation rules, message structure rules are abstract definitions. These definitions mark immutable fields, mutable fields, delimiters, and other information within the message. They can be defined manually or automatically by the conversion relationship between abstract and concrete messages in step one. Since there is a one-to-many mapping between abstract and concrete messages, this relationship allows analysis of the information required for BooFuzz ​​message structure rules, such as mutable fields, thereby automating the generation of message structure rules.

[0056] BooFuzz ​​message ordering rules define the connection relationships between messages. After defining the message structure rules, these messages can be connected according to the given relationships. During fuzzing, test cases are generated based on these relationships. The protocol state machine learned from the abstract model contains a large amount of state transition information, which includes the connection relationships between messages. This information can be used to automatically generate BooFuzz ​​message ordering rules. The state transition information in the protocol state machine is the state transition between states through the input of a certain message. There are multiple conversion methods for this to the connection relationships between messages. This invention implements several conversion methods:

[0057] 1. Using all the information in the protocol state machine, the resulting rule definition is very complex. Although it can guarantee the maximum coverage, it is inefficient to fully explore it during fuzz testing.

[0058] 2. Only use edges in the protocol state machine that result in different state transitions. In a protocol state machine, there are many edges that do not result in different state transitions; that is, after inputting a certain message, the state remains the same. If a high state coverage is to be achieved quickly, these edges should not be prioritized.

[0059] 3. Using the shortest path between two states, the shortest path between any two states can be obtained in the protocol state machine. By connecting the outputs on this path, the shortest path connection between messages is obtained.

[0060] Feedback is provided during subsequent fuzzing, providing code coverage information. This feedback allows for analysis of the quality of message ordering rules. The fuzzer prioritizes message ordering rules with higher code coverage and records the corresponding code coverage information for manual optimization.

[0061] The automatically generated message generation rules and message order rules enable the fuzzing module to cover key states in the protocol state machine, improving code coverage and increasing the probability of discovering vulnerabilities.

[0062] Step 3: The instrumenter instrumentes the protocol implementation of the input server.

[0063] The instrumenter, based on e9patch, instrumentes the protocol implementation. It directly instrumentes the binary file while preserving the original program logic. Each instrumentation location has a unique identifier, and the identifier is used to record code coverage information during the execution of the instrumented code. Based on the collected path information and the interaction methods between the fuzzer and the program under test in the fuzzing module, e9patch instrumentation code can be written, allowing e9patch to instrument the protocol implementation according to this code.

[0064] This information is recorded during fuzzing and fed back to the fuzz tester to guide the generation of test cases.

[0065] Step four: The fuzzer starts and initializes the server, and performs fuzz testing on the server according to the fuzz testing strategy. During the fuzz testing process, the instrumented protocol implementation will provide feedback information to the fuzzer to guide the generation of test cases.

[0066] The fuzz testing module is generated based on BooFuzz, and the rules for generating test cases are obtained in step two.

[0067] BooFuzz ​​starts and initializes the server, generates messages according to the generation rules, inputs them into the server, processes the messages, and returns a response message. BooFuzz ​​analyzes the server's status based on the server's response to determine whether the server is operating normally.

[0068] BooFuzz ​​lacks code coverage feedback, but this invention implements it. The instrumented protocol implementation obtains its own execution paths and records these paths in shared memory. During fuzzing, the fuzzer communicates with the server. Besides the fuzzer's input messages and the server's output messages, the fuzzer can also obtain execution path information from shared memory. When a new execution path appears, it indicates that the current input message can cause the server to execute a path it has never executed before. The fuzzer will then explore this message further, thus achieving code coverage feedback.

[0069] The fuzzing module can be implemented using either an uninstrumented protocol or an instrumented protocol. If the fuzzing module uses an instrumented protocol, the coverage feedback function will be enabled. During the fuzzing process, code coverage information will be collected and fed back to the fuzzer. The fuzzer will then adjust its test case generation method based on the code coverage feedback information.

[0070] During fuzzing, test cases that cause server crashes are recorded. When the server crashes, the fuzzer records the input sequence that caused the crash and crash information for further manual analysis. The server is then restarted, and fuzzing continues.

[0071] During fuzzing, test cases that cause the server output to violate manually defined rules are also recorded. This feature can uncover vulnerabilities in the protocol implementation that violate protocol specifications. The fuzzer records the server's state information and output during fuzzing. When the state information and output violate manually defined rules, it may indicate a vulnerability in the server that violates protocol specifications. For example, if the protocol specification defines that a certain message input in a certain state should not produce a certain output, this rule can be provided to the fuzzer. The fuzzer can then analyze the output in this state. If it produces an unexpected output, it will record the input sequence and output for further manual analysis.

[0072] Combining the two methods allows both memory errors and semantic errors to be detected during fuzz testing.

[0073] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A model-based network protocol fuzz testing system, characterized in that, include: The model learning module includes a mapper and a learner. The learner interacts with the server through the mapper to obtain the server's state machine model. A fuzzing module, comprising a generator and a fuzzing tester, wherein the generator analyzes the state machine model obtained by the learner and generates a fuzzing strategy according to generation rules; The fuzz tester performs fuzz testing on the server according to the fuzz testing strategy generated by the generator. An instrumenter is used to instrument the protocol implementation of the input server. During fuzzing, the instrumented protocol implementation will feed back information to the fuzzer to guide the generation of test cases. The testing method performed by the fuzz testing system includes the following steps: Step 1: The model learning module starts and initializes the server. The learner interacts with the server through the mapper and obtains the server's state machine model through the abstract model learning method. Step 2: The generator analyzes the server's state machine model obtained by the learner and generates a fuzz testing strategy based on the generation rules. Step 3: The instrumenter instrumentes the protocol implementation of the input server; Step 4: The fuzz tester starts and initializes the server, and performs fuzz testing on the server according to the fuzz testing strategy. During the fuzz testing process, the instrumented protocol implementation will feed back information to the fuzz tester to guide the generation of test cases. The generation rules in step two are automatically generated based on the state transition information in the protocol state machine. This state transition information is the connection relationship between states achieved through the input of a certain message. Specifically, it includes the following: (1) Use all the information in the protocol state machine; (2) Only use the edges in the protocol state machine where different state transitions occur; (3) Using the shortest path between two states, the shortest path between any two states can be obtained in the protocol state machine. By connecting the outputs on this path, the shortest path connection between messages is obtained. Feedback is provided during subsequent fuzzing, providing code coverage information. This feedback allows for analysis of the quality of message ordering rules. The fuzzer prioritizes message ordering rules with higher code coverage and records the corresponding code coverage information for manual optimization.

2. The model-based network protocol fuzz testing system according to claim 1, characterized in that, The mapper interacts abstractly with the server, while the learner interacts concretely with the mapper.

3. The model-based network protocol fuzz testing system according to claim 1, characterized in that, The mapper is configured with one-to-many mapping and transformation rules between abstract inputs and concrete inputs, and between abstract outputs and concrete outputs. The mapper can convert abstract inputs into concrete inputs and concrete outputs into abstract outputs.

4. The model-based network protocol fuzz testing system according to claim 1, characterized in that, In step one, the model learned by the abstract model is a deterministic finite protocol state machine. For the protocol implementation, the model records the state information and state transition information of the protocol implementation.

5. The model-based network protocol fuzz testing system according to claim 1, characterized in that, In step one, in each round of interaction, the learner selects an abstract message and inputs it into the mapper. The mapper converts the abstract message into a concrete message according to the conversion rules and inputs it into the server. After receiving the concrete message, the server returns a concrete output to the mapper. The mapper converts the concrete output into an abstract output according to the conversion rules and returns it to the learner. At this point, the learner obtains the abstract output corresponding to the abstract input and updates the model accordingly.

6. The model-based network protocol fuzz testing system according to claim 1, characterized in that, In step three, the instrumenter is implemented based on e9patch and instrumentes the protocol implementation. It directly instrumentes the binary file while ensuring the original logic of the program. Each instrumentation position has a unique identifier, and the identifier is used to record code coverage information when the instrumented code is executed.

7. The model-based network protocol fuzz testing system according to claim 1, characterized in that, In step four, the fuzz testing module is generated based on BooFuzz. BooFuzz ​​starts and initializes the server, generates messages according to the generation rules, inputs them into the server, processes the messages, and returns a response message. BooFuzz ​​analyzes the server's status based on the server's response to determine whether the server is operating normally.

8. The model-based network protocol fuzz testing system according to claim 7, characterized in that, In step four, the instrumented protocol implementation can obtain its own execution path and record these paths in shared memory. During fuzzing, the fuzzer communicates with the server through inter-process communication. In addition to the fuzzer input messages and the server output messages, the fuzzer can also obtain the execution path information in shared memory. When a new execution path appears, it means that the input message at this time can enable the server to execute a path that has never been executed before. The fuzzer will explore this message further, thereby realizing code coverage feedback. The fuzzing module can be implemented using either an uninstrumented protocol or an instrumented protocol. If the fuzzing module uses an instrumented protocol, the coverage feedback function will be enabled. During the fuzzing process, code coverage information will be collected and fed back to the fuzzer. The fuzzer will then adjust its test case generation method based on the code coverage feedback information.

Images