A method and system for fuzz testing of IEC104 protocol

Abstract

The application discloses a kind of IEC104 protocol's fuzzy testing method and system, the method includes: establishing XML generation file, XML sending file and XML monitoring file;The XML generation file is parsed, and generates fuzzy test case;The XML sending file is parsed, and the fuzzy test case is sent to the target equipment of open IEC104 protocol;The XML monitoring file is parsed, and the service state is monitored based on the configuration data of the XML sending file and the XML monitoring file with the target equipment.This application uses XML description file to configure control for the three key processes of fuzzy test case generation, test case sending and target monitoring, can carry out fuzzy test for different target equipment specification without modifying metadata analysis tool code, and according to configuration, different service state changes and system survival are alarmed, and the efficiency of suspected vulnerability discovery is improved in multiple dimensions.

Description

Technical Field

[0001] This invention relates to the field of testing technology for the IEC104 protocol, and more particularly to a fuzz testing method and system for the IEC104 protocol. Background Technology

[0002] The IEC 104 specification is an international standard widely used in industries such as power and urban rail transit. In practical applications, due to the large number of equipment manufacturers, inconsistencies in implementation among manufacturers, and differences in implementation across different environments, the IEC 104 specification has spawned numerous variants. Developing fuzzing scripts specifically for these variants is an enormous task, resulting in poor adaptability and difficulty in maintenance. Because the mechanisms for establishing and maintaining sessions differ between different specifications, using pre-generated test messages may lead to session interruptions, preventing further testing. Furthermore, traditional fuzzing only monitors system viability for the test target, offering a single dimension and low efficiency in discovering potential vulnerabilities.

[0003] Therefore, existing technologies still need to be improved and enhanced. Summary of the Invention

[0004] To address the aforementioned deficiencies in existing technologies, this invention provides a fuzz testing method and system for the IEC 104 protocol. The technical solution adopted by this invention is as follows:

[0005] In a first aspect, the present invention provides a fuzz testing method for the IEC 104 protocol, wherein the method includes:

[0006] Create XML generation files, XML sending files, and XML monitoring files;

[0007] The XML file is parsed to generate fuzz test cases;

[0008] The XML file is parsed, and the fuzz test cases are sent to the target device that supports the IEC104 protocol.

[0009] The XML monitoring file is parsed, and the service status and the target device are monitored based on the configuration data of the XML sending file and the XML monitoring file.

[0010] In one implementation, parsing the XML generated file and generating fuzz test cases includes:

[0011] Load the generated XML file and parse it using a metadata parsing tool;

[0012] Enter the initial state of the XML generated file, and generate the fuzz test cases under the Action tag under the initial state of the XML generated file.

[0013] In one implementation, parsing the XML transmission file and sending the fuzz test cases to the target device that supports the open IEC104 protocol includes:

[0014] Load the XML sending file and parse the XML sending file using a metadata parsing tool;

[0015] Enter the initial state of the XML sending file, execute the Action startup chain under the initial state of the XML sending file, and jump to the sending state;

[0016] Execute the Action tag in the sending state to send the fuzz test case to the target device with the open IEC104 protocol.

[0017] In one implementation, parsing the XML transmission file and sending the fuzz test cases to the target device with the open IEC104 protocol further includes:

[0018] Execute the operation to update the fuzzy test case number in the sending state, and send the fuzzy test case after the update is completed.

[0019] In one implementation, parsing the XML transmission file and sending the fuzz test cases to the target device with the open IEC104 protocol further includes:

[0020] Determine whether the fuzz test cases have been sent completely. If they have, stop sending.

[0021] In one implementation, parsing the XML monitoring file and monitoring the service status and the target device based on the configuration data of the XML sending file and the XML monitoring file includes:

[0022] Load the XML monitoring file, start network monitoring, and run ARP and ICMP protocol monitoring;

[0023] Determine whether the target device is alive;

