An automated fuzz testing method and system for RTSP protocol of closed-source Internet of Things devices

Abstract

This invention discloses an automated fuzzing method and system for the RTSP protocol of closed-source Internet of Things (IoT) devices, relating to the field of network information security technology. The method includes: receiving relevant parameters of the target IoT device; generating a test configuration file for the target IoT device based on the relevant parameters; performing automated fuzzing of the target IoT device based on the test configuration file, wherein the fuzzing process uses integrated proxy forwarding and multi-dimensional anomaly monitoring to capture anomaly logs of the target IoT device in real time, the multi-dimensional monitoring including the protocol layer, transport layer, and network layer; parsing the anomaly logs of the target IoT device into preset structured data; annotating and deduplicating the preset structured data to obtain mutation points; performing automated replay testing on the mutation points to verify them; and obtaining vulnerability test results.

Description

Technical Field

[0001] This invention relates to the field of network information security technology, specifically to an automated fuzz testing method and system for the RTSP protocol of closed-source Internet of Things (IoT) devices. Background Technology

[0002] Real-Time Streaming Protocol (RTSP) is the de facto standard protocol for implementing streaming media control in IoT audio and video devices. It is widely used in devices such as smart cameras and network video recorders, and is closely related to people's lives. Its security directly impacts the security of devices and user privacy. The protocol itself is complex, involving various request methods, rich header fields, stateful session management, and digest authentication mechanisms. Historically, it has frequently been plagued by medium- to high-risk vulnerabilities such as buffer overflows, command injection, and authentication bypass, posing a continuous threat to device and user data security. Therefore, conducting thorough fuzz testing on the RTSP protocol of closed-source IoT devices is a crucial means of discovering unknown security vulnerabilities and assessing its security.

[0003] Currently, automated fuzz testing of the RTSP protocol for closed-source IoT devices still faces significant challenges. On the one hand, the closed-source firmware of these devices means that testing can only be performed based on a black-box approach, placing extremely high demands on the adaptability and intelligence of testing tools. On the other hand, the industry lacks mature, efficient, and specifically designed automated testing solutions for this scenario, resulting in low overall testing efficiency. Summary of the Invention

[0004] To address the shortcomings mentioned in the background section, the present invention aims to provide an automated fuzz testing method and system for the RTSP protocol of closed-source Internet of Things (IoT) devices.

[0005] Firstly, the objective of this invention can be achieved through the following technical solution: an automated fuzz testing method for the RTSP protocol of closed-source Internet of Things (IoT) devices, the method comprising the following steps: Receive relevant parameters of the target IoT device, and generate a test configuration file for the target IoT device based on the relevant parameters; wherein, the relevant parameters of the target IoT device include a pre-built structured knowledge base, a preset Peach framework general test strategy template, and pre-captured seed message messages of the target IoT device; Automated fuzz testing of the target IoT device is performed based on the test configuration file of the target IoT device. During the fuzz testing process, the abnormal logs of the target IoT device are captured in real time through integrated proxy forwarding and multi-dimensional anomaly monitoring. The multi-dimensional monitoring includes the protocol layer, transport layer and network layer. The abnormal logs of the target IoT device are parsed into pre-defined structured data. The pre-defined structured data is then labeled with mutation points and deduplicated. Mutation points are selected and then automatically replay tests are performed on the mutation points to verify them and obtain vulnerability test results.

[0006] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: the pre-built structured knowledge base includes a knowledge base based on publicly disclosed vulnerabilities and a knowledge base based on the RTSP protocol specification, as follows: The process of building a knowledge base based on publicly disclosed vulnerabilities: We crawled vulnerability entries related to the RTSP protocol from the official CVE website to obtain vulnerability information; then, we used a large language model and designed prompt words to analyze each CVE entry, determine the vulnerability type and accurately attribute the cause, locate the mutation point that triggers the vulnerability, and finally classify it according to the location of the mutation point to generate structured CVE guidance data. The construction process based on the RTSP protocol specification knowledge base is as follows: Parse the RFC 2326 standard document and automatically extract key sentences containing mandatory or prohibited semantics; call a large language model to perform secondary screening and structuring processing on the extracted sentences, retain compliance rules related to RTSP client requests, and classify and sort them according to the header fields and request methods involved, generating standardized RFC specification guidance data.

[0007] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: the preset Peach framework general test strategy template includes deep mutation for internal parameters of header fields, mutation for complete header field values, mutation for URI paths in the request line, mutation for Session header fields, mutation for authentication parameter nonce, and mutation for authentication parameter response.

