LLM end-to-end-based industrial control protocol fuzz testing script generation method

Abstract

The application relates to an LLM end-to-end-based industrial control protocol fuzzing test script generation method, which comprehensively analyzes and extracts a target protocol specification text, analyzes and generates function code JSON from a protocol traffic sample PCAP packet, performs consistency checking between the extracted result and the function code JSON, generates a fuzzing test script by applying a large language model according to the extracted protocol message format of the field source and the consistency checking result of the field example data source, wherein the field is accurate and has no loss, and the data is more targeted, finally, the fuzzing test engine is executed, the fuzzing test script is iteratively optimized through reinforcement learning, the optimal target fuzzing test script is obtained, and the accuracy and efficiency of script generation are improved.

Description

Technical Field

[0001] This invention relates to a method for generating fuzzy test scripts for industrial control protocols based on LLM end-to-end, and belongs to the field of network protocol test script generation technology. Background Technology

[0002] Industrial control protocols are a key component of network-based collaborative manufacturing. While significantly improving the efficiency of interaction, organization, control, and management of numerous devices in a manufacturing system, they also face increasingly serious security risks. Industrial control systems use proprietary protocols to achieve communication between components, thereby controlling various industrial control devices within the industrial control network. The security of these protocols is crucial to the overall security of the industrial control system. Besides mainstream standard protocols such as Modbus / TCP, OPC, and Ethernet / IP, many non-standard and proprietary protocols exist in various niche areas and among small and medium-sized manufacturers. For example, the configuration and communication between industrial control systems and host computers often rely heavily on proprietary protocols, offering high operational privileges but poor robustness, posing a significant risk to network security.

[0003] In the current network environment, new software and systems are constantly emerging, with their code size and architecture becoming increasingly large and complex, leading to a surge in the number of vulnerabilities that are difficult to discover. In the face of these ever-changing threats and complex systems, it is necessary to quickly identify and respond to newly emerging vulnerabilities.

[0004] Fuzzing is a common method used to perform robustness testing on industrial control protocols and discover security vulnerabilities. Fuzzing of industrial control protocols relies on understanding the protocol message format and interaction process. Fuzzing engines generally support mainstream standard protocols such as Modbus / TCP, OPC, and Ethernet / IP well. However, for the numerous non-standard and proprietary protocols in the industrial control field, significant manpower is required to identify and understand the protocol format and interaction process before generating fuzzing scripts, resulting in low efficiency, accuracy, and effectiveness. The core idea of ​​fuzzing is to input a large amount of randomly generated, unexpected data into the target program while simultaneously collecting and monitoring abnormal information during test case execution to discover illegal inputs that cause errors in the target program and identify its vulnerabilities.

[0005] Current fuzzing techniques for industrial control system (ICS) protocols provide two types of input to the fuzzing engine: manually constructed fuzzing scripts and ICS protocol traffic PCAP packets. Manually constructed fuzzing scripts require significant human effort to identify and understand the protocol format and interaction process before generating the scripts. The fuzzing engine then uses regular expressions to define various test patterns and automatically generate numerous test cases. The efficiency, accuracy, and effectiveness (the probability of detecting security vulnerabilities) of this approach all depend on the human's understanding of the ICS protocol. The other approach directly inputs ICS protocol traffic PCAP packets into the fuzzing engine. During testing, the engine replays the PCAP packets after modifying certain fields. These modifications are generally random and without specific targets. This method requires less human intervention, but the testing results are difficult to guarantee. Therefore, current methods for discovering security vulnerabilities in ICS protocols using fuzzing are generally inefficient. Summary of the Invention

[0006] The technical problem to be solved by this invention is to provide a method for generating fuzz test scripts for industrial control protocols based on LLM end-to-end, which integrates protocol parsing and traffic parsing to efficiently generate fuzz test scripts.

[0007] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: The present invention designs an LLM-based end-to-end industrial control protocol fuzzy test script generation method, which, for the target protocol specification text and its corresponding protocol traffic sample PCAP packet, performs the following steps A to D to generate the corresponding optimal target fuzzy test scripts;

[0008] Step A. Apply a large language model to parse the target protocol specification text, extract the protocol message format and protocol interaction process; at the same time, analyze the protocol traffic sample PCAP packets, identify each protocol session and extract the application layer data from them, generate the JSON function codes of each target protocol, and then proceed to Step B;

[0009] Step B. Apply the large language model to compare the extracted protocol message format and protocol interaction process with the generated target protocol's various function code JSONs, generate various consistency check scripts, execute consistency checks, obtain each difference point, outlier value, and boundary value, and then proceed to step C;

[0010] Step C. Based on the fact that the fields in the fuzz test script are derived from the extracted protocol message format, and the example data of the fields are derived from various differences, outliers, and boundary values, apply the large language model to generate at least one type of fuzz test script for each function code JSON of the target protocol, and then proceed to step D.