[0024] If the target device is not alive, a system alarm will be triggered;

[0025] If the target device is alive, monitoring ends after the fuzz test case is sent and stopped.

[0026] In one implementation, parsing the XML monitoring file and monitoring the service status and target device based on the configuration data of the XML sending file and the XML monitoring file includes:

[0027] Load the XML monitoring file and start the logic service status monitoring;

[0028] Determine whether the business status is abnormal;

[0029] If the business status is abnormal, a system alarm will be triggered;

[0030] If the business status is normal, monitoring ends after the fuzz test case sending stops.

[0031] Secondly, embodiments of the present invention also provide a fuzz testing system for the IEC104 protocol, wherein the system includes:

[0032] The file creation module is used to create XML generated files, XML sent files, and XML monitoring files.

[0033] The test case generation module is used to parse the XML generated file and generate fuzz test cases;

[0034] The test case sending module is used to parse the XML sending file and send the fuzz test cases to the target device that has the open IEC104 protocol;

[0035] The business and equipment monitoring module is used to parse the XML monitoring file and monitor the business status and the target device based on the configuration data of the XML sending file and the XML monitoring file.

[0036] Thirdly, embodiments of the present invention also provide a terminal device, wherein the terminal device includes a memory, a processor, and an IEC104 protocol fuzzing program stored in the memory and executable on the processor, wherein when the processor executes the IEC104 protocol fuzzing program, it implements the steps of the IEC104 protocol fuzzing method described in any of the above schemes.

[0037] Fourthly, embodiments of the present invention also provide a computer-readable storage medium, wherein the computer-readable storage medium stores a fuzzing program for the IEC104 protocol, and when the fuzzing program for the IEC104 protocol is executed by a processor, it implements the steps of the fuzzing method for the IEC104 protocol as described in any of the above schemes.

[0038] Beneficial Effects: Compared with existing technologies, this invention provides a fuzzing method for the IEC104 protocol. First, this invention establishes an XML generation file, an XML sending file, and an XML monitoring file. The XML generation file is parsed to generate fuzzing test cases. The XML sending file is parsed and sent to the target device that supports the IEC104 protocol. The XML monitoring file is parsed, and the service status and the target device are monitored based on the configuration data in the XML sending and monitoring files. This invention uses XML description files for configuration control of the three key processes of fuzzing test case generation, test case sending, and target monitoring. It can perform fuzzing tests on different target device protocols without modifying the metadata parsing tool code, and provides alerts for different service status changes and system viability based on the configuration, thus improving the efficiency of discovering suspected vulnerabilities from multiple dimensions. Attached Figure Description

[0039] Figure 1 A flowchart illustrating a specific implementation of the fuzz testing method for the IEC104 protocol provided in this embodiment of the invention.

[0040] Figure 2 This is a schematic diagram of the fuzz testing method for the IEC104 protocol provided in an embodiment of the present invention.

[0041] Figure 3 This is a schematic diagram illustrating the generation principle of fuzzy test cases in the fuzzy testing method for the IEC104 protocol provided in this embodiment of the invention.

[0042] Figure 4 This is a schematic diagram illustrating the principle of sending fuzz test cases in the fuzz testing method for the IEC104 protocol provided in this embodiment of the invention.

[0043] Figure 5 This is a monitoring principle diagram of the fuzz testing method for the IEC104 protocol provided in an embodiment of the present invention.

[0044] Figure 6 This is a schematic diagram of the fuzzy testing device for the IEC104 protocol provided in an embodiment of the present invention.

[0045] Figure 7 This is a block diagram illustrating the internal structure of the terminal device provided in an embodiment of the present invention. Detailed Implementation

