Vulnerability detection and optimization methods, devices and equipment for robot operating systems

Abstract

This invention relates to the field of program vulnerability detection, and discloses an optimized method, apparatus, and device for vulnerability detection in a robot operating system. The method includes: obtaining registration information through a registration tracker and obtaining execution information of the robot operating system through a runtime tracker; the registration information includes attributes related to callback functions and the type of the callback functions; constructing a callback trace based on the registration information and the execution information; analyzing the callback trace to verify whether a new system state has been generated; generating new test cases based on the new system state, and using the new test cases as test cases for the next round of iterations. This invention solves the problem of traditional fuzzy testing for robot operating system vulnerabilities being coarse and incomplete.

Description

Technical Field

[0001] This invention relates to the field of program vulnerability detection technology, and in particular to a vulnerability detection optimization method, apparatus and equipment for robot operating systems. Background Technology

[0002] Robot Operating Systems (ROS) are widely used in industrial and academic environments and have become the de facto standard for developing robot systems. Currently, tens of thousands of devices supported by ROS are integrated into our daily lives. A robot operating system mainly consists of two parts: the robot operating system application and the robot operating system runtime. It can be deployed on various operating systems, including Linux, Mac, and various real-time operating systems.

[0003] The robot operating system runtime is the core, providing basic functions such as message passing and callback scheduling. Its top layer includes client library implementations, such as C++, Python, and Java user libraries, providing application programming interface (API) implementations in different languages ​​for developing high-level applications. Below this top layer is the robot operating system client library (general user library), which is the standard interface to these APIs, providing basic functions such as system scheduling and callback management. To ensure compatibility with different Data Distribution Service (DDS) implementations, the general user library relies on the robot operating system middleware interface (RMW) as an intermediary bridge. This makes communication between distributed components more efficient. The robot operating system applications deploy various user-specific applications, each designed to perform a specific task. Each application typically consists of multiple nodes, each with callbacks that communicate via topics and services. A node is responsible for a single modular purpose; its callbacks are functions invoked in response to specific events (such as receiving messages or service requests), managed by the C++ user library executor. These callbacks are scheduled according to the real-time requirements of the robot operating system. The executor also ensures consistent interaction with message events.

[0004] Fuzz testing, as a highly efficient vulnerability discovery technique, has successfully uncovered countless critical vulnerabilities in various systems. It generates test cases by randomly selecting seeds that conform to the input specifications of the system under test, and uses various anomaly detectors to monitor for potential vulnerabilities. Furthermore, some fuzz testing engines use coverage as a guide to generate more effective test cases. This approach not only improves the comprehensiveness of the testing but also enhances the ability to discover vulnerabilities. By checking whether currently executed test cases trigger new code, higher mutation priority is given to these test cases, thereby testing deeper layers of the system's code.

[0005] However, because robot operating systems focus on performing specific tasks, their control flow is relatively fixed, resulting in limited variability in code coverage. This limitation may prevent previous code coverage tests from fully capturing the complex and diverse state transitions within the robot operating system. For example, different inputs can trigger drastically different behavioral patterns in the system, which may not be adequately reflected in traditional code coverage tests, such as callback duration and message throughput, yet still result in the same code coverage. Therefore, traditional code coverage-based fuzzing methods may not be effective enough for robot operating systems, failing to fully explore their potential security vulnerabilities. Thus, a more suitable fuzzing method for robot operating systems is needed. Summary of the Invention

[0006] This invention provides an optimized method, apparatus, and device for vulnerability detection in robot operating systems, which solves the problem that traditional fuzzy testing for robot operating system vulnerabilities is coarse and incomplete.

[0007] An optimization method for vulnerability detection in robot operating systems includes the following in a fuzzing loop for each robot operating system:

[0008] Registration information is obtained through a registration tracker, and execution information of the robot's operating system is obtained through a runtime tracker; the registration information includes attributes related to the callback function and the type of the callback function.

[0009] A callback tracing is constructed based on the registration information and the execution information;

[0010] The callback tracing is analyzed to verify whether a new system state has been generated;

[0011] New test cases are generated based on the new system state, and these new test cases are used as test cases in the next round of the loop.

