A method and related device for testing safety of a UAV

Abstract

Embodiments of the present application disclose a kind of unmanned plane safety test method and related equipment, the present application will be based on MAVProxy Construction false data injection attacker, carry out multi-level attack test to unmanned plane ontology, control system and ground control station;Through sensor false data injection, data tampering and control command tampering and other means, interfere with the sensor of unmanned plane ontology and control system, can simulate a variety of security threats, comprehensive evaluation unmanned plane system when facing false data injection, control system hijacking and communication interference and other security attacks the attack resistance of ability, for improving the security, reliability and emergency response capability of unmanned plane in complex and changeable environment Provide technical support;The protocol used for attack test and the object of attack test are open source, so it has good reproducibility and universality.The present application is widely applied in unmanned plane technical field.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of unmanned aerial vehicle (UAV) technology, and in particular to a UAV safety testing method and related equipment. Background Technology

[0002] Unmanned Aerial Vehicles (UAVs), as unmanned aircraft that fly through remote control or autonomous programming, have a history dating back to their military reconnaissance applications in the early 20th century. Early on, limited by technology, UAVs relied primarily on radio remote control and had relatively simple performance. With advancements in computer technology, sensor technology, and control algorithms, UAVs gradually acquired intelligent autonomous flight capabilities, expanding their military applications to reconnaissance, strike, and support scenarios. In the 21st century, UAVs have rapidly penetrated the civilian and commercial sectors, achieving large-scale applications in areas such as power line inspection, agricultural plant protection, environmental monitoring, aerial filming, and logistics delivery.

[0003] The widespread adoption of drones has driven the development of open-source drone systems. These systems, based on open source code and hardware design, facilitate research and secondary development. They consist of four core components: open-source flight controllers (such as the Pixhawk series based on PX4 or ArduPilot), general-purpose sensors (GPS, gyroscopes, barometers, etc.), open communication protocols (represented by MAVLink), and open-source ground station software (such as QGroundControl).

[0004] As the application scenarios of drones become increasingly complex, security threats are becoming more prominent. Drones interact with ground stations, sensors, and satellites via wireless or wired networks during flight, making them more vulnerable to cyberattacks than traditional aircraft. Existing research has confirmed the feasibility of various attack methods, such as GPS spoofing (misleading drone positioning by forging GPS signals), sensor attacks (interfering with or falsifying sensor data), and control command tampering (altering flight instructions). Summary of the Invention

[0005] To address the current technical problems of drones being vulnerable to cyberattacks, the present invention aims to provide a drone security testing method and related equipment. The drone security testing method in this embodiment executes a complete closed loop through the following process: attack preparation (platform startup and agent configuration), loading plugins according to a preset time sequence to implement the attack (e.g., sensor interference → task tampering → control takeover), and attack effect verification (simulation platform visualization + packet analysis). This enables multi-level, time-series combined attack testing, allowing for a comprehensive and in-depth test of the drone's security performance.

[0006] On one hand, embodiments of the present invention include a method for testing the safety of unmanned aerial vehicles (UAVs), the method comprising:

[0007] An unmanned aerial vehicle (UAV) platform is established; the UAV platform includes a ground control station, a UAV flight controller, and a physical environment simulator. The ground control station and the UAV flight controller are connected via a first communication link, and the physical environment simulator and the UAV flight controller are connected via a second communication link. Both the first and second communication links use the MAVLink protocol.

[0008] A fake data input attack tool is established; the fake data input attack tool includes an attack plugin library and agent software based on the MAVLink protocol, and the attack plugin library includes multiple attack plugins;

[0009] The attack plugin is loaded into the proxy software to conduct attack tests on the drone platform.

[0010] Furthermore, the establishment of the fake data input attack tool includes:

[0011] Multiple attack test targets were identified; the attack test targets included the ground control station, the UAV flight controller, and the physical environment simulator.

[0012] Obtain the attack plugin corresponding to each of the aforementioned attack test objects;

[0013] Based on each of the aforementioned attack plugins, the attack plugin library is constructed.

[0014] Further, the step of obtaining the attack plugin corresponding to each of the attack test objects includes:

[0015] Iterate through all the attack test objects described;

[0016] For any of the attack test objects, obtain the MAVLink message in the MAVLink protocol corresponding to the attack test object, obtain the function corresponding to the MAVLink message, add a hook function to the function corresponding to the MAVLink message, obtain the attack code file, and generate a corresponding attack plugin based on the attack code file.

[0017] Furthermore, the step of obtaining the attack plugin corresponding to each of the attack test objects further includes:

[0018] Randomly select multiple of the aforementioned attack plugins;

[0019] The attack code files are copied and exchanged between the selected attack plugins.

[0020] Furthermore, the step of loading the attack plugin through the proxy software to conduct attack tests on the drone platform includes:

[0021] Identify the target of the attack test;

[0022] Based on the attack test target, the proxy software performs a man-in-the-middle proxy based on the MAVLink protocol to insert into the first communication link and / or the second communication link;

[0023] Based on the attack test target, the corresponding attack plugin is loaded through the proxy software;

[0024] From the inserted communication link, obtain the data packets sent by the source;

[0025] Run the loaded attack plugin to modify the acquired data packets;

[0026] The modified data packet is sent to the destination in the inserted communication link.

[0027] Furthermore, the step of loading the attack plugin through the proxy software to conduct attack tests on the drone platform also includes:

[0028] The quality of the first communication link and the quality of the second communication link are detected; the quality of the first communication link is the quality of the communication link before the proxy software is inserted into the communication link, and the quality of the second communication link is the quality of the communication link after the proxy software is inserted into the communication link.

[0029] The quality of the first communication link and the quality of the second communication link are compared to obtain the link quality comparison results;

[0030] The attack test results are determined based on the link quality comparison results.

[0031] Furthermore, the insertion of the first communication link and / or the second communication link further includes:

[0032] When the attack test target is on the first communication link, insert into the first communication link;

[0033] When the attack test target is on the second communication link, insert into the second communication link;

[0034] or

[0035] Simultaneously insert the first communication link and the second communication link.

[0036] Furthermore, when the first communication link and the second communication link are simultaneously inserted, the step of loading the corresponding attack plugin through the proxy software according to the attack test object includes:

[0037] When the attack test target is on the first communication link, the attack plugin is loaded multiple times on the first communication link at a lower frequency, and the attack plugin is loaded multiple times on the second communication link at a higher frequency.

[0038] When the attack test target is on the second communication link, the attack plugin is loaded multiple times on the second communication link at a lower frequency, and the attack plugin is loaded multiple times on the first communication link at a higher frequency.

[0039] On the other hand, embodiments of the present invention also include a computer device, including a memory and a processor, the memory for storing at least one program, and the processor for loading at least one program to execute the drone safety testing method in the embodiments.

[0040] On the other hand, embodiments of the present invention also include a computer-readable storage medium storing a processor-executable program, which, when executed by a processor, is used to perform the drone safety testing method in the embodiments.

[0041] The beneficial effects of the embodiments of the present invention are as follows: The UAV security testing method in the embodiments will construct a fake data injection attacker based on MAVProxy to conduct multi-level attack tests targeting the UAV body, control system, and ground control station; by means of sensor fake data injection, data tampering, and control command tampering, it will interfere with the sensors and control system of the UAV body, simulate various security threats, and comprehensively evaluate the anti-attack capability of the UAV system when facing security attacks such as fake data injection, control system hijacking, and communication interference, providing technical support for improving the security, reliability, and emergency response capability of UAVs in complex and ever-changing environments; the protocols used for attack testing and the objects of attack testing are all open source, thus having good reproducibility and universality. Attached Figure Description

[0042] Figure 1 This is a schematic diagram of the message structure of a MAVLink v1 message packet in the embodiment;

[0043] Figure 2 This is a schematic diagram of the message structure of a MAVLink v2 message packet in an embodiment;

[0044] Figure 3 This is a schematic diagram of the basic structure of the MAVProxy software in the embodiment;

[0045] Figure 4 This is a structural diagram of the PX4 software architecture in the embodiment;

[0046] Figure 5 This is a schematic diagram of the Gazebo simulation environment in the embodiment;

[0047] Figure 6 This is a schematic diagram of the QGroundControl user interface in the embodiment;

[0048] Figure 7 This is a schematic diagram of the drone platform in the embodiment;

[0049] Figure 8 This is a schematic diagram illustrating the steps of the drone safety testing method in the embodiment;

[0050] Figure 9 This is a schematic diagram of the overall structure of the drone platform and the fake data input attacker in the embodiment;

[0051] Figure 10 This is a schematic diagram of the drone simulation platform and attack framework module in the embodiment;

[0052] Figure 11 This is a schematic diagram of the attack framework of the fake data injector in the embodiment;

[0053] Figure 12 This is a schematic diagram of the function call relationship of MAVProxy in the embodiment;

[0054] Figure 13 This is a schematic diagram of part of the program code that implements GPS spoofing at the ground station in the embodiment;

[0055] Figure 14 This is a schematic diagram of part of the program code implementing the flight mission tampering attack in the embodiment;

[0056] Figure 15 This is a schematic diagram of the payload of a long command in the MAVLink protocol in the embodiment;

[0057] Figure 16 This is a schematic diagram of part of the program code implementing the sensor data tampering attack in the embodiment;