[0011] Step D. For each fuzz test script, import the fuzz test script into the fuzz test engine for execution, and iteratively optimize the fuzz test script through reinforcement learning based on the test results to obtain the corresponding optimal target fuzz test script.

[0012] As a preferred technical solution of the present invention: in step A, the protocol traffic sample PCAP packet is analyzed according to the following steps A1 to A3 to generate the various function codes JSON of the target protocol;

[0013] Step A1. Use PyShark to convert the protocol traffic sample PCAP packets into pdml format files, classify them according to protocol sessions, obtain each protocol session, and proceed to step A2;

[0014] Step A2. For each protocol session, filter out non-application layer protocol data, keep only the application layer protocol data, update the protocol session, and then proceed to step A3.

[0015] Step A3. Based on the application of the extraction of each field in the application layer protocol data of the pdml format file, train the large language model, and apply the trained large language model to extract the data information of each field in each protocol session, form the function code JSON of each protocol session, and constitute the function code JSON of the target protocol.

[0016] As a preferred technical solution of the present invention: In step B, each consistency check script is obtained, including consistency checks of protocol traffic and protocol specifications, and consistency checks of protocol requests and protocol responses. Then, each consistency check script is imported into a fuzz test engine to perform consistency checks and obtain each difference point, outlier, and boundary value.

[0017] As a preferred technical solution of the present invention: In step C, firstly, based on the analysis of the bugs found in the fuzzing test and the construction of fuzzing test script examples corresponding to each type of fuzzing test, the large language model is trained using each fuzzing test script example; then, according to the fact that the fields in the fuzzing test script come from the extracted protocol message format, and the example data of the fields come from each difference point, outlier, and boundary value, the trained large language model is applied to generate at least one type of fuzzing test script for each function code JSON of the target protocol.

[0018] As a preferred embodiment of the present invention, the fuzz test scripts of each type in step C include the following:

[0019] The structural variation fuzz test script employs variation strategies such as deleting fields, repeating fields, swapping field positions, or nested structures.

[0020] A flood attack fuzzing test script, defining parameters such as packet volume per second, concurrent connections, and test duration;

[0021] The fault injection fuzz test script injects erroneous data or counting deviations into a pre-defined specified field.

[0022] As a preferred technical solution of the present invention: in step D, for each fuzz test script, the following steps D1 to D8 are executed respectively;

[0023] Step D1. Initialize i=1, construct the fuzzing script for the i-th iteration using the fuzzing script, and proceed to step D2;

[0024] Step D2. Import the i-th iteration fuzz test script into the fuzz test engine, run the test on the target system, obtain the corresponding i-th iteration test result, and calculate the i-th iteration reward value corresponding to the i-th iteration test result according to the preset reward function, and then proceed to step D3;

[0025] Step D3. Determine whether the iteration termination condition is met. If yes, the fuzz test script for the i-th iteration is the corresponding optimal target fuzz test script; otherwise, proceed to step D4.

[0026] Step D4. Construct the i-th state vector using the i-th iteration fuzz test script and the i-th iteration test result, and proceed to step D5;

[0027] Step D5. Determine if i equals 1. If yes, proceed to step D7; otherwise, proceed to step D6.

[0028] Step D6. Construct a quadruple with the (i-1)th iteration state vector, the (i-1)th iteration optimal modification operation, the (i-1)th iteration reward value, and the ith iteration state vector, store it in the experience pool, and proceed to step D7.

[0029] Step D7. Based on the state vector of the i-th iteration, the agent selects the optimal modification operation of the i-th iteration from the preset modification operations for the fuzz test script through the policy network and applies it to the fuzz test script of the i-th iteration to obtain the fuzz test script of the (i+1)-th iteration, and then proceeds to step D8.

[0030] Step D8. The agent updates the policy network based on the experience pool, then increments the value of i by 1, and returns to step D2.

[0031] As a preferred embodiment of the present invention, the preset reward function in step D2 is as follows:

[0032] ;

[0033] in, This indicates the reward for discovering a vulnerability. Rewards indicating protocol coverage Rewards indicating testing efficiency The reward item represents the novelty of the fuzz test script. In order to represent The weight, .

[0034] As a preferred technical solution of the present invention: the iteration termination condition in step D3 is one of the following three: a preset maximum number of iterations, a preset maximum cumulative iteration processing time, or a preset upper and lower fluctuation range of the reward value obtained in step D2.

[0035] Corresponding to the above, the present invention also designs an electronic device, including a memory, a processor, and a computer program stored in the memory, characterized in that, when the processor executes the program, it implements steps A to D in the method for generating fuzzy test scripts based on LLM end-to-end industrial control protocol.