[0012] In one embodiment of the present invention, the registration information obtained through the registration tracker and the execution information of the robot operating system obtained through the runtime tracker specifically include: installing a first tracker in the C++ user library layer of the robot operating system and installing a second tracker in the general user library layer; when the user application starts the callback registration process, recording a first callback attribute through the first tracker and writing the first callback attribute into a data retrieval buffer; when the callback registration process propagates to the general user library layer, recording a second callback attribute through the second tracker and writing the second callback attribute into a data retrieval buffer; when the executor of the C++ user library layer schedules the execution of the callback function, obtaining the data generated during the execution of the robot operating system through the runtime tracker, aggregating it, and storing it in a specific data retrieval buffer.

[0013] In one embodiment of the present invention, the step of constructing a callback trace based on the registration information and the execution information specifically includes: processing the registration data into structured information; the structured information includes a callback sequence number and processing procedures at different layers; calculating a latency index based on the execution information in each fuzzing loop, the latency index including callback latency and message latency; merging the callback latency and the message latency index to construct a callback trace, the callback trace being represented as two different vectors, wherein one vector represents the callback latency and the other vector represents the message latency.

[0014] In one embodiment of the present invention, the step of calculating the delay index based on the execution information in each fuzzing loop specifically includes: determining the callback delay based on the callback sequence number, the handler, and the first timestamp; and determining the message delay based on the callback sequence number, the message buffer size, and the second timestamp.

[0015] In one embodiment of the present invention, the callback sequence number is generated by a hash function and serves as a unique identifier to distinguish various callback functions; the first timestamp includes the timestamp when the callback function is called, the timestamp when the callback function starts execution, and the timestamp when the callback function finishes execution; the second timestamp includes the timestamps for message publication and subscription.

[0016] In one embodiment of the present invention, analyzing the callback tracing to verify whether a new system state has been generated specifically includes: analyzing the callback tracing and identifying a new system state based on judgment indicators; the judgment indicators include:

[0017] (1) Determine whether the callback tracing contains a new execution sequence;

[0018] (2) Determine whether the delay of a specific callback deviates from the established average benchmark value by more than a first preset threshold;

[0019] (3) Determine whether the throughput of a specific message deviates from the average baseline by a second preset threshold;

[0020] A new system state is determined when at least one of the judgment indicators is true.

[0021] In one embodiment of the present invention, the runtime tracker includes: a third tracker for recording the handler of the target callback; a fourth tracker for recording the timestamp of the callback start time; a fifth tracker for recording the timestamp of the callback end time; and a sixth tracker for recording communication information, the communication information including the size of the incoming message buffer and timestamps related to publish and subscribe activities.

[0022] A vulnerability detection and optimization device for a robot operating system, comprising:

[0023] The information collection module is used to obtain registration information through the registration tracker and execution information of the robot operating system through the runtime tracker; the registration information includes attributes related to the callback function and the type to which the callback function belongs;

[0024] A callback tracing construction module is used to construct callback traces based on the registration information and the execution information;

[0025] The new state determination module is used to analyze the callback tracing and verify whether a new system state has been generated.

[0026] The test case generation module is used to generate new test cases based on the new system state, and to use the new test cases as test cases for the next round of the loop.

[0027] A vulnerability detection and optimization device for a robot operating system, comprising:

[0028] At least one processor; and,

[0029] The memory is connected to the at least one processor via a bus; wherein,

[0030] The memory stores instructions that can be executed by the at least one processor to implement the method as described in any of the above embodiments.

[0031] A non-volatile storage medium storing computer-executable instructions, which are executed by a processor to implement the method as described in any of the above embodiments.

[0032] This invention provides a method, apparatus, and device for vulnerability detection and optimization in a robot operating system, which has at least the following beneficial effects:

[0033] First, by instrumenting trackers into the robot operating system, system behavior can be collected more systematically. Based on the collected system behavior information, the state transitions and input processing of the robot operating system are guided, generating high-quality payloads. During testing, by continuously analyzing callback traces, inputs triggering new system states are identified, and these are used to guide the generation of high-quality payloads. This feedback-based test case generation method can produce higher-quality inputs, thereby improving the efficiency of fuzz testing of the robot operating system. Firstly, by considering state transitions, this invention can explore a wider range of system behaviors than traditional code coverage-based testing methods, enabling more comprehensive fuzz testing. Secondly, by identifying new system states, a higher vulnerability detection rate is provided, increasing the likelihood of discovering critical vulnerabilities. Finally, feedback-based payload generation optimizes the testing process, making fuzz testing faster and more accurate, improving testing efficiency and reliability. Attached Figure Description