[0058] Figure 17 This is a schematic diagram of part of the program code implementing the sensor spoofing data injection attack in the embodiment;

[0059] Figure 18 This is a schematic diagram of part of the program code implementing the control command tampering attack in the embodiment;

[0060] Figure 19 This is a schematic diagram of the MAVProxy man-in-the-middle proxy configuration process in the embodiment;

[0061] Figure 20 This is a schematic diagram of the QGroundControl interface after being subjected to a sensor tampering attack in the embodiment.

[0062] Figure 21 This is a schematic diagram of the Gazebo interface after being attacked by a sensor spoofing data injection attack in the embodiment.

[0063] Figure 22 This is a schematic diagram of the QGroundControl interface after being subjected to a sensor spoofing data injection attack in the embodiment.

[0064] Figure 23 This is a schematic diagram of the QGroundControl interface after being subjected to a control command tampering attack in the embodiment.

[0065] Figure 24 This is a schematic diagram of the QGroundControl interface after being subjected to a flight mission tampering attack in the embodiment.

[0066] Figure 25 This is a schematic diagram of the Gazebo interface under hijacking attack in the embodiment (representing Wireshark capturing COMMAND_LONG data packets);

[0067] Figure 26 This is a schematic diagram of the QGroundControl interface (representing the MAVProxy interface) after being subjected to a GPS spoofing attack in the embodiment.

[0068] Figure 27 This is a schematic diagram of the communication link quality (first communication link quality) before the proxy software is inserted into the communication link in the embodiment;

[0069] Figure 28 This is a schematic diagram of the communication link quality (second communication link quality) after the agent software is inserted into the communication link in the embodiment. Detailed Implementation

[0070] I. Technical Problems and Technical Solutions

[0071] In open-source drone systems, communication protocols are a core component, and the MAVLink (Micro Air VehicleLink) protocol, due to its lightweight, low-bandwidth, and real-time characteristics, has become a reliable standard for drone communication. The MAVLink protocol is applied in four main scenarios: command and status interaction between the flight controller and the ground station (such as sending flight commands and transmitting location information), collaboration between the mission board and the flight controller (such as mission execution status feedback), data transmission between sensors and the flight controller (such as GPS positioning and gyroscope attitude data), and collaborative communication between drone swarms (such as location sharing and formation control). The widespread application of the MAVLink protocol makes it a critical link in drone security—vulnerabilities in the protocol or attacks on the communication link could lead to serious consequences such as drone loss of control and data leakage.

[0072] Therefore, conducting security tests on the MAVLink protocol, discovering communication link vulnerabilities through simulated attacks, and observing the flight stability of drones under various disturbances have become core requirements for improving the security of drone systems.

[0073] Currently, the field of drone security attacks and testing suffers from the following core shortcomings, all of which can be specifically addressed by the embodiments of this invention:

[0074] 1. Attack testing techniques lack systematicity and practicality.

[0075] Current attack tests only target single attack scenarios and have not formed a multi-dimensional attack system covering sensors, control commands, and flight missions. Furthermore, the attack methods lack versatility, often relying on specific drone models or protocol versions, making them difficult to adapt to mainstream open-source drone systems (such as those based on PX4 and MAVLink).

[0076] 2. The security testing platform has limited functionality and low integration.

[0077] Current drone security testing platforms have significant shortcomings: they lack a complete closed loop of "attack tools - simulation environment - performance evaluation," requiring manual configuration of communication links and attack parameters, making operation complex. For example, current technology struggles to intercept MAVLink protocol data in real time and inject false information, and it also cannot quantify the impact of attacks on communication links.

[0078] 3. Lack of a dedicated attack framework based on the MAVLink protocol

[0079] MAVLink, as a reliable communication protocol for drones, lacks dedicated tools for security testing. Existing attack tools do not utilize protocol proxy technology to achieve transparent interception and tampering, making it impossible to design attack logic targeting MAVLink message structures (such as critical messages like HIL_SENSOR and MISSION_ITEM_INT). For example, traditional tools struggle to accurately tamper with sensor data or flight mission commands, and the attack process is easily detected by both communicating parties, resulting in poor stealth.

[0080] To address the shortcomings of current drone attack security testing technologies, such as "insufficient coverage of attack methods, lack of flexibility in usage, insufficient depth of test coverage, and insufficient integration of attack scenarios with flight missions," the following methods can be used:

[0081] First, we constructed a fake data injection attacker based on MAVProxy, forming a testing tool that supports multi-layered, time-series combined attacks. By designing dedicated attack plugins targeting the UAV itself, control system, and ground control station, we covered multiple attack methods, including sensor fake data injection, sensor data tampering, control command tampering, flight mission tampering, hijacking attacks, and GPS spoofing attacks, thus solving the problems of existing platforms having limited attack methods and insufficient coverage.

[0082] Secondly, the plug-in design enhances the flexibility of use. Users can dynamically load different attack plugins according to their testing needs, which supports testing of single attack scenarios and can also combine multiple attacks to form a sequential attack process, solving the problem of fixed usage and lack of flexibility of the existing platform.

[0083] Third, we will deepen the depth of testing coverage by attacking the drone's sensors and control system, disrupting the control system's mission execution and control authority, and interfering with the ground control station's positioning and navigation. This will verify the security of the drone system across the entire "equipment-control-command" chain, solving the problem that existing tests only focus on a single link and lack sufficient coverage.

[0084] Fourth, it closely integrates attack scenarios with flight missions, simulating real-world attack scenarios when UAVs are performing missions in a simulation environment (such as being injected with false sensor data during flight or having waypoints tampered with during mission execution), making it more closely aligned with actual application scenarios and solving the problem of insufficient integration between existing tests and actual missions.

[0085] Ultimately, through the above design, various real-world security threats were simulated to comprehensively evaluate the anti-attack capabilities of the unmanned aerial vehicle (UAV) system under attacks such as false data injection, control hijacking, and communication interference, providing technical support for improving the security, reliability, and emergency response capabilities of UAVs in complex environments.

[0086] II. Technical Basis for Implementing UAV Safety Testing Methods (I) MAVLink Protocol

[0087] MAVLink Protocol Analysis

[0088] MAVLink (Micro Air Vehicle Link) is a lightweight message serialization protocol based on serial communication. Originally released in 2009 by Lorenz Meier of ETH Zurich, it is licensed under the LGPL open-source license and is primarily used for communication between drones, ground stations, and other related devices. It defines a set of common data types and message formats to enable interaction and data sharing between different devices. The MAVLink protocol supports various drone platforms, including fixed-wing, multi-rotor, helicopters, and ground vehicles, and provides powerful functionality not only for monitoring and controlling unmanned systems but also for integrating them into the internet. Due to its open design and flexibility, this protocol has become one of the most widely used standard communication protocols in the drone industry.

[0089] Communication and transmission protocols

[0090] The MAVLink protocol, as an application layer protocol, aims to define the message format and structure for data transmission between components in an unmanned aerial vehicle (UAV) system. At the application layer, MAVLink messages, after being constructed and serialized, are transmitted sequentially through the transport layer, network layer, data link layer, and physical layer. At the receiving end, data packets are decapsulated layer by layer, starting from the physical layer, until they reach the application layer and are decoded into MAVLink messages. The MAVLink protocol supports multiple transport layers and media, and can be transmitted in various ways, including using network interfaces or transmitting in the Sub-GHz band (433MHz, 868MHz, 915MHz) via a low-bandwidth serial telemetry channel.

[0091] While sub-GHz bands enable wide-range communication, their performance is significantly affected by environment, noise levels, and antenna configuration, potentially leading to unreliable communication. In contrast, network interfaces offer greater stability and reliability as they are less susceptible to environmental factors and interference. Furthermore, network interfaces provide higher data transfer rates and lower latency, crucial for real-time applications. When using network interfaces, Wi-Fi or Ethernet are typically chosen, and MAVLink messages are transmitted over IP networks. In UAV system networks, two transport layer protocols, TCP and UDP, are used, either of which can be used to transmit application-layer MAVLink messages. TCP provides a reliable, connection-oriented service. This service includes ensuring MAVLink messages are delivered to the destination, flow control, and congestion control mechanisms—that is, the source suppresses its transmission rate when the network is congested. UDP is a simplified transport layer protocol that provides no unnecessary services; it lacks reliability, flow control, and congestion control. While it lacks mechanisms to ensure reliable message delivery, its connectionless, direct data transmission, and low packet header overhead provide a lightweight and fast transmission solution for real-time and fault-tolerant message streams. The choice between the two protocols depends on the information exchange needs between components in the drone system.

[0092] Message types and structures

[0093] In the MAVLink protocol, all messages are binary serial messages, transmitted using binary serialization. During message transmission, the message type and fields are first defined. Then, according to the definitions, the message field values ​​are serialized into binary data, and the serialized data is encapsulated into a MAVLink packet for transmission. The receiving end parses the MAVLink packet and deserializes it, converting the binary data back to the original field values. The advantages of binary serialization include reduced data transmission costs, shorter communication latency, improved response speed, and guaranteed communication universality across various systems and devices, thereby significantly improving the efficiency and real-time performance of communication between unmanned systems and ground stations.

[0094] The MAVLink protocol has been released in several versions. MAVLink v1 was widely adopted around 2013, and is now only used by some legacy peripherals. MAVLink v2 is the currently recommended main version, and has been adopted by many major users since early 2017. The following will describe in detail the similarities and differences between the two versions.