[0046] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0047] This embodiment provides a fuzzing method for the IEC104 protocol. Specifically, this embodiment first establishes an XML generation file, an XML sending file, and an XML monitoring file. The XML generation file is parsed to generate fuzzing test cases. The XML sending file is parsed and sent to the target device that supports the IEC104 protocol. The XML monitoring file is parsed, and the service status and the target device are monitored based on the configuration data in the XML sending and monitoring files. This embodiment uses XML description files for configuration control of the three key processes of fuzzing test case generation, test case sending, and target monitoring. It can perform fuzzing tests on different target device protocols without modifying the metadata parsing tool code, and provides alerts for different service status changes and system viability based on the configuration, improving the efficiency of discovering suspected vulnerabilities from multiple dimensions.

[0048] Exemplary methods

[0049] The fuzzy testing method of the IEC104 protocol in this embodiment can be applied to terminal devices, such as mobile phones, computers, tablets, and other intelligent terminal products. Specifically, as shown... Figure 1 As shown, the method includes the following steps:

[0050] Step S100: Create an XML generation file, an XML sending file, and an XML monitoring file.

[0051] This embodiment first establishes an XML generation file, an XML sending file, and an XML monitoring file. Then, based on these files, subsequent steps such as test case generation, test case sending, and monitoring are performed. The tags used in the XML generation file, XML sending file, and XML monitoring file defined in this embodiment are described as follows:

[0052] 1) XML generation file

[0053] Tag Tester

[0054] XML configuration file entry point.

[0055] Tag Random

[0056] Define a random number seed; if empty, no seed is set.

[0057] Global

[0058] The Global item defines a list of global variables for the test context.

[0059] Tag GlobalValue

[0060] GlobalValue is a global variable. Its id value is the variable's ID, used to associate the variable, and its value is the variable's value. All variables are global, and their values ​​can be changed through functions.

[0061] Tag DataModel

[0062] DataModel is used to define a list of data models.

[0063] Tag model

[0064] The model refers to a model definition in the data model, where the name field in the model item represents the model name.

[0065] Tag item

[0066] An item represents a segment of data within the current data model. The order of items is the same as their definition order, and multiple items constitute a complete data model.

[0067] Its attribute analysis is shown in Table 1 below:

[0068]

[0069]

[0070] Table 1

[0071] Tag State Model

[0072] The State Model defines a list of business behaviors. The protocol defines a protocol identifier.

[0073] Tag State

[0074] State defines a specific business behavior, and name represents the business name. The entry state is uniformly defined as "initial".

[0075] Tag Action

[0076] Its attribute analysis is shown in Table 2 below:

[0077]

[0078]

[0079] Table 2

[0080] Tag function

[0081] The `function` definition specifies the function to be executed under an `Action`. The execution timing depends on the `Action` type: before sending data and after receiving data. Its attributes are detailed in Table 3 below.

[0082] property meaning call Call the built-in function name parameters List of parameters passed callback The return value after calling the function (optional)

[0083] Table 3

[0084] 2) Sending files via XML

[0085] Tag Sender

[0086] Send configuration file entry.

[0087] Global

[0088] The Global item defines a list of global variables for the test context.

[0089] Global Value

[0090] GlobalValue is a global variable. Its id value is the variable's ID, used to associate the variable, and its value is the variable's actual value. All variables are global, and their values ​​can be changed through functions.

[0091] Tag State Model

[0092] StateModel defines a list of business behaviors, and the protocol property specifies the protocol type.

[0093] Tag State

[0094] State defines a specific business behavior, and here we agree that the unified entry point State is initial.

[0095] Tag Action

[0096] Its attribute analysis is shown in Table 4 below:

[0097]

[0098] Table 4

[0099] Tag function

[0100] The function defines the function to be executed under the Action. The execution time is divided into before sending data and after receiving data, depending on the Action type, as shown in Table 5.

[0101] property meaning call Call the built-in function name parameters List of parameters passed callback The return value after calling the function (optional)

[0102] Table 5

[0103] 3) XML monitoring files

[0104] Tag Detector

[0105] Detector is the entry point for XML configuration.

[0106] Target