[0034] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:

[0035] Figure 1 A detailed architecture diagram of ROSFUZZ provided in this embodiment of the invention;

[0036] Figure 2 A schematic diagram illustrating the steps of a vulnerability detection and optimization method for a robot operating system provided in an embodiment of the present invention;

[0037] Figure 3 A basic workflow diagram of the tracker provided in this embodiment of the invention;

[0038] Figure 4 This is a schematic diagram illustrating the process of identifying a new system state provided in an embodiment of the present invention;

[0039] Figure 5 A complete load generation process diagram provided for embodiments of the present invention;

[0040] Figure 6 A schematic diagram of a vulnerability detection and optimization device for a robot operating system provided in an embodiment of the present invention;

[0041] Figure 7 This is a schematic diagram of a vulnerability detection and optimization device for a robot operating system provided in an embodiment of the present invention. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be described clearly and completely below in conjunction with specific embodiments. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0043] It should be noted that those skilled in the art will understand, explicitly and implicitly, that the embodiments described in this invention can be combined with other embodiments without conflict. Unless otherwise defined, the technical or scientific terms used in this invention should be understood in their ordinary sense by those skilled in the art. The terms "a," "an," "an," "the," etc., used in this invention do not indicate quantity limitation and can represent singular or plural. The terms "comprising," "including," "having," and any variations thereof used in this invention are intended to cover non-exclusive inclusion; the terms "first," "second," "third," etc., used in this invention are merely to distinguish similar objects and do not represent a specific ordering of objects.

[0044] The following explains some of the concepts involved in this invention.

[0045] "Registration" mainly refers to the process of associating predefined callback functions with specific events or message types in the robot operating system.

[0046] In a robot operating system, callback functions are typically used to respond to specific events or messages, such as when sensor data arrives or when other nodes publish specific types of messages. To handle these events or messages, developers write callback functions and register them with the robot operating system. This way, when the relevant event or message occurs, the robot operating system automatically invokes these registered callback functions.

[0047] C++ user libraries refer to the C++ standard library or user-defined libraries. These libraries contain a series of pre-written functions, classes, or components to simplify programming tasks and improve code reusability.

[0048] RCLCPP is a C++ user library for robot operating systems. It is designed specifically for the development of robot operating systems and provides high-level functions for robot operating systems. It is a user-facing interface built on the RCL and ROSIDL APIs.

[0049] RCL is a client library for the robot operating system, providing interfaces to the core functions of the robot operating system such as topics, services, parameters, and actions.

[0050] ROSIDL is used to define interfaces in a robot operating system. It uses a subset of the Interface Definition Language (IDL) to describe the interactions between ROS components.

[0051] RMW (ROS Middleware) refers to the middleware layer of the robot operating system, which enables the robot operating system to be compatible with different interchangeable low-level communication protocols.

[0052] The present invention will now be described.

[0053] Robot operating systems are designed to efficiently process input through a series of callbacks, which the executor schedules based on incoming messages. This time-series execution of callbacks is called callback tracing, and it provides a unique perspective on the system's internal state. Unlike code coverage, which may not vary significantly across different inputs, callback tracing offers more detailed insights into callback execution duration and message throughput, thus serving as a more accurate indicator of internal system state transitions. Therefore, by leveraging callback tracing during fuzzing, testers can gain deeper insights into system state transitions, identify inputs that trigger more system behaviors, and ultimately improve fuzzing performance.

[0054] To achieve these goals, many challenges remain:

[0055] Firstly, close monitoring of the state transitions of the robot operating system is crucial during the testing phase. However, given that the robot operating system operates in a dynamic and ever-changing environment, and contains numerous components and upper-level applications, existing methods for automatically acquiring state information are insufficient. These methods often rely on manual specifications or fail to provide the necessary information in real time when addressing the challenges of system diversity. Therefore, there is an urgent need to develop an automated method capable of accurately analyzing system interactions during testing to comprehensively reflect the real-time state of the robot operating system.