[0036] The method for generating fuzzy test scripts for industrial control protocols based on LLM end-to-end communication, as described in this invention, has the following technical advantages compared to existing technologies:

[0037] This invention designs a method for generating fuzzy test scripts for industrial control protocols based on LLM end-to-end. It integrates the extraction of target protocol specification text through parsing and analyzing protocol traffic sample PCAP packets to generate function code JSON. After a consistency check between the extracted results and the function code JSON, and based on the protocol message format extracted from the field sources and the consistency check results of the field example data sources, a large language model is applied to generate a fuzzy test script. This ensures accurate and complete field representation and more targeted data. Finally, the fuzzy test script is executed by a fuzzy testing engine, and reinforcement learning is used to iteratively optimize the fuzzy test script to obtain the optimal target fuzzy test script, thus improving the accuracy and efficiency of script generation. Attached Figure Description

[0038] Figure 1 This is a schematic diagram of the architecture of the LLM-based end-to-end industrial control protocol fuzzy test script generation method designed in this invention;

[0039] Figure 2 This is an example diagram illustrating the application of PyShark to convert and obtain pdml format files in the design and implementation of this invention. Detailed Implementation

[0040] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings.

[0041] This invention designs a method for generating fuzzy test scripts for industrial control protocols based on LLM end-to-end communication. In practical applications, such as... Figure 1 As shown, for the target protocol specification text and its corresponding protocol traffic sample PCAP packets, the following steps A to D are performed to generate the corresponding optimal target fuzz test scripts.

[0042] Step A. Apply a large language model to parse the target protocol specification text, extract the protocol message format and protocol interaction process; at the same time, analyze the protocol traffic sample PCAP packets, identify each protocol session and extract the application layer data from them, generate the JSON function codes of each target protocol, and then proceed to Step B.

[0043] Large language models possess strong semantic understanding capabilities and excel in natural language understanding, extracting structured information from complex text. Therefore, without relying on other tools, large language models, through refined prompting engineering, can parse protocol specification text and extract protocol message formats and interaction processes. Since there are many types of protocol specifications, such as RFC documents which are standardized documents describing network protocols and contain natural language text, diagrams, state machine descriptions, etc., but lack a unified structured format, large language models can automatically extract protocol specifications from RFC documents, including message formats and interaction processes (such as finite state machines, FSMs). In RFCs, protocol message formats typically include the following:

[0044] Data packet header / tail structure: field name, length, and value (such as the sequence number and flags in the TCP header).

[0045] Field semantics: For example, SYN=1 indicates a connection request.

[0046] Encoding rules: such as Big-Endian, variable-length fields.

[0047] Example data packet: Examples in hexadecimal or ASCII form (e.g., 0x00 0x01 0x02).

[0048] Protocol interaction processes are typically described using a finite state machine (FSM), which includes:

[0049] States: such as TCP's SYN_SENT and ESTABLISHED.

[0050] Events: such as receiving a SYN or sending an ACK.

[0051] Transitions: such as SYN_SENT → (received SYN+ACK) → ESTABLISHED.

[0052] Regarding the acquisition of the JSON corresponding to each function code of the protocol traffic sample PCAP packet in step A above, in actual applications, the specific design is as follows: steps A1 to A3.

[0053] Step A1. Use PyShark to convert the protocol traffic sample PCAP packets into pdml format files, and classify them according to protocol sessions to obtain each protocol session, then proceed to step A2.

[0054] PyShark can identify industrial control protocols in various scenarios and convert PCAP packets into .pdml format files, facilitating further analysis and processing by large language models. In practical applications, the obtained .pdml format files look like... Figure 2 As shown.

[0055] Step A2. For each protocol session, filter out non-application layer protocol data, specifically filtering out files in the .pdml format file with names such as "geninfo", "eth", "ip", and "tcp". <proto>The structure is modified so that only the application layer protocol data is retained, the protocol session is updated, and then the process proceeds to step A3.

[0056] Step A3. Based on the application of the extraction of each field in the application layer protocol data of the pdml format file, train the large language model, and apply the trained large language model to extract the data information of each field in each protocol session, form the function code JSON of each protocol session, and constitute the function code JSON of the target protocol.

[0057] In practical applications, the following is an example of extracting data information from various fields in each protocol session, such as the field name, type, and size.

[0058] <field name="mbtcp.trans_id" showname="Transaction Identifier: 2" size="2" pos="54" show="2" value="0002" / >

[0059] The JSON function codes that make up each protocol session are illustrated below.

