Method and system for detecting logic vulnerabilities of extensible stateful protocol entities

Abstract

The application discloses a kind of extensible stateful protocol entity program logic vulnerability detection method and system.Test preparation stage: locally deploying the entity program to be tested, a script file describing the traffic message of the stateful protocol to be tested and its corresponding message type is used as input;State machine learning stage: select input symbol from script file and map to corresponding message message, then fuzz it to generate test case;And judge whether the test case still belongs to the symbol, yes, send to the program to be tested for execution, otherwise modify;Collect the response message after the execution of the program to be tested, and map to the corresponding output symbol, use model learning to build a minimum deterministic Mealy state machine corresponding to the protocol entity program to be tested;Result arrangement and analysis stage, the result state machine obtained by learning is pruned and processed.The application is suitable for the detection of logic vulnerability of stateful protocol entity program, and has strong scalability, high vulnerability detection efficiency.

Description

Technical Field

[0001] This invention relates to the field of network communication protocol testing technology, and more specifically, to a method and system for detecting logical vulnerabilities in scalable stateful protocol entity programs. Background Technology

[0002] Fuzzing is a method for discovering vulnerabilities by providing unexpected inputs to a target system and monitoring the abnormal results. It offers advantages such as high accuracy, strong usability, and low dependence on the source code of the test target. Since most protocol implementations are provided by vendors, users often lack sufficient understanding of their internal implementation structure; therefore, fuzzing is frequently used for vulnerability discovery.

[0003] Based on whether there is a correlation between protocol messages, network protocols are divided into stateful protocols and stateless protocols. Stateless protocols, such as ICMP and DNS, have each request message that is independent and there is no correlation between them; while stateful protocols, such as FTP, TCP, TLS, and DTLS, have each request and response affecting the next request and response, and both communicating parties need to maintain a protocol state space.

[0004] For fuzz testing of stateful protocols, test case messages are only accepted by the protocol entity if they match the current state of the protocol entity; otherwise, they are rejected. Therefore, testing requires reliance on the protocol state machine. If testing is to be performed on a specific intermediate state within the protocol state machine, a preceding message must first be sent to bring the protocol entity program to the state under test before the test can proceed.

[0005] Existing fuzzing methods for stateful network protocol entities mainly focus on crash vulnerability testing that can cause the protocol entity program to crash. The main patented methods are as follows: CN 104796240 A proposes a fuzzing method for crash vulnerabilities of stateful network protocols; CN 114116500 A proposes a fuzzing method for crash vulnerabilities of protocol entity programs of unknown protocols; and CN 105763392 A proposes a method for fuzzing industrial control components based on protocol state.

[0006] Besides the aforementioned methods for testing crashes in stateful protocols, there are also a few methods for testing logical vulnerabilities in protocols. Logical vulnerabilities are usually caused by programmers' inaccurate understanding of the protocol specifications, leading to logical errors in the protocol implementation code. Logical vulnerabilities generally do not cause crashes in the protocol entity program, making them relatively difficult to detect. The paper "Protocol state machine fuzzing of TLS Implementations (tls-fuzzer)" proposes a method for detecting logical vulnerabilities. It utilizes automata learning techniques to construct state machines for different protocol entity programs. Through a mapper module, abstract input symbols are transformed into concrete message packets and sent to the program under test. Simultaneously, the message responses returned by the program under test are received and transformed into abstract output symbols. These input and output symbols are used to construct the state machine of the protocol entity program. Finally, logical vulnerabilities are discovered by manually analyzing the learned state machine. If problematic states or abnormal state transitions are found, their corresponding source code is located to analyze whether logical errors exist. "Analysis of DTLS Implementations Using Protocol StateFuzzing (dtls-fuzzer)" also employs a similar method to detect logical vulnerabilities in the DTLS protocol.

[0007] However, the above-mentioned protocol logic vulnerability testing work has the following shortcomings: its mapper and fuzzing implementation code are tightly coupled with the TLS and DTLS protocols, and can only learn and build state machines for the TLS and DTLS protocols. If it is to be extended to implement testing of other protocols, the protocol mapper and fuzzing implementation code need to be modified, which is difficult to modify and has poor protocol scalability.