[0056] Secondly, constructing a state-guided test case generation mechanism is also crucial. Given the vast input space of a robot operating system, which needs to respond to various sensor data, control commands, and user configurations, traditional fuzz testing methods primarily rely on code coverage or manually defined specifications to guide input generation. This approach may not fully cover all input dimensions of the system, such as changes in execution time or adjustments to the scheduling order. Therefore, to effectively explore the state space of the robot operating system, a more efficient and comprehensive test case generation strategy is needed.

[0057] To address the aforementioned issues, this invention proposes a vulnerability detection and optimization method, apparatus, and device for robot operating systems. By analyzing collected state information as guidance and generating high-quality payloads, it aims to better explore complex behaviors within the robot operating system and uncover previously overlooked problems.

[0058] This invention relates to fuzz testing of robot operating systems, aiming to efficiently discover vulnerabilities in these systems. For ease of description below, this vulnerability discovery tool is referred to as ROSFUZZ. It utilizes runtime system interactions as system states to generate high-quality payloads, thereby effectively detecting vulnerabilities throughout the robot operating system.

[0059] ROSFUZZ performs fuzz testing through the following steps. First, it collects and processes system behavior data. To better understand this behavior, ROSFUZZ embeds custom trackers in different components of the robot operating system's runtime environment to systematically collect execution interaction information. Second, ROSFUZZ analyzes callback traces. Based on the collected interaction information, it analyzes the callback traces to form a summary containing key information such as callback execution duration, executor scheduling operations, and message throughput. This information can be used to guide the robot operating system's state transitions and input processing. Finally, ROSFUZZ generates high-quality payloads. During testing, ROSFUZZ continuously analyzes callback traces, identifies inputs that trigger new system states, and uses this as guidance to generate high-quality payloads. This feedback-based test case generation method produces higher-quality inputs, thereby improving the efficiency of robot operating system fuzz testing.

[0060] The specific design architecture of ROSFUZZ is as follows: Figure 1 As shown, ROSFUZZ comprises two phases: a callback trace collection phase and a callback trace guidance generation phase. In the collection phase, ROSFUZZ instrumentes the robot operating system runtime using a custom tracker, capturing key system behaviors such as callback execution, executor scheduling, and message passing. In each fuzzing loop, the instrumented tracker records real-time execution behavior. Subsequently, ROSFUZZ aggregates and organizes the recorded information into callback traces. In the generation phase, ROSFUZZ uses callback traces as system state indicators, identifying and prioritizing payloads that will trigger new system states, thereby improving future payload synthesis. This iterative approach enables the invention to continuously generate high-quality inputs, optimize the robot operating system state space exploration, and improve its overall fuzzing efficiency.

[0061] The advantages of this invention are as follows: First, it enables more comprehensive fuzz testing of the robot operating system. By considering state transitions, this invention can explore a wider range of system behaviors than traditional code coverage-based methods. Second, it provides a higher vulnerability detection rate by focusing on new system states, increasing the likelihood of discovering critical vulnerabilities. Finally, this invention achieves higher efficiency: the feedback-based payload generation optimizes the testing process, making fuzz testing faster and more accurate.

[0062] The following is a detailed explanation.

[0063] Figure 2 This is a schematic diagram illustrating the steps of a vulnerability detection and optimization method for a robot operating system provided in an embodiment of the present invention. Figure 2 The vulnerability detection and optimization method for the robot operating system shown can be executed by a vulnerability detection and optimization device for the robot operating system. This device can be located on a server, such as a physical server containing independent hosts, a virtual server hosted in a host cluster, or a cloud server. This embodiment of the invention does not limit the specific implementation of this method. The vulnerability detection and optimization method for the robot operating system may include the following steps:

[0064] S210: Obtain registration information through the registration tracker and obtain execution information of the robot operating system through the runtime tracker; the registration information includes attributes related to the callback function and the type to which the callback function belongs.