[0060] { "diagnostic_request":{

[0061] "transaction_identifier.Int":2,

[0062] "transaction_identifier.Hex":"0002",

[0063] "protocol_identifier.Int":0,

[0064] "protocol_identifier.Hex":"0000",

[0065] "length.Int":6,

[0066] "1ength.Hex":0006",

[0067] "unit_identifier.Int":0,

[0068] "unit_identifier.Hex":"00",

[0069] "function_code.Int":8,

[0070] "function_code.Hex":"08",

[0071] "diagnostic_code.Int":2,

[0072] "diagnostic_code.Hex":"0002",

[0073] "data.Int":0,

[0074] "data.Hex":"0000"

[0075] },

[0076] "diagnostic_response":{

[0077] "transaction_identifier.Int":2,

[0078] "transaction_identifier.Hex":"0002",

[0079] "protocol_identifier.Int":0,

[0080] "protocol_identifier.Hex":"0000",

[0081] "length.Int":3,

[0082] "length.Hex":"0003",

[0083] "unit_identifier.Int":0,

[0084] "unit_identifier.Hex":"00",

[0085] "function_code.Int":136,

[0086] "function_code.Hex":"88",

[0087] "exception_code.Int":1,

[0088] "exception_code.Hex":"01"

[0089] }

[0090] }

[0091] Step B. Apply the large language model to compare the extracted protocol message format and protocol interaction process with the generated target protocol's various function code JSONs, and generate various consistency check scripts, including consistency checks between protocol traffic and protocol specifications, and consistency checks between protocol requests and protocol responses. Then, import each consistency check script into the fuzzing engine to perform consistency checks, obtain each difference point, outlier, and boundary value, and then proceed to Step C.

[0092] Protocol consistency checks are the process of verifying whether a system conforms to a specific protocol specification. They cover all key behaviors of the protocol, including normal processes and abnormal situations (such as error messages, timeouts, and out-of-order data). Performing protocol consistency checks is a way to improve the efficiency of protocol fuzzing. By identifying inconsistencies between the protocol implementation and the protocol specification, these inconsistencies can be effectively identified through fuzzing. A practical application example is shown below.

[0093] [ {

[0094] "name":"Validate the value of the transaction identifier field",

[0095] "condition":"diagnostic_request.transaction_identifier.Int==diagnostic_response.transaction_identifier.Int",

[0096] "description": "The transaction identifier field value of the request message is equal to the transaction identifier field value of the response message."

[0097] },

[0098] {

[0099] "name":"Verification Protocol Identifier Field Value",

[0100] "condition":"diagnostic_request.protocol_identifier.Int==diagnostic_response.protocol_identifier.Int",

[0101] "description": "The protocol identifier field value of the request message is equal to the protocol identifier field value of the response message."

[0102] },

[0103] {

[0104] "name":"Value of the verification unit identifier field",

[0105] "condition":"diagnostic_request.unit_identifier.Int==diagnostic_response.unit_identifier.Int",

[0106] "description": "The unit identifier field value of the request message is equal to the unit identifier field value of the response message."

[0107] },

[0108] {

[0109] "name":"Verification response message length field value",

[0110] "condition":"diagnostic_response.length.Int==(strlen(diagnostic_response.unit_identifier.Hex)+strlen(diagnostic_response.function_code.Hex)+strlen(diagnostic_response.exception_code.Hex))",

[0111] "description": "The length field value of the response message is equal to the sum of the Hex lengths of the unit identifier, function code, and exception code fields following the length field."

[0112] } ]

[0114] When performing fuzz testing on industrial control and IoT devices, the input to the fuzz testing engine is various fuzz testing scripts. During the fuzz testing process, the fuzz testing engine will generate a large number of test cases based on these fuzz testing scripts through various mutations, and use these test cases to implement fuzz testing.

[0115] Step C. First, based on the analysis of bugs discovered in the fuzzing test and the construction of fuzzing script examples corresponding to each type of fuzzing test, train the large language model using each fuzzing script example; then, based on the fact that the fields in the fuzzing scripts originate from the extracted protocol message format, and the example data of the fields originates from various differences, outliers, and boundary values, apply the trained large language model to generate at least one type of fuzzing script for each function code JSON of the target protocol, and then proceed to step D.

[0116] The various types of fuzzing scripts mentioned above include structural mutation fuzzing scripts, flood attack fuzzing scripts, and fault injection fuzzing scripts. Among them, structural mutation fuzzing scripts employ mutation strategies such as deleting fields, repeating fields, swapping field positions, or nested structures. In practical applications, an example of a structural mutation fuzzing script that generates the function code "Hello" for the OPC-UA protocol is as follows.

[0117] <?xml version="1.0"encoding="UTF-8"?>

[0118] <script name="OPC-UAOnTCP.Hello.StructureMutation" version="2.0.0">

[0119] <test>

[0120] <channel name="DEFAULT"transport="TCP:4840" / >

[0121] <send>