[0008] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: the process of generating a test configuration file for the target IoT device based on relevant parameters of the target IoT device, as follows: The seed message packets of the target IoT device are captured in advance and combined with the preset Peach framework general test strategy template to construct a prompt word and submit it to the large language model. The large language model automatically learns and adapts to generate a set of test configuration files for the target device address, session and authentication parameters, which serve as the test configuration files for the target IoT device.

[0009] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: an automated verification process for the test configuration file of the target IoT device, including checking the validity of the XML format, the integrity of key blocks, and whether the request sequence conforms to the RTSP session logic.

[0010] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: During fuzzing, the security knowledge base in the configuration file is queried. For each seed message of the protocol to be tested, prompt words are constructed based on the associated vulnerability patterns or protocol compliance rules in the knowledge base. The large language model is then called to generate test cases with clear attack intentions. The integrated proxy forwarding process includes: By managing RTSP sessions and processing digest authentication challenge responses, ensure that test cases pass basic authentication; Parse the special control prefixes preset in the test request, and decide whether and how to update the session identifier in the request accordingly; After each mutation test, the agent will automatically initiate a complete standard RTSP session, enabling the target IoT device to return to a stable communication state.

[0011] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: the multi-dimensional anomaly monitoring includes integrated proxy forwarding and monitoring analysis, proxy-based vulnerability monitor, ICMP-based network activity monitor, and network reachability status monitor.

[0012] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: parsing the anomaly logs of the target IoT device into preset structured data. The logs from different monitoring sources are used to reconstruct the complete RTSP request messages corresponding to each test and parse them into a custom structured data model. The pre-defined structured data is annotated with variant points and deduplicated: By automatically comparing and identifying differences from the original seed message, independent protocol mutation points are separated, and logs that have not undergone mutation are removed. Based on predefined feature rules, the vulnerability type caused by each mutation point is automatically labeled, and the labeling results are intelligently clustered and deduplicated to select a representative set of test cases as mutation points. The process of automating replay testing and verification of mutation points involves dynamically generating targeted test configurations with corresponding control prefixes based on the mutation point information, and calling the Peach framework to resend the mutation request to the target device. During the replay process, device status monitoring and automatic recovery mechanisms, as well as multi-dimensional anomaly monitoring mechanisms, are used to ensure the continuity and stability of the replay verification process and to confirm whether anomalies are triggered stably.

[0013] Secondly, in order to achieve the above objectives, this invention discloses an automated fuzz testing system for the RTSP protocol of closed-source Internet of Things (IoT) devices, comprising: The parameter configuration module is used to receive relevant parameters of the target IoT device and generate a test configuration file for the target IoT device based on the relevant parameters. The relevant parameters of the target IoT device include a pre-built structured knowledge base, a preset Peach framework general test strategy template, and pre-captured seed message messages of the target IoT device. The fuzzing module is used to perform automated fuzzing tests on target IoT devices based on the test configuration files of the target IoT devices. During the fuzzing process, the abnormal logs of the target IoT devices are captured in real time through integrated proxy forwarding and multi-dimensional anomaly monitoring. The multi-dimensional monitoring includes the protocol layer, transport layer and network layer. The vulnerability verification module is used to parse the abnormal logs of the target IoT device into preset structured data, mark and deduplicate the preset structured data for mutation points, filter out mutation points, perform automated replay testing on the mutation points to verify them, and obtain vulnerability test results.

[0014] In another aspect of the present invention, in order to achieve the above-mentioned objective, a terminal device is disclosed, including a memory, a processor, and a computer program stored in the memory and capable of running on the processor. The memory stores the computer program capable of running on the processor. When the processor loads and executes the computer program, it employs an automated fuzz testing method for the closed-source Internet of Things (IoT) device RTSP protocol as described above.