[0008] CN 109525457 A proposes a method for fuzzing protocol entity programs based on protocol state transitions, discovering logical vulnerabilities by identifying abnormal state transitions within the protocol entity. For protocol entity programs with publicly available protocol specifications, the protocol state machine information described in the specification is first used to guide fuzzing. For private protocol entity programs with unknown specifications, the program's state machine information is obtained through protocol reverse engineering to guide fuzzing. Then, based on the obtained state machine of the protocol entity program, the shortest path traversing all transitions of the protocol state machine is solved, and each state transition is tested sequentially according to this shortest path. During the testing process, abnormal state transitions of the protocol entity are discovered based on the unique input / output sequence of the protocol state. The limitations of this method are: the protocol state machine in the publicly available protocol specification and the state machine of the protocol entity program are not necessarily completely consistent; the program may exhibit some reasonable intermediate states and state transitions during implementation; and the private protocol state machine information obtained through protocol reverse engineering deviates significantly from the actual protocol state. These inconsistencies / deviations in the state machine affect the accuracy of the test results.

[0009] To address the aforementioned issues, this invention proposes a scalable method and system for detecting logical vulnerabilities in stateful protocol entity programs. It takes the traffic packets of the stateful protocol under test and their corresponding message types as input, and effectively constructs the state machine of the protocol entity program through a combination of fuzz testing and automata learning. Then, it discovers potential logical vulnerabilities in the protocol entity program under test by manually analyzing the state machine. Summary of the Invention

[0010] To address the aforementioned problems, this invention proposes a scalable logical vulnerability detection method and system for stateful protocol entity programs. The method consists of three phases: a test preparation phase, a state machine learning phase, and a result processing and analysis phase. In the test preparation phase, the protocol entity program under test is deployed locally, using a script file describing the traffic packets and corresponding message types of the stateful protocol under test as input. In the state machine learning phase, firstly, input symbols are selected from the script file, mapped to corresponding message packets, and the message packets are fuzzified to generate test cases. Then, similarity calculations are used to determine if the test case belongs to the given symbol; if so, it is sent to the program under test for execution; otherwise, it is fuzzified again for correction. Finally, response packets after the program under test executes the test cases are collected, and similarity calculations are used to map the response packets to corresponding output symbols. Model learning is then used to construct a minimal deterministic Mealy state machine corresponding to the protocol entity program under test, i.e., the result state machine. In the result analysis phase, the learned result state machine is pruned and processed to facilitate analysis of abnormal path migrations and redundant states by testers.

[0011] This invention proposes a scalable method for detecting logical vulnerabilities in stateful protocol entity programs, which mainly includes three stages: test preparation stage, state machine learning stage, and result processing and analysis stage.

[0012] 1. Test Preparation Phase

[0013] The Wireshark tool is used to capture the communication traffic of the protocol under test, and the message packets and their corresponding message types are used as input to a fuzz tester. Specifically, this includes the following:

[0014] 1.1 Deployment of the protocol entity program under test

[0015] Deploy the protocol entity program under test, start the protocol entity program under test and its corresponding communication terminal (if the protocol entity program under test is a client, start the corresponding communication server, otherwise start the corresponding communication client).

[0016] 1.2 Network Traffic Capture

[0017] Launch the network packet analysis tool Wireshark to capture the network traffic between the protocol entity under test and its corresponding communication terminal.

[0018] 1.3 Message Type Classification

[0019] The captured network traffic is filtered and organized into different message types, while ensuring that each message type corresponds to at least one message packet instance.

[0020] Then, messages sent by the protocol entity program under test are classified as output message types; messages sent by the communication end are classified as input message types.

[0021] Finally, each message type is uniquely identified by a symbol, and the data structure of the organized message types is represented as <symbol, the set of message instances corresponding to the message type identified by the symbol>.

[0022] 1.4 Script File Construction

[0023] All message instances, message types, and symbols obtained in section 1.3 are described in a script file, forming a script file that describes the traffic packets of the stateful protocol under test and their corresponding message types. This script file is used as input to the tester. The script file contains three mapping tables: a symbol mapping table, an input symbol mapping table, and an output symbol mapping table. The input symbol mapping table describes the one-to-one mapping between symbols and message types; the input symbol mapping table describes the one-to-many mapping between all input symbols and the message instances corresponding to the message types identified by those symbols; and the output symbol mapping table describes the one-to-many mapping between all output symbols and the message instances corresponding to the message types identified by those symbols.

[0024] 2. State machine learning phase

[0025] The fuzz tester first selects input symbols from the script file, maps the symbols to the corresponding message messages, and then fuzzes them to generate test cases.

[0026] Next, the similarity calculation is used to determine whether the test case still belongs to this state. If it does, it is sent to the program under test for execution; otherwise, it is corrected.

