Welcome back, cyberwarriors!

A while back, we walked you through building your own hacking drone. It was a drone loaded up with tools designed to help you out during an actual pentest. That was a hands-on project in every sense of the word. If you built one, you probably learned a ton just from putting the hardware together.

This time, we’re doing something different. No soldering iron. We’re staying entirely inside your laptop working with the Damn Vulnerable Drone, which is an open-source simulator built for teaching you exactly how drones get hacked, without you ever touching a real drone.

The Damn Vulnerable Drone

The Damn Vulnerable Drone, or DVD, is a training simulator that was made for people who want to learn drone hacking without buying a drone. It recreates an entire drone system in software, including a flight controller, an onboard companion computer, a ground control station and the wireless links connecting them all. Every piece is there, and every piece runs inside Docker containers on a single computer.

The project was built by Nicholas Aleks, a security researcher and co-founder of DEF CON Toronto, and it’s aimed squarely at intermediate-level red teamers and hacking enthusiasts who want to practice with actual drone protocols and architecture. Drone hardware and radios are genuinely expensive, and a mistake on a real flight controller can be costly. You get to make your mistakes safely, over and over, until you actually understand what you’re doing. DVD runs actual ArduPilot firmware as an ordinary program and pairs ArduPilot’s SITL with Gazebo, which is a 3D robotics simulator that supplies realistic physics. Motors spin up, GPS signals drift the way they really do, and the drone actually flies through a rendered 3D world.

Under the Hood

Every Docker container gets its own address on an internal network. That’s a design choice that mirrors how a real drone’s components actually work. The first piece is the Flight Controller, which runs the ArduPilot firmware itself and talks directly to the Gazebo simulator to process virtual sensor data. The second piece is the Companion Computer, which handles Wi-Fi, camera streaming, telemetry logging, and autonomous navigation, and which also exposes its own web interface for you to interact with. The third piece is the Ground Control Station, the pilot’s side of the operation, covering mission planning, mapping, video, and joystick control, all communicating over a simulated wireless MAVLink link. And the fourth piece is the Simulator itself, the Gazebo container that models flight physics behind the scenes. The documentation specifically tells you not to attack this fourth container directly, because doing so can crash the entire lab out from under you. Everything else is fair game. That one, leave alone.

Getting Started

To install it we need to pull down containers. The project offers two configurations based on whether you have a dedicated graphics card.

If the answer is no, you need Lite Mode. It uses a simplified 2D flight model, needs no GPU at all, and runs comfortably on 4 to 8 GB of RAM, 2 CPU cores, and about 100 GB of disk space. It works on Kali Linux or most other Linux distributions, and you can run it either on bare metal or inside a virtual machine. If the answer is yes, Full Mode gives you the complete Gazebo 3D environment, but it asks more of your machine in return. You need 8 to 16 GB of RAM, 2 to 4 CPU cores, 100 GB of disk space, and a GPU with at least 2 GB of VRAM supporting OpenGL 3.0 or newer. Full Mode is Kali Linux only, and it strongly prefers bare metal, though a virtual machine with GPU passthrough will also work.

Kali Linux is the officially supported operating system either way, and both modes need Docker and Docker Compose installed as the only real software dependency you have to worry about. Once Docker is installed, the whole lab comes up with a handful of commands. 

First, if Docker isn’t already on your system, you’ll want to install it:

kali > printf '%s\n' "deb https://download.docker.com/linux/debian bullseye stable" | sudo tee /etc/apt/sources.list.d/docker-ce.list

kali > curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/docker-ce-archive-keyring.gpg

kali > sudo apt update -y
kali > sudo apt install docker-ce docker-ce-cli containerd.io -y
kali > sudo systemctl enable docker --now
kali > sudo usermod -aG docker $USER && newgrp docker

Then, clone the repository and pull down the containers. If you’re going with Lite Mode, do this:

kali > git clone https://github.com/nicholasaleks/Damn-Vulnerable-Drone.git && cd Damn-Vulnerable-Drone
kali > docker compose -f docker-compose-lite.yaml pull

From there, three small scripts manage the whole lab’s lifecycle for you:

kali > sudo ./start.sh --mode lite --Wi-Fi wpa2
kali > sudo ./status.sh
kali > sudo ./stop.sh