[0095] (1) MAVLink v1

[0096] like Figure 1As shown, a MAVLink v1 message packet consists of a header, payload, and CRC checksum field. The header comprises six fields, each occupying one byte, for a total of six bytes. The first field, STX, is the start byte, used to identify the beginning of a new MAVLink v1 message, and is 0xFE. The second field, LEN, indicates the number of bytes in the payload, i.e., the length of the subsequent message data portion. The third field, SEQ, represents the message sequence number, used to detect packet loss or duplicate packets; this value increments by 1 with each new message sent. The value of SEQ ranges from 0 to 255; once the value reaches 255, the sequence number of the next message is set to 0. The fourth field, SYS ID, represents the system ID of the sending system, used to distinguish different systems in the network, such as a specific drone. The fifth field, COMP ID, represents the ID of the component sending the message, used to distinguish different components within the system, such as an autopilot and a camera. The sixth field, MSG ID, indicates the message type of the payload in the message; for example, a message with MSG ID 0 indicates a HEARTBEAT type message. The subsequent PAYLOAD field is the payload, which is the actual message data carried in the message. Its content and structure depend on the specific message type. Fields in the payload are arranged according to a predefined message format, and their length is specified by the payload length, with a maximum of 255 bytes. Finally, the last two bytes of the message are a CRC checksum, used to check the data integrity of the message during transmission. Upon receiving the message, the receiving end uses a CRC check to confirm whether the message has been corrupted. If the check fails, the message is discarded. In MAVLink v1, the minimum length message packet is an acknowledgment packet without a payload, with a length of 8 bytes. The maximum length message packet is a message packet containing a complete payload, with a length of 263 bytes.

[0097] (2) MAVLink v2

[0098] MAVLink v2 is a backward-compatible update to MAVLink v1. It shares all fields from the older version, adds new fields, and resizes some existing fields, providing greater flexibility and security for MAVLink communication. Figure 2As shown, MAVLink v2 consists of 11 fields. The header comprises eight fields, each occupying 1 byte except for the MGD ID (which occupies 3 bytes), for a total of 10 bytes. Six fields are identical to MAVLink v1: STX, LEN, SEQ, SYS ID, COMP ID, and MSG ID. Notably, in MAVLink v2, the STX value is 0xFD instead of 0xFE. Furthermore, the message ID in MAVLink v2 has been expanded from 8 bits to 24 bits, supporting over 16 million unique message definitions, far exceeding the 256 message types defined in MAVLink v1. Two new fields have been added to the header: the incompatibility flag INC FLAGS and the compatibility flag CMP FLAGS. These fields indicate whether the packet contains special processing requirements, allowing for protocol evolution while maintaining backward compatibility. The payload portion is largely the same as MAVLink v1, but in MAVLink v2, the message ID is expanded to 24 bits, thus supporting a wider range of message types. Furthermore, MAVLinkv2 supports message extensions, allowing the addition of new fields to existing message definitions without affecting the binary compatibility of receivers that haven't updated. The next two bytes of the payload are a CRC checksum, used to detect data integrity during transmission. Upon receiving a message, the receiver uses a CRC check to confirm whether the message has been corrupted. If the check fails, the message is discarded. In addition, MAVLink v2 adds a 13-byte optional field, SIGNATURE, to the end of the message. If the incompatibility flag is set to 0x01, a digital signature will be appended. A digital signature is a cryptographic technique used to verify the integrity and authenticity of a message. Signing messages can protect the communication link from attacks and prevent data tampering or forgery to a certain extent. Adding a digital signature to MAVLink messages improves the security of the communication link and ensures that data is not tampered with during transmission. However, it should be noted that digital signatures increase message length and processing time, potentially affecting communication efficiency. Therefore, in practical applications, the need to enable digital signatures should be weighed based on actual requirements.

[0099] MAVLink message types

[0100] The MAVLink protocol defines several message types, identified by their message IDs. Messages with IDs less than 255 are common to both MAVLink v1 and MAVLink v2, while messages with IDs greater than 255 are specific to MAVLink v2. It's important to note that in MAVLink 1.0, message IDs were encoded as 8 bits, while in MAVLink 2.0, this is extended to 24 bits. Based on their purpose, MAVLink messages are generally divided into two categories: status messages and command messages. Status messages are typically sent by the UAV system to a ground station or other receiving device and contain information about the system's status, such as the UAV system's ID, position, speed, and altitude. Command messages are typically sent by the ground station or user programs to the UAV system to perform certain operations or tasks via the autopilot, such as takeoff, landing, heading to waypoints, or performing tasks involving multiple waypoints.

[0101] (II) MAVLink Protocol Transparent Proxy Technology

[0102] Basic working principle of protocol proxy

[0103] Protocol proxy is a network communication technology whose main function is to intercept, analyze, modify, or forward data packets in a communication link. In the context of drone-based data injection attacks, we focus on transparent proxy technology based on the MAVLink protocol. Transparent proxy technology allows attackers to capture and tamper with data packets in a communication link without being detected by either party. The basic working principle of protocol proxy is briefly introduced below:

[0104] (1) Interception: The protocol proxy first needs to place itself in the communication link so that all data packets must pass through the proxy to reach their destination. In the MAVLink protocol, the proxy can achieve this by modifying port configuration or by utilizing network topology.

[0105] (2) Analysis: When a data packet passes through the agent, the agent analyzes the data packet to extract relevant information. In the MAVLink protocol, the agent can parse various fields in the data packet, such as message type, data payload, checksum, etc., to understand the status and control information of the UAV.

[0106] (3) Modification: After analyzing the data packets, the agent can modify them as needed. For example, the agent can tamper with sensor data, control commands, or flight mission information to carry out spoofing data injection attacks. The modified data packets need to have their checksums recalculated to ensure the integrity of the data packets.

[0107] (4) Forwarding: After modifying the data packet, the agent needs to forward the data packet to the destination. In the MAVLink protocol, the agent sends the modified data packet to the UAV system or ground control station, so that neither party can detect the existence of the agent.

[0108] Through the four steps described above, the protocol proxy achieves control over the communication link and data tampering. In drone spoofing attacks, this technique provides attackers with an effective means to analyze and manipulate the communication of drone systems, thereby achieving control and damage to the drones.

[0109] Typical open-source tools for the MAVLink protocol

[0110] With the development of the MAVLink protocol, more and more drone developers and researchers are adopting it to achieve communication between aircraft and ground stations. At the same time, some open-source software tools have emerged for developing, testing, debugging, and integrating software in systems based on the MAVLink protocol.

[0111] (1) QGroundControl: QGroundControl (QGC) is a feature-rich, cross-platform ground station software that supports operating systems such as Windows, macOS, Linux, and Android. It supports the MAVLink protocol, is compatible with various UAVs, and provides functions such as flight planning, setting adjustment, and telemetry data display.

[0112] (2) Mission Planner: Mission Planner is a Windows-based ground station software designed specifically for the ArduPilot flight control system. It supports the MAVLink protocol and provides functions such as map viewing, flight plan creation, real-time telemetry data display, and parameter adjustment. In addition, Mission Planner offers advanced features such as UAV simulation, log analysis, and firmware updates.

[0113] (3) MAVSDK: MAVSDK (formerly known as Dronecode SDK) is a C++-based library that supports the MAVLink protocol and is used to develop custom applications for drones. MAVSDK provides interfaces for multiple programming languages, such as Python, Swift, and Java, enabling developers to easily develop drone applications on various platforms.

[0114] (4) pymavlink: pymavlink is a Python library for generating MAVLink messages, supporting both Python 2 and Python 3. It includes tools for parsing, generating, sending, and receiving MAVLink messages, as well as a lightweight library for UDP, TCP, and serial port communication.

[0115] (5) MAVProxy is a lightweight, modular MAVLink ground station proxy based on Python, developed by Dr. Andrew Tridgell. It provides a command-line interface for researchers and developers to implement complex control and monitoring functions. The following is a detailed introduction to MAVProxy:

[0116] a. Modularization: The core of MAVProxy is its modular design, which allows users to easily add and remove features according to their needs. Modules can be written in Python and can be dynamically loaded at runtime. This design makes MAVProxy highly flexible and suitable for various scenarios.

[0117] b. Extensibility: MAVProxy boasts a rich plugin library, offering numerous pre-built functional modules. These modules cover a wide range of functions, including map display, data charting, logging, and remote control calibration. Furthermore, developers can create custom modules to meet specific needs.

[0118] c. Multi-device support: MAVProxy can connect to multiple MAVLink devices simultaneously, enabling communication and data forwarding between devices. This makes MAVProxy a powerful network tool that facilitates communication and control between different devices.

[0119] d. Command-line interface: MAVProxy provides a feature-rich command-line interface that allows users to quickly perform common operations such as parameter settings, waypoint management, and mode switching. This is extremely useful for researchers and developers, as they can immediately see the results of commands without needing a complex graphical interface.

[0120] e. Data Analysis: MAVProxy can receive and analyze telemetry data from UAVs in real time. Users can view the data in real time through the command-line interface or visualize the data using built-in graphics tools (such as matplotlib). Furthermore, MAVProxy can record flight data for later analysis.

