A JSON data fuzzing method for robot WebRTC real-time communication
By constructing a corpus in robot WebRTC communication and generating behavioral signatures using external feedback, combined with multi-strategy mutation and fault detection, the difficulty of discovering deep anomaly paths in JSON data testing under black-box environment is solved, the ability to reproduce faults is improved, and the security and stability of the communication link are enhanced.
Patent Information
- Authority / Receiving Office
- CN Β· China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SICHUAN UNIV
- Filing Date
- 2026-02-25
- Publication Date
- 2026-06-12
AI Technical Summary
In real-time WebRTC communication for robots, existing fuzz testing methods struggle to effectively guide JSON data testing in black-box or weakly observable environments, resulting in low efficiency in discovering deep anomaly paths, difficulty in reproducing fault samples, and impact on the security and stability of the communication link.
By establishing a test communication environment, building an initial corpus, generating behavioral signatures using external observable feedback, and combining corpus management and multi-strategy mutation, we can improve test coverage and fault sample retention capabilities. We can generate test cases using byte-level and JSON structure-aware mutations, and perform sample saving and restart/reconnection processing during fault detection.
It improves the efficiency of deep anomaly path discovery in black-box environments, enhances fault reproduction capabilities, reduces the risk of crashes and denial-of-service attacks, and strengthens robot network security and system operation stability.
Smart Images
Figure CN122195824A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of software testing and network communication security testing technology, specifically to a JSON data fuzzing test method for real-time communication of robots using WebRTC (Web Real-Time Communication). Background Technology
[0002] With the widespread use of robots and other intelligent terminals in applications such as remote control, status reporting, and voice / data interaction, a low-latency, interactive real-time communication link is needed between the terminal and the control end. WebRTC is widely used in such scenarios due to its real-time communication capabilities and can carry business data transmission through data channels. Because robots typically face limitations in computing power and resources, network environment fluctuations, and sensitivity to control link latency, the stability of the communication and message processing modules on the WebRTC link directly impacts business continuity and control availability.
[0003] In the aforementioned real-time communication scenarios, the business layer often uses JSON (JavaScript Object Notation) to carry control commands, status data, parameter configurations, file fragments, or audio blocks. Because JSON messages can have diverse field types, large differences in length boundaries, deep object nesting levels, uncertain array sizes, and complex exception handling, the number of branches in message parsing, field validation, resource allocation, and error handling logic increases significantly. This can lead to problems such as crashes, freezes, resource exhaustion, abnormal state machine transitions, or incorrect parsing of control commands. Furthermore, the WebRTC link involves connection negotiation, timeout, and retransmission mechanisms. The external manifestations of anomalies can include timeouts, disconnections, and abnormal responses, further increasing the complexity of problem localization and reproduction.
[0004] For security testing and defect discovery of network protocols and systems, existing technologies commonly employ static analysis, dynamic analysis, and fuzz testing. Among these, fuzz testing has become a frequently used defect discovery method due to its high degree of automation, low dependence on source code, and wide applicability. In protocol / message fuzzing schemes, one approach is to generate test cases by mutating message content based on a corpus; another approach involves introducing protocol format constraints, syntactic / semantic constraints, or other knowledge to guide the mutation process, thereby reducing invalid test cases and improving testing efficiency.
[0005] However, directly applying the aforementioned general fuzzing scheme to "robot WebRTC real-time communication data channel business JSON data" may still have the following shortcomings: First, the robot end or embedded target is often a black box or difficult-to-insert environment, making it difficult to obtain the coverage information required for traditional coverage-guided fuzzing, resulting in a lack of effective guidance for test case selection and corpus evolution. Second, blind or random mutation has a low hit rate on complex JSON structures (deep nesting, secondary serialization parameters, long fields / fragmented fields, etc.), easily generating a large number of invalid inputs that cannot enter deep processing logic, resulting in low utilization of test resources. Third, WebRTC session state and link mechanism affect external observable feedback, making it difficult to reliably identify "new paths" and "reproducible fault triggering conditions," thereby affecting the efficiency of crash reproduction and regression verification.
[0006] Therefore, a JSON data fuzzing testing method is needed for robot WebRTC real-time communication scenarios. Without relying on target instrumentation, this method utilizes externally observable execution feedback to construct approximate metrics that can be used for guidance. Combined with corpus management and multi-strategy mutation, it improves the efficiency of deep anomaly path discovery and the ability to retain and reproduce fault samples. This reduces the dependence on target environment modification and improves test coverage. Consequently, it helps to discover potential security and anomaly handling defects in the robot's real-time communication link and JSON message processing module in advance, reducing the risk of crashes and denial-of-service attacks triggered by abnormal inputs, and improving the network security level and overall operational security of the robot system. Summary of the Invention
[0007] The technical problem this invention aims to solve is to provide a JSON data fuzzing method that allows for approximate guidance without obtaining true coverage in black-box or weakly observable environments for real-time WebRTC communication of robots. This improves the efficiency of discovering deep anomaly paths and enhances the retention and reproducibility of fault-triggered samples. The technical solution is as follows:
[0008] A method for fuzz testing JSON data for real-time WebRTC communication with robots includes the following steps:
[0009] S1: Establish test communication environment: Establish WebRTC connection and data channel to enable the test terminal to send business JSON data to the target terminal and receive feedback.
[0010] S2: Obtain message templates and build an initial corpus: Obtain the initial JSON message format, field meanings, and value ranges as the initial corpus;
[0011] S3: Corpus Entry Management and Energy Scheduling Seed Selection: Maintain entry attributes for each corpus entry, including hash identifier, execution time, depth value, energy value, and whether it has been tested; and assign selection weights according to the entry attributes to select seed entries;
[0012] S4: Multi-strategy mutation generation test cases: Perform byte-level mutation, combination mutation, and JSON structure-aware mutation on the selected seed entries;
[0013] S5: Test Case Execution and External Feedback Collection: Send the generated test cases to the target service on the robot side via the WebRTC data channel and collect execution feedback; the execution feedback includes: execution time, response length, and exception type;
[0014] S6: Approximate guidance and corpus evolution: Discretize and bucket the collected execution time and response length, and combine them with the exception type to generate a behavior signature; when the behavior signature is new, trigger the test case of the behavior signature to be added to the corpus and persisted, and at the same time update its depth value and energy value to drive corpus evolution.
[0015] S7: Fault Detection and Sample Retention: When a robot-side target crashes or becomes unavailable, the trigger sample is saved and deduplicated by hash. In automatic mode, the target is restarted and the WebRTC connection is rebuilt before testing continues. In non-automatic mode, testing is stopped and reproduction information is output.
[0016] Compared with the prior art, the present invention has the following beneficial effects:
[0017] This invention utilizes externally observable feedback to construct behavioral signatures as approximate guiding indicators in challenging or black-box environments, promoting corpus evolution and improving the efficiency of deep anomaly path discovery. Through corpus management and energy scheduling, high-value samples are given more mutation opportunities, reducing the proportion of invalid inputs and improving the efficiency of long-term testing. By deduplicating and saving faulty samples and employing an optional restart and reconnection mechanism, the efficiency of fault reproduction and regression verification is improved. Furthermore, it helps to identify potential security vulnerabilities in the robot's WebRTC communication link and JSON message processing module in advance, reducing the risk of crashes or denial-of-service attacks triggered by abnormal inputs, thereby enhancing robot network security and system operational safety. Attached Figure Description
[0018] Figure 1 This is a schematic diagram of the overall process of the method of the present invention.
[0019] Figure 2 This diagram illustrates the corpus management, weighted scheduling selection, multi-strategy mutation generation, external feedback collection, and corpus evolution closed loop in the testing method of this invention.
[0020] Figure 3 This is a schematic diagram of the fault detection, sample saving and deduplication, and restart and reconnection process in this invention. Detailed Implementation
[0021] The technical method of the present invention will be further described below with reference to the embodiments and accompanying drawings.
[0022] The flowchart of the JSON data fuzzing test method for real-time WebRTC communication of this invention is shown below. Figure 1 As shown (corresponding to S1 to S7), the specific steps include:
[0023] S1: Establish a test communication environment:
[0024] First, establish a WebRTC connection and data channel to enable the test server to send business JSON data to the target server and receive feedback. Specifically:
[0025] S11: Establish a WebRTC real-time communication connection between the test end and the robot end, and open the data channel;
[0026] S12: Determine the data channel JSON message processing link of the object to be tested as the robot end, including at least message reception, JSON parsing, field validation and business execution entry.
[0027] S2: Obtain message templates and build an initial corpus:
[0028] Then, an initial corpus is built, which contains at least two types of business JSON seed messages to cover different message processing branches.
[0029] We first need to obtain the initial JSON message format, field meanings, and value ranges as an initial corpus. This can be provided directly or obtained through reverse engineering. Details are as follows:
[0030] S21 (Reverse Template Acquisition): In the absence of public interface documentation or incomplete interface documentation, reverse analysis is performed on the business interaction of the robot's WebRTC data channel to extract the field structure, field meaning, and value constraints of the JSON message and form an initial message template.
[0031] S22 (Constructing Seed Corpus): Construct multiple types of business JSON messages as initial seeds based on the message template, including at least two of the following: heartbeat / keep-alive, subscription, control request, data reporting, and file or audio segmentation.
[0032] S23 (Serialization into the corpus): Serialize the seed message into a byte sequence and add it to the corpus as a corpus entry, and set the initial energy value for the seed corpus.
[0033] After completing the above preparations, the cyclical testing phase consisting of S3 to S7 is entered: scheduling and seeding of the corpus, mutation generation, execution feedback, and corpus evolution; when a fault occurs, the fault handling process is entered and recovery or cessation is performed.
[0034] Figure 2 The closed-loop testing process of the fuzzing test of the present invention is shown to be executed in a loop in the order of "corpus management β weighted scheduling seed selection β multi-strategy mutation generation β execution sending and feedback collection β behavior signature generation and judgment β branch backflow" (corresponding to S3 to S6).
[0035] S3: Corpus Entry Management and Energy Scheduling Selection:
[0036] The detailed steps are as follows:
[0037] S31: Maintain entry attributes for each corpus entry. Entry attributes should include at least the following: hash identifier, execution time, depth value, energy value, and whether it has been tested.
[0038] S32: Assign selection weights based on entry attributes and select seed entries; the selection weights are at least positively correlated with energy values, positively correlated with the "insufficiently tested" state, and given additional weights to shallow depth entries.
[0039] (1);
[0040] (2);
[0041] (3);
[0042] Where the subscript i represents the attribute of the i-th corpus entry, Let i be the energy value of the i-th corpus. The performance score for the i-th corpus is... Whether the i-th corpus has been sufficiently tested. Let be the depth value of the i-th corpus. The selection weight value for the i-th corpus (Equation (1) is the formula for calculating the selection weight); The formulas for whether it is being tested and the depth value calculation are (Equation (2) and Equation (3)).
[0043] The hash flag in the entry attributes is used for deduplication; the execution time is for subsequent S5 feedback collection. The depth value indicates which generation of mutation the current corpus originated from, and the energy value is one of the weights on which the corpus might be selected. Giving extra weight to shallow depth entries is to quickly expand to different corpora, rather than making too many modifications to corpora of the same type. Both the energy value and the depth value have initial values ββset, and the hash flag is used to remove duplicate entries.
[0044] S4: Multi-strategy mutation generation test cases:
[0045] S41 (Byte-level mutation): Perform at least one of the following on the seeded entry: bit-flip mutation, arithmetic mutation, interesting value replacement mutation, block insertion / deletion / overwrite, and dictionary insertion / replacement mutation.
[0046] S42 (Combined Mutation): Generates complex input by concatenating multiple basic mutations with random numbers, and optionally performs fragment splicing on different corpus entries to construct new combined inputs;
[0047] S43 (JSON Structure-Aware Mutation): When the input can be parsed into a JSON object, perform type replacement, field deletion, deep nesting construction, or ultra-long string construction on the fields; when parsing fails, it degenerates into byte-level mutation to ensure test continuity.
[0048] Interesting values ββ(special test values) refer to a set of pre-collected boundary values, extreme values, or typical error values ββused to replace the original field during mutation, making it easier to trigger abnormal branches.
[0049] S5: Test Case Execution and External Feedback Collection
[0050] S51: Send test cases to the target service on the robot side via the WebRTC data channel.
[0051] S52: Collect external observable execution feedback, which includes at least: execution time, response length, and exception type.
[0052] S6: Approximate Guidance and Corpus Evolution:
[0053] The execution time, response length, and exception type are the three feedback indicators that need to be recorded in step S5. Step S6 discretizes these three indicators by binning them and then assembles them into a behavior signature. If this signature has not appeared before, it is considered that this input has triggered a new external behavior. If it is a new behavior, the input is added to the corpus to continue to mutate and expand around it. If it is not a new behavior, the attributes or weights of the corpus entries are updated.
[0054] S61: Discretize the execution time and response length into buckets, and combine them with the exception type to generate a behavior signature.
[0055] The bucketing rule can be described as follows: Discretize the execution time (exec_time) in units of 0.1 seconds (e.g., 0.00β0.09 seconds into bucket 0, 0.10β0.19 seconds into bucket 1, and 0.30β0.39 seconds into bucket 3), and discretize the response length (response_len) in units of 100 bytes (e.g., 0β99 bytes into bucket 0, 100β199 bytes into bucket 1, and 300β399 bytes into bucket 3). Then, use "time bucket number: length bucket number: error type" to form the behavior signature (e.g., 3:0:timeout).
[0056] S62: When the behavior signature is a new behavior signature, the test cases that trigger the new behavior signature will be added to the corpus and persisted, and their depth and energy values ββwill be updated at the same time; when the behavior signature is not new, only the statistics will be updated.
[0057] S7: Fault Detection and Sample Retention
[0058] S71: When a robot-side target crash or unavailable is detected, save the trigger sample and deduplicate it by hash.
[0059] S72: In automatic mode, restart the target and rebuild the WebRTC connection, then return to S3 to continue execution; in non-automatic mode, stop the test and output the information needed to reproduce the results.
[0060] Figure 3 This invention illustrates fault detection and recovery of the tested program in fuzz testing, and provides a detailed handling process for faults such as termination of the tested WebRTC service or abnormal exit of the tested program caused by sending incorrect format messages or exceptions.
[0061] The specific process is as follows: Figure 3 As shown in S7, the fault detection process includes: target state detection (periodic detection), crash or unavailability determination, fault handling (saving samples and deduplicating), and automatic recovery or stopping the output of reproduction information. If no crash or unavailability is determined, the normal operating state is maintained and testing continues; if a crash or unavailability is determined, the test sample that triggered the fault is saved and deduplicated before saving. Then, it is determined whether to automatically recover: if automatic recovery is performed, a stop cleanup and restart recovery are executed; if automatic recovery is not performed, testing is stopped and the reproduction information is output before ending.
[0062] In summary, this invention addresses the challenges of effective guided testing of the JSON message processing link in robot WebRTC real-time communication scenarios under black-box or difficult-to-insert conditions, including the difficulty in discovering deep anomaly paths and reproducing fault samples stably. It provides a fuzzy testing method based on corpus management and weighted scheduling, combined with multi-strategy mutation, and utilizes externally observable execution feedback to generate behavioral signatures to drive corpus evolution. Furthermore, it improves long-term testing stability through fault detection, fault sample saving and deduplication, and optional automatic recovery mechanisms. Through these technical solutions, this invention can improve test coverage for complex JSON inputs and abnormal link conditions without relying on target instrumentation, enhance the efficiency of deep anomaly triggering and fault reproduction, thereby strengthening the network security level and system operational security of the robot communication link.
Claims
1. A method for fuzz testing JSON data for real-time WebRTC communication of robots, characterized in that, Includes the following steps: S1: Establish test communication environment: Establish WebRTC connection and data channel to enable the test terminal to send business JSON data to the target terminal and receive feedback. S2: Obtain message templates and build an initial corpus: Obtain the initial JSON message format, field meanings, and value ranges as the initial corpus; S3: Corpus Entry Management and Energy Scheduling Selection: Maintain entry attributes for each corpus entry, including hash identifier, execution time, depth value, energy value, and whether it has been tested; And select seed entries by assigning selection weights based on the entry attributes; S4: Multi-strategy mutation generation test cases: Perform byte-level mutation, combination mutation, and JSON structure-aware mutation on the selected seed entries; S5: Test Case Execution and External Feedback Collection: Send the generated test cases to the target service on the robot side via the WebRTC data channel and collect execution feedback; the execution feedback includes: execution time, response length, and exception type; S6: Approximate guidance and corpus evolution: Discretize and bucket the collected execution time and response length, and combine them with the exception type to generate a behavior signature; when the behavior signature is new, trigger the test case of the behavior signature to be added to the corpus and persisted, and at the same time update its depth value and energy value to drive corpus evolution. S7: Fault Detection and Sample Retention: When a robot-side target crashes or becomes unavailable, the trigger sample is saved and deduplicated by hash. In automatic mode, the target is restarted and the WebRTC connection is rebuilt before testing continues. In non-automatic mode, testing is stopped and reproduction information is output.
2. The JSON data fuzzing method for real-time WebRTC communication of robots according to claim 1, characterized in that, Step S1 is as follows: S11: Establish a WebRTC real-time communication connection between the test end and the robot end, and open the data channel; S12: Determine the data channel JSON message processing link of the object to be tested as the robot end, specifically including message reception, JSON parsing, field validation and business execution entry.
3. The JSON data fuzzing method for real-time WebRTC communication of robots according to claim 1, characterized in that, Step S2 is as follows: S21: Reverse Template Acquisition: By performing reverse analysis on business interactions, extract the field structure, field meaning, and value constraints of JSON messages to form an initial message template; S22: Construct seed corpus: Construct multi-type business JSON messages as initial seeds based on the message template; the multi-type business JSON messages include at least two of the following: heartbeat / keep-alive, subscription, control request, data reporting, and file or audio segmentation. S23: Serialization and insertion: Serialize the seed message into a byte sequence and add it to the corpus as a corpus entry, setting the initial energy value for the seed corpus.
4. The JSON data fuzzing method for real-time WebRTC communication of robots according to claim 1, characterized in that, In step S3, the hash identifier is used for deduplication of corpus entries, the depth value indicates which generation of mutation the corpus entry was generated from, and the energy value is used to indicate the weight of the corpus entry being selected for mutation. The selection weights are positively correlated with energy values ββand with insufficiently tested states, and additional weights are given to shallow depth entries.
5. The JSON data fuzzing method for real-time WebRTC communication of robots according to claim 1, characterized in that, In step S4, the byte-level mutation includes at least one of bit-flipping mutation, arithmetic mutation, interesting value replacement mutation, block insertion, deletion, overwriting, and dictionary insertion and replacement mutation; The combined mutations include generating complex inputs by concatenating multiple basic mutations with random numbers, and constructing new combined inputs by splicing fragments from different corpus entries. The JSON structure-aware mutation performs type replacement, field deletion, deep nesting construction, or ultra-long string construction on fields when the input can be parsed into a JSON object, and degenerates into byte-level mutation when parsing fails.
6. The JSON data fuzzing method for real-time WebRTC communication of robots according to claim 1, characterized in that, In step S6, when the behavior signature is not new, only the statistical information of the corresponding corpus entry is updated, that is, the corpus entry attributes or weights.
7. The JSON data fuzzing method for real-time WebRTC communication of robots according to claim 1, characterized in that, The fault detection process in step S7 includes: target state detection, crash or unavailability determination, fault handling, and automatic recovery or cessation of output reproduction information; If it is determined that no crash or unavailability has occurred, then maintain normal operation and continue testing; If a crash or unavailability is determined to have occurred, the test sample that triggered the failure is saved and deduplicated before saving. Then determine whether to automatically restore: If automatic recovery is enabled, then stop the cleanup and restart the recovery process. If it does not recover automatically, the test will stop and output the reproduction information before ending.