Industrial control private protocol vulnerability mining method based on protocol analysis

Abstract

The invention discloses an industrial control private protocol vulnerability mining method based on protocol analysis. The method comprises the steps of 1, preprocessing industrial control protocol flow data; and 2, analyzing the target protocol by using the byte change characteristics and the heuristic rule. And 3, generating a test case of the target protocol by using the analysis specification. And 4, reconstructing a protocol state machine by using the state conversion track of the flow, and guiding the protocol to reach a target state for testing. And 5, tracking the state of the detected target and monitoring and positioning the triggered vulnerability through a network. According to the method, the analysis accuracy of the private protocol specification can be effectively improved, the test case acceptance rate, the test target anomaly rate and the state coverage rate in the fuzzy test process are remarkably improved, and meanwhile, more protocol states can be efficiently tested under the condition of the same number of test cases so as to mine more potential vulnerabilities in the protocol.

Description

Technical Field

[0001] This invention belongs to the field of network information security technology, and relates to industrial control system private protocol parsing technology and vulnerability mining technology, specifically to a method for mining vulnerabilities in industrial control system private protocols based on protocol parsing. Background Technology

[0002] Industrial Control Systems (ICS) are automated systems that manage and control industrial production processes and equipment, widely used in critical infrastructure sectors such as defense, transportation, energy, and water supply. The stable operation of ICS is crucial for national security, social stability, and economic development. With the rapid development of internet technology, the industrial sector, a pillar of the national economy, is accelerating its digital transformation. However, security remains one of the major challenges in this transformation process. ICS protocols, initially designed primarily for real-time performance and stability, lacked security considerations, resulting in numerous potential vulnerabilities. In the context of the Industrial Internet, the various components of industrial control systems are inevitably exposed to external networks, posing a risk of cyberattacks. Given these potential cybersecurity threats, identifying protocol vulnerabilities before they are exploited becomes paramount.

[0003] Fuzzing is a highly versatile method for discovering protocol vulnerabilities. It involves constructing test cases and providing them to the System Under Test (SUT), then observing the system's unusual responses to uncover vulnerabilities. The mutation process of test cases must still adhere to the protocol specification to ensure they are effectively accepted by the SUT. This technique has achieved great success in discovering vulnerabilities in public ICS protocols, but it still has the following limitations when dealing with proprietary ICS protocols that lack protocol specifications:

[0004] First, existing methods struggle to accurately identify protocol formats, leading to erroneous modification of critical information fields and the generation of numerous invalid test cases. Protocol fields are typically categorized into critical fields controlling communication and non-critical fields carrying only data. Due to a lack of protocol specification guidance, existing methods apply the same mutation method to all fields. This results in erroneous modification of critical fields in test cases, causing them to be rejected by the System Under Test (SUT). Second, existing methods cannot accurately identify the protocol state space, limiting the protocol's state coverage. Due to the closed nature of the ICS environment, reverse engineering binary files is impractical. Existing methods rely on network traffic tracing to identify protocol states. Captured traffic messages rarely fully cover all formats defined in the protocol specification, making it impossible for test cases generated from raw traffic to test all protocol states. Furthermore, these methods lack means to observe protocol states, preventing the identification and utilization of protocol state information contained in abnormal response messages, thus missing opportunities to discover potential vulnerabilities. The ambiguity of certain protocol states requires sending pre-sequences, which, without protocol state machine guidance, limits the effective exploration of deep paths by the fuzzer. Existing methods can only rely on compliant paths to test the target state, which greatly limits the coverage of the protocol state. Summary of the Invention

[0005] The purpose of this invention is to design a method for mining vulnerabilities in industrial control system private protocols based on protocol parsing. This method parses the protocol specifications and state machines based on traffic to guide the generation of test cases and realize the mining of vulnerabilities in industrial control system private protocols.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] A method for discovering vulnerabilities in industrial control private protocols based on protocol parsing is described below:

[0008] Step 1: Using the original industrial control protocol traffic as input, preprocess the data packets in the traffic and extract the payload of each data packet.