[0121] (III) Proxy Software—MAVProxy Basic Structure of MAVProxy Software

[0122] The basic structure of the MAVProxy software consists of four main parts: the core, modules, the command-line interface (CLI), and plugins. These parts work together to enable MAVProxy to communicate and control other software that uses the MAVLink protocol. The connections between these parts are as follows: Figure 3 As shown, straight lines represent direct connections, dashed lines represent indirect connections, and arrows represent the transmission of data and control flows. A detailed explanation follows:

[0123] (1) Command Line Interface (CLI): This is the interface through which users interact with MAVProxy, allowing users to input commands such as loading and unloading modules, changing parameter settings, and executing route tasks. The CLI is connected to the core part. The command line interface transmits the user's commands to the core part for processing, and the processed results are sent back to the user by the core part and displayed on the command line interface.

[0124] (2) Core Component: This is the center of the entire system, responsible for handling MAVLink communication, distributing data, and executing commands. The core component connects the command-line interface, modules, and plugins, and passes data and commands between these components.

[0125] (3) Modules: Modules are functional components of MAVProxy, providing various functions such as map display, telemetry recording, UAV status monitoring, and waypoint management. Modules can be loaded or unloaded as needed, allowing users to customize ground station functions according to specific requirements. Modules are connected to the core, meaning the core distributes parsed information to each module so that these modules can perform corresponding operations as needed. Simultaneously, each module can also send requests to the core as needed.

[0126] (4) Plugins: Plugins can extend the functionality of MAVProxy, such as forwarding data to other ground station software or implementing custom functions. The relationship between the core and plugins is similar to the relationship between modules. The core provides parsed data to plugins, which can process this data as needed. At the same time, plugins can also send commands or requests to the core, which will execute the corresponding operations.

[0127] It's worth noting that while both modules and plugins extend the functionality of MAVProxy, they are relatively independent. Modules primarily focus on the implementation of functions within the ground station, while plugins focus more on integration with external systems.

[0128] (IV) Unmanned Aerial Vehicle Flight Controller (Flight Control Software) — PX4

[0129] PX4 is a leading open-source drone control system solution that provides a powerful and modular platform for autonomous aircraft. Figure 4As shown, PX4 mainly consists of two layers.

[57] Flight stack is an estimation and flight control system, while middleware is a general-purpose robotics application layer that can support any type of autonomous robot, providing internal / external communication and hardware integration.

[0130] The flight stack implements guidance, navigation, and control algorithms to support various aircraft types, such as fixed-wing, multi-rotor, and vertical takeoff and landing (VTOL) aircraft. It includes estimators for attitude and position estimation, as well as corresponding controllers. Through its highly modular design, developers can easily add new algorithms, controllers, or estimators to meet evolving technologies and requirements. Furthermore, the flight stack supports multiple flight modes and flexible control strategies, enabling UAVs to flexibly switch control methods under various mission and flight conditions.

[0131] The middleware handles sensor drivers, communication interfaces with external devices and systems, and internal data transfer. It primarily includes device drivers for embedded sensors, communication with the external world such as companion computers and ground control stations, and the uORB publish-subscribe message bus. The middleware supports a wide range of sensor devices, ensuring the UAV's high customizability and scalability. Simultaneously, support for multiple communication protocols such as MAVLink enables seamless integration with other systems. The uORB message bus, as the core component for internal data transfer, ensures low-latency, high-efficiency, and decoupled communication between modules.

[0132] (V) Physical Environment Simulator—Gazebo

[0133] Gazebo is an open-source 3D robot simulator designed to provide developers and researchers in the field of robotics with a tool for robot simulation. It offers a scalable platform capable of supporting simulations of various robot types, including mobile robots, stationary robots, and multi-robot systems. The Gazebo simulator is highly customizable, allowing users to customize models and environments. Figure 5 This is the Gazebo physics simulation world built in this article. In addition, Gazebo has a rich sensor library that can simulate various sensors, such as cameras, LiDAR, and inertial measurement units, making robot simulations more realistic and accurate.

[0134] (VI) Ground Control Station—QGroundControl

[0135] QGroundControl is an open-source ground control station software that provides comprehensive flight control and configuration capabilities for PX4 or ArduPilot-based aircraft. Its design prioritizes ease of use, allowing beginners to easily get started while providing advanced feature support for experienced users. The user interface is... Figure 6 As shown. Its main functions include comprehensive setup and configuration of ArduPilot and PX4-driven aircraft, autonomous flight mission planning, real-time monitoring of aircraft position, flight path, waypoints, and vehicle instruments, and support for managing multiple aircraft. Furthermore, QGroundControl is highly compatible, supporting aircraft running PX4, ArduPilot, or other autopilots that communicate using the MAVLink protocol, and can run on Windows, OS X, Linux, iOS, and Android devices.

[0136] QGroundControl boasts high compatibility, supporting aircraft running PX4, ArduPilot, or other autopilots that communicate using the MAVLink protocol, and runs on Windows, OS X, Linux, iOS, and Android devices. Its key features include comprehensive setup and configuration of ArduPilot and PX4 Pro-driven aircraft, autonomous flight mission planning, real-time monitoring of aircraft position, flight path, waypoints, and vehicle instruments, and support for managing multiple aircraft.

[0137] (VII) Unmanned Aerial Vehicle Platform

[0138] like Figure 7 As shown, the basic UAV simulation platform based on Software-in-the-Loop (SITL) design consists of three main software components: PX4, QGroundControl, and Gazebo. PX4, as the flight control software, is responsible for key functions such as UAV flight, navigation, and sensor data processing. QGroundControl, as the ground station software, provides UAV monitoring, mission planning, and flight control functions, offering comprehensive remote operation and control support for pilots. Gazebo, as the simulation software, can highly simulate the UAV's flight process in a real environment, including various aspects such as the environment, the aircraft, and sensors, providing a highly realistic simulation experience.

[0139] In this platform, PX4 communicates with QGroundControl and Gazebo via the MAVLink protocol. For the transport layer, PX4 uses UDP with QGroundControl and TCP with Gazebo, ensuring reliable and real-time data transmission. The platform guarantees the realism and accuracy of the simulation process, providing a foundation for subsequent attack testing.

[0140] III. Unmanned Aerial Vehicle (UAV) Safety Testing Methods

[0141] Based on the aforementioned technical foundation, a method for testing the safety of unmanned aerial vehicles (UAVs) is provided. (Refer to...) Figure 8 The drone safety testing method includes the following steps:

[0142] S1. Establish a drone platform;

[0143] S2. Establish a fake data input attack tool;

[0144] S3. Attack tests on the drone platform were conducted by loading an attack plugin through proxy software.

[0145] In step S1, the established drone platform is as follows: Figure 9 As shown, the system includes a ground control station (QGround Control), a drone flight controller (PX4), and a physical environment simulator (Gazebo). The ground control station and the drone flight controller are connected via a first communication link, and the physical environment simulator and the drone flight controller are connected via a second communication link. Both the first and second communication links use the MAVLink protocol. In the absence of network attacks, the drone platform can perform normal drone flight simulation.

[0146] In step S2, the fake data input attack tool established is as follows: Figure 9 As shown, it includes an attack plugin library and a proxy software (MAVProxy) based on the MAVLink protocol. The attack plugin library includes multiple attack plugins.

[0147] Specifically, refer to Figure 10 This paper proposes a method for implementing a drone spoofing data injection attack based on MAVProxy. To construct an effective drone spoofing data injection attack, a plugin-based design approach is adopted, using software simulation as the primary development method. Future development is expected to support hardware-in-the-loop simulation. Specifically, this research embeds the code and configuration required to simulate drone security attacks into corresponding plugins. When the attacker starts the attack, the attacker can load the selected attack plugin according to their needs and then input specific attack commands into the attacker, thereby damaging the drone system.

[0148] This man-in-the-middle proxy-based fake data injection attack uses MAVProxy as its prototype and leverages its modular structure to design an attack plugin library targeting the MAVLink protocol. When a user issues a command to load plugins, a set of related attack plugins are configured into the attacker. At this point, the user can input attack commands to control the attacker to inject fake data into ground stations or drones.

[0149] Specifically, the MAVLink message data communicating between the ground control station QGC and the UAV flight controller PX4 is encapsulated in UDP protocol and transmitted from the source address to the destination address via the IP network. The main message types include heartbeat messages (to maintain connection and identify system type), attitude information, position information, velocity information, telemetry data, flight mission management, and parameter configuration. These message types enable the QGC to monitor the UAV's status, position, velocity, and other relevant parameters in real time, providing users with a real-time flight status display. Simultaneously, the QGC can operate the UAV controlled by the PX4 by sending control commands, such as takeoff, landing, changing flight mode, and waypoint planning. This interaction enables real-time monitoring and effective control of the UAV in practical applications.

[0150] The physical environment simulator Gazebo and the UAV flight controller PX4 also communicate using the MAVLink protocol. However, unlike PX4, this communication link encapsulates the transmitted data using TCP before it reaches the target address via an IP network. The TCP protocol provides reliable data transmission, ensuring that MAVLink messages between Gazebo and PX4 are transmitted sequentially and without errors. During communication between Gazebo and PX4, the MAVLink protocol transmits various message types to achieve UAV simulation and control. The main message types include sensor data, attitude information, and execution commands. These message types allow Gazebo to simulate real-world sensor inputs, providing PX4 with the corresponding data to perform flight control in the simulation environment. Simultaneously, PX4 drives the UAV model in Gazebo by transmitting execution commands, such as motor control signals. This interaction ensures the accuracy and effectiveness of the UAV control algorithm are verified and tested in the simulation environment.

