Attacking civilian UAVs

May 15, 2023

During this project, we explored possible attacks and countermeasures against civilian UAVs. Cheap civilian drones have not just become a fun hobby for FPV racers and film enthusiasts, but also a danger for aviation safety and privacy. They are used in the field to provide intelligence against opposing forces or to combat them with deadly precision.

Contents

  1. Motivation
  2. Limitations and Scope
  3. Setup and Hardware
  4. Exploring the Attack Surface
  5. Capturing and Hijacking Video Streams
  6. Jamming and Spoofing Remote Controls
  7. Other Attack Vectors
  8. Detection
  9. Conclusion
  10. References

1. Motivation

Intelligence is everything on the modern battlefield, and civilian drones have proven to be valuable assets in this regard. They provide spotting capabilities for artillery or carry explosives for sabotage operations and precision strikes. Outside of combat zones, they pose a significant threat to aviation safety and general privacy. These circumstances make drones interesting targets for remote attacks, which we wanted to explore in this post.

2. Limitations and Scope

Due to budget and time constraints, we focussed our research primarily on fairly cheap, Chinese FPV drones. We only conducted experiments using low power soft-kill systems, since hard-kill measures, like net- or projectile launchers or high power jammers would have a high chance of destroying drones or causing collateral damage.

3. Setup and Hardware

Drone
The main criteria for choosing the drone, were availability and compatibility with our existing FPV hardware. Specifically, it had to support the FrySky D8 protocol and send video signals over the 5.8GHz band. The final decision was made in favor of the Mobula 6 from Happymodel.

Our FPV hardware consisted of the Radiomaster T8 Lite remote controller and a pair of simple VTX goggles by HGLRC.

SDR
To be able to flexibly send and receive data on different frequency bands, we also needed a software defined radio. Because it was affordable and covered all required bands (1MHz - 6GHz), we chose the HackRF One.

Since the HackRF did not offer enough power for some of our tests, we also added an amplifier.
For additional filtering, a 2.4GHz band-pass filter was used as well.

Antennas
For video transmission/reception we utilized one of the FPV goggles 5.8GHz antennas and for omnidirectional capture/jamming of RC signals a 2.4GHz antenna of an ALFA Wi-Fi card. To get a more predictable and focussed jamming arch, we also purchased a 2.4GHz Yagi antenna.

Software
To analyze and replay RC signals, we primarily used the Universal Radio Hacker. For capturing and (de)modulating video transmissions, we chose SDRangel. Our jammers were constructed using GnuRadio with a few custom blocks. The drone was configured using Betaflight.

4. Exploring the Attack Surface

Most FPV drones offer two primary attack vectors. The video stream broadcasted by the drone and received by the FPV goggles, as well as the RC signal send by the controller and interpreted by the drone's flight controller. Our drone uses the 5.8GHz bands to transmit video and the 2.4GHz bands for remote control. Since almost all consumer hardware using radio signals, which is sold in the US, has to be registered by the FCC, getting specific frequency ranges for devices like our controller is quite easy. They can be found in the official and publically available FCC database using their unique ID. Our controller for example utilizes the 2416-2466MHz range and has a power output of 43.9mW. The frequency for the video signal can more or less be set freely by the operator prior to flight. Happymodel provides a table of recommended frequency channels. Having this information, we can jam, spoof and capture these signals.
Other drones provide additional targets such as GPS or drone location protocols (e.g. DJI DroneID) which can be used to track drone and pilot movement. GPS may also be spoofed to circumvent geofencing or to abuse return-to-home functionality.

5. Capturing and Hijacking Video Streams

As mentioned above, the drone operator can freely choose any band in the 5.8GHz spectrum to broadcast video. So the first step in capturing or hijacking the streaming signal, is detecting the frequency used. This task can be accomplished fairly easily by using a simple spectrum analyzer, roughly tuned to the center of the 5.8GHz spectrum. Now we simply tune the frequency up and down, while watching our waterfall output. Even at greater distances, the video stream signal can be spotted with no issues.

Knowing the more or less exact frequency used in the transmission, we can either capture live video or send our own data to take the operator's vision. Should the operator not have visual contact with the drone, this will, in most cases, result in a crash. He is also unable to change the used frequency band, since this would require a wired connection to a computer. It should be noted, that for this attack to be effective, the antenna used for sending the signal has to be directed at the operator and his goggles and not the drone itself. The smaller the distance to the operator or the stronger the signal send, the more likely the attack will succeed.

Since our drone is fairly simple, it uses an analog signal to broadcast the video feed. Using the ATV demodulator in SDRangel we can demodulate and view the stream. This particular (de)modulator does not support color, even though it would be possible in theory.