[0027] Finally, the response messages of the program under test after executing the test cases are collected, and they are mapped to corresponding output symbols through similarity calculation. A minimal deterministic Mealy state machine corresponding to the protocol entity program under test is then constructed using model learning. Specifically, it includes the following:

[0028] 2.1 Message Acquisition

[0029] Input symbols are randomly selected from the symbol mapping table in the script file. For each selected symbol, the message message instance corresponding to the message type identified by the symbol is obtained from the input symbol mapping table in the script file. If a symbol has multiple instances, one is randomly selected as the message message to be obfuscated.

[0030] 2.2 Message Obfuscation

[0031] The received message messages are obfuscated, including no processing, empty processing, random field mutation, and havoc mutation operations, which change the attribute values ​​of some fields in the message messages.

[0032] 2.3 Fuzzy Correction

[0033] The above fuzzing operation is corrected using similarity calculation. The fuzzed test cases are then compared with all message instances corresponding to the message types identified by all input symbols, using the Levenshtein distance formula:

[0034] dis(MMinput M input ) = lev(MM input M input ) / max(len(MM input ),len(M input ))

[0035] Where lev(MM) input M input ) indicates that the test cases MM input The insertion, replacement, and deletion operations are converted into a message message instance M for comparison. input The minimum number of operations required, max() indicates the maximum value, and len() indicates the length of the response message. dis(MM) input M input The ) indicates the dissimilarity between two message messages.

[0036] Calculate the MM of test cases generated by fuzzification input Find the message instance M with the smallest dissimilarity to all message instances. min_dis If the message instance belongs to the same input symbol S as the current test case. input If the condition is met, the correction is complete, proceed to the next step. Otherwise, perform the blurring operation again and repeat the above process until the condition is met.

[0037] 2.4 Test Case Execution

[0038] Send the revised test cases from step 2.3 to the protocol entity program under test for execution.

[0039] 2.5 Output Symbol Matching

[0040] Obtain the response message returned after the program completes the test cases in step 2.4, and use similarity calculation to determine the output symbol corresponding to the response message. Calculate the similarity between the response message and all message instances corresponding to the message types identified by all output symbols, using the Levenshtein distance formula:

[0041] dis(MR output M output )

[0042] =lev(MR output M output ) / max(len(MR output ),len(M output ))

[0043] Where lev(MR) output M output ) indicates that the response message MR will be sent.output The insertion, replacement, and deletion operations are converted into a message message instance M for comparison. output The minimum number of operations required, max() indicates the maximum value, and len() indicates the length of the response message. dis(MR output M output The dissimilarity (MR) of two response messages is represented by ). output The dissimilarity of all message instances corresponding to the message types identified by all output symbols is used to determine the output symbol S corresponding to the response message with the smallest dissimilarity. output As the response message MR output The corresponding output symbol.

[0044] 2.6 State Machine Learning

[0045] The open-source automata learning framework LearnLib is used to learn the state machine of the program under test. It receives the input symbols and returned output symbols, constructs a minimal deterministic Mealy state machine corresponding to the protocol entity program using Anglokin's L* algorithm, and verifies the state machine using Chow's W-method algorithm. If verification fails, the state machine is reconstructed. This iterative learning process is repeated until verification is successful. At this point, the learned state machine is considered to conform to the actual program, the learning process ends, and this is taken as the final state machine result.

[0046] 3. Results Compilation and Analysis Stage

[0047] The state machine learned in section 2.6 is pruned and refined to facilitate analysis of abnormal path transitions and redundant states by testers. This includes the following steps:

[0048] 3.1 State Machine Arrangement

[0049] The constructed state machine is then manually analyzed and refined to facilitate testing of abnormal path migrations and redundant states. This includes the following operations:

[0050] 3.1.1 Path Marking

[0051] Mark a complete normal state transition path in the state machine. This path contains all the complete interactive states of the protocol under test, and each state transition in the path conforms to the protocol specification.

[0052] 3.1.2 Redundant Path Deletion

[0053] Delete all state transition paths that cannot reach the last interactive state.

[0054] 3.2 State Machine Analysis

[0055] After the above operations, the resulting state machine will contain one normal state transition path and some paths that do not follow the normal state transition but still complete communication interaction. These paths may omit or skip certain states compared to the normal path. Analyzing these states helps identify potential abnormal path transition problems. Specifically, this includes the following operations:

[0056] 3.2.1 Normative Analysis

[0057] Examine each path in the state machine that leads to the final state, and analyze whether the state transitions in these paths conform to the specifications of the protocol under test.