[0009] Step 2: Using the payload obtained in Step 1 as input data, extract the candidate function code set of request and response messages within the threshold range based on byte similarity, and then generate all possible combinations of request and response function codes. Group them according to the values ​​of the combination sequence pairs, and use heuristic constraints to calculate the scores of the groups to identify the request and response function code fields.

[0010] Step 3: Using the byte similarity and function code position obtained in Step 2 as input data, generate two different protocol formats, and mutate the message according to the protocol formats to generate test cases.

[0011] Step 4: Using the original industrial control protocol traffic as input, the protocol's state is represented by the request and response function codes obtained in Step 2. After removing duplicate states, the protocol's state machine is constructed based on the chronological order of message transmission. When performing fuzz testing on the target under test, the protocol state machine is used to guide the transmission of test case sequences, track the target's state, and locate triggered vulnerabilities through network monitoring.

[0012] A method for discovering vulnerabilities in industrial control private protocols based on protocol parsing is characterized by including a function code parsing module, a test case generation module, and a status guidance module. The specific process is as follows:

[0013] First, the function code parsing module analyzes the traffic captured in the ICS environment, identifying protocol function codes using byte variation characteristics and packet grouping characteristics. Then, the test case generation module reconstructs the protocol format based on the parsing results, providing guidance for byte variations in test cases. Finally, the state guidance module identifies the protocol state space through function codes in request and response messages, thereby guiding fuzz testing of the target protocol state.

[0014] The key technical point of this invention is:

[0015] First, a new protocol parsing method is proposed, which accurately identifies protocol function codes by utilizing byte change characteristics and heuristic rules, thereby enabling the classification of traffic of different formats and the parsing of key fields under private protocols.

[0016] Second, a bidirectional traffic state tracking algorithm is proposed, which accurately identifies the protocol state space by tracking request and response function codes, thereby guiding fuzzy testing of the target state.

[0017] The method described in this patent can achieve efficient vulnerability discovery of proprietary industrial control protocols, and has the following advantages compared with related publicly available technologies:

[0018] I. This invention identifies the location of function codes in private protocols based on byte change characteristics and heuristic rules, eliminating the dependence of existing protocol parsing methods on datasets and prior knowledge. By guiding test case mutations through parsing specifications, it effectively improves the acceptance rate of mutated test cases on the device under test. Practice has proven that this method can generate a large number of effective test cases.

[0019] Second, this invention uses a bidirectional traffic state tracking algorithm to accurately identify the protocol state space by tracking request and response function codes, effectively ensuring that test cases can accurately reach the target protocol state for testing. Practice has proven that this method can discover more protocol states and vulnerabilities within the same number of test cases. Attached Figure Description

[0020] Figure 1This is a schematic diagram illustrating the process of identifying private protocol function codes based on traffic flow according to the present invention.

[0021] Figure 2 This is a schematic diagram illustrating the process of reconstructing the protocol format and generating test cases according to the present invention.

[0022] Figure 3 This is a schematic diagram illustrating the process of sending test cases and monitoring the target status during fuzz testing according to the present invention.

[0023] Figure 4 The figure shows the experimental results comparing the analytical accuracy of this invention with other fuzzy testing methods.

[0024] Figure 5 The figure shows the experimental results of the test case acceptance rate of this invention compared with other fuzz testing methods. Detailed Implementation

[0025] The workflow of this invention includes three stages: protocol function code parsing, test case generation, and fuzzing. In the protocol function code parsing stage, byte positions with similarity within a threshold range are extracted as a candidate function code set. Request and response function codes are then combined and grouped according to sequence pair values. Heuristic constraints are used to calculate group scores to identify function code positions. In the test case generation stage, based on the previously calculated byte similarity, dynamic bytes (D) and static bytes (S) are distinguished, and two different protocol formats, A and B, are generated. Messages are then mutated according to these protocol formats. In the fuzzing stage, the protocol state is identified based on the request and response function codes combined with the original industrial control traffic. The message transition order is determined chronologically to reconstruct the protocol state machine. A specified message sequence is sent based on the protocol state machine to perform fuzzing testing on the target state.