[0122] <PDU name="OPC_UA_Hello"protocol="OPC-UA"

[0123] mutate="delete([messageType,messagesize,securechannelId,clientProtocolversion,endpointurl]);repeat([messageType,messagesize,securechannelId,clientProtocolVersion,endpointurl],500);swap([messageType,messagesize,securechannelId,clientProtocolVersion,endpointurl],

[0124] [messageType,messagesize,securechannelId,clientProtocolversion,endpointurl]);nested_struct([messageType,messagesize,securechannelId,clientProtocolversion,endpointurl],OPC_UA_Hello);">

[0125] <field name="messageType"type="string"

[0126] constraint="set_value('HEL');">48 45 4c< / field>

[0127] <field name="messagesize"type="Unsigned32">00 00 01 00< / field>

[0128] <field name="securechannelId"type="Guid">

[0129] <field name="data1"type="Unsigned32">00 00 00 00< / field>

[0130] <field name="data2"type="Unsigned16">00 00< / field>

[0131] <field name="data3"type="Unsigned16">00 00< / field>

[0132] <field name="data4"type="Unsigned8[8]">00 00 00 00 00 00 00 00 00< / field>

[0133] < / field>

[0134] <field name="clientProtocolVersion"type="Unsigned32">00 00 00 01< / field>

[0135] <field name="endpointur1"type="String">

[0136] <field name="length"type="Unsigned16">00 08< / field>

[0137] <field name="value"type="string">74 63 70 3a 2f 2f 6c 6f 63 61 6C 686f 73 74 3a 34 38 34 30< / field>

[0138] < / field>

[0139] < / PDU>

[0140] < / send>

[0141] < / test>

[0142] < / script>

[0143] The specific strategies for structural variation include:

[0144] delete: Deletes the specified field;

[0145] repeat: Repeats the specified field multiple times;

[0146] swap: Exchanges the positions of two fields;

[0147] nested_struct: Nests another identical structure within a structure.

[0148] This is a flood attack fuzzing script that defines parameters such as the number of packets sent per second, the number of concurrent connections, and the test duration. In practical applications, an example of generating a flood attack fuzzing script targeting the function code "Hello" for the OPC-UA protocol is shown below.

[0149] <?xml version="1.0"encoding="UTF-8"?>

[0150] <script name="OPC-UAOnTCP.Hello.Flooding" version="2.0.0">

[0151] <test>

[0152] <channel name="DEFAULT"transport="TCP:4840" / >

[0153] <flooding parameter="100,10,150,30,1"default="off">

[0154] <send>

[0155] <PDU name="OPC-UA_Hello"protocol="OPC-UAonTCP">

[0156] <field name="message_type"type="string">HEL< / field>

[0157] <field name="chunk_type"type="Unsigned8">1< / field>

[0158] <field name="message_size"type="Unsigned32"

[0159] constraint="set_random_value(4,1024);">00 00 00 14< / field>

[0160] <field name="secure_channel_id"type="Unsigned32"

[0161] constraint="set_random_value(1,10000);">00 00 00 01< / field>

[0162] <struct name="endpoint_url"type="string">

[0163] <value>opc.tcp: / / localhost:4840< / value>

[0164] < / struct>

[0165] <struct name="receiver_buffer_size"type="Unsigned32"

[0166] constraint="set_random_value(65536,1048576);">00 01 00 00< / struct>

[0167] <struct name="sender_buffer_size"type="Unsigned32"

[0168] constraint="set_random_value(65536,1048576);">00 01 00 00< / struct>

[0169] <struct name="maximum_message_size"type="Unsigned32"

[0170] constraint="set_random_value(65536,1048576);">00 01 00 00< / struct>

[0171] <struct name="maximum_chunk_count"type="Unsigned32"

[0172] constraint="set_random_value(1,1000);">00 00 00 01< / struct>

[0173] < / PDU>

[0174] < / send>

[0175] < / flooding>

[0176] < / test>

[0177] < / script>

[0178] Flooding parameters: parameter="100,10,150,30,1"

[0179] 100: Number of data packets sent per second (100 pps);

[0180] 10: Initial number of concurrent connections;

[0181] 150: Maximum number of concurrent connections;

[0182] 30: Test duration (seconds);

[0183] 1: Incremental step size (number of new connections per second).

[0184] Fault injection fuzzing scripts inject erroneous data or counting deviations into predefined specified fields. In practical applications, such as generating a fault injection script for the ModbusTCP protocol targeting the function code WriteFileRecord, an example is shown below.

[0185] <?xml version="1.0"encoding="UTF-8"?>

[0186] <script name="NodbusTCP.WriteFileRecord.FaultInjection" version="2.0.0">

[0187] <test>

[0188] <channel name="DEFAULT"transport="TCP:502" / >