[0065] In one embodiment of the present invention, the registration information obtained through the registration tracker and the execution information of the robot operating system obtained through the runtime tracker specifically include: installing a first tracker in the C++ user library layer of the robot operating system and installing a second tracker in the general user library layer; when the user application starts the callback registration process, the first callback attribute is recorded through the first tracker and written to the data retrieval buffer; when the callback registration process propagates to the general user library layer, the second callback attribute is recorded through the second tracker and written to the data retrieval buffer; when the executor of the C++ user library layer schedules the execution of the callback function, the data generated during the execution of the robot operating system is obtained through the runtime tracker, aggregated, and stored in a specific data retrieval buffer.

[0066] Specifically, on the one hand, the registration tracker is started when different callback registration events are invoked. It is designed to automatically extract various callback attributes, including namespace, address assigned to the callback at different architecture layers, and specific callback types, such as subscription callbacks, timer callbacks, and services.

[0067] The basic workflow of registering a tracker is as follows: Figure 3As shown in the left-middle diagram. Specifically, when the robot operating system starts, the target application begins registering all predefined callbacks. The robot operating system, specifically the C++ user library (e.g., RCLCPP) layer and the general user library (e.g., RCL) layer, is responsible for registering these callbacks by associating them with specific namespaces and assigning corresponding addresses (handlers) at multiple levels: C++ user library handlers (e.g., RCLCPP handlers), general user library handlers (e.g., RCL handlers), and middleware component handlers (e.g., RMW handlers). To facilitate the capture of the above information, two different tracers are installed in the C++ user library layer and the general user library layer, respectively: a first tracer (e.g., the rclcpp_callback_init() function installed in the RCLCPP layer) and a second tracer (e.g., the rcl_callback_init() function installed in the RCL layer).

[0068] When a user application initiates the callback registration process, this activity is intercepted by the C++ user library `_callback_init()` tracer, which then logs details such as the C++ user library handler, the generic user library handler, and the type of callback—whether it's a subscription, timer, or service. This registration activity further propagates to the generic user library layer, where the generic user library `_callback_init()` tracer logs additional attributes, including the callback name and middleware handler. Furthermore, the registration tracer writes the collected data to a data retrieval buffer, which ROSFUZZ accesses to construct the callback trace.

[0069] On the other hand, such as Figure 3 As shown in the diagram on the right, a runtime tracer is designed to monitor the execution behavior of a system. The essence of robot operating system execution lies in the executor scheduling callbacks in response to different events (most commonly, receiving messages). Therefore, the runtime tracer primarily focuses on monitoring callback scheduling behavior and message publish / subscribe behavior.

[0070] In one embodiment of the present invention, the runtime tracker includes: a third tracker for recording the handler of the target callback; a fourth tracker for recording the timestamp of the callback start time; a fifth tracker for recording the timestamp of the callback end time; and a sixth tracker for recording communication information, including the size of the incoming message buffer and timestamps related to publish and subscribe activities.

[0071] Specifically, as a key component residing within the C++ user library layer, the executor is responsible for scheduling callback execution. This includes waiting for centralized callback scheduling, initiating callback execution, and terminating the execution process. To capture these complex details, this invention employs a series of tracers, including a third tracer (e.g., `executor_execute()`) that records the handler for the target callback; a fourth tracer (e.g., `callback_start()`) that records the timestamp of the target callback's start time; and a fifth tracer (e.g., `callback_end()`) that records the timestamp of the target callback's end time. Furthermore, to capture detailed messaging information, a sixth tracer (e.g., `rcl_take()`) is used. This sixth tracer is designed to record communication information, including the size of the incoming message buffer and timestamps related to publish and subscribe activities. After the execution phase is complete, the runtime tracer submits aggregated data to a specific retrieval buffer, retrieving this data via ROSFUZZ to construct an accurate callback trace.

[0072] S220: Build a callback tracing based on registration and execution information.

[0073] In one embodiment of the present invention, a callback tracing is constructed based on registration information and execution information, specifically including: processing registration data into structured information; the structured information includes a callback sequence number and processing procedures at different layers; calculating a latency index based on the execution information in each fuzzing loop, the latency index including callback latency and message latency; merging the callback latency and message latency indexes to construct a callback tracing, the callback tracing being represented as two different vectors, wherein one vector represents the callback latency and the other vector represents the message latency.