[0015] The beneficial effects of this invention are: This invention utilizes a large language model, based on the Peach framework's general test strategy template and target device seed messages, to automatically generate and verify device-specific test configuration files. It constructs a dual-track security knowledge base based on publicly disclosed IoT device vulnerabilities (CVEs) and the RTSP protocol specification (RFC2326). During the test execution phase, this knowledge base guides the large language model to generate accurate test cases that violate security rules, combining this with traditional random testing to form a more comprehensive and intelligent test strategy. It also unifies the parsing of multi-source test anomaly logs into a custom structured mutation description model, achieving intelligent deduplication and automated replay verification, and generating standardized vulnerability result archives, forming a complete analysis and verification closed loop. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Figure 1 This is a schematic diagram of the method flow of the present invention; Figure 2 This is a schematic diagram of the workflow of the present invention; Figure 3 This is a schematic diagram of the system structure of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] Example 1: like Figure 1 As shown, an automated fuzz testing method for the RTSP protocol of closed-source IoT devices includes the following steps: S101: Receive relevant parameters of the target IoT device and generate a test configuration file for the target IoT device based on the relevant parameters of the target IoT device; wherein, the relevant parameters of the target IoT device include a pre-built structured knowledge base, a preset Peach framework general test strategy template, and pre-captured seed message messages of the target IoT device; The pre-built structured knowledge base includes a knowledge base based on publicly disclosed vulnerabilities and a knowledge base based on the RTSP protocol specification. The process is as follows: A knowledge base based on publicly disclosed vulnerabilities is constructed. Vulnerability entries related to the RTSP protocol are crawled from the official CVE website to obtain vulnerability information. Then, each CVE entry is analyzed using a large language model and designed prompts to determine its vulnerability type (e.g., buffer overflow, command injection) and accurately attribute its cause, locating the specific mutation point that triggers the vulnerability. Finally, structured CVE guidance data is generated by classifying the mutation points. Secondly, a knowledge base based on the RTSP protocol specification is constructed. The RFC 2326 standard document is parsed, automatically extracting key sentences containing mandatory or prohibited semantics. The large language model is then used to perform secondary filtering and structuring of the extracted sentences, retaining compliance rules related to RTSP client requests, and classifying and sorting them according to the relevant header fields and request methods to generate standardized RFC specification guidance data. This structured knowledge base will serve as a guiding resource for intelligent testing using the large language model and will continue to play a vital role.

[0019] The default Peach framework general test strategy template includes deep mutation for internal parameters of header fields (such as Authorization: nonce), mutation for complete header field values, mutation for URI paths in the request line, mutation for Session header fields, mutation for authentication parameter nonce, and mutation for authentication parameter response.

[0020] Specifically, a set of six pre-designed test strategy templates for the general Peach framework were developed and standardized. Each template targets specific test dimensions for message mutation, including deep mutation of internal parameters in header fields (such as Authorization: nonce), mutation of complete header field values, mutation of URI paths in the request line, mutation of Session header fields, mutation of the authentication parameter nonce, and mutation of the authentication parameter response. These templates define the data model, state machine, and mutation strategy, but retain device-specific parameters as abstract fields to be populated, providing a foundation for subsequent automated configuration generation for relevant target devices.

[0021] The process of generating a test configuration file for the target IoT device based on its relevant parameters is as follows: The seed message packets of the target IoT device are captured in advance and combined with the preset Peach framework general test strategy template to construct a prompt word and submit it to the large language model. The large language model automatically learns and adapts to generate a set of test configuration files for the target device address, session and authentication parameters, which serve as the test configuration files for the target IoT device.

[0022] Specifically, the system dynamically generates, verifies, and enhances device-specific configuration files. This step is performed for each specific target device under test. The pre-captured seed message packets of the target device are combined with the aforementioned general template library to construct a prompt, which is then submitted to the large language model. The large language model automatically learns and adapts to this, generating a specific test configuration file for the target device's address, session, and authentication parameters. After generation, the system performs automated verification of the test configuration file, including checking the validity of the XML format, the integrity of key blocks, and whether the request sequence conforms to RTSP session logic. If the verification passes, the system automatically adds corresponding special control prefixes (such as "all:session", "all:nonce", "ok") based on the test type (corresponding to 6 template types) to guide the proxy server in intelligent session and authentication management.

[0023] S102: Perform automated fuzz testing on the target IoT device based on the test configuration file of the target IoT device. During the fuzz testing process, the abnormal logs of the target IoT device are captured in real time through integrated proxy forwarding and multi-dimensional anomaly monitoring. The multi-dimensional monitoring includes the protocol layer, transport layer and network layer. Perform hybrid strategy protocol fuzzing. The RTSP protocol fuzzing engine executes two types of tests based on Peach's configuration file. Traditional random fuzzing: The Peach framework, based on the data model definition in the test configuration file (Pit file), randomly or rule-basedly mutates various fields of the RTSP request, generating a large number of test cases to achieve broad protocol state and input space coverage. Intelligent guided testing based on a large language model: The system queries the security knowledge base. For each seed message of the protocol to be tested, the system dynamically constructs prompts based on the associated vulnerability patterns or protocol compliance rules in the knowledge base, and calls the large language model to generate test cases with clear attack intent. For example, it guides the large language model to generate an Authorization header containing an excessively long string to test buffer overflows, or constructs an illegal Cesq sequence to test state machine logic defects. The generated intelligent test cases are dynamically updated to a dedicated configuration file (Pit file) and submitted to the Peach framework for execution.