Just as we can demodulate them, we can also modulate analog signals from MP4 or PNG files and broadcast the colorless video.

If we don't wish to send our own video, we can of course also just send random noise to jam the drone's signal.
Simple example using Gnu Radio:

For maximum range and effectiveness, an amplifier may be added.

Doing so, we achieved a reliable hijack/jamming range of around 5 meters. At greater distances, the interference was noticeable, but not strong enough to effectively hinder flight. The broadcasting power of the drone, configured by the operator in Betaflight, also influenced the jamming success.

6. Jamming and Spoofing Remote Controls

During our research and measurements, we discovered that the FrySky protocol utilized by our Drone, uses FHSS (Frequency-hopping spread spectrum). This means, that in contrast to the 5.8GHz video signal, which uses one single frequency band, the RC transmission is divided into multiple smaller sub-bands. The signal rapidly switches between these bands in a pseudo-random manner, making it significantly less vulnerable to interference or jamming. The seed used to determine the switching pattern is exchanged during the initial binding procedure with the remote controller. By recording and analyzing the signal, we were able to determine, that the drone communication utilizes 49 channels, with 1.5MHz spacing, adding up to a total bandwidth of around 70MHz. Since our SDR was only capable of transmitting over a 20MHz bandwidth, this posed a significant challenge.

Our first approach was to record different RC commands like disarms (full deactivation of flight systems) or erratic control inputs, which could cause the drone to crash. By analyzing the signals of the remote controller, we determined a handful of channels and their specific frequencies and attempted to replay the captured signals on them in an endless loop. We were hoping to get lucky and hit one of the channels while the drone was expecting commands from that frequency. For this to work, our signal would have to be more powerful than the remote controller. After multiple attempts, we were able to crash the drone occasionally. To make this attack work more reliably, one would have to analyze the full signal bandwidth, calculate the FHSS seed and determine the next channel to be used.

Since our replay attack was unreliable, we attempted a jamming approach next. Instead of sending spoofed RC commands, we would send as much noise, with as much power as possible, to drown out the controller's signal and cause the drone to lose its connection. Depending on the configured failsafe, this could either cause the drone to land on the spot, return to predetermined GPS coordinates or, as was the case with our drone, drop to the ground. Of course, we would be unable to simply jam the entire 70MHz bandwidth, so we had to develop a slightly more so­phis­ti­ca­ted jammer. The best jammers use so called protocol-aware jamming, which, similar to what we mentioned above, attempts to calculate the used FHSS seed and reactively jam the next channels. Implementing a protocol-aware jammer requires either two SDRs or a single, full-duplex capable SDR. Neither was available to us at the time. We therefor chose a slightly cruder method: sweep jamming.

Instead of jamming on one single frequency, a spectrum is chosen and swept over in a curve like manner, trying to generate as much noise as possible over an area larger than our actual bandwidth. The wider the spectrum, the less effective the jamming. For our attack, we chose 2416MHz as the lower and 2466MHz as the upper boundary.

To have enough power to drown out the controller's signal, we daisy-chained three amplifiers for a total gain of 30dBm.

We first tested our omnidirectional 2.4GHz antenna. It was able to effectively jam the drone up to a radius of around 2 meters.

Jammer activated at 11 seconds (Omni):

We also tested our Yagi antenna. After flying into the antenna's arch, the drone lost its connection immediately. With the correct orientation and rotation, we were able to achieve a reliable jamming range of around 3 meters.

Jammer active (Yagi):

The jamming success was of course also dependent on the distance of the remote controller to the drone. The ranges mentioned above were those at which the drone crashed, even with the remote being fairly close.
While technically possible and useful for reverse engineering, decoding the remote commands from the controller was deemed irrelevant for any attack on the drone or the operator.

7. Other Attack Vectors

Some other interesting attack vectors, which were however not directly applicable to our drone:

GPS
Many drones rely on GPS for different navigation tasks. May it be to keep the drone from flying into restricted airspace or to have it return home after an unexpected RC disconnect. GPS however is an incredibly low-power signal, which makes it very vulnerable to jamming or spoofing attacks. In 2011 Iran was able to spoof the GPS guidance system of an American RQ-170 drone and force it to land in Iranian territory.

DJI Drone ID (or equivalent)
To be able to more effectively trace and capture perpetrators using their drones for nefarious purposes, DJI added the DroneID protocol to their products. This protocol constantly broadcasts the exact position of the drone and the pilot. Using DJI's purpose build hardware, law enforcement can decode this data. According to DJI, this data is sent encrypted. Researchers of the Ruhr Universität Bochum however were able to capture and decode it without issues. This is especially dangerous for soldiers using these drones for reconnaissance. A well-equipped adversary would be able to pinpoint the pilot's position and retaliate. It would therefor be advisable to patch the firmware and remove the DroneID feature, before deploying DJI drones in the field.
According to the new EU standard EN 4709, all drones manufactured after January 2024 will be required to implement a feature similar to DroneID (Direct Remote ID).