[0151] Utilizing the modular structure of MAVProxy, a plugin-based attack framework module was designed. Specifically, such as... Figure 10As shown, the MAVProxy software was used as a prototype, and its internal structure was modified, including adding hook functions and modifying the logic for handling MAVLink messages. Multiple attack test targets were implemented for the UAV platform, including the UAV itself (physical environment simulator), the control system (UAV flight controller), and the ground control station. Figure 11 The three types of attack plugins shown contain a range of attack methods:

[0152] (1) Attack Plugin Targeting the UAV Body (Attack Plugin 1): Attack Plugin 1 is designed to attack the UAV body, including injecting spoofed sensor data, tampering with sensor data, and altering control commands. Through these attack methods, attackers can influence the UAV's sensors and control system, thereby interfering with its performance or causing it to go out of control.

[0153] (2) Attack Plugin Targeting the Control System (Attack Plugin Two): Attack Plugin Two targets the control system of the UAV, including flight mission tampering and hijacking attacks. Flight mission tampering aims to modify the mission instructions executed by the UAV, thereby causing it to perform incorrect or malicious tasks. Hijacking attacks, on the other hand, gain control of the UAV, forcing it to perform tasks specified by the attacker, thereby achieving control over the UAV.

[0154] (3) Attack Plugin Targeting Ground Control Stations (Attack Plugin Three): Attack Plugin Three primarily targets ground control stations, implementing GPS spoofing attacks. By interfering with the GPS signals of the ground control station, attackers can affect the station's positioning and navigation capabilities, thereby impacting the control and command of the UAV.

[0155] Employing a plugin-based design, each attack experiment can effectively implement specific attack cases for a particular scenario. Furthermore, different attack cases can be combined to design a more effective attack scheme, enabling richer attack applications. In addition, this solution supports flexible custom development to extend the functionality of the attacker without affecting the stability and performance of existing plugins. By writing code files and performing corresponding configuration operations, new attack modules can be easily integrated into existing plugins in a modular form.

[0156] Based on the attack framework described above, detailed attack configurations will be further described below. These configurations include parameters such as the specific implementation methods of each attack plugin, attack strength, and injection points, in order to simulate attacks in different scenarios. This framework and configuration design can provide a practical and flexible foundation for research on drone-based fake data injection attacks.

[0157] In this embodiment, Figure 9 and Figure 10The attack plugin library shown includes some attack plugins whose content, generation methods, and principles are as follows:

[0158] (I) Fake Data Injection Attack Plugin Targeting Ground Control Stations

[0159] This paper presents a GPS spoofing attack targeting the ground station. GLOBAL_POSITION_INT is a MAVLink status message used to transmit the UAV's real-time global location information. This information typically includes latitude, longitude, altitude, and other location-related data. The PX4 flight controller sends this information to the QGroundControl ground station so that the operator can view and monitor the UAV's real-time location on a map.

[0160] In GPS spoofing attacks, GLOBAL_POSITION_INT is sent by PX4 and passes through the proxy software MAVProxy before being successfully received by QGC. The MAVProxy process for this data packet is as follows: Figure 12 As shown.

[0161] For GLOBAL_POSITION_INT, MAVProxy receives the data stream from PX4 (i.e., the master port), then passes it to the `process_buffer()` function to enter the MAVLink parsing buffer. It then calls `parse_char()` to parse the input data bytes and finally calls `parse_char_legacy()`. This function first checks if the beginning of the byte stream contains the correct protocol markers, and then parses out the message header and message body. If parsing is successful, it returns a MAVLink message. Finally, the MAVLink message is passed to the callback function `call_back()` for processing. Based on this, an attack plugin needs to add a hook function inside the `call_back()` function to call specific attack code and implement the attack.

[0162] Part of the code, such as Figure 13 As shown, when the attack command "attack gps_spoofing" is entered into MAVProxy, the program filters out GPS_RAW_INT data packets and then tampers with their latitude and longitude information. Finally, it forwards these packets to QGC. Thus, QGC receives tampered, fake GPS information packets, and the program achieves GPS spoofing.

[0163] (II) Virtual Data Injection Attack Plugins Targeting Control Systems

[0164] MISSION_ITEM_INT is a MAVLink mission instruction message used to transmit mission instructions between the UAV and the ground station. Mission instructions typically include waypoints, actions, parameters, and other information to control the UAV's flight path and behavior. A UAV's flight mission consists of a series of MISSION_ITEM_INT messages, which together define the entire flight plan from takeoff to landing. The ground station software sends these instructions to the UAV's flight controller (such as a PX4) via the MAVLink protocol. When the flight controller receives the MISSION_ITEM_INT message, it adjusts the UAV's flight path and behavior according to the mission instructions. For example, the UAV might turn at a specified waypoint, perform a specific action (such as taking a picture or landing), or adjust its flight speed according to predetermined parameters.

[0165] For MISSION_ITEM_INT, MAVProxy receives the data stream from the QGC (out port), then passes it to the process_mavlink() function via the main_loop() function. The process_buffer(), parse_char(), and parse_char_legacy() functions are then called sequentially to parse the data stream into MAVLink messages. However, unlike MISSION_ITEM_INT, this parsed MAVLink message is not passed to the callback function call_back() for processing; instead, it is returned to process_mavlink(), which then determines whether to forward the message to other MAVProxy modules.

[0166] Therefore, designing an attack plugin requires adding a hook function inside the `process_mavlink()` function. This hook function calls the specific attack code to achieve a flight mission tampering attack. The partial code implementing the flight mission tampering attack is shown below. Figure 14 As shown, the program filters out the MISSION_ITEM_INT message from all data packets sent by QGC, then modifies the x and y coordinate variables within it, and forwards it to PX4. It's worth noting that if the UAV system uses a local coordinate system in meters, the coordinate variable unit is 10. -4 Meters. If the UAV system uses a global coordinate system based on latitude and longitude, then the coordinate variable unit is 10. -7 Spend.

[0167] Furthermore, a hijacking attack was designed into the virtual data injection attack plugin for control systems. This attack targets the COMMAND_LONG command message in MAVLink, a multi-functional command. It allows sending different types of commands based on the command type and parameters of the message. The message ID of the long command message is 76, and it defines 11 fields, such as... Figure 15 As shown, the `command` field in `MAV_CMD` represents the type of command to be executed, and its value is the command ID defined in the enumeration. The seven parameters depend on the command type. For each command, a set of parameters associated with that command can be set. A command ID of 400 indicates a disarm command, and when both `param1` and `param2` are 21196, it indicates a forced disarm command, which can be used to launch a hijacking attack. Entering the `disarm force` command in `MAVProxy` can control the drone to immediately disarm and then crash from the air, completing the attack.

[0168] (III) Fake data injection attack plugins targeting the UAV itself

[0169] HIL_SENSOR is a status message used in the simulation system to simulate sensor data and send it to the flight controller. This message contains data from multiple sensors, such as accelerometers, gyroscopes, magnetometers, and barometers. By sending the simulated data to the flight controller, various flight conditions and environments can be simulated. The attack plugin includes two attack methods targeting this MAVLink message: sensor data tampering and sensor data injection. Since the HIL_SENSOR data packet is sent from Gazebo to PX4, hook functions can be added inside the `process_mavlink()` function to implement the specific attack. Partial code examples of the two attack methods are shown below. Figure 16 and Figure 17 As shown, after detecting the HIL_SENSOR message, the former modifies the magnetic sensor data in the detected data packet and then forwards it to PX4, while the latter creates a new HIL_SENSOR spoof data packet, which is transmitted to PX4 for processing along with the HIL_SENSOR simulation data packet sent by Gazebo.

[0170] "HIL_ACTUATOR_CONTROLS" is a command message. In PX4 and Gazebo simulations, the HIL_ACTUATOR_CONTROLS data packet transmits instructions from the flight control software to drive actuators in the simulation environment. In this case, PX4, acting as the flight control system, provides the desired actuator control signals to the Gazebo simulator. The Gazebo simulator adjusts the aircraft's dynamics and attitude in the simulation based on these signals. Specifically, a hook function can be added inside the `process_mavlink()` function to call specific attack code. Control command tampering attack code, such as... Figure 18 As shown, after filtering out the HIL_ACTUATOR_CONTROLS messages, all controls fields in the packet are set to 0.8. For quadcopter drones, all four motors will receive the same control signals, which may allow the aircraft to maintain balance in the air without any other complex movements. However, in some situations, such as when the aircraft's center of gravity, motor power, and other external factors (such as wind, turbulence, etc.) do not meet the balance requirements, the drone may even lose control and crash.

[0171] As can be seen from the above description of some attack plugins, attack plugins can be generated in the following way: For any attack test object, obtain the MAVLink message in the MAVLink protocol corresponding to the attack test object, obtain the function corresponding to the MAVLink message, add hook functions to the function corresponding to the MAVLink message, obtain the attack code file, and generate a corresponding attack plugin based on the attack code file.