[0024] During the fuzzing process, the security knowledge base in the configuration file is queried. For each seed message of the protocol to be tested, prompt words are constructed based on the associated vulnerability patterns or protocol compliance rules in the knowledge base, and a large language model is called to generate test cases with clear attack intentions. The integrated proxy forwarding process includes: A dedicated RTSP proxy server is deployed to form the core hub for test traffic forwarding. All test cases generated by the fuzzing engine are forwarded to the target device through this proxy. The core function of this proxy is to manage RTSP sessions and process digest authentication challenge responses, ensuring that test cases can pass basic authentication. Simultaneously, the proxy parses pre-defined special control prefixes (such as "all:session") in test requests, intelligently deciding whether and how to update dynamic fields such as session identifiers and authentication random numbers in the requests, thereby achieving precise and targeted testing of the device's specific state machine and authentication logic. Furthermore, after each mutation test, the proxy automatically initiates a complete standard RTSP session (OPTIONS, DESCRIBE, SETUP, PLAY, TEARDOWN request sequence) to help the device recover to a stable communication state. During this process, any new issues exposed by the device can be observed.

[0025] Multi-dimensional anomaly monitoring includes integrated proxy forwarding and monitoring analysis, proxy-based vulnerability monitoring, ICMP-based network activity monitoring, and network reachability status monitoring.

[0026] (1) Integrated proxy forwarding and monitoring analysis. By integrating real-time response and connection monitoring in the proxy forwarding process, anomaly detection is performed on the feedback from the target device. The proxy checks whether the response status code is abnormal, analyzes whether the response content is empty or contains abnormal data, and detects whether the connection has been reset or rejected, thereby detecting whether vulnerabilities such as buffer overflow and null pointer dereference have been triggered.

[0027] (2) Proxy-based vulnerability monitor. By capturing and analyzing HTTP requests initiated by the target device, and matching the device request path with predefined vulnerability characteristics, it detects whether a stored XSS or command injection vulnerability has been triggered.

[0028] (3) ICMP-based network activity monitor. Real-time capture of ICMP request packets actively sent by the target device to monitor whether the command injection vulnerability is successfully triggered, causing the device to initiate network connections to the outside world.

[0029] (4) Network reachability status monitor. By continuously sending network probe messages to the target device, the system monitors its service and network connectivity status in real time. When a device is detected to be unresponsive or its service is interrupted, the system automatically records the abnormal time point to assist in locating the request that caused the device to crash.

[0030] S103: Parse the abnormal logs of the target IoT device into preset structured data, mark and deduplicate the preset structured data for mutation points, filter out mutation points, perform automated replay testing on the mutation points to verify them, and obtain vulnerability test results.

[0031] The process of automating the processing of massive test exception logs to complete a precise closed loop from raw exceptions to verifiable vulnerabilities is as follows: Step 1: Structured Parsing, Mutation Point Annotation, and Deduplication of Anomaly Logs. This method first reconstructs the complete RTSP request message corresponding to each test from logs from different monitoring sources and parses it into a custom structured data model. Then, through automated comparison, it identifies differences from the original seed message, thus separating independent protocol mutation points and removing logs that have not undergone mutation. Based on predefined feature rules, the system automatically annotates each mutation point with the potential vulnerability type (such as buffer overflow, command injection, etc.), and performs intelligent clustering and deduplication on the annotation results to select a representative set of test cases.

[0032] Step 2: Automated Replay Verification. To ensure the authenticity and reproducibility of each potential vulnerability, this method performs automated replay testing on the selected mutation points. The system dynamically generates a targeted test configuration with a corresponding control prefix (such as "DESCRIBE:nonce") based on the mutation point information and calls the Peach framework to resend the mutation request to the target device. During the replay process, device status monitoring and automatic recovery mechanisms, as well as multi-dimensional anomaly monitoring mechanisms, are used to ensure the continuity and stability of the replay verification process and confirm whether anomalies are consistently triggered.