[0026] In the protocol function code parsing stage, the key technology of this invention lies in the identification of the function code location in the proprietary industrial control protocol, and the process is as follows: Figure 1 As shown. The input to this stage is the raw traffic dataset, and the output is the location of the request and response function codes. The specific implementation steps are as follows:

[0027] Step 1: Extract the payload portion of the request and response messages from the original industrial control traffic as the initial traffic set.

[0028] Step 2: Align the payload portion byte-wise and extract bytes at the same positions as independent sets. For each set, calculate the similarity between all possible pairs of elements in the set using the Levenshtein distance, sum and average these values ​​to obtain the similarity at the current byte position. This yields the similarity s = {s1, s2, s3, ..., s...} for each byte position. i}, where s iThis represents the similarity at the position of the i-th byte.

[0029] Step 3: Extract byte positions with similarity within the threshold range (0.4-1) as a candidate function code set, and label them as the request function code candidate set Q={Q1, Q2,…, Q…} i} and the candidate set of response function codes P={P1, P2,…, P i The byte position with a score of 1 is marked as static byte S, and the remaining positions are marked as dynamic byte D.

[0030] Step 4: Group consecutive request and response information into groups, and implement a question-and-answer mapping relationship by copying the smaller one in each group. Map the candidate function code set into (Q, P) pairs composed of positional information using a Cartesian product. For each (Q, P) pair, group the mapping information according to the specific value of the function code.

[0031] Step 5: For each (Q, P) pair forming a group, calculate the comprehensive score by evaluating heuristic constraints to determine the function code of the protocol. The (Q, P) pair with the highest score is the correct position of the function code. The specific steps are as follows:

[0032] Step 5.1, define the intra-group similarity S i Inter-group similarity S e To evaluate the byte variation characteristics of information. The Levenstein distance is used to calculate the similarity l(x) between any two pieces of information. i ,x j When x i x j Calculate S when they belong to the same group i Calculate S when they belong to different groups e Group number t is represented as Z. t The number of messages in group number t is represented by n. t The number of pairwise combinations of different groups of messages is represented by n. o Let the number of groups be n. Substitute this into the formula:

[0033] (1)

[0034] (2)

[0035] Step 5.2, define the grouping constraint S g The balance of message count is assessed by the deviation of each group's message count from the average count. The average message count for each group is expressed as... Let m be the number of all message sequences. Substituting this into the formula:

[0036] (3)

[0037] Step 5.3, define the length constraint S l To evaluate the similarity of message field structures, the maximum length and average length of the t-th message sequence are denoted as l. t-max and l t-ave Substitute into the formula:

[0038] (4)

[0039] Step 5.4, define coupling constraint S c The coupling degree of messages is evaluated by the number of types of function code sequence pairs in the request and response messages. The number of types of coupled sequence pairs is represented by n. s The total number of coupled sequence pairs is expressed as n. a :

[0040] (5)

[0041] Step 5.5, define the comprehensive constraint score S p Select S p The highest (Q, P) pair serves as the location information for the request and response function codes:

[0042] (6)

[0043] In the test case generation phase, the key technology of this invention lies in reconstructing the protocol format based on byte similarity to guide message mutation, and the process is as follows: Figure 2 As shown, the input data includes byte similarity and function code location, and the output data consists of test cases. The specific steps are as follows:

[0044] Step 1: Generate an initial format A = {(D, L1), (S, L2), ..., (D, L...} based on byte similarity and function code position. i )}, where D and S represent dynamic and static fields respectively, and L i This indicates the length of the i-th field.

[0045] Step 2: Calculate the byte similarity in the correct (Q, P) pairs to generate protocol format B for different functional types. i ={(s1, L1), (s2, L2), ..., (s i , L i )}, where B i Represents the i-th functional type, s i L represents the similarity of bytes. i This represents the i-th byte.

[0046] Step 3: Use format A to randomly add or subtract dynamic bytes of each message to generate different messages, retain the information received by SUT and insert it into the initial seed set.

[0047] Step 4: Use Format B to guide mutation, selecting Format B that corresponds to the seed information function code. i Generate test cases. Generate a random value between 0 and 1 for each byte, and apply format B. i For bytes with a similarity less than the random value, random replacement, insertion, and deletion mutation operations are performed.