[0172] In this embodiment, since each attack plugin contains attack code files, after generating multiple attack plugins, several attack plugins can be randomly selected, and the attack code files can be copied and exchanged among the selected attack plugins. For example, when attack plugin 1 and attack plugin 2 are selected, some or all of the attack code files in attack plugin 1 can be copied to attack plugin 2, and vice versa. This makes the attack plugins contain a richer set of attack code files, increasing the diversity of drone attack testing.

[0173] After completing steps S1-S3 to establish the drone platform and the fake data input attacker, step S3 is executed to load the attack plugin through the proxy software to conduct attack tests on the drone platform.

[0174] In this embodiment, when performing step S3, which is to load the attack plugin through the proxy software to perform attack testing on the drone platform, the following steps can be executed:

[0175] S301. Identify the target of the attack test;

[0176] S302. Based on the attack test target, use proxy software to perform man-in-the-middle proxying based on the MAVLink protocol to insert into the first communication link and / or the second communication link;

[0177] S303. Based on the target of the attack test, load the corresponding attack plugin through the proxy software;

[0178] S304. Obtain the data packets sent by the source from the inserted communication link;

[0179] S305. Run the loaded attack plugin to modify the acquired data packets;

[0180] S306. Send the modified data packet to the destination in the inserted communication link.

[0181] In step S301, the target of the attack test is determined, such as whether the target of the attack test is a ground control station, a UAV flight controller, or a physical environment simulator.

[0182] In step S302, it is determined whether the proxy software (MAVProxy) should be inserted into the first communication link or the second communication link.

[0183] Specifically, during step S302, a simple determination method can be adopted: the communication link on which the attack test target is located determines which communication link the proxy software (MAVProxy) should insert into. That is, if the attack test target is on the first communication link, insert into the first communication link; if the attack test target is on the second communication link, insert into the second communication link. For example, if the attack test target is a ground control station, then it can be determined that the proxy software (MAVProxy) inserts into the first communication link where the ground control station is located; if the attack test target is a UAV flight controller, then it can be determined that the proxy software (MAVProxy) inserts into the first and second communication links where the UAV flight controller is located.

[0184] In step S302, MAVProxy acts as a man-in-the-middle proxy for the MAVLink protocol, which can insert communication links between simulation components. The specific workflow is as follows: Figure 19 As shown. (Refer to...) Figure 19First, determine which communication link MAVProxy should insert into. If it's the communication link between Gazebo and PX4, then analyze the Gazebo and PX4 ports. Next, configure the Gazebo port, changing it to a new port. Then, set MAVProxy's master (receive port) to the original Gazebo port and the out (output port) to the new Gazebo port. This configuration completes the man-in-the-middle proxy setup. A similar configuration method is used for the communication link between QGC and PX4, which will not be elaborated on here. This proxy configuration method allows attackers to launch attacks on the communication links between simulation components, thereby damaging the UAV system.

[0185] In this embodiment, when performing step S302, regardless of which communication link the attack test target is on, the proxy software (MAVProxy) can be inserted into both the first and second communication links simultaneously. In this case, when performing step S303, which is the step of loading the corresponding attack plugin through the proxy software based on the attack test target, the following steps can be performed:

[0186] S30301. When the target of the attack test is on the first communication link, the attack plugin is loaded multiple times on the first communication link at a lower frequency, and the attack plugin is loaded multiple times on the second communication link at a higher frequency.

[0187] S30302. When the target of the attack test is on the second communication link, the attack plugin is loaded multiple times on the second communication link at a lower frequency, and the attack plugin is loaded multiple times on the first communication link at a higher frequency.

[0188] In steps S30301-S30302, "lower frequency" refers to a frequency that is lower than "higher frequency." The principle behind steps S30301-S30302 is as follows: regardless of which communication link the target of the attack is on, the attack plugin is loaded multiple times on both communication links. Furthermore, the attack plugin is loaded multiple times at a lower frequency on the communication link where the target is located, thus enabling direct attack testing on the target. On the communication link where the target is not located, the attack plugin is loaded multiple times at a higher frequency, thereby enabling attack testing on that communication link. Due to the correlation between different communication links, such attacks may overflow and affect the target itself. The higher attack frequency can amplify this overflow's impact on the target, thus achieving indirect attack testing on the target and enabling multi-faceted attack testing of the target.

[0189] In step S303, based on the attack test target, the corresponding attack plugin is loaded from the attack plugin library via the proxy software (MAVProxy). For example, if the attack test target is a ground control station, then the proxy software (MAVProxy) loads an attack plugin for ground control stations from the attack plugin library.

[0190] In step S304, the proxy software (MAVProxy) obtains the data packets sent by the source from the inserted communication link through a man-in-the-middle proxy. For example, if the attack test target is a ground control station, the proxy software (MAVProxy) can choose to insert into the first communication link. In this way, when the ground control station communicates with the UAV flight controller, at the same time, the ground control station sends data packets as the source and the UAV flight controller receives data packets as the destination, or the UAV flight controller sends data packets as the source and the ground control station receives data packets as the destination.

[0191] In step S305, the proxy software (MAVProxy) runs the loaded attack plugin, modifies the data packet sent by the source, and then executes step S306 to send the modified data packet to the destination in the inserted communication link, thereby realizing the attack test on the target.

[0192] IV. Verification of Unmanned Aerial Vehicle Security Attack Functions

[0193] The following section uses several specific attack plugins as examples to illustrate the attack tests conducted in steps S303-S306.

[0194] (I) Sensor data tampering attack test

[0195] The source port of the HIL_SENSOR message, i.e., the Gazebo port, is 4560, while the destination port, i.e., the PX4 port, is 52344. It's important to note that the system randomly assigns the PX4 port number, so the PX4 port number may differ in each experiment. First, the Gazebo port number needs to be configured, changing it to 4561. Next, set the MAVProxy's receive port (master) to 4561 and its output port (out) to 4560, thus completing the man-in-the-middle proxy configuration.

[0196] Next, the MAVProxy spoofed data injection attack plugin targeting the drone itself is loaded. This plugin can filter out and tamper with HIL_SENSOR packets. When the attacker enters the attack command "sensor_tempering" in MAVProxy, the attack program begins to run. First, MAVProxy listens to all packets during the communication between Gazebo and PX4 and filters out SENSOR_HIL packets. Then, the attack plugin modifies the xmag, ymag, and zmag fields in the payload, and finally forwards the tampered HIL_SENSOR packet to PX4.

[0197] Experimental results are as follows Figure 20 As shown, the ground station displayed "Baro sensor#0 failure: Timeout," and the drone immediately aborted its mission. Specifically, the tampered magnetic sensor data may not match the data from other sensors received by the PX4. This data inconsistency caused the PX4 to misjudge a hardware failure and take protective measures by discarding erroneous data packets. This behavior prevented the PX4 from receiving sensor data, including that from the Baro sensor, within the specified time, thus triggering a timeout error. Ultimately, the QGroundControl ground station displayed "Baro sensor#0 failure: Timeout," causing the drone to abort its flight mission.

[0198] (II) Sensor False Data Injection Attack Test

[0199] Furthermore, this paper presents an injection attack targeting the sensor. Wireshark packet capture analysis confirms that spoofed data packets were successfully injected into the PX4.

[0200] Experimental results are as follows Figure 21 and Figure 22 As shown, the drone system, interfered with by spurious sensor data packets, has crashed. In the Gazebo simulation environment, the drone crashes directly; in QGroundControl (QGC), the drone stops moving, and various data exhibit extremely unreasonable fluctuations. For example, the flight altitude rises to 58.5 meters and continues to climb (the normal flight altitude is 3 meters). Specifically, the injection of spurious sensor data packets causes the drone's control and navigation systems to misjudge, thus failing to correctly assess the current flight status and preventing the drone from taking appropriate control measures.

[0201] Due to the unique nature of this attack method, attackers can inject false sensor data packets into the drone at any point in its operation, potentially causing it to malfunction or crash. In this situation, QGroundControl will also receive incorrect sensor data, resulting in significant abnormal fluctuations in the drone's data. Ultimately, the entire drone system becomes chaotic, and its components malfunction due to interference.

[0202] (III) Control Command Tampering Attack Test

[0203] When all the controls fields in the HIL_ACTUATOR_CONTROLS message are set to 0.8, for a quadcopter (quadrotor drone), all four motors will receive the same control signal. This may cause the aircraft to maintain balance in the air, but it will not perform other complex maneuvers. However, in some situations, such as when the aircraft's center of gravity, motor power, and other external factors (such as wind, turbulence, etc.) do not meet the balance requirements, this control signal may cause the drone to go out of control or even crash.

[0204] After loading the fake data injection attack plugin targeting the drone itself using MAVProxy, the control command "hardware_backdoor" was entered to tamper with the attack command. The experimental results are as follows: Figure 23 As shown. When the attack occurs, in the Gazebo simulation environment, the drone receives a tampered HIL_ACTUATOR_CONTROLS data packet from PX4, in which the controls field of the HIL_ACTUATOR_CONTROLS message is all set to 0.8. Therefore, all four motors will receive the same control signal and rotate at the same speed, causing the aircraft to lose balance and eventually crash. At this point, PX4 detects the abnormal flight state and attempts to trigger fail-safe mode for landing. After receiving the fail-safe information from PX4, the ground station displays "Failsafe activated, triggering descend" to notify the operator that the drone has entered fail-safe mode.