The start.sh script alone has quite a few options worth knowing about. The –mode full or –mode lite flag picks your simulation type, matching the two modes described above. And the –Wi-Fi wep or –Wi-Fi wpa2 flag is optional, but it’s worth turning on, because it spins up a virtual wireless network alongside everything else. That means your practice can actually include real Wi-Fi attacks as the very first step, instead of starting the exercise with network access already handed to you.

Interface and Feedback

Once everything is up and running, DVD is controlled through a browser-based management console sitting at localhost:8000

This console is really where the whole exercise plays out. A set of buttons trigger five distinct flight states: Initial Boot, Arm & Takeoff, Autopilot Flight, Emergency/Return-to-Land, and Post-Flight Data Processing. Each one simulates a different phase of a drone’s mission and opens up a different attack surface for you to explore. Triggering “Arm & Takeoff,” for instance, actually gets the simulated drone airborne, which gives GPS and navigation-based attacks something real to act on.

That mapping to real flight phases is there for a reason. A drone accepts different commands, and trusts different sources of data, depending on whether it’s sitting idle on the ground, climbing out after takeoff, cruising on autopilot, or executing an emergency fail-safe. That means exercises built around each individual state end up testing different parts of the system. 

The Attack Scenario Library

This is really the heart of the whole project. It has more than 40 named attack scenarios, organized into six categories, each one with its own documentation page and a spoiler-tagged walkthrough waiting behind it. It’s a deliberately broad menu, and it’s worth noticing that some scenarios are about gathering information without being noticed, while others are about actively manipulating or outright breaking the system in front of you.

Reconnaissance scenarios are about passively fingerprinting the drone, its companion computer, and its ground station by watching Wi-Fi and MAVLink traffic go by, without touching anything yet. Protocol Tampering scenarios involve spoofing telemetry values the drone reports, things like its GPS position, battery level, or system status, to see whether the system properly checks what it’s being told. Denial of Service scenarios focus on disrupting flight through methods like Wi-Fi deauthentication or flooding the communication link until it can’t keep up. Injection scenarios involve sending forged commands directly into the MAVLink stream, ranging all the way from a simple waypoint change to a full companion-computer takeover. Exfiltration scenarios are about pulling data off the drone entirely, whether that’s flight logs, mission plans, or content from the camera feed. And Firmware Attacks focus on modifying or reverse-engineering the ArduPilot firmware itself, right down at the code level.

Because every scenario runs against fully simulated components, you actually get to see the complete effect of an attack play out. A spoofed GPS reading really does nudge the simulated flight path off course. A flooded communication link really does degrade control, right in front of you. And you get to watch all of it happen without any of the legal or physical risk that would come with testing the same techniques on live hardware.

Wi-Fi and Non-Wi-Fi Modes

DVD can be deployed in two different ways, and which one you pick depends on which part of the attack chain you actually want to practice. Wi-Fi Mode spins up a real, functioning virtual wireless network, broadcasting an SSID called Drone_Wi-Fi on the 192.168.13.0/24 range, with your choice of weak WEP encryption or the considerably stronger WPA2. This lets the whole exercise start from the very beginning, with you playing the role of an attacker who doesn’t have network access yet and has to earn it.

Non-Wi-Fi Mode skips that entire step and simply brings the containers up directly. This is useful if you just want to focus purely on protocol-level attacks, or if you’re not running inside a Kali VM with wireless card support to begin with. In this mode, the documentation asks you to treat the situation as though initial access to the drone’s data link has already been established, so you can jump straight to the MAVLink-level work.

Summary

The Damn Vulnerable Drone takes an idea that’s already well proven in web security and applies it to a domain where practicing on the real thing tends to be expensive. By simulating a full ArduPilot and MAVLink drone stack inside Docker, right down to Wi-Fi, camera streaming, and flight physics, it hands penetration testers, students, and researchers a realistic, disposable target, backed by more than 40 documented attack scenarios and built-in walkthroughs to guide the way. It won’t teach you to fly a real drone. But it will teach you exactly how one can be hacked, and for anyone working in drone security, that’s the more useful skill anyway.

If you’re interested in drone hacking, check out our Building Your Own Hacking Drone series, where we walk you through attack scenarios targeting Bluetooth and Wi-Fi across a wide range of devices.

We also offer a Drone Hacking training course, taking place November 10-12 at 4:00 PM UTC, available to Subscriber and Subscriber Pro students.

The post Drone Hacking: Hacking UAVs with Damn Vulnerable Drone first appeared on Hackers Arise.