[0048] In the fuzzing phase, the key technology of this invention lies in constructing a protocol state machine based on request and response function codes, guiding test cases to perform fuzzing tests on specific protocol states. The process is as follows: Figure 3 As shown, the input data includes the original industrial control flow set and function code locations, and the output data is equipment fault information. The specific steps are as follows:

[0049] Step 1: Extract the function code pair representing the protocol state n from the combination of request and response information. i Construct a state machine (directed state graph) in chronological order. Determine the protocol states n. i Merging identical nodes means storing request messages with the same function code in the same node.

[0050] Step 2: Generate a guiding sequence based on the state transition trajectory in the directed state graph, and combine it with the test cases to send to the device under test. Specifically, test case m i The function codes are consistent with the node states of the bootstrap sequence, and these specific messages combine to form the test case sequence P. i = {m0, m1, m2,…, m i The data is then sent sequentially to the device under test, allowing for a comprehensive test of every state of the protocol.

[0051] Step 3: Monitor the periodic heartbeat messages during the connection process between the device under test and the testing device to determine if the device under test is malfunctioning.

[0052] Step 4: When a heartbeat message cannot be detected within a fixed time, the device under test is determined to have an abnormality and the connection is disconnected. The system will record the state of the protocol when the abnormality occurs and the test case that triggered the abnormality.

[0053] The beneficial effects of this invention are:

[0054] I. This invention solves a key challenge in function code identification during proprietary protocol fuzzing. By utilizing byte change features and heuristic rules, it eliminates the dependence of existing protocol parsing methods on datasets and prior knowledge.

[0055] It significantly improves the accuracy of protocol state identification.

[0056] II. This invention innovatively proposes a bidirectional traffic state tracking algorithm. By tracking request and response function codes, it accurately identifies the protocol state space, thereby guiding the fuzzy processing of the target state. Experiments show that this invention outperforms state-of-the-art fuzzers in terms of test case acceptance rate, test target anomaly rate, and protocol state coverage.

[0057] Third, experiments verified the effectiveness of this invention in vulnerability discovery: During fuzzing, the same number of test cases were sent, and the number of vulnerabilities discovered and the time required by different fuzzers were compared to evaluate their vulnerability discovery capabilities. Experimental results show that compared with state-of-the-art fuzzers, this invention can discover the same vulnerabilities in a shorter time, while also discovering more vulnerabilities.

[0058] In the verification experiments, this invention uses two protocol traffic sets to verify the proposed method. The first protocol is Modbus, one of the most widely used ICS protocols, used to evaluate the fuzzing performance of the fuzzer on common protocols. Modbus uses only function codes to define specific operations between the PLC and other devices. Its simplicity allows us to easily verify the protocol parsing and vulnerability discovery capabilities of the fuzzer. The second protocol is S7comm, which implements communication between Siemens PLCs and other devices, used to evaluate the fuzzing performance of the fuzzer on proprietary protocols. Unlike Modbus, S7comm uses multi-layer function codes to support more complex operations. This diversity of formats allows this paper to further evaluate the fuzzing performance of the invention when handling complex protocols. Since there is a lack of publicly available specifications for S7comm, we use the parsing format of Wireshark as the benchmark for evaluation.

[0059] In terms of evaluation, the following metrics are used to assess protocol parsing and fuzzing capabilities: Protocol parsing experiments include homogeneity (h), completeness (c), and V-measure (v); Fuzzing experiments include Test Case Acceptance Rate (TCAR), Test Target Anomaly Rate (TTAR), Test Case Diversity (TCD), and Time to Discover Vulnerability (TFV). The specific definitions are as follows:

[0060] The protocol parsing experiment used commonly used grouping metrics to evaluate the accuracy of the grouping results, including homogeneity (h), completeness (c), and V-measure (v), which are defined as follows:

[0061] (7)

[0062] Where H(S|G) is the conditional entropy of the grouping result S under a given grouping label G, and H(S) is the entropy of the grouping result S.

[0063] (8)

[0064] Where H(S|G) is the conditional entropy of the group label S under a given grouping result G, and H(G) is the entropy of the group label G.

[0065] (9)

[0066] Where v is the harmonic mean of h and c, used to provide a comprehensive assessment of grouping accuracy.

[0067] The fuzzing experiment uses Test Case Acceptance Rate (TCAR) to measure the effectiveness of the test cases generated by the fuzzer, and the formula is as follows:

[0068] (10)

[0069] in, and These represent the number of responses received and the total number of test cases sent, respectively.

[0070] Fuzzing experiments use the Target Test Anomaly Rate (TTAR) to measure the fuzzer's ability to generate valid test cases and trigger vulnerabilities in the target system. The formula is as follows:

[0071] (11)

[0072] in, This indicates the total number of test cases sent. This indicates the number of test cases that caused the test target to malfunction.

[0073] Fuzzing experiments use Test Case Diversity (TCD) to measure the fuzzer's ability to generate diverse test cases, and the formula is as follows:

[0074] (12)

[0075] in, This represents the total number of generated test case information categories. It represents the total number of information categories in the original dataset.

[0076] Fuzzing experiments use Time to Discover Vulnerabilities (TFV) to measure the fuzzer's ability to discover vulnerabilities. The less time it takes to discover a vulnerability when sending the same number of test cases, the more effective the fuzzer is in vulnerability discovery.

[0077] To verify the improvements made by this invention in protocol parsing, we compared it with two advanced parsing methods: Netzob and NetPlier.

[0078] This paper groups, in addition to Modbus and S7comm protocols, to introduce other protocols with different format structures, including Distributed Network Protocol (DNP3), Dynamic Host Configuration Protocol (DHCP), Three-Dimensional File Transfer Protocol (TFTP), and Network Time Protocol (NTP), to verify the general performance of our heuristic-based function code parsing method. We group request messages and evaluate the accuracy of the parsing method using metrics such as homogeneity, completeness, and V-measure, benchmarked against Wireshark's parsing format.

[0079] Figure 4 The results show that the fuzzer (ICSploit) of this invention outperforms Netzob and NetPlier in terms of homogeneity, completeness, and V-measure, indicating better overall performance in function code parsing across various protocols. Regarding homogeneity, ICSploit significantly outperforms NetPlier in recognizing the S7comm protocol. This is because NetPlier defaults to placing function codes in the same position for bytes, while the S7comm protocol does not satisfy this prior condition. Our method combines all possible bytes to reduce the impact of prior knowledge on the parsing function. In terms of completeness, ICSploit's performance slightly decreases in NTP. This is because the default function code field is byte-based, while NTP function codes are actually 0.5 bytes-based. This introduces redundancy when grouping based on bytes containing function codes, reducing the completeness of classification. TFTP function codes are 2 bytes-based, but their high-order bytes are usually fixed, so the corresponding completeness index is not affected. Our method ensures that messages in the group belong to the same type as much as possible, which minimizes the impact on subsequent protocol structure generation.

[0080] State Recognition: We selected traffic containing commonly used functions in the Modbus and S7comm protocols as the dataset for our experiments. Table 1 lists the parsing results of three different methods. Since the Modbus protocol format is relatively simple, and different functions share the same format, all three methods can accurately identify the read and write functions of the Modbus protocol. However, in the more complex S7comm protocol format, the NetZob and NetPlier methods failed to identify all functions. The reason for this is that NetZob groups all messages into one group during the grouping process, thus generating a single format that cannot correctly identify S7comm functions. NetPlier, due to grouping errors, confuses read and write functions, generating the same format for both, and therefore only identifies one. Our method, ICSploit, can correctly identify the location of protocol request and response function codes and generate corresponding protocol formats for each function type, enabling the location of function codes in complex protocols.

[0081] Table 1: Experimental results comparing the parsing function of this invention with other fuzzy testing methods

[0082]

[0083] Note: ICSploit is the name of the fuzzy generator in this invention.

[0084] In summary, ICSploit improves the accuracy of function code recognition compared to existing parsing methods.

[0085] To verify the fuzzing performance of this invention, we compared the quality of test cases generated by ICSploit with three other fuzzers, BooFuzz, NCMfuzzer, and Bleem, to evaluate its basic general performance. Specifically, this was assessed based on test case acceptance rate, test target anomaly rate, and test case diversity.

[0086] Test Case Acceptance Rate (TCAR): We use TCAR to evaluate the acceptance rate of the generated test cases. For each of the four methods, we send 20,000 generated test cases to the PLC. The results are as follows: Figure 5 As shown, for both Modbus and S7comm protocols, the test cases generated by ICSploit achieved a pass rate greater than 85%, outperforming the other three methods. This is because ICSploit effectively reduces the probability of mutation in key fields within the messages, making the generated test cases more compliant with protocol specifications and easier for the SUT to accept and process.

[0087] Protocol State Coverage: We used TCD to evaluate the diversity of test cases generated by different methods to measure protocol state coverage. The results are shown in Table 2. Because the Modbus protocol has less stringent format requirements, test cases are more readily accepted, making it easier to generate different types of information. Therefore, all four methods can generate different types of messages. Among them, ICSploit generated significantly more message types than the other three methods, with state coverage improvements of 261.54%, 176.47%, and 213.33%, respectively. For the S7comm protocol, the other three methods generated a similar number of message types to the original dataset, without generating any additional message types. In contrast, ICSploit generated more test case types, with an average state coverage improvement of 70%. Higher protocol state coverage increases the probability of identifying anomalies, enabling the fuzzer to discover more potential vulnerabilities.

[0088] Table 2: Test case diversity for different fuzzers

[0089]

[0090] Note: ICSploit is the name of the fuzzy generator in this invention.

[0091] Test Target Anomaly Rate (TTAR): We used TTAR to evaluate the anomaly rate of the test targets, and the results are shown in Table 3. Compared to existing advanced fuzzers, ICSploit found up to 76 and 48 additional message anomalies in Modbus and S7comm, respectively. For the Modbus protocol, it is prone to causing device anomalies. Therefore, the anomaly rates for all four methods are relatively high. For the S7comm protocol, ICSploit's anomaly rate is significantly higher than other fuzzers. This is because S7comm is more complex, and certain states require sequential message transmission to reach. ICSploit's state guidance module helps the fuzzer reach these states and perform fuzz testing, while also exploring new states during the testing process. This allows ICSploit to more effectively discover deeper vulnerabilities.

[0092] Table 3: Test target anomaly rate for different fuzzers

[0093]

[0094] Note: ICSploit is the name of the fuzzy generator in this invention.

[0095] Vulnerability Discovery Performance: We compared ICSploit with state-of-the-art obfuscators to discover vulnerabilities on the PLC S200-smart, which supports Modbus and S7comm protocols. The vulnerability discovery capability of each method was evaluated by the number of vulnerabilities discovered and the time required. As shown in Table 4, ICSploit discovered 2 Modbus protocol vulnerabilities and 4 S7comm vulnerabilities in the PLC S200-smart, while other methods discovered only 1, 2, and 2 Modbus protocol vulnerabilities, respectively. We confirmed the existence of a zero-day vulnerability in S7comm through a rigorous verification process and submitted it to the relevant vendor. ICSploit was significantly faster than other methods in terms of vulnerability discovery time. This indicates that ICSploit can discover the same vulnerabilities in a shorter time and is capable of discovering more vulnerabilities compared to state-of-the-art obfuscators.

[0096] Table 4: Time required for this invention and other fuzzing methods to discover vulnerabilities

[0097]

[0098] Note: ICSploit is the name of the fuzzer in this invention.

Claims

1. A method for discovering vulnerabilities in industrial control private protocols based on protocol parsing, characterized in that, include: Step 1: Using the raw industrial control protocol traffic as input, preprocess the data packets in the traffic and extract the payload of each data packet; Step 2: Using the payload obtained in Step 1 as input data, extract the candidate function code set of request and response messages within the threshold range based on byte similarity, and then generate all possible combinations of request and response function codes and group them according to the values ​​of the combination sequence pairs. Calculate the group scores through heuristic constraints to identify the request and response function code fields. Step 3: Using the byte similarity and function code position obtained in Step 2 as input data, generate two different protocol formats, and mutate the message according to the protocol formats to generate test cases; Step 4: Using the original industrial control protocol traffic as input, the state of the protocol is represented by the request and response function codes obtained in Step 2. After removing duplicate states, the protocol state machine is constructed according to the order of message sending time. When performing fuzz testing on the target under test, the protocol state machine is used to guide the sending of test case sequences, track the state of the target under test, and locate the triggered vulnerabilities through network monitoring.

2. The method for mining vulnerabilities in industrial control private protocols based on protocol parsing according to claim 1, characterized in that, The specific method for identifying the request and response function codes in step 2 is as follows: Step 2.1: Align the payload portion byte-wise and extract bytes at the same positions as independent sets. For each set, use the Levenshtein distance to calculate the similarity between all possible pairs of elements in the set, and sum and average these values ​​to obtain the similarity at the current byte position. This yields the similarity s = {s1, s2, s3, ..., s...} for each byte position. i }, where s i Represents the similarity at the position of the i-th byte; Step 2.2: Extract byte positions with similarity within the threshold range (0.4-1) as a candidate function code set, and label them as the request function code candidate set Q={Q1, Q2,…, Q…} i } and the candidate set of response function codes P={P1, P2,…, P i The byte position with a score of 1 is marked as static byte S, and the remaining positions are marked as dynamic byte D; Step 2.3: Group consecutive request and response information into a group, and implement a question-and-answer mapping relationship by copying the smaller one in each group; map the candidate function code set into (Q, P) pairs composed of position information in a Cartesian product manner; for each (Q, P) pair, group the mapping information according to the specific value of the function code; Step 2.4: For each group formed by (Q, P) pairs, calculate the comprehensive score by evaluating heuristic constraints to determine the function code of the protocol; the (Q, P) pair with the highest score is the correct position of the function code.

3. The method for mining vulnerabilities in industrial control private protocols based on protocol parsing according to claim 1, characterized in that, The specific methods for generating test cases in step 3 include: Step 3.1: Generate an initial format A = {(D, L1), (S, L2), ..., (D, L...} based on byte similarity and function code position. i )}, where D and S represent dynamic and static fields respectively, and L i This indicates the length of the i-th field; Step 3.2: Calculate the byte similarity in the correct (Q, P) pairs to generate protocol format B for different functional types. i = {(s1,L1), (s2, L2),…,( s i , L i )}, where B i Represents the i-th functional type, s i L represents the similarity of bytes. i Indicates the i-th byte; Step 3.3: Use format A to randomly add or subtract dynamic bytes of each message to generate different messages, retain the information received by SUT and insert it into the initial seed set; Step 3.4: Use Format B to guide mutation, selecting Format B that corresponds to the seed information function code. i Generate test cases; generate a random value of 0-1 for each byte, and apply format B. i For bytes with a similarity less than the random value, perform random replacement, insertion, and deletion mutation operations.

4. The method for mining vulnerabilities in industrial control private protocols based on protocol parsing according to claim 1, characterized in that, The specific method for performing fuzz testing on the target under test in step 4 includes: Step 4.1: Extract the function code pair representing the protocol state n from the combination of request and response information. i Construct a state machine in chronological order; configure the protocol states n i Merging identical nodes means storing request messages with the same function code in the same node; Step 4.2: Generate a guiding sequence based on the state transition trajectory in the directed state graph, and combine it with the test cases to send to the device under test; specifically, test case m i The function codes are consistent with the node states of the bootstrap sequence, and these specific messages combine to form the test case sequence P. i = {m0, m1, m2,…, m i The data is then sent sequentially to the device under test to comprehensively test each state of the protocol. Step 4.3: Monitor the periodic heartbeat messages during the connection process between the device under test and the test device to determine if the device under test is malfunctioning. Step 4.4: When a heartbeat message cannot be detected within a fixed time, determine that the device under test has an abnormality and disconnect the connection. Record the state of the protocol when the abnormality occurs and the test case that triggered the abnormality.

Images