[0058] 3.2.2 Redundancy Analysis

[0059] The process involves checking for redundant or unexpected states in the state machine and analyzing whether these states are problematic. If problematic states or abnormal state transitions are found, their corresponding source code is located to analyze for logical errors.

[0060] Based on the above method, this invention proposes a scalable logic vulnerability detection system for stateful protocol entity programs, including a test preparation module, a state machine learning module, and a result processing and analysis module, wherein the state machine learning module includes a mapper unit, a fuzz testing unit, and a learner unit.

[0061] Test Preparation Module: Using Wireshark, network traffic between the protocol under test (DUT) and its corresponding communication program is captured. The traffic is then categorized into different message types, ensuring that each message type has at least one message packet. Each message type is abstracted as a symbol, and stored in input and output symbol alphabets based on whether the message was sent by the DUT entity program. Each alphabet contains multiple tuples in the format <symbol, the set of message packets corresponding to that symbol>. All this information is recorded in a file named symbolalphabet.xml.

[0062] Mapper unit: Retrieves all tuple information from the symbolalphabet.xml file, specifically including all input symbols and their corresponding message messages in the input symbol alphabet, and all output symbols and their corresponding message messages in the output symbol alphabet; randomly selects a series of input symbols from all input symbols to form an input symbol sequence, and parses each input symbol into its corresponding input message message according to the input symbol alphabet;

[0063] The fuzzing unit performs fuzzing operations on the received message messages, including no processing, empty processing, random field mutation, and HAVOC; it changes the attribute values ​​of some fields in the message messages; and it corrects the fuzzing operations through similarity calculation; it sends the corrected message messages as test cases to the protocol entity program under test, and obtains the response messages returned by the program after executing the test cases; the mapper unit maps the output symbol alphabet to the corresponding output symbols.

[0064] The learner unit uses the open-source automaton learning framework LearnLib for model learning. The learner unit receives the input symbols sent this time and the returned output symbols, uses model learning to construct a minimum deterministic Mealy state machine corresponding to the protocol entity program, and determines a final result state machine through continuous iterative learning. The final result state machine fully reflects all the behaviors of the protocol entity program under test.

[0065] The results processing and analysis module prunes and processes the state machine built from model learning, enabling testers to analyze abnormal path migrations and redundant states.

[0066] The beneficial effects of this invention are:

[0067] 1. This invention does not require prior knowledge of specific protocol specifications. It only requires a script file describing the mapping between packet traffic instances and packet types of the protocol under test as input. In contrast, methods such as tls-fuzzer and dtls-fuzzer require protocol specification information (packet format, packet fields, and other descriptive information) as input. Therefore, it does not require writing a complete protocol specification description script, which greatly reduces the preparation workload for testing new protocols. Moreover, it is more convenient for testing the logical vulnerabilities of private protocols with unknown specifications and has good protocol scalability.

[0068] 2. This invention is not limited to specific protocols in terms of mapping and fuzzing strategies. Instead, it corrects test cases through similarity calculations after mutation, and adding new test protocols does not require modification of the test program code. In contrast, the tls-fuzzer and dtls-fuzzer methods require writing detailed related code according to the protocol specification in modules such as mapping and fuzzing strategies, and testing new protocols requires a lot of code modification and extension work. Therefore, this method has stronger protocol scalability.

[0069] 3. Compared to the method in CN 109525457 A that discovers logical vulnerabilities in abnormal state transitions through protocol reverse analysis or known protocol specifications, this invention adopts a model learning approach, which can better learn and update the state machine of the protocol entity program during the testing process. Therefore, the learned state machine is more complete and the test results are more accurate. Attached Figure Description

[0070] Figure 1 This is a flowchart illustrating a scalable stateful protocol entity program logic vulnerability detection method according to the present invention.

[0071] Figure 2 This is an example diagram of the script file format in the test preparation phase of an extensible stateful protocol entity program logic vulnerability detection method of the present invention.

[0072] Figure 3 This is a flowchart of the state machine learning phase in the scalable stateful protocol entity program logic vulnerability detection method of the present invention.

[0073] Figure 4 This is an example diagram of the state machine organization in the result organization and analysis stage of the scalable stateful protocol entity program logic vulnerability detection method of the present invention. Detailed Implementation

[0074] The technical solutions of the embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0075] like Figure 1 As shown, the scalable stateful protocol entity program logic vulnerability detection method proposed in this invention mainly includes three stages: test preparation stage, state machine learning stage, and result processing and analysis stage.