[0205] (iv) Flight mission tampering attack test

[0206] Unlike the previous attacks, the following attack targets the communication between PX4 and Gazebo, but rather the communication between PX4 and the ground station QGC. It can be determined that the port number for PX4 communication is 14580, while the port number for QGC communication is 14550. Next, the QGC communication port number is configured to 14551, and then the MAVProxy's master port is set to 14550, and the out port is set to 14551, thus completing the man-in-the-middle proxy configuration. All subsequent attacks will be based on this configuration.

[0207] After loading the virtual data injection attack plugin for the control system into MAVProxy, enter the specific attack command "mission_tampering". It is important to note that the attack should be performed during the flight mission loading phase before the drone takes off. Figure 24 As shown, the drone's flight trajectory changed after the attack: the yellow line represents the ideal drone trajectory originally set by QGC, and the red line represents the actual drone trajectory after the flight mission tampering attack. As can be seen from the figure, the mission point position shifted a certain distance along both the x and y axes according to the attack settings, causing the drone to deviate from its intended flight path, thus confirming the attack's success.

[0208] (V) Hijacking Attack Test

[0209] Load the control system-targeting attack plugin into MAVProxy, and then enter the command "disarm force". The experimental results are as follows: Figure 25 As shown in the image, the COMMAND_LONG packet captured by Wireshark shows a value of 400 for the cmd field, 0 for param1, and 21196 for param2. This confirms that the packet's purpose is to force the drone to lock. Therefore, after being hijacked, the drone displayed on the Gazebo interface crashed to the ground and was unable to continue its flight mission.

[0210] (vi) GPS Spoofing Attack Test

[0211] A spoofing attack plugin targeting ground control stations was loaded, and the attack command "gps_spoofing" was input to achieve a GPS spoofing attack. Experimental results are as follows: Figure 26 As shown. By observing the information displayed in MAVProxy, it can be determined that the drone is still capable of completing its flight mission; however, in the QGC interface, the drone has stopped flying. Therefore, the GPS spoofing attack causes the drone's position displayed on the QGroundControl map to become inaccurate, and the operator will be unable to obtain the drone's real-time GPS information through the ground control station.

[0212] As can be seen from the examples of various specific attack plugins mentioned above, different attack tests can be achieved through different attack plugins.

[0213] V. Performance Testing of the Fake Data Injection Attack Tool (Determination of Attack Test Results)

[0214] In the aforementioned attack scheme, MAVProxy was successfully used as an attack tool to listen to, intercept, tamper with, and inject MAVLink messages, thereby achieving an attack on the UAV system. However, merely achieving the attack effect is insufficient to prove the effectiveness of the fake data injection attacker; that is, attack test results on the UAV system have not yet been obtained. To comprehensively evaluate the performance of the fake data injection attacker, the impact on communication link performance after the injection of the attack tool can be studied. Furthermore, studying the degree to which communication link performance is affected by the attack can help assess the stealth of the attack process, thereby improving the attack's undetectability.

[0215] To achieve this goal, this embodiment uses Wireshark to monitor and analyze the communication link in real time after the injection of the attack tool. By comparing the performance data of the communication link before and after the attack, the impact of the fake data injection attacker on the UAV system is evaluated, and the attack strategy is adjusted and optimized accordingly. This process will help to gain a more comprehensive understanding of the UAV system's performance when attacked, thereby further improving the performance of the attack tool.

[0216] In this test scenario, QGC was used to specify the UAV flight mission. During this time, Wireshark was used to monitor and analyze the communication links between PX4 and Gazebo, as well as between PX4 and QGC, in real time. First, PX4, Gazebo, QGC, and MAVProxy were started to ensure that communication between them was established. Next, packet capture was started in Wireshark, and the presence or absence of packets on the communication links after MAVProxy insertion was observed to evaluate the impact of MAVProxy on the throughput performance of the communication links.

[0217] Figure 27 and Figure 28 This is a graph showing the throughput over time in the communication link between QGroundControl and PX4. Figure 27 The situation before inserting the communication link for the agent software, therefore Figure 27 This can represent the quality of the communication link before the agent software is inserted into the communication link, i.e., the quality of the first communication link; Figure 28 The situation after inserting a communication link into the proxy software, therefore Figure 28This can represent the quality of the communication link after the agent software is inserted into the communication link, i.e., the quality of the second communication link; the red line represents the change of the throughput of the PX4 port over time, while the black line represents the change of the throughput of the QGroundControl port over time.

[0218] contrast Figure 27 and Figure 28 It can be seen that for the communication link between the ground control station QGroundControl and the UAV flight controller PX4 (the first communication link), when PX4 communicates directly with QGroundControl, the two lines completely overlap. After inserting MAVProxy, although there are some deviations, the two lines still largely overlap. Therefore, it can be concluded that inserting MAVProxy has virtually no impact on the first communication link between PX4 and QGroundControl. In other words, the attack test results for the first communication link indicate that it has strong anti-attack capabilities or strong stability.

[0219] contrast Figure 27 and Figure 28 It can be seen that, regarding the communication link (the second communication link) between the physical environment simulator Gazebo and the UAV flight controller PX4, the insertion of MAVProxy has a significant impact on the communication between Gazebo and PX4. For example... Figure 28 As shown, the red line represents the throughput of the PX4 port over time, and the black line represents the throughput of the Gazebo port over time. When Gazebo and PX4 communicate directly via TCP, the two lines largely overlap. However, after inserting MAVProxy, a significant difference in throughput occurs. The root cause is that they communicate via TCP. After each message transmission, the receiver sends an ACK to the sender, indicating that the data has been correctly received. However, the number of data packets sent by PX4 and Gazebo differs, and TCP has congestion control features, leading to different ACK packet flows on the two ports. Therefore, inserting MAVProxy increases the complexity of the communication link, resulting in a decrease in communication quality. In other words, the attack test results for the second communication link indicate that either the second communication link is less resistant to attacks, or the first communication link is less stable.

[0220] Compared with existing technologies, the drone safety testing method in this embodiment has three significant advantages:

[0221] First, the attack coverage is more comprehensive and flexible. Existing technologies mostly focus on single attack scenarios (such as only supporting communication interference or sensor fault injection), while this invention achieves full-link attack coverage of "UAV body - control system - ground control station" through plug-in design, and supports sequential combined attacks (such as "sensor false data injection → flight mission tampering → hijacking" continuous attacks), which can simulate multi-stage threats in real scenarios, and solve the problems of existing technologies having single attack methods and not being closely integrated with actual tasks;

[0222] Secondly, it is more practical and reproducible. Existing technologies are difficult to reuse due to reasons such as not being open source, while this invention is built on the open source tool MAVProxy and the PX4 / Gazebo simulation platform. The attack plugin can be dynamically loaded and the attack process can be reproduced. At the same time, the transparent proxy technology enables seamless tampering and forwarding of MAVLink messages, making the attack more covert and closer to real attack scenarios.

[0223] Third, it forms a complete testing loop. Existing technologies mostly only verify attack functions without assessing the impact on the UAV communication link. However, this invention simultaneously monitors performance indicators such as communication throughput through Wireshark during attack testing, quantifying the impact of attacks on the link's real-time performance and stability. This provides comprehensive data support for optimizing the UAV's anti-attack capabilities, encompassing both "functional effectiveness" and "performance impact," thus solving the problem of the single testing dimension in existing technologies.

[0224] In summary, the UAV security testing method in this embodiment addresses the shortcomings of existing security testing platforms, such as insufficient coverage of attack methods, lack of flexibility in usage, insufficient depth of test coverage, and insufficient integration of attack scenarios with flight missions. It constructs a fake data injection attacker based on MAVProxy to conduct multi-layered attack tests targeting the UAV itself, its control system, and the ground control station. Through methods such as sensor fake data injection, data tampering, and control command tampering, it interferes with the UAV's sensors and control system; through flight mission tampering and hijacking attacks, it disrupts the UAV's mission execution or control; through GPS spoofing attacks, it interferes with the ground control station's positioning and navigation, affecting the UAV's command and control; and by simulating various security threats, it comprehensively evaluates the UAV system's resistance to attacks such as fake data injection, control system hijacking, and communication interference, providing technical support for improving the security, reliability, and emergency response capabilities of UAVs in complex and ever-changing environments.

[0225] The drone safety testing method in this embodiment also has the following advantages:

[0226] 1. A pluggable fake data injection attack framework based on MAVProxy is built. It can achieve multi-level attacks on the UAV body, control system and ground control station by dynamically loading attack plugins. It supports flexible switching between single attacks and time-series combined attacks (such as continuous attacks of "sensor injection → mission tampering → hijacking").

[0227] 2. Design of attack plugins targeting the UAV itself, specifically including: methods to tamper with sensor data by intercepting and modifying HIL_SENSOR messages (virtual sensor data messages); methods to inject fake sensor data by generating fake HIL_SENSOR messages and injecting them into the communication link; and methods to tamper with control commands by modifying the controls field in HIL_ACTUATOR_CONTROLS messages (actuator control messages).

[0228] 3. Design of attack plugins for control systems, specifically including: a method to tamper with flight missions by intercepting and modifying the x and y coordinate fields in the MISSION_ITEM_INT message (mission waypoint message); and a method to hijack attacks by injecting COMMAND_LONG messages (long command messages, such as cmd=400, param2=21196) containing specific parameters.