[0189] <send channel="DEFAULT">

[0190] <PDU name="NodbusTCP_writeFileRecord_Request"protocol="ModbusTCP">

[0191] <struct name="modbus_tcp_header"type="Struct">

[0192] <field name="transaction_id"type="Unsigned16"

[0193] mutate="replace(Integer.Unsigned16);">00 01< / field>

[0194] <field name="protocol_id"type="Unsigned16"

[0195] mutate="replace(Integer.Unsigned16);">00 00< / field>

[0196] <length name="length"type="Unsigned16"

[0197] scope="modbus_request.unit_identifier,modbus_request.function_code,modbus_request.reference_type,modbus_request.byte_count,modbus_request.data"

[0198] constraint="recount();"

[0199] mutate="replace(Integer.Unsigned16);miscount([-1,+1]);">00 09< / length>

[0200] <field name="unit_identifier"type="Unsigned8"

[0201] mutate="replace(Integer.Unsigned8);">01< / field>

[0202] < / struct>

[0203] <struct name="modbus_request"type="Struct">

[0204] <field name="function_code"type="Unsigned8"

[0205] mutate="replace(Integer.Unsigned8);">15< / field><!--15(0x0F)forWriteFileRecord -->

[0206] <field name="reference_type"type="Unsigned16"

[0207] mutate="replace(Integer.Unsigned16);">00 01< / field>

[0208] <field name="byte_count"type="Unsigned16"

[0209] mutate="replace(Integer.Unsigned16);miscount([-1,+1]);">00 04< / field>

[0210] <field name="data"type="string"

[0211] mutate="replace(String);inject_after(['2F','2D'],[string]);">01 02 0304< / field>

[0212] < / struct>

[0213] < / PDU>

[0214] < / send>

[0215] < / test>

[0216] < / script>

[0217] The specific fault injection strategy is as follows:

[0218] transaction_id: Replace with a different 16-bit unsigned integer;

[0219] protocol_id: Replace with a different 16-bit unsigned integer;

[0220] length: Replace with a different 16-bit unsigned integer, or you can count errors (+1 or -1).

[0221] unit_identifier: Replace with a different 8-bit unsigned integer;

[0222] function_code: Replace with a different 8-bit unsigned integer;

[0223] `reference_type`: Replace with a different 16-bit unsigned integer;

[0224] byte_count: Replace with different 16-bit unsigned integers, or you can count errors (+1 or -1).

[0225] data: Replace with a different string and inject special characters into the data.

[0226] Step D. For each fuzz test script, execute steps D1 to D8 respectively, import the fuzz test script into the fuzz test engine for execution, and iteratively optimize the fuzz test script through reinforcement learning based on the test results to obtain the corresponding optimal target fuzz test script.

[0227] First, initialize:

[0228] Define the state space: Encode the fuzzing script structure (such as field values ​​and mutation strategies) and historical test feedback (such as error types and coverage) into a state vector.

[0229] Define the action space: Design the modification operations for the fuzzing script, such as changing function codes, adjusting the range of field mutations, and injecting new sample data.

[0230] Step D1. Initialize i=1, construct the fuzzing script for the i-th iteration using the fuzzing script, and proceed to step D2.

[0231] Step D2. Import the i-th iteration fuzzing script into the fuzzing engine, run the test on the target system, obtain the corresponding i-th iteration test results (such as whether an anomaly is triggered, changes in protocol coverage), and apply the following preset reward function:

[0232] ;

[0233] Calculate the reward value for the i-th iteration corresponding to the test result of the i-th iteration, where, This indicates the reward for discovering a vulnerability. Rewards indicating protocol coverage Rewards indicating testing efficiency The reward item represents the novelty of the fuzz test script. In order to represent The weight, Then proceed to step D3.

[0234] In practical applications, rewards for vulnerability discovery as follows:

[0235] ;

[0236] in, Indicates information about the new vulnerability Severity rating (e.g., CVSS score normalized to [0,1]); Indicates new vulnerability Novelty (1 for first discovery, 0 for repeated discovery).

[0237] Rewards related to protocol coverage as follows:

[0238] ;

[0239] in, Represents the state vector Protocol coverage (such as state machine node / edge coverage). Represents the state vector Protocol coverage (such as state machine node / edge coverage). This indicates the importance weight of different coverage areas (e.g., safety-critical paths have a higher weight).

[0240] Rewards for testing efficiency as follows:

[0241] ;

[0242] ExecutionTime represents the test execution time (in seconds). Indicates the penalty for invalid tests (such as timeout, duplicate requests). Used to adjust reward items The weighting is used to balance execution speed with penalties for invalid tests. The higher the value: the more rewards. The stronger the impact on the total reward, the more the algorithm will tend to choose test scripts with fast execution speed; The smaller the value: the more likely it is to be a reward item. With the impact diminishing, the algorithm may focus more on other objectives such as vulnerabilities or coverage. In practical applications, The value needs to be adjusted through experiments.