[0076] 1. Test Preparation Phase

[0077] The Wireshark tool is used to capture packet traffic of the protocol under test, and the message packets and their corresponding message types are used as input to a fuzz tester. The process includes the following steps:

[0078] 1.1 Deploy the protocol entity program to be tested, and start the protocol entity program to be tested and its corresponding communication terminal (if the protocol entity program to be tested is a client, start the corresponding communication server; otherwise, start the corresponding communication client).

[0079] 1.2 Launch the network packet analysis tool Wireshark to capture the network traffic between the protocol entity program under test and its corresponding communication terminal.

[0080] 1.3 The captured network traffic is filtered and sorted into different message types, while ensuring that each message type corresponds to at least one message packet instance.

[0081] Then, messages sent by the protocol entity program under test are classified as output message types; messages sent by the communication end are classified as input message types.

[0082] Finally, each message type is uniquely identified by a symbol, and the data structure of the organized message types is represented as <symbol, the set of message instances corresponding to the message type identified by the symbol>.

[0083] For example, if the protocol entity under test is a server, and a message M corresponds to the message type ClientHello, firstly, this message is sent by the client and is considered input to the protocol entity under test; therefore, it is categorized as an input message type. Next, this type is abstractly and uniquely identified by a CH symbol. Finally, we represent the information using the data structure described above, i.e.<CH,{M}> .

[0084] 1.4 Describe all message instances, message types, and symbols obtained in 1.3 above using a script file. Figure 2 This is an example diagram of a script file format.

[0085] After the aforementioned fuzzing preparation phase is completed, a script file describing the traffic packets of the stateful protocol under test and their corresponding message types will be obtained. This script file contains three mapping tables: a SymbolAlphabet (describing a one-to-one mapping between symbols and message types), an InputSymbolAlphabet (describing a one-to-many mapping between all input symbols and the message packet instances corresponding to the message type identified by that symbol), and an OutputSymbolAlphabet (describing a one-to-many mapping between all output symbols and the message packet instances corresponding to the message type identified by that symbol). This script file is used as input to the fuzz tester.

[0086] 2. State machine learning phase

[0087] like Figure 3 As shown, the fuzz tester first selects input symbols from the script file, maps the symbols to the corresponding message messages, and then fuzzes them to generate test cases.

[0088] Next, the similarity calculation is used to determine whether the test case still belongs to this state. If it does, it is sent to the program under test for execution; otherwise, it is corrected.

[0089] Finally, the response messages of the program under test after executing the test cases are collected, and they are mapped to corresponding output symbols through similarity calculation. A minimal deterministic Mealy state machine corresponding to the protocol entity program under test is then constructed using model learning. Specifically, it includes the following:

[0090] 2.1 Message Acquisition

[0091] Input symbols are randomly selected from the SymbolAlphabet table in the script file. For each selected symbol, the message message instance corresponding to the message type identified by the symbol is obtained from the InputSymbolAlphabet table in the script file. If there are multiple instances, one is randomly selected as the message message to be obfuscated.

[0092] The pseudocode for this process is shown below:

[0093]

[0094]

[0095] 2.2 Message Obfuscation

[0096] The received message messages are obfuscated, including no processing, empty processing, random field mutation, and havoc mutation operations, which change the attribute values ​​of some fields in the message messages.

[0097] 2.3 Fuzzy Correction

[0098] The above fuzzing operation is corrected using similarity calculation. The fuzzed test cases are then compared with all message instances corresponding to the message types identified by all input symbols, using a formula based on Levenshtein distance:

[0099] dis(MM input M input ) = lev(MM input M input ) / max(len(MM input ),len(M input ))

[0100] Where lev(MM) input M input ) indicates that the test cases MM input The insertion, replacement, and deletion operations are converted into a message message instance M for comparison. input The minimum number of operations required, max() indicates the maximum value, and len() indicates the length of the response message. dis(MM) input M input The ) indicates the dissimilarity between two message messages.

[0101] Calculate the MM of test cases generated by fuzzification input Find the message instance M with the smallest dissimilarity to all message instances. min_dis If the message instance belongs to the same input symbol S as the current test case.input If the condition is met, the correction is complete, proceed to the next step. Otherwise, perform the blurring operation again and repeat the above process until the condition is met.

[0102] The pseudocode for this process is shown below:

[0103]

[0104] 2.4 Test Case Execution

[0105] Send the revised test cases from 2.3 to the protocol entity program under test for execution.

[0106] 2.5 Output Symbol Matching