Image: https://github.com/RUB-SysSec/DroneSecurity

Firmware
The firmware required to operate the drone's many systems has to be either flashed by the user itself or is pre-flashed in the factory. This could allow an outside attacker or the manufacturer to flash malicious firmware. This would however require extensive knowledge of the drone's inner workings, but could theoretically circumvent any encryption or FHSS implemented. While an outside attack, due to its complexity, seems fairly unlikely, supply chain attacks are a real danger, especially with many drones being manufactured in China. We also conducted a static analysis of the Betaflight firmware, but concluded that no feasibly exploitable vulnerabilities could be found for our drone.

8. Detection

Since jamming is power intensive and may also interfere with uninvolved devices, it is unwise to have a jammer running for extensive periods. We therefor experimented with different detection techniques, which would alert the jamming system to the presence of a drone and allow it to reactively engage the intruder.

RF based
The first concept was to detect the drone or the remote controller via their broadcasted radio signals. This would require a database of known fingerprints for matching. With the appropriate hardware, it would also allow the more or less accurate locating of the pilot. Our attempts at detecting a truly unique pattern in the drone's transmissions were however unsuccessful.

Computer vision based
Since our attempts at radio fingerprinting failed, we chose a different approach. Our idea was to train an object classifier to detect drones via a camera, which could for example be mounted on a building. If the detector is confident the object is actually a drone, it should trigger the jammer.

We chose YOLOv8 as our base detection model and gave it additional training on pictures of drones in general as well as some handcrafted samples of our own drone. For this, we mostly took videos of our drone flying and extracted the frames as JPG images.

After three training runs, our model was able to detect most drones and especially the Mobula 6. We then combined this model with our jammer into a python tool. (Some of the visual candy was left out in the source code below)

import cv2
import supervision as sv
from ultralytics import YOLO
from jammer import top_block
from time import time

# preparing the jammer (2.426GHz)
tb = top_block()
tb.center_freq = 2426e6

# starting video capture from webcam
capture = cv2.VideoCapture(-1)
capture.set(3, 640)
capture.set(4, 480)

# loading our trained weights
model = YOLO("weights/last.pt")

box_annotator = sv.BoxAnnotator(thickness=1, text_thickness=1, text_scale=0.5)
start_ts = 0

while True:
  # read frame
  _, image = capture.read()

  # get detections from YOLOv8
  result = model(image)[0]
  detections = sv.Detections.from_yolov8(result)

  # filter detections with low confidence
  detections = detections[detections.confidence > 0.8]

  # start/stop jammer
  if len(detections) > 0:
    tb.start_jammer()
    start_ts = time()
  else:
    if time() - start_ts > 5:
      tb.stop_jammer()

  # draw box around detections
  image = box_annotator.annotate(scene=image, detections=detections)

  cv2.imshow("Detector", image)

  if cv2.waitKey(10) & 0xFF == ord("q"):
    break

capture.release()
cv2.destroyWindow("Detector")
tb.stop_jammer()

Test with a camera attached to our Yagi-antenna:

9. Conclusion

Because of the many systems and sensors they encompass, drones offer interesting targets for cyberattacks. During our tests, we were able to take over the drone's video feed, watch through its eyes and crash it in the end. Most manufacturers (besides maybe DJI) seem to have little interest in implementing security measures in their drones. While spoofing and sniffing attacks could be prevented, by implementing encryption and/or rolling codes on the drone and the connected FPV hardware, jamming will almost always remain a problem. An attacker with enough resources will be able to overpower most remote control and guidance systems.

10. References

https://www.ndss-symposium.org/ndss-paper/drone-security-and-the-mysterious-case-of-djis-droneid/
https://github.com/RUB-SysSec/DroneSecurity
https://dl.acm.org/doi/10.1145/3485272
https://kth.diva-portal.org/smash/record.jsf?pid=diva2%3A1463784&dswid=-5182
https://www.mdpi.com/1424-8220/22/4/1487
https://ieeexplore.ieee.org/document/8398711
https://ieeexplore.ieee.org/document/9217129
https://www.researchgate.net/publication/343054471_A_Drone_Detection_and_Inhibition_Tool_using_GNURadio_and_a_Raspberry_Pi
https://en.wikipedia.org/wiki/Iran%E2%80%93U.S._RQ-170_incident https://github.com/ultralytics/ultralytics https://www.kaggle.com/datasets/muki2003/yolo-drone-detection-dataset