[0107] Attribute IP: The IP address of the target device

[0108] Attribute port: The port of the target device

[0109] Tag Network

[0110] Network monitoring configuration

[0111] Tags: ARP, ICMP

[0112] ARP is the ARP monitoring configuration, and ICMP is the ICMP-ping configuration.

[0113] attribute interval: Sending interval

[0114] The `imeout` attribute specifies the timeout period.

[0115] Tag Logic

[0116] Logic is for business logic monitoring, protocol is the protocol name, and intervalType is the method of sending monitoring packets, which is divided into packetInterval and timeInterval.

[0117] Tag State

[0118] The `name` attribute is the name of the monitored service, which can be customized for differentiation.

[0119] The tag send

[0120] The definitions related to sending messages are as follows: packet is the query message to be sent, timeInterval is the sending interval, and packetInterval is the packet sending interval.

[0121] tag recv

[0122] The child tag is defined as follows:

[0123] conditions --- List of monitoring conditions

[0124] ifc --- Single condition description

[0125] cid---condition id

[0126] `range` returns the range of the message to be read. Two parameters are separated by a comma: the first parameter indicates the byte number in the message, and the second parameter indicates the step size.

[0127] value --- the decimal threshold of the condition

[0128] cmp --- comparison function, whitelist

[0129] rules --- List of rules

[0130] rid---rule ID

[0131] when --- The combination of conditions that satisfy the rule, currently only satisfying and and or. When the rule conditions are met, an alarm is triggered.

[0132] This embodiment allows for flexible configuration of the XML generation file, XML sending file, and XML monitoring file, enabling subsequent steps to generate, send, and monitor test cases based on the configured data, thus achieving flexible configuration and multi-dimensional monitoring.

[0133] Step S200: Parse the XML generated file to generate fuzz test cases.

[0134] In this embodiment, as Figure 2 As shown in the diagram, this embodiment parses the XML generated file and generates fuzz test cases. For the logic of generating fuzz test cases, the `Global` tag is used to define the variables needed in the generation process. The `model` tag under the `DataModel` tag is used to describe the test case model, serving as the template for the generated test case message. The `model` in `DataModel` defines the fuzz test case model to be generated. Items are concatenated from top to bottom to form the complete test case model. The item with the name "IEC-104-fuzz" is the fuzz generation part. Each test case generated using the `iec104_model` model consists of: payload = 68140e470000670106000100000000 + 7 bytes of fuzzy value.

[0135] Within the `StateModel` tag, the `State` tag describes the various states generated for test cases and the conditions for state transitions. All `State` tags constitute a state machine. Each `State` tag contains multiple `Action` tags to describe the operations executed sequentially and cyclically within that state. Without state transitions, a test case message is generated once per cycle within that state. When a state transition operation is involved, the state transitions to the new state. Within the `Action` tag, the `function` tag describes the operation function used under the current action, the `call` tag describes calling the tool's built-in functions, the `parameters` tag describes the parameters used by the built-in functions, and the `callback` tag describes the return value after processing by the built-in functions.

[0136] In specific implementation, such as Figure 3 As shown in the diagram, this embodiment loads the generated XML file and parses it using a metadata parsing tool. The metadata parsing tool in this embodiment is implemented using a state machine. A state machine is a tool for modeling object behavior, describing the sequence of state changes an object undergoes during its lifecycle and how it responds to various external events. After parsing is complete, the system enters the initial state of the generated XML file, and generates the fuzzy test cases under the Action tag in the initial state. The initial state contains only one Action, with action type "send" and model "iec104_model," indicating that a fuzzy test case with model "iec104_model" is generated.

[0137] Step S300: Parse the XML sending file and send the fuzz test cases to the target device with the open IEC104 protocol.