[0107] After the test cases are executed in section 2.4, the response message returned is obtained, and a similarity calculation is used to determine the output symbol corresponding to the response message. The similarity between the response message and all message instances corresponding to the message types identified by all output symbols is calculated using a formula based on Levenshtein distance:

[0108] dis(MR output M output )

[0109] =lev(MR output M output ) / max(len(MR output ),len(M output ))

[0110] Where lev(MR) output M output ) indicates that the response message MR will be sent. output The insertion, replacement, and deletion operations are converted into a message message instance M for comparison. output The minimum number of operations required, max() indicates the maximum value, and len() indicates the length of the response message. dis(MR output M output The ) indicates the dissimilarity between the two response messages.

[0111] Calculate the response message MR output The dissimilarity of all message instances corresponding to the message types identified by all output symbols is used to determine the output symbol S corresponding to the response message with the smallest dissimilarity. output As the response message MR output The corresponding output symbol.

[0112] The pseudocode for this process is shown below:

[0113]

[0114] 2.6 State Machine Learning

[0115] The input symbols and returned output symbols sent in this transmission are collected, and the open-source automata learning framework LearnLib is used to learn the state machine of the program under test. One of the commonly used algorithms for model learning is Angloin's L* algorithm, which uses an observation table to gradually build a complete state machine. Its main idea includes two steps: member lookup and equivalence lookup.

[0116] 2.6.1 Member Query. In Angloluin's L* model learning, a state is uniquely determined by its input / output sequence. If, for any two states, the output sequences they return are equal for all input sequences, then they are considered to be the same state. Therefore, by continuously generating input sequences and judging from the output response sequences, it is determined whether a new state is being generated. If states with identical input / output sequences are found, they are merged into the same state. During the learning process, all input and output results and their corresponding states are recorded in an observation table. This iterative learning continues until the observation table can no longer be updated (i.e., no new states are found). At this point, a hypothetical state machine is generated, which fully reflects each state in the observation table, i.e., the input / output transitions between states.

[0117] 2.6.2 Equivalence Queries. After obtaining a hypothetical state machine in the membership query phase (2.6.1), it is necessary to verify whether this state machine is consistent with the actual state machine of the protocol entity program. This verification process is called equivalence query. The equivalence query is implemented using Chow's W-method built into LearnLib: Input symbols are continuously generated and simultaneously sent to both the hypothetical state machine and the protocol entity program under test, and the consistency of their response sequences is observed. If an inconsistency is found before reaching the maximum query limit (this method sets the limit to 10,000, i.e., sending 10,000 input symbols consecutively), it indicates that the current hypothetical state machine does not match the actual protocol state machine. The input sequence that caused this inconsistency is used as a negative example, updated in the observation table, and the membership query in 2.6.1 is performed again to relearn the state machine.

[0118] This iterative learning process, as described in 2.6, continues until the query limit is reached and no counterexamples are found: if the output sequence returned by the hypothetical state machine is exactly the same as the response sequence returned by the actual protocol entity program, it indicates that the current hypothetical state machine conforms to the actual state machine, the learning ends, and it is taken as the final state machine result.

[0119] 3. Results Compilation and Analysis Stage

[0120] The state machine learned in section 2.6 is pruned and refined, and then manually analyzed to identify logical flaws. This involves the following steps:

[0121] 3.1 State Machine Arrangement

[0122] 3.1.1 Path Marking

[0123] Mark a complete normal state transition path in the state machine. This path contains all the complete interactive states of the protocol under test, and each state transition in the path conforms to the protocol specification.

[0124] 3.1.2 Redundant Path Deletion

[0125] Delete all state transition paths that cannot reach the last interactive state.

[0126] 3.2 State Machine Analysis

[0127] Specifically, the following operations are included:

[0128] 3.2.1 Normative Analysis

[0129] Examine each path in the state machine that leads to the final state, and analyze whether the state transitions in these paths conform to the specifications of the protocol under test.

[0130] 3.2.2 Redundancy Analysis

[0131] The process involves checking for redundant or unexpected states in the state machine and analyzing whether these states are problematic. If problematic states or abnormal state transitions are found, the corresponding source code is located to analyze whether there are any logical errors.

[0132] by Figure 4 For example, in the analysis and processing step 3.2: After the above operations, the paths s6->s7 and s8->s7, which cannot reach the last interactive state, are deleted, and a normal state transition path s1->s2->s3->s4->s5->9 is highlighted. There are also some paths in the state machine that complete communication interaction without going through normal state transitions. These paths may have omitted or skipped certain states compared to normal paths. Analyzing these states helps identify potential abnormal path transition problems.