[0074] In one embodiment of the present invention, the delay index is calculated based on the execution information in each fuzzing loop, specifically including: determining the callback delay based on the callback sequence number, the handler and the first timestamp; and determining the message delay based on the callback sequence number, the message buffer size and the second timestamp.

[0075] In one embodiment of the present invention, the callback sequence number is generated by a hash function and serves as a unique identifier to distinguish various callback functions; the first timestamp includes the timestamp when the callback function is called, the timestamp when the callback function starts execution, and the timestamp when the callback function finishes execution; the second timestamp includes the timestamps for message publication and subscription.

[0076] Specifically, once registration information and runtime behavior (execution information) are collected, a callback tracing can be constructed. Initially, the raw registration data is processed to form structured information containing callback sequence numbers and corresponding handlers (addresses) at different levels, including C++ user library handlers and general user library handlers. The callback sequence number is generated using a hash function that considers the callback's name and type as a unique identifier to distinguish various callbacks.

[0077] Next, based on runtime data from each fuzzing loop, this invention focuses on calculating two key latency metrics: callback latency and message latency. Callback latency includes the callback sequence number, execution latency, and scheduling latency. The latency of each callback is determined based on the obtained handler, combined with the timestamps of the invocation (when the executor signal is ready to execute), start, and end of execution. Similarly, message latency is determined by considering the callback sequence number, message buffer size, and message publication and subscription timestamps, enabling this invention to calculate transmission throughput.

[0078] Finally, the callback delay and message delay metrics are combined to construct a callback trace. This trace is represented as two distinct vectors: one for callback delay and another for message delay. Furthermore, during execution, the executor may schedule a callback to execute multiple times; therefore, callback delay and message delay may contain duplicate elements.

[0079] S230: Analyze callback tracing to verify whether a new system state has been generated.

[0080] In one embodiment of the present invention, analyzing the callback tracing to verify whether a new system state has been generated specifically includes: analyzing the callback tracing and identifying the new system state based on judgment indicators; the judgment indicators include:

[0081] (1) Determine whether the callback tracing contains a new execution sequence;

[0082] (2) Determine whether the delay of a specific callback deviates from the established average benchmark value by more than a first preset threshold;

[0083] (3) Determine whether the throughput of a specific message deviates from the average baseline by a second preset threshold;

[0084] A new system state is determined when at least one of the criteria is true.

[0085] Specifically, to fully explore the state space of the robot operating system, it is crucial to generate a load that conforms to the robot operating system interface specification. However, the robot operating system has multi-dimensional input vectors and a highly structured interface, including topic messages and services. The derived callback tracing encapsulates various performance metrics, including the execution sequence of callbacks and messages and their associated latency and throughput. After acquiring the current callback tracing, a preliminary analysis is performed to calculate the total latency of each callback and the average latency of each message in the tracing. Specifically, to perceive state changes, this invention maintains two global structures: a callback graph and a global callback latency. The callback graph represents the time sequence of callback calls, while the global callback latency includes the overall callback latency and message throughput, representing the average performance of each encountered callback and message. In particular, this invention identifies new system states based on the following metrics: (1) By tracing the callback process, it determines whether a new execution sequence has been generated, thereby revealing profound insights into previously unexplored interaction patterns. (2) It assesses whether the latency of a specific callback deviates significantly from the existing average benchmark. (3) It detects whether the throughput of a specific message is significantly lower than the average benchmark. To establish an average baseline, this invention performs a certain number of summary analyses on the delay of each input, and then uses statistical methods to determine an appropriate value.

[0086] S240: Generate new test cases based on the new system state, and use the new test cases as test cases for the next round of the loop.

[0087] Specifically, in order to better illustrate the method of the present invention, Figure 4 The diagram illustrates the process of identifying new system states. Specifically, callback tracing analysis is performed after each load execution. First, the current callback tracing is checked to see if it contains any new execution sequences, representing a new edge in the global callback graph. If the current callback tracing introduces a new execution order, a corresponding edge is added to the callback graph. Then, it is checked whether the latency associated with a particular callback significantly exceeds the established baseline. In particular, from the current callback tracing, ROSFUZZ first calculates the current callback latency, including message latency and callback latency. This is compared to the global callback latency to check if a new callback has been found, or if the current message and callback latencies deviate significantly from the baseline. Each new state serves as a guide for generating subsequent inputs, thus enriching the exploration of the system state space. This, in turn, enhances the effectiveness of the testing process and the efficiency during testing.