[0138] For the logic of sending fuzz test cases, except that the label `DataModel` does not need to be defined to describe the data model, the labels `Gloal` and `StateModel` serve the same purpose as in generating test cases. Specifically, as follows: Figure 2 and Figure 4As shown in the diagram, this embodiment loads the XML sending file and parses it using a metadata parsing tool. It then enters the initial state of the XML sending file, executes the Action initiation chain under the initial state, and jumps to the sending state. Next, in the sending state, it performs an operation to update the fuzz test case number, and after the update is complete, it sends the fuzz test case, thereby maintaining the business session context. Then, it executes the Action tag for sending the fuzz test case in the sending state, sending the fuzz test case to the target device with the open IEC104 protocol. Finally, it determines whether the fuzz test case has been successfully sent; if so, it stops sending.

[0139] Step S400: Parse the XML monitoring file and monitor the service status and the target device based on the configuration data of the XML sending file and the XML monitoring file.

[0140] In this embodiment, for the monitoring logic of the device under test, the tags `arp` and `icmp` under the `Network` tag describe the parameter settings for ARP and ICMP protocol monitoring. ARP (Address Resolution Protocol) is a TCP / IP protocol that obtains the physical address based on the IP address. ICMP (Internet Control Message Protocol) is a sub-protocol of the TCP / IP protocol suite. The `Logic` tag represents a set of various states for service monitoring, with each `State` tag describing the state machine for a monitoring scenario. Under the `State` tag, the `send` tag defines the monitoring packets sent and the sending interval; the `recv` tag describes the monitoring condition tuples and rules after receiving query responses; the `conditions` tag is a set of condition tuples; and the `rules` tag is a set of rules. Each rule is a combination of several condition tuples and logical operators. When a return message triggers a rule, the monitoring state machine will issue an alarm.

[0141] Specifically, such as Figure 2 and Figure 5As shown, this embodiment first loads the XML monitoring file, which is divided into two parts: Network monitoring and Business Logic status monitoring. Network monitoring defines the system monitoring parameters required during the monitoring process, including ICMP and ARP protocol monitoring. Logic status monitoring defines the parameters required for business threshold monitoring and the triggering logic for business status alarms. Multiple business monitoring states can be defined in Logic status monitoring, multiple business query messages can be set, and multiple condition tuples and rule combinations can be set. Combined with the system monitoring set in Network monitoring, the status of target devices can be monitored from multiple dimensions, greatly improving the efficiency of discovering suspected vulnerabilities. Network monitoring defines the parameters for ARP and ICMP protocol network monitoring. Logic status monitoring defines a business status monitoring scenario named "power," whose business query message is 681404000C006701050001000000000000000000000000, and a business monitoring message is sent every 5 test cases. Recv defines condition tuples and rule sets. When a returned message triggers a rule, a business rule alarm will be triggered.

[0142] In one implementation, this embodiment first initiates network monitoring and runs ARP and ICMP protocol monitoring; then it determines whether the target device is alive; if the target device is not alive, a system alarm is triggered. If the target device is alive, monitoring ends after the fuzz test case transmission stops.

[0143] In another implementation, this embodiment initiates logic service status monitoring. It then determines whether the service status is abnormal. If the service status is abnormal, a system alarm is triggered. If the service status is normal, monitoring ends after the fuzz test case sending stops.

[0144] Therefore, this embodiment adopts a novel fuzzing method based on the IEC104 protocol. It uses XML description files to configure and control the three key processes of fuzzing test case generation, test case sending, and target monitoring. It can perform fuzzing tests on different target device protocols without modifying the metadata parsing tool code, and provide alarms for different business status changes and system liveness based on the configuration, thereby improving the efficiency of discovering suspected vulnerabilities from multiple dimensions.

[0145] Exemplary device