[0033] Step 3: Standardized Report Generation and Archiving. For vulnerabilities confirmed through replay verification, this method automatically aggregates all relevant data (including mutation requests, monitor logs, etc.). Subsequently, vulnerabilities are automatically classified based on feature rules (such as buffer overflows, command injection, etc.). Finally, the system organizes and generates a structured test results directory according to vulnerability type, producing a vulnerability statistics report to provide information and evidence support for security analysis.

[0034] Example 2: To achieve the above objective, based on Example 1, as follows... Figure 3 As shown, this invention discloses an automated fuzz testing system for the RTSP protocol of closed-source Internet of Things (IoT) devices, comprising: The parameter configuration module 11 is used to receive relevant parameters of the target IoT device and generate a test configuration file for the target IoT device based on the relevant parameters of the target IoT device; wherein, the relevant parameters of the target IoT device include a pre-built structured knowledge base, a preset Peach framework general test strategy template, and pre-captured seed message messages of the target IoT device; The fuzzing module 12 is used to perform automated fuzzing tests on the target IoT device based on the test configuration file of the target IoT device. During the fuzzing process, the abnormal logs of the target IoT device are captured in real time through integrated proxy forwarding and multi-dimensional anomaly monitoring. The multi-dimensional anomaly monitoring includes the protocol layer, transport layer and network layer. The vulnerability verification module 13 is used to parse the abnormal logs of the target IoT device into preset structured data, mark and deduplicate the preset structured data for mutation points, filter out mutation points, perform automated replay testing on the mutation points, and obtain vulnerability test results.

[0035] Based on the same inventive concept, this invention also provides a computer device, comprising: one or more processors, and a memory for storing one or more computer programs; the programs include program instructions, and the processor executes the program instructions stored in the memory. The processor may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. It is the computing and control core of the terminal, used to implement one or more instructions, specifically for loading and executing one or more instructions stored in a computer storage medium to implement the above-described method.

[0036] It should be further explained that, based on the same inventive concept, the present invention also provides a computer storage medium storing a computer program, which, when executed by a processor, performs the above-described method. This storage medium can be any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In the present invention, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0037] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0038] The foregoing has shown and described the basic principles, main features, and advantages of this disclosure. Those skilled in the art should understand that this disclosure is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of this disclosure. Various changes and modifications can be made to this disclosure without departing from its spirit and scope, and all such changes and modifications fall within the scope of this disclosure as claimed.

Claims

1. An automated fuzz testing method for the RTSP protocol of closed-source Internet of Things (IoT) devices, characterized in that, The method includes the following steps: Receive relevant parameters of the target IoT device, and generate a test configuration file for the target IoT device based on the relevant parameters; wherein, the relevant parameters of the target IoT device include a pre-built structured knowledge base, a preset Peach framework general test strategy template, and pre-captured seed message messages of the target IoT device; Automated fuzz testing of the target IoT device is performed based on the test configuration file of the target IoT device. During the fuzz testing process, the abnormal logs of the target IoT device are captured in real time through integrated proxy forwarding and multi-dimensional anomaly monitoring. The multi-dimensional monitoring includes the protocol layer, transport layer and network layer. The abnormal logs of the target IoT device are parsed into pre-defined structured data. The pre-defined structured data is then labeled with mutation points and deduplicated. Mutation points are selected and then automatically replay tests are performed on the mutation points to verify them and obtain vulnerability test results.

2. The automated fuzz testing method for the RTSP protocol of closed-source IoT devices according to claim 1, characterized in that, The pre-built structured knowledge base includes a knowledge base based on publicly disclosed vulnerabilities and a knowledge base based on the RTSP protocol specification, as follows: The process of building a knowledge base based on publicly disclosed vulnerabilities: We crawled vulnerability entries related to the RTSP protocol from the official CVE website to obtain vulnerability information; then, we used a large language model and designed prompt words to analyze each CVE entry, determine the vulnerability type and accurately attribute the cause, locate the mutation point that triggers the vulnerability, and finally classify it according to the location of the mutation point to generate structured CVE guidance data. The construction process based on the RTSP protocol specification knowledge base is as follows: Parse the RFC 2326 standard document and automatically extract key sentences containing mandatory or prohibited semantics; call a large language model to perform secondary screening and structuring processing on the extracted sentences, retain compliance rules related to RTSP client requests, and classify and sort them according to the header fields and request methods involved, generating standardized RFC specification guidance data.