[0243] Awards for novelty of fuzz test scripts as follows:

[0244] ;

[0245] in, This represents the script novelty score calculated using the K-nearest neighbor algorithm. Used to adjust reward items The weighting encourages the generation of diverse test scripts. The higher the value: the more rewards. The stronger the impact on the total reward, the more likely the algorithm will prioritize generating test cases that differ significantly from historical scripts. The smaller the value: the more likely it is to be a reward item. The impact on the total reward diminishes, and the algorithm may be more inclined to repeat known policies with high rewards. Typical values ​​are usually set to small values, such as... =0.1, to avoid overexploration at the expense of vulnerability discovery.

[0246] Furthermore, in practical applications, specific design .

[0247] Step D3. Determine whether the iteration termination condition is met. In practical applications, the iteration termination condition is one of the following three: the preset maximum number of iterations, the preset maximum cumulative iteration processing time, or the preset upper and lower fluctuation range of the reward value obtained in step D2. If it is met, the fuzz test script for the i-th iteration is the corresponding optimal target fuzz test script; otherwise, proceed to step D4.

[0248] Step D4. Construct the i-th state vector using the i-th iteration fuzz test script and the i-th iteration test result, and proceed to step D5.

[0249] Step D5. Determine if i is equal to 1. If yes, proceed to step D7; otherwise, proceed to step D6.

[0250] Step D6. Construct a quadruple with the (i-1)th iteration state vector, the (i-1)th iteration optimal modification operation, the (i-1)th iteration reward value, and the ith iteration state vector, store it in the experience pool, and proceed to step D7.

[0251] Step D7. Based on the state vector of the i-th iteration, the agent selects the optimal modification operation of the i-th iteration from the preset modification operations for the fuzz test script through the policy network, and applies it to the fuzz test script of the i-th iteration to obtain the fuzz test script of the (i+1)-th iteration, and then proceeds to step D8.

[0252] Step D8. The agent updates the policy network based on the experience pool, then increments the value of i by 1, and returns to step D2.

[0253] The generated fuzz test script is then imported into the fuzz test engine, and reinforcement learning is performed based on the test results to continuously iterate and optimize the fuzz test script, thereby improving the effectiveness and efficiency of fuzz testing. The application of reinforcement learning to fuzz test script optimization essentially involves the agent interacting with the test environment to continuously learn the optimal script generation strategy.

[0254] The above-mentioned design of the LLM end-to-end industrial control protocol fuzzy test script generation method is applied to a practical application to design an electronic device, including a memory, a processor, and a computer program stored in the memory. When the processor executes the program, it implements steps A to D in the LLM end-to-end industrial control protocol fuzzy test script generation method.

[0255] This invention designs a method for generating fuzzy test scripts for industrial control protocols based on LLM end-to-end. It integrates the extraction of target protocol specification text through parsing and analyzing protocol traffic sample PCAP packets to generate function code JSON. After a consistency check between the extracted results and the function code JSON, and based on the protocol message format extracted from the field sources and the consistency check results of the field example data sources, a large language model is applied to generate a fuzzy test script. This ensures accurate and complete field representation and more targeted data. Finally, the fuzzy test script is executed by a fuzzy testing engine, and reinforcement learning is used to iteratively optimize the fuzzy test script to obtain the optimal target fuzzy test script, thus improving the accuracy and efficiency of script generation.

[0256] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of the present invention.< / proto>

Claims

1. A method for generating fuzzy test scripts for end-to-end industrial control protocols based on LLM, characterized in that: For the target protocol specification text and its corresponding protocol traffic sample PCAP packets, perform the following steps A to D to generate the corresponding optimal target fuzz test scripts; Step A. Apply a large language model to parse the target protocol specification text, extract the protocol message format and protocol interaction process; at the same time, analyze the protocol traffic sample PCAP packets, identify each protocol session and extract the application layer data from them, generate the JSON function codes of each target protocol, and then proceed to Step B; Step B. Apply the large language model to compare the extracted protocol message format and protocol interaction process with the generated target protocol's various function code JSONs, generate various consistency check scripts, execute consistency checks, obtain each difference point, outlier, and boundary value, and then proceed to step C. Step C. Based on the fact that the fields in the fuzz test script originate from the extracted protocol message format, and the example data of the fields come from various differences, outliers, and boundary values, apply the large language model to generate at least one type of fuzz test script for each function code JSON of the target protocol, and then proceed to step D; Step D. For each fuzz test script, import the fuzz test script into the fuzz test engine for execution, and iteratively optimize the fuzz test script through reinforcement learning based on the test results to obtain the corresponding optimal target fuzz test script.