[0229] 4. Design of attack plugins for ground control stations, namely, a method to achieve GPS spoofing attacks by intercepting and tampering with the lat (latitude) and lon (longitude) fields in the GLOBAL_POSITION_INT message (global location message).

[0230] 5. Application of transparent proxy technology based on MAVLink protocol in attacks: By configuring ports, the attacker is embedded in the communication link to intercept, parse, tamper with / inject, recalculate checksums and forward MAVLink messages seamlessly, ensuring that the attack process is unknown to both communicating parties.

[0231] 6. The execution flow of multi-level timing combination attacks includes a complete closed loop of attack preparation (platform startup and agent configuration), loading plugins to carry out attacks according to preset timing (such as sensor interference → task tampering → control takeover), and attack effect verification (simulation platform visualization + packet analysis).

[0232] 7. A method for constructing a software-in-the-loop simulation test platform based on PX4, Gazebo, and QGroundControl, which realizes communication between components through the MAVLink protocol, and combines an attacker to complete the verification of attack effects and the evaluation of communication link performance (such as throughput comparison).

[0233] A computer program that executes the drone safety testing method in this embodiment can be written into a computer device or storage medium. When the computer program is read out and run, the drone safety testing method in this embodiment is executed, thereby achieving the same technical effect as the drone safety testing method in the embodiment.

[0234] It should be noted that, unless otherwise specified, when a feature is referred to as "fixed" or "connected" to another feature, it can be directly fixed or connected to the other feature, or indirectly fixed or connected to the other feature. Furthermore, the descriptions of "upper," "lower," "left," and "right" used in this disclosure are only relative to the relative positional relationships of the components of this disclosure in the accompanying drawings. The singular forms "a," "an," and "the" used in this disclosure are also intended to include the plural forms, unless the context clearly indicates otherwise. Moreover, unless otherwise defined, all technical and scientific terms used in this embodiment have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in this embodiment specification is only for describing specific embodiments and is not intended to limit the embodiments of the invention. The term "and / or" as used in this embodiment includes any combination of one or more of the associated listed items.

[0235] It should be understood that although the terms first, second, third, etc., may be used to describe various elements in this disclosure, these elements should not be limited to these terms. These terms are only used to distinguish elements of the same type from each other. For example, a first element may also be referred to as a second element without departing from the scope of this disclosure, and similarly, a second element may also be referred to as a first element. The use of any and all instances or exemplary language (“e.g.,” “such as,” etc.) provided in this embodiment is intended only to better illustrate embodiments of the invention and, unless otherwise required, does not impose a limitation on the scope of embodiments of the invention.

[0236] It should be recognized that embodiments of the present invention can be implemented or carried out by computer hardware, a combination of hardware and software, or by computer instructions stored in a non-transitory computer-readable storage medium. The method can be implemented using standard programming techniques—including a non-transitory computer-readable storage medium configured with a computer program, wherein such a storage medium causes the computer to operate in a specific and predefined manner—according to the methods and drawings described in the specific embodiments. Each program can be implemented in a high-level procedural or object-oriented programming language to communicate with the computer system. However, if desired, the program can be implemented in assembly or machine language. In any case, the language can be a compiled or interpreted language. Furthermore, for this purpose, the program can run on a programmed application-specific integrated circuit (ASIC).

[0237] Furthermore, the procedures described in this embodiment can be performed in any suitable order, unless otherwise indicated by this embodiment or otherwise obviously contradictory to the context. The procedures (or variations and / or combinations thereof) described in this embodiment can be executed under the control of one or more computer systems configured with executable instructions, and can be implemented by hardware or a combination thereof as code (e.g., executable instructions, one or more computer programs, or one or more applications) that commonly executes on one or more processors. A computer program includes multiple instructions executable by one or more processors.

[0238] Furthermore, the method can be implemented in any suitable type of computing platform, including but not limited to personal computers, minicomputers, mainframes, workstations, networked or distributed computing environments, standalone or integrated computer platforms, or in communication with charged particle tools or other imaging devices, etc. Aspects of embodiments of the invention can be implemented as machine-readable code stored on a non-transitory storage medium or device, whether removable or integrated into a computing platform, such as a hard disk, optical read and / or write storage medium, RAM, ROM, etc., such that it is readable by a programmable computer, and when the storage medium or device is read by the computer, it can be used to configure and operate the computer to perform the processes described herein. Furthermore, the machine-readable code, or portions thereof, can be transmitted via wired or wireless networks. The invention of this embodiment includes these and other different types of non-transitory computer-readable storage media when such media comprises instructions or programs that implement the steps above in conjunction with a microprocessor or other data processor. Embodiments of the invention also include the computer itself when programmed according to the methods and techniques of embodiments of the invention.

[0239] A computer program can be applied to input data to perform the functions of this embodiment, thereby transforming the input data to generate output data stored in non-volatile memory. The output information can also be applied to one or more output devices, such as a display. In a preferred embodiment of the invention, the transformed data represents physical and tangible objects, including a specific visual depiction of physical and tangible objects generated on the display.

[0240] The above are merely preferred embodiments of the present invention. The embodiments of the present invention are not limited to the above-described implementations. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the embodiments of the present invention, as long as they achieve the same technical effects, should be included within the scope of protection of the embodiments of the present invention. Within the scope of protection of the embodiments of the present invention, the technical solutions and / or implementation methods can have various modifications and variations.

Claims

1. A method for testing the safety of unmanned aerial vehicles (UAVs), characterized in that, The drone safety testing method includes: An unmanned aerial vehicle (UAV) platform is established; the UAV platform includes a ground control station, a UAV flight controller, and a physical environment simulator. The ground control station and the UAV flight controller are connected via a first communication link, and the physical environment simulator and the UAV flight controller are connected via a second communication link. Both the first and second communication links use the MAVLink protocol. A fake data input attack tool is established; the fake data input attack tool includes an attack plugin library and agent software based on the MAVLink protocol, and the attack plugin library includes multiple attack plugins; The attack plugin is loaded into the proxy software to conduct attack tests on the drone platform; The establishment of the fake data input attack tool includes: Multiple attack test targets were identified; the attack test targets included the ground control station, the UAV flight controller, and the physical environment simulator. Obtain the attack plugin corresponding to each of the aforementioned attack test objects; Based on each of the aforementioned attack plugins, the attack plugin library is constructed. The step of loading the attack plugin into the proxy software to perform attack tests on the drone platform includes: Identify the target of the attack test; Based on the attack test target, the proxy software performs a man-in-the-middle proxy based on the MAVLink protocol to insert into the first communication link and / or the second communication link; Based on the attack test target, the corresponding attack plugin is loaded through the proxy software; From the inserted communication link, obtain the data packets sent by the source; Run the loaded attack plugin to modify the acquired data packets; The modified data packet is sent to the destination in the inserted communication link.

2. The UAV safety testing method according to claim 1, characterized in that, The step of obtaining the attack plugin corresponding to each of the attack test objects includes: Iterate through all the attack test objects described; For any of the attack test objects, obtain the MAVLink message in the MAVLink protocol corresponding to the attack test object, obtain the function corresponding to the MAVLink message, add a hook function to the function corresponding to the MAVLink message, obtain the attack code file, and generate a corresponding attack plugin based on the attack code file.

3. The UAV safety testing method according to claim 2, characterized in that, The step of obtaining the attack plugin corresponding to each of the attack test objects respectively also includes: Randomly select multiple of the aforementioned attack plugins; The attack code files are copied and exchanged between the selected attack plugins.

4. The UAV safety testing method according to claim 1, characterized in that, The step of loading the attack plugin into the proxy software to perform attack tests on the drone platform also includes: The quality of the first communication link and the quality of the second communication link are detected; the quality of the first communication link is the quality of the communication link before the proxy software is inserted into the communication link, and the quality of the second communication link is the quality of the communication link after the proxy software is inserted into the communication link. The quality of the first communication link and the quality of the second communication link are compared to obtain the link quality comparison results; The attack test results are determined based on the link quality comparison results.

5. The unmanned aerial vehicle (UAV) safety testing method according to claim 1, characterized in that, The insertion of the first communication link and / or the second communication link further includes: When the attack test target is on the first communication link, insert into the first communication link; When the attack test target is on the second communication link, insert into the second communication link; or Simultaneously insert the first communication link and the second communication link.

6. The UAV safety testing method according to claim 5, characterized in that, When the first communication link and the second communication link are simultaneously inserted, the step of loading the corresponding attack plugin through the proxy software according to the attack test object includes: When the attack test target is on the first communication link, the attack plugin is loaded multiple times on the first communication link at a lower frequency, and the attack plugin is loaded multiple times on the second communication link at a higher frequency. When the attack test target is on the second communication link, the attack plugin is loaded multiple times on the second communication link at a lower frequency, and the attack plugin is loaded multiple times on the first communication link at a higher frequency.

7. A computer device, characterized in that, It includes a memory and a processor, the memory being used to store at least one program, and the processor being used to load at least one program to execute the drone safety testing method according to any one of claims 1-6.

8. A computer-readable storage medium storing a processor-executable program, characterized in that, The processor-executable program, when executed by the processor, is used to perform the drone safety testing method according to any one of claims 1-6.

Images