[0133] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for detecting logical vulnerabilities in scalable stateful protocol entity programs, characterized in that... It includes three phases: test preparation phase, state machine learning phase, and results processing and analysis phase. During the test preparation phase, the entity program to be tested is first deployed locally, and a script file describing the traffic packets of the stateful protocol to be tested and its corresponding message types is taken as input. In the state machine learning phase, firstly, input symbols are selected from the script file, mapped to corresponding message messages, and the message messages are fuzzified to generate test cases. Next, the similarity is used to determine whether the test case still belongs to the symbol. If it does, it is sent to the program under test for execution; otherwise, it is fuzzified again for correction. Finally, the response messages after the program under test executes the test cases are collected, and the response messages are mapped to the corresponding output symbols through similarity calculation. A minimal deterministic Mealy state machine, i.e., the result state machine, is constructed using model learning for the protocol entity program under test. During the results processing and analysis phase, the learned state machine is pruned and processed to facilitate the analysis of abnormal path migrations and redundant states by testers. The state machine learning phase is implemented as follows: 3.1 Message Acquisition Randomly select input symbols from the symbol mapping table in the script file. For each selected symbol, retrieve the message message instance corresponding to the message type identified by the symbol from the input symbol mapping table in the script file. If a symbol has multiple instances, randomly select one instance as the message message to be obfuscated. 3.2 Message Obfuscation The received message messages are obfuscated, including no processing, empty processing, random field mutation, and havoc mutation operations, which change the attribute values ​​of some fields in the message messages. 3.3 Fuzzy Correction The obfuscation operation is corrected using similarity calculation; the similarity between the obfuscated test cases and all message instances corresponding to the message types identified by all input symbols is calculated using the Levenshtein distance formula: dis(MM input ,M input ) = lev(MM input ,M input ) / max(len(MM input ),len(M input )) Among them, lev(MM) input M input ) indicates that the test cases MM input The insertion, replacement, and deletion operations are converted into a message message instance M for comparison. input The minimum number of operations required, max() represents taking the maximum value, and len() represents calculating the message instance M. input Length; dis(MM) input M input The ) indicates the dissimilarity between two message instances; Calculate the MM of test cases generated by fuzzification input Find the message instance M with the smallest dissimilarity to all message instances. min_dis If the message instance M min_dis It belongs to the same input symbol S as the current test case. input If the condition is met, the correction is complete, proceed to the next step; otherwise, perform the blurring operation again and repeat the above process until the condition is met. 3.4 Test Case Execution Send the revised test cases from step 3.3 to the protocol entity program under test for execution; 3.5 Output Symbol Matching Obtain the response message returned after the program completes the test cases in step 3.4, and use similarity calculation to determine the output symbol corresponding to the response message; calculate the similarity between the response message and all message message instances corresponding to the message types identified by all output symbols, using the Levenshtein distance formula: dis(MR output ,M output ) = lev(MR output ,M output ) / max(len(MR output ),len(M output )) Where lev(MR) output M output This indicates that the response message MR will be sent. output The insertion, replacement, and deletion operations are converted into a message message instance M for comparison. output The minimum number of operations required, max() represents taking the maximum value, and len() represents calculating the message instance M. output Length; dis(MR) output M output The ) indicates the dissimilarity between two response message instances; Calculate the response message MR output The dissimilarity of all message instances corresponding to the message types identified by all output symbols is used to determine the output symbol S corresponding to the response message with the smallest dissimilarity. output As the response message MR output The corresponding output symbol; 3.6 State Machine Learning The open-source automata learning framework LearnLib is used to learn the state machine of the program under test. The input symbols sent and the output symbols returned are received. Angloluin's L* algorithm is used to construct a minimal deterministic Mealy state machine corresponding to the protocol entity program, and Chow's W-method algorithm is used to verify the state machine. If the verification fails, the state machine is reconstructed. This iterative learning is repeated until the verification is successful. At this point, the learned state machine is considered to conform to the actual program, the learning ends, and it is taken as the final state machine result.