[0146] Based on the above embodiments, the present invention also provides a fuzz testing system for the IEC104 protocol, which is jointly constructed by a hardware platform and a software platform. The hardware platform is a general-purpose Linux system host, capable of sending IEC104 messages via a network interface card (NIC). The software platform consists of the following components: a Python 3.9 development environment, an XML management system built with Flask, and a metadata parsing tool developed in Python. Specifically, as... Figure 6 As shown in the diagram, the system in this embodiment includes: a file creation module 10, a test case generation module 20, a test case sending module 30, and a service and device monitoring module 40. Specifically, the file creation module 10 is used to create an XML generation file, an XML sending file, and an XML monitoring file. The test case generation module 20 is used to parse the XML generation file and generate fuzzy test cases. The test case sending module 30 is used to parse the XML sending file and send the fuzzy test cases to the target device that supports the IEC104 protocol. The service and device monitoring module 40 is used to parse the XML monitoring file and monitor the service status and the target device based on the configuration data in the XML sending file and the XML monitoring file.

[0147] Based on the above embodiments, the present invention also provides a terminal device, the principle block diagram of which can be as follows: Figure 7 As shown, the terminal device includes a processor and memory connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage medium. The network interface of the terminal device is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a fuzzy testing method according to the IEC 104 protocol.

[0148] Those skilled in the art will understand that Figure 7 The block diagram shown is merely a partial structural diagram related to the present invention and does not constitute a limitation on the terminal device to which the present invention is applied. The specific terminal device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0149] In one embodiment, a terminal device is provided, comprising a memory, a processor, and a fuzz testing program for the IEC 104 protocol stored in the memory and executable on the processor. When the processor executes the fuzz testing program for the IEC 104 protocol, it implements the following operation instructions:

[0150] Create XML generation files, XML sending files, and XML monitoring files;

[0151] The XML file is parsed to generate fuzz test cases;

[0152] The XML file is parsed, and the fuzz test cases are sent to the target device that supports the IEC104 protocol.

[0153] The XML monitoring file is parsed, and the service status and the target device are monitored based on the configuration data of the XML sending file and the XML monitoring file.

[0154] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, operational databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual operating data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0155] In summary, this invention discloses a fuzzing method and system for the IEC104 protocol. The method includes: creating an XML generation file, an XML sending file, and an XML monitoring file; parsing the XML generation file to generate fuzzing test cases; parsing the XML sending file and sending the fuzzing test cases to a target device that supports the IEC104 protocol; and parsing the XML monitoring file and monitoring the service status and the target device based on the configuration data in the XML sending and monitoring files. This invention uses XML description files for configuration control of the three key processes of fuzzing test case generation, test case sending, and target monitoring. It can perform fuzzing tests on different target device protocols without modifying the metadata parsing tool code, and provides alerts for changes in different service statuses and system viability based on the configuration, thus improving the efficiency of discovering suspected vulnerabilities from multiple dimensions.

[0156] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A fuzz testing method for the IEC 104 protocol, characterized in that, The method includes: Create XML generation files, XML sending files, and XML monitoring files; The XML file is parsed to generate fuzz test cases; The XML file is parsed, and the fuzz test cases are sent to the target device that supports the IEC104 protocol. The XML monitoring file is parsed, and the service status and the target device are monitored based on the configuration data of the XML sending file and the XML monitoring file. The step of parsing the XML file and sending the fuzz test cases to the target device with the open IEC104 protocol includes: Load the XML sending file and parse the XML sending file using a metadata parsing tool; Enter the initial state of the XML sending file, execute the Action startup chain under the initial state of the XML sending file, and jump to the sending state; Execute the Action tag in the sending state for sending the fuzz test case, and send the fuzz test case to the target device with the open IEC104 protocol; The step of parsing the XML file and sending the fuzz test cases to the target device with the open IEC104 protocol also includes: Perform the update fuzz test case number operation in the sending state, and send the fuzz test case after the update is completed; The XML monitoring file is divided into two parts: Network monitoring and Business Logic status monitoring. The Network monitoring defines the system monitoring parameters required during the monitoring process, including ICMP and ARP protocol monitoring. The Logic status monitoring defines the parameters required for business threshold monitoring, as well as the triggering logic for business status alarms. The Logic status monitoring defines multiple business monitoring states, sets multiple business query messages, and sets multiple condition tuples and rule combinations to work in conjunction with the system monitoring set by the Network monitoring to monitor the target device status from multiple dimensions.