[0088] The callback tracing bootstrapping process comprises three steps: interface extraction, payload synthesis, and new state identification. In the interface extraction step, ROSFUZZ extracts the interface specifications from the target robot's operating system, including message types, message formats, and message fields. In the payload synthesis step, ROSFUZZ selects a payload from the corpus to generate a new payload. In the new state identification step, the current callback tracing is compared with the global callback tracing and callback graph to identify any new system states, and interesting payloads are saved to the corpus.

[0089] Figure 5 This paper outlines the complete payload generation workflow. Initially, ROSFUZZ performs a dry run, extracting all interface specifications from the robot operating system. This includes a comprehensive list of interfaces—topics, services, actions—along with their associated data files, message types, and formats. Then, during the fuzzing phase, ROSFUZZ checks the current payload pool; if the pool is not empty, it selects an interesting payload for field-level mutation. Conversely, if the pool is empty, it randomly selects an interface from the extracted specifications and generates a payload accordingly. These payloads are then sent to the robot operating system for execution. Finally, ROSFUZZ checks whether the payload triggers any system crashes or new system states. If a new state or crash is triggered, the payload is saved in the pool for subsequent iterations. Through this iterative process, the invention can continuously generate high-quality payloads, enabling a more comprehensive and in-depth exploration of the robot operating system's state space.

[0090] The above describes a vulnerability detection and optimization method for a robot operating system provided by an embodiment of the present invention. Based on the same inventive concept, the present invention also provides a corresponding vulnerability detection and optimization device for a robot operating system, such as... Figure 6 As shown, it includes:

[0091] The information collection module 610 is used to obtain registration information through the registration tracker and execution information of the robot operating system through the runtime tracker; the registration information includes attributes related to the callback function and the type to which the callback function belongs;

[0092] Callback tracing building module 620 is used to build callback traces based on registration and execution information;

[0093] The new state determination module 630 is used to analyze callback tracing and verify whether a new system state has been generated.

[0094] The test case generation module 640 is used to generate new test cases based on the new system state, and to use the new test cases as test cases for the next round of the loop.

[0095] This invention also provides a corresponding vulnerability detection and optimization device for a robot operating system, such as... Figure 7 As shown, it includes:

[0096] The system includes at least one processor 702, a communication interface 704, a memory 706, and a communication bus 708; wherein the processor 702, the communication interface 704, and the memory 706 communicate with each other through the communication bus 708; the processor 702 can call the logical instructions stored in the memory 706 to cause at least one processor 702 to execute the steps of the above embodiments.

[0097] Based on the same idea, some embodiments of the present invention also provide media corresponding to the above methods.

[0098] Some embodiments of the present invention provide a storage medium storing computer-executable instructions, which are executed by a processor to implement the steps of the embodiments described above.

[0099] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can perform the steps of the vulnerability detection optimization method for a robot operating system provided in the above embodiments.

[0100] The various embodiments in this invention are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the device, medium, and program product embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0101] The devices, media, and program products and methods provided in the embodiments of the present invention are one-to-one correspondences. Therefore, the devices, media, and program products also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices, media, and program products will not be repeated here.

[0102] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process method or product that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process method or product. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process method or product that includes that element.

[0103] The above are merely embodiments of the present invention and are not intended to limit the invention. Although the present invention has been described in detail above with general descriptions and specific embodiments, modifications or improvements can be made to it, which will be obvious to those skilled in the art. Therefore, all such modifications or improvements made without departing from the spirit of the present invention fall within the scope of protection claimed by the present invention.

Claims