3. The automated fuzz testing method for the RTSP protocol of closed-source IoT devices according to claim 1, characterized in that, The preset Peach framework general test strategy template includes deep mutation for internal parameters of header fields, mutation for complete header field values, mutation for URI paths in the request line, mutation for Session header fields, mutation for authentication parameter nonce, and mutation for authentication parameter response.

4. The automated fuzz testing method for the RTSP protocol of closed-source IoT devices according to claim 1, characterized in that, The process of generating a test configuration file for the target IoT device based on relevant parameters of the target IoT device is as follows: The seed message packets of the target IoT device are captured in advance and combined with the preset Peach framework general test strategy template to construct a prompt word and submit it to the large language model. The large language model automatically learns and adapts to generate a set of test configuration files for the target device address, session and authentication parameters, which serve as the test configuration files for the target IoT device.

5. The automated fuzz testing method for the RTSP protocol of a closed-source Internet of Things device according to claim 4, characterized in that, The automated verification process for the test configuration file of the target IoT device includes checking the validity of the XML format, the integrity of key blocks, and whether the request sequence conforms to the RTSP session logic.

6. The automated fuzz testing method for the RTSP protocol of a closed-source Internet of Things device according to claim 1, characterized in that, During the fuzzing process, the security knowledge base in the configuration file is queried. For each seed message of the protocol to be tested, prompt words are constructed based on the associated vulnerability patterns or protocol compliance rules in the knowledge base, and a large language model is called to generate test cases with clear attack intent. The integrated proxy forwarding process includes: By managing RTSP sessions and processing digest authentication challenge responses, ensure that test cases pass basic authentication; Parse the special control prefixes preset in the test request, and decide whether and how to update the session identifier in the request accordingly; After each mutation test, the agent will automatically initiate a complete standard RTSP session, enabling the target IoT device to return to a stable communication state.

7. The automated fuzz testing method for the RTSP protocol of closed-source IoT devices according to claim 1, characterized in that, The multi-dimensional anomaly monitoring includes integrated proxy forwarding and monitoring analysis, proxy-based vulnerability monitoring, ICMP-based network activity monitoring, and network reachability status monitoring.

8. The automated fuzz testing method for the RTSP protocol of a closed-source Internet of Things device according to claim 1, characterized in that, The step involves parsing the anomaly logs of the target IoT device into pre-defined structured data. The logs from different monitoring sources are used to reconstruct the complete RTSP request messages corresponding to each test and parse them into a custom structured data model. The pre-defined structured data is annotated with variant points and deduplicated: By automatically comparing and identifying differences from the original seed message, independent protocol mutation points are separated, and logs that have not undergone mutation are removed. Based on predefined feature rules, the vulnerability type caused by each mutation point is automatically labeled, and the labeling results are intelligently clustered and deduplicated to select a representative set of test cases as mutation points. The process of automating replay testing and verification of mutation points involves dynamically generating targeted test configurations with corresponding control prefixes based on the mutation point information, and calling the Peach framework to resend the mutation request to the target device. During the replay process, device status monitoring and automatic recovery mechanisms, as well as multi-dimensional anomaly monitoring mechanisms, are used to ensure the continuity and stability of the replay verification process and to confirm whether anomalies are triggered stably.

9. An automated fuzz testing system for the RTSP protocol of closed-source Internet of Things (IoT) devices, employing the automated fuzz testing method for the RTSP protocol of closed-source IoT devices as described in any one of claims 1 to 8, characterized in that, include: The parameter configuration module is used to receive relevant parameters of the target IoT device and generate a test configuration file for the target IoT device based on the relevant parameters. The relevant parameters of the target IoT device include a pre-built structured knowledge base, a preset Peach framework general test strategy template, and pre-captured seed message messages of the target IoT device. The fuzzing module is used to perform automated fuzzing tests on target IoT devices based on the test configuration files of the target IoT devices. During the fuzzing process, the abnormal logs of the target IoT devices are captured in real time through integrated proxy forwarding and multi-dimensional anomaly monitoring. The multi-dimensional monitoring includes the protocol layer, transport layer and network layer. The vulnerability verification module is used to parse the abnormal logs of the target IoT device into preset structured data, mark and deduplicate the preset structured data for mutation points, filter out mutation points, perform automated replay testing on the mutation points to verify them, and obtain vulnerability test results.

10. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and capable of running on the processor, characterized in that, The memory stores a computer program that can run on the processor. When the processor loads and executes the computer program, it employs an automated fuzz testing method for the closed-source Internet of Things (IoT) device RTSP protocol, as described in any one of claims 1 to 8.

Images