2. The fuzz testing method for the IEC104 protocol according to claim 1, characterized in that, The step of parsing the XML generated file and generating fuzz test cases includes: Load the generated XML file and parse it using a metadata parsing tool; Enter the initial state of the XML generated file, and generate the fuzz test cases under the Action tag under the initial state of the XML generated file.

3. The fuzz testing method for the IEC 104 protocol according to claim 1, characterized in that, The step of parsing the XML file and sending the fuzz test cases to the target device with the open IEC104 protocol also includes: Determine whether the fuzz test cases have been sent completely. If they have, stop sending.

4. The fuzz testing method for the IEC 104 protocol according to claim 1, characterized in that, The step of parsing the XML monitoring file and monitoring the service status and the target device based on the configuration data of the XML sending file and the XML monitoring file includes: Load the XML monitoring file, start network monitoring, and run ARP and ICMP protocol monitoring; Determine whether the target device is alive; If the target device is not alive, a system alarm will be triggered; If the target device is alive, monitoring ends after the fuzz test case is sent and stopped.

5. The fuzz testing method for the IEC 104 protocol according to claim 4, characterized in that, The step of parsing the XML monitoring file and monitoring the service status and target devices based on the configuration data of the XML sending file and the XML monitoring file includes: Load the XML monitoring file and start the logic service status monitoring; Determine whether the business status is abnormal; If the business status is abnormal, a system alarm will be triggered; If the business status is normal, monitoring ends after the fuzz test case sending stops.

6. A fuzz testing system for the IEC 104 protocol, characterized in that, The system includes: The file creation module is used to create XML generated files, XML sent files, and XML monitoring files. The test case generation module is used to parse the XML generated file and generate fuzz test cases; The test case sending module is used to parse the XML sending file and send the fuzz test cases to the target device that has the open IEC104 protocol; The business and equipment monitoring module is used to parse the XML monitoring file and monitor the business status and the target device based on the configuration data of the XML sending file and the XML monitoring file. The step of parsing the XML file and sending the fuzz test cases to the target device with the open IEC104 protocol includes: Load the XML sending file and parse the XML sending file using a metadata parsing tool; Enter the initial state of the XML sending file, execute the Action startup chain under the initial state of the XML sending file, and jump to the sending state; Execute the Action tag in the sending state for sending the fuzz test case, and send the fuzz test case to the target device with the open IEC104 protocol; The step of parsing the XML file and sending the fuzz test cases to the target device with the open IEC104 protocol also includes: Perform the update fuzz test case number operation in the sending state, and send the fuzz test case after the update is completed; The XML monitoring file is divided into two parts: Network monitoring and Business Logic status monitoring. The Network monitoring defines the system monitoring parameters required during the monitoring process, including ICMP and ARP protocol monitoring. The Logic status monitoring defines the parameters required for business threshold monitoring, as well as the triggering logic for business status alarms. The Logic status monitoring defines multiple business monitoring states, sets multiple business query messages, and sets multiple condition tuples and rule combinations to work in conjunction with the system monitoring set by the Network monitoring to monitor the target device status from multiple dimensions.

7. A terminal device, characterized in that, The terminal device includes a memory, a processor, and an IEC104 protocol fuzzing program stored in the memory and executable on the processor. When the processor executes the IEC104 protocol fuzzing program, it implements the steps of the IEC104 protocol fuzzing method as described in any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a fuzzing program for the IEC104 protocol. When the fuzzing program for the IEC104 protocol is executed by a processor, it implements the steps of the fuzzing method for the IEC104 protocol as described in any one of claims 1-5.

Images