1. A vulnerability detection and optimization method for a robot operating system, characterized in that, The fuzzing loop in each robot operating system includes: Registration information is obtained through a registration tracker, and execution information of the robot's operating system is obtained through a runtime tracker; the registration information includes attributes related to the callback function and the type of the callback function. A callback tracing is constructed based on the registration information and the execution information; The callback tracing is analyzed to verify whether a new system state has been generated. Specifically, the analysis includes: analyzing the callback tracing and identifying a new system state based on judgment indicators. The judgment indicators include: (1) determining whether the callback tracing contains a new execution sequence; (2) determining whether the delay of a specific callback deviates from the established average benchmark value by a value higher than a first preset threshold; (3) determining whether the throughput of a specific message deviates from the average benchmark value by a value lower than a second preset threshold. When at least one of the judgment indicators is true, it is determined that a new system state has been generated. New test cases are generated based on the new system state, and these new test cases are used as test cases in the next round of the loop.

2. The vulnerability detection and optimization method for a robot operating system according to claim 1, characterized in that, The registration information obtained through the registration tracker and the execution information of the robot operating system obtained through the runtime tracker specifically include: Install the first tracker in the C++ user library layer of the robot operating system, and install the second tracker in the general user library layer; When the user application initiates the callback registration process, the first callback attribute is recorded through the first tracker and written to the data retrieval buffer. When the callback registration process propagates to the general user library layer, the second callback attribute is recorded by the second tracker and written to the data retrieval buffer. When the executor scheduling callback function of the C++ user library layer is executed, the data generated during the execution of the robot operating system is obtained through the runtime tracker, aggregated, and stored in a specific data retrieval buffer.

3. The vulnerability detection and optimization method for a robot operating system according to claim 1, characterized in that, The step of constructing callback tracing based on the registration information and the execution information specifically includes: The registration data is processed into structured information; the structured information includes callback sequence numbers and processing procedures at different levels; The latency metrics are calculated based on the execution information in each fuzzing loop, and the latency metrics include callback latency and message latency; The callback delay and the message delay metrics are combined to construct a callback trace, which is represented by two different vectors, one vector representing the callback delay and the other vector representing the message delay.

4. The vulnerability detection and optimization method for a robot operating system according to claim 3, characterized in that, The calculation of the latency metric based on the execution information in each fuzzing loop specifically includes: The callback delay is determined based on the callback sequence number, the handler, and the first timestamp; The message delay is determined based on the callback sequence number, message buffer size, and second timestamp.

5. The vulnerability detection and optimization method for a robot operating system according to claim 4, characterized in that, The callback sequence number is generated by a hash function and serves as a unique identifier to distinguish various callback functions. The first timestamp includes the timestamp when the callback function is called, the timestamp when the callback function starts executing, and the timestamp when the callback function finishes executing; The second timestamp includes the timestamps for message publication and subscription.

6. The vulnerability detection and optimization method for a robot operating system according to claim 1, characterized in that, The runtime tracer includes: The third tracker is used to record the handler for the target callback; The fourth tracker is used to record the timestamp of the callback start time; The fifth tracker is used to record the timestamp of the callback end time; The sixth tracker is used to record communication information, including the size of the incoming message buffer and timestamps related to publish and subscribe activities.

7. A vulnerability detection and optimization device for a robot operating system, characterized in that, include: The information collection module is used to obtain registration information through the registration tracker and execution information of the robot operating system through the runtime tracker; the registration information includes attributes related to the callback function and the type to which the callback function belongs; A callback tracing construction module is used to construct callback traces based on the registration information and the execution information; The new state determination module is used to analyze the callback tracing and verify whether a new system state has been generated. Specifically, it includes: analyzing the callback tracing and identifying a new system state based on judgment indicators; the judgment indicators include: (1) determining whether the callback tracing contains a new execution sequence; (2) determining whether the delay of a specific callback deviates from the established average benchmark value by a value higher than a first preset threshold; (3) determining whether the throughput of a specific message deviates from the average benchmark value by a value lower than a second preset threshold; when at least one of the judgment indicators is true, it is determined that a new system state has been generated. The test case generation module is used to generate new test cases based on the new system state, and to use the new test cases as test cases for the next round of the loop.

8. A vulnerability detection and optimization device for a robot operating system, characterized in that, include: At least one processor; as well as, The memory is connected to the at least one processor via a bus; wherein, The memory stores instructions executable by the at least one processor, which are executed to implement the method as described in any one of claims 1-6.

9. A non-volatile storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are executed by a processor to implement the method as described in any one of claims 1-6.

Images