2. The method for detecting logical vulnerabilities in scalable stateful protocol entity programs according to claim 1, characterized in that... The test preparation phase involves using existing tools to capture network traffic of the protocol under test, and using the message packets and their corresponding message types as input to the tester. This includes the following steps: 2.1 Deployment of the protocol entity program under test Deploy the protocol entity program under test, and start the protocol entity program under test and its corresponding communication terminal; 2.2 Network Traffic Capture Launch the network packet analysis tool Wireshark to capture the network traffic between the protocol entity program under test and its corresponding communication terminal; 2.3 Message Type Classification The captured network traffic is filtered and organized into different message types, while ensuring that each message type corresponds to at least one message packet instance; Then, the messages sent by the protocol entity program under test are classified into output message types; the messages sent by the communication end are classified into input message types. Finally, each message type is uniquely identified by a symbol, and the data structure of the organized message types is represented as <symbol, the set of message instances corresponding to the message type identified by the symbol>; 2.4 Script File Construction All message instances, message types, and symbols mentioned in step 2.3 are described in a script file to form a script file that describes the traffic packets of the stateful protocol under test and their corresponding message types. This script file is used as the input to the tester. The script file contains three mapping tables: a symbol mapping table, an input symbol mapping table, and an output symbol mapping table. The symbol mapping table describes the one-to-one mapping relationship between symbols and message types. The input symbol mapping table describes the one-to-many mapping relationship between all input symbols and the message instances corresponding to the message types identified by those symbols. The output symbol mapping table describes the one-to-many mapping relationship between all output symbols and the message instances corresponding to the message types identified by those symbols.

3. The method for detecting logical vulnerabilities in scalable stateful protocol entity programs according to claim 1, characterized in that... Results compilation and analysis phase: 4.1 State Machine Arrangement The constructed state machine is then organized through analysis to facilitate testers' analysis of abnormal path migrations and redundant states; specifically, this includes the following operations: 4.1.1 Path Marking Mark a complete normal state transition path in the state machine. This path contains all the complete interactive states of the protocol under test, and each state transition in the path conforms to the protocol specification. 4.1.2 Redundant Path Deletion Delete all state transition paths that cannot reach the last interactive state; 4.2 State Machine Analysis After state machine organization, the resulting state machine will contain one normal state transition path and some paths that do not follow the normal state transition but still complete communication interaction. These paths may omit or skip certain states compared to the normal path. By analyzing these states, potential abnormal path transition problems can be discovered; specifically, the following operations are included: 4.2.1 Normative Analysis Examine each path in the state machine that leads to the final state, and analyze whether the state transitions in these paths conform to the specifications of the protocol under test. 4.2.2 Redundancy Status Analysis Look for redundant or unexpected states in the state machine and analyze whether these states have problems. If problematic states or abnormal state transitions are found, find their corresponding source code to analyze whether there are logical errors.

4. A scalable logical vulnerability detection system for stateful protocol entity programs, used to execute the method described in claim 1, characterized in that... It includes a test preparation module, a state machine learning module, and a result processing and analysis module. The state machine learning module includes a mapper unit, a fuzz testing unit, and a learner unit. Test Preparation Module: Using Wireshark, network traffic between the protocol under test (DUT) and its corresponding communication program is captured. The traffic is then categorized into different message types, ensuring that each message type has at least one message packet. Each message type is abstracted as a symbol, and stored in input and output symbol alphabets based on whether the message was sent by the DUT entity program. Each alphabet contains multiple tuples in the format <symbol, the set of message packets corresponding to that symbol>. All this information is recorded in a file named symbolalphabet.xml. Mapper unit: Retrieves all tuple information from the symbolalphabet.xml file, specifically including all input symbols and their corresponding message messages in the input symbol alphabet, and all output symbols and their corresponding message messages in the output symbol alphabet; randomly selects a series of input symbols from all input symbols to form an input symbol sequence, and parses each input symbol into its corresponding input message message according to the input symbol alphabet; Fuzzing unit: Performs fuzzing operations on the received message messages, including no processing, empty processing, random field mutation, and havoc; and changes the attribute values ​​of some fields in the message messages. The fuzzy operation is corrected by similarity calculation; the corrected message is sent as a test case to the protocol entity program under test, and the response message returned by the program after executing the test case is obtained. The mapper unit maps the output symbol to the corresponding output symbol according to the output symbol alphabet; Learner Unit: The open-source automaton learning framework LearnLib is used for model learning. The learner unit receives the input symbols sent this time and the returned output symbols, uses model learning to construct a minimum deterministic Mealy state machine corresponding to the protocol entity program, and determines a final result state machine through continuous iterative learning. The final result state machine fully reflects all the behaviors of the protocol entity program under test. The results processing and analysis module prunes and processes the state machine built from the model learning process, enabling testers to analyze abnormal path migrations and redundant states.

Images