2. The method for generating fuzzy test scripts for industrial control protocols based on LLM end-to-end as described in claim 1, characterized in that: In step A, the protocol traffic sample PCAP packets are analyzed according to steps A1 to A3 as follows, and the function codes JSON of the target protocol are generated. Step A1. Use PyShark to convert the protocol traffic sample PCAP packets into pdml format files, classify them according to protocol sessions, obtain each protocol session, and proceed to step A2; Step A2. For each protocol session, filter out non-application layer protocol data, keep only the application layer protocol data, update the protocol session, and then proceed to step A3. Step A3. Based on the application layer protocol data extracted from the pdml format file, the large language model is trained. After training, the large language model extracts the data information of each field in each protocol session, and forms the function code JSON of each protocol session, thus constituting the JSON of each function code of the target protocol.

3. The method for generating fuzzy test scripts for industrial control protocols based on LLM end-to-end as described in claim 1, characterized in that: In step B, each consistency check script is obtained, including consistency checks between protocol traffic and protocol specifications, and consistency checks between protocol requests and protocol responses. Then, each consistency check script is imported into the fuzzing engine to perform consistency checks and obtain each difference point, outlier, and boundary value.

4. The method for generating fuzzy test scripts for industrial control protocols based on LLM end-to-end as described in claim 1, characterized in that: In step C, firstly, based on the analysis of bugs discovered by fuzzing and the construction of fuzzing script examples corresponding to each type of fuzzing test, the large language model is trained using each fuzzing script example; then, based on the fact that the fields in the fuzzing scripts originate from the extracted protocol message format, and the example data of the fields originates from various differences, outliers, and boundary values, the trained large language model is applied to generate at least one type of fuzzing script for each function code JSON of the target protocol.

5. The method for generating fuzzy test scripts for industrial control protocols based on LLM end-to-end as described in claim 1 or 4, characterized in that, The fuzz test scripts for each type in step C include the following: The structural variation fuzz test script employs variation strategies such as deleting fields, repeating fields, swapping field positions, or nested structures. A flood attack fuzzing test script, defining parameters such as packet volume per second, concurrent connections, and test duration; The fault injection fuzz test script injects erroneous data or counting deviations into a pre-defined specified field.

6. The method for generating fuzzy test scripts for industrial control protocols based on LLM end-to-end as described in claim 1, characterized in that: In step D, for each fuzz test script, the following steps D1 to D8 are executed respectively; Step D1. Initialize i=1, construct the fuzzing script for the i-th iteration using the fuzzing script, and proceed to step D2; Step D2. Import the i-th iteration fuzz test script into the fuzz test engine, run the test on the target system, obtain the corresponding i-th iteration test result, and calculate the i-th iteration reward value corresponding to the i-th iteration test result according to the preset reward function, and then proceed to step D3; Step D3. Determine whether the iteration termination condition is met. If so, the fuzz test script for the i-th iteration is the corresponding optimal target fuzz test script. Otherwise proceed to step D4; Step D4. Construct the i-th state vector using the i-th iteration fuzz test script and the i-th iteration test result, and proceed to step D5; Step D5. Determine if i is equal to 1; if yes, proceed to step D7. Otherwise proceed to step D6; Step D6. Construct a quadruple with the (i-1)th iteration state vector, the (i-1)th iteration optimal modification operation, the (i-1)th iteration reward value, and the ith iteration state vector, store it in the experience pool, and proceed to step D7. Step D7. Based on the state vector of the i-th iteration, the agent selects the optimal modification operation of the i-th iteration from the preset modification operations for the fuzz test script through the policy network and applies it to the fuzz test script of the i-th iteration to obtain the fuzz test script of the (i+1)-th iteration, and then proceeds to step D8. Step D8. The agent updates the policy network based on the experience pool, then increments the value of i by 1, and returns to step D2.

7. The method for generating fuzzy test scripts for industrial control protocols based on LLM end-to-end as described in claim 6, characterized in that, The preset reward function in step D2 is as follows: ； in, This indicates the reward for discovering a vulnerability. Rewards indicating protocol coverage Rewards indicating testing efficiency The reward item represents the novelty of the fuzz test script. In order to represent The weight, .

8. The method for generating fuzzy test scripts for industrial control protocols based on LLM end-to-end as described in claim 6, characterized in that: The iteration termination condition in step D3 is one of the following three: a preset maximum number of iterations, a preset maximum cumulative iteration processing time, or a preset upper and lower fluctuation range of the reward value obtained in step D2.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, When the processor executes the program, it implements steps A to D in the LLM-based end-to-end industrial control protocol fuzz test script generation method as described in any one of claims 1-8.

Images