# Damn Vulnerable Drone: a drone hacking lab that runs in Docker > Damn Vulnerable Drone is an MIT licensed, intentionally vulnerable drone hacking simulator built on ArduPilot SITL, Gazebo and MAVLink, packaged as a set of privileged Docker containers with a management console and scenario walkthroughs. It suits offensive security practitioners and penetration testers who want a legal, hardware free place to learn drone attack paths, and it is not a drone, a firmware image or a tool for use against real aircraft. **nicholasaleks/Damn-Vulnerable-Drone** — Damn Vulnerable Drone is an intentionally vulnerable drone hacking simulator based on the popular ArduPilot/MAVLink architecture, providing a realistic environment for hands-on drone hacking. - Repository: https://github.com/nicholasaleks/Damn-Vulnerable-Drone - Stars: 851 · Forks: 155 - Language: JavaScript - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/nicholasaleks-damn-vulnerable-drone ## A lab for people who cannot legally fly a drone to attack The Damn Vulnerable Drone is described as an intentionally vulnerable drone hacking simulator based on the popular ArduPilot and MAVLink architecture, providing a realistic environment for hands-on drone hacking. The framing is a training environment, and the README spells out the audience: offensive security professionals, intermediate level security professionals, pentesters and hacking enthusiasts. The stated purpose is to enhance offensive security skills within a controlled environment. The reason this needed to exist is cost. The README argues that the project was designed to address the substantial expenses often linked with drone hardware, hacking tools and maintenance, and that a free simulator lets people immerse themselves in drone hacking without financial concerns. The analogy the project draws is flight simulators, which pilots use for training, applied to attackers. That makes this the drone equivalent of the deliberately vulnerable web applications used in security courses. The value is not that the lab is realistic in every detail, but that it lets someone practise a full attack path safely, repeatably and at no cost, with walkthroughs available when they get stuck. The repository is MIT licensed, primarily JavaScript, with the last push to the repository on 2026-09-29 and no published GitHub releases. ## Lite Mode drops Gazebo and runs ArduPilot flight dynamics instead The simulator can be run in two modes depending on available hardware, and the difference is bigger than a graphics setting. Lite Mode needs no GPU. It runs on Kali Linux, which is recommended although it may run on most Linux distributions, on bare metal or in a virtual machine without GPU passthrough. The minimum hardware is 4 to 8 GB of RAM, two processor cores, 100 GB of disk storage and 4 GB of swap. Docker and Docker Compose are the software requirements. Instead of Gazebo, it runs a 2D lightweight simulator using ArduPilot's built-in flight dynamics model. The README recommends Lite Mode for users who cannot meet the GPU requirements of Full Mode, or who simply want a faster and more lightweight setup. That is the sensible default for a first install. Full Mode is the 3D environment with Gazebo, and the requirements narrow sharply. The operating system is Kali Linux, and no other operating system is supported. Bare metal is recommended for best performance, and the section on using a virtual machine is cut off in the README excerpt, but the mention of GPU passthrough in the Lite Mode section indicates what that passage covers. One of the feature entries is qualified in a way worth noting: one-click QGroundControl user interface launching is described as only supported on x86 architecture. If you are on a different processor family, the ground control station integration is where you will hit a wall. ## Four privileged containers on a private 10.13.0.x network The architecture is a set of Docker services wired to each other over a dedicated network, and the compose file shows the whole shape of the lab. The flight controller runs privileged, shares a named volume called serial-uart-socket mounted at /sockets, and sits at 10.13.0.2 on the simulator network. ```yaml flight-controller: image: n1ckaleks/damn-vulnerable-drone-flight-controller:latest container_name: flight-controller privileged: true build: context: . dockerfile: ./flight-controller/Dockerfile volumes: - serial-uart-socket:/sockets networks: simulator: ipv4_address: 10.13.0.2 ``` The companion computer sits at 10.13.0.3, also privileged, and adds the web interface on port 3000 and the ROS middleware configuration. ```yaml companion-computer: image: n1ckaleks/damn-vulnerable-drone-companion-computer:latest container_name: companion-computer privileged: true extra_hosts: - "host.docker.internal:host-gateway" ports: - "3000:3000" environment: - WIFI_ENABLED - ROS_DOMAIN_ID=42 - RMW_IMPLEMENTATION=rmw_cyclonedds_cpp - CYCLONEDDS_URI=file:///etc/cyclonedds.xml networks: simulator: ipv4_address: 10.13.0.3 ``` The ground control station takes 10.13.0.4 and depends on the companion computer, and the simulator service completes the set. Every container is privileged, and the serial-uart-socket volume is how the simulated serial link between the flight controller and the companion computer is carried. The privilege level is worth a moment of thought. These containers run as privileged Docker containers with access to devices, which is how a serial link and a display are simulated, but it also means the lab is only as safe as the host running it. Treat the machine as a disposable lab box, not as a workstation. ## The ground control station borrows your X11 socket and DISPLAY The ground control station is the only service that needs the outside world, and the way it does that is instructive. ```yaml ground-control-station: image: n1ckaleks/damn-vulnerable-drone-ground-control-station:latest container_name: ground-control-station privileged: true environment: - WIFI_MODE - DISPLAY=${DISPLAY} - QT_NO_MITSHM=1 - XDG_RUNTIME_DIR=/tmp - XAUTHORITY=/home/gcs/.Xauthority - HEADLESS=0 volumes: - /tmp/.X11-unix:/tmp/.X11-unix - ${HOME}/.Xauthority:/home/gcs/.Xauthority:ro - /etc/machine-id:/etc/machine-id:ro devices: - /dev/dri:/dev/dri ``` The X11 Unix socket directory is bind mounted, the Xauthority file is mounted read only, and the DISPLAY variable is passed through from the host. In other words, the Qt based ground control station draws on your desktop rather than inside the container. Two of those lines are there to make that work rather than to describe it. QT_NO_MITSHM=1 disables the MIT-SHM extension, which is a common source of failures when a Qt application runs against a socket shared from another host, and XDG_RUNTIME_DIR points at a writable temporary directory so the toolkit has somewhere to put runtime state. The /dev/dri device mapping is what allows hardware accelerated rendering to reach the host GPU in Full Mode, which is the reason the full mode requirements insist on GPU passthrough. The /etc/machine-id mount keeps the container's machine identity consistent with the host. For a headless CI machine, none of this applies, and the entry point in the repository is a set of shell scripts named start.sh, status.sh and stop.sh alongside a docker-compose.yaml for full mode and a docker-compose-lite.yaml for the lighter one. ## The management console is where you trigger the attack scenarios The companion computer web interface is the control surface of the lab, and it does more than configure the companion computer. The feature list describes it as companion computer configuration management via web interface and simulated serial connection to the flight controller, and separately as a management web console used to trigger scenarios and drone flight states. The companion computer service publishes port 3000 on the host, and telemetry forwarding goes through MAVLink Router running on the companion computer, reachable from that same interface. So the workflow is: bring the stack up, open the console, choose a scenario, and the simulator changes state in response. The scenarios are described as comprehensive hacking scenarios, ideal for practising a wide range of drone hacking techniques from basic reconnaissance to advanced exploitation, and the README says the same set of tactics, techniques and scenarios is broadly applicable across various drone systems, models and communication protocols. Two more features round out the simulation. Onboard camera streaming and gimbal is simulated, with an RTSP stream from the drone camera and companion computer integration, which is what lets a scenario involve looking through the camera. And flight logging is dynamic, with Ardupilot flight bin logs written to a simulated SD card, so the artefacts of a flight, including telemetry and logs, are available for later analysis exactly as they would be from a real aircraft. The simulator also ships a copy of the standard drone toolchain. QGroundControl is launched from the console and MAVProxy is integrated as a ground control station, and the repository has a ground-control-station directory alongside flight-controller, companion-computer and simulator. ## Walkthroughs are provided, which is the point of a lab One feature line deserves attention because it tells you what kind of project this is. Detailed walkthroughs: if you need help hacking against a particular scenario the walkthrough documentation is available as a spoiler. That is a deliberate pedagogical choice, and it marks the project as a training environment rather than a toolkit. A real intrusion attempt leaves you to work out the path yourself. Here, the answer key exists and is documented, so a learner can check their reasoning after trying, and an instructor can point a student at exactly the scenario they want covered. The repository also carries a Community Support section, a Feedback and Contributions section, a Maintainers section, a Credits section and a Disclaimer section in the README table of contents, and a version.txt file at the root. The MIT licence covers the code, and the project is open source and available at no cost. The installation instructions come with a warning that matters for planning. Depending on the computer's performance and internet speed, the full end to end installation process including container builds and image pulls can take between 30 and 60 minutes, and the advice is to let each step complete before moving forward. One limitation is stated plainly and should be repeated when you brief anyone using this lab. The current setup does not mirror every drone architecture or configuration. It is a faithful model of one stack, not a general purpose drone emulator. ## Conclusion This simulator suits an offensive security practitioner or penetration tester who wants to rehearse drone attack paths, from reconnaissance to exploitation, without buying hardware, without breaking the law and without a maintenance bill, since the whole lab is Docker containers and a management web console. It does not suit a real drone operator, a firmware developer building a product, or anyone looking for a tool to point at aircraft they do not own, and the README is candid that the current setup does not mirror every drone architecture or configuration. Before you plan an exercise around it, read the installation guidance and budget 30 to 60 minutes for the first build, pick Lite Mode unless you have Kali Linux on bare metal with a GPU, and confirm your host can spare 100 GB of disk and 4 GB of swap, since those are the stated minimums and they are large for a lab. ## FAQ ### What is the Damn Vulnerable Drone simulator? It is an intentionally vulnerable drone hacking simulator based on the ArduPilot and MAVLink architecture, designed as a controlled environment for offensive security professionals to practise drone attack techniques without real hardware. ### What are the system requirements for the Damn Vulnerable Drone? In Lite Mode the README lists 4 to 8 GB of RAM, two processor cores, 100 GB of disk storage, 4 GB of swap, and Docker with Docker Compose, with no GPU required. Full Mode with Gazebo needs Kali Linux, and bare metal is recommended for best performance. ### How does the simulator run the drone firmware? It uses ArduPilot's Software-in-the-Loop approach, which executes the drone firmware in a virtual environment the way it would behave on real hardware. Full Mode adds Gazebo for the 3D environment and physics, while Lite Mode uses ArduPilot's built-in flight dynamics model in 2D. ### How do I trigger attack scenarios in the lab? The management web console, served by the companion computer container on port 3000, is used to trigger scenarios and drone flight states. The README also points to detailed walkthrough documentation for individual scenarios. ### Does the simulator cover every type of drone? No. The README states that the current setup does not mirror every drone architecture or configuration, while arguing that the tactics, techniques and scenarios included are broadly applicable across various drone systems, models and communication protocols. ## Sources - [Issues](https://github.com/nicholasaleks/Damn-Vulnerable-Drone/issues) - [License: MIT](https://github.com/nicholasaleks/Damn-Vulnerable-Drone/blob/master/LICENSE) - [nicholasaleks/Damn-Vulnerable-Drone on GitHub](https://github.com/nicholasaleks/Damn-Vulnerable-Drone) - [README](https://github.com/nicholasaleks/Damn-Vulnerable-Drone/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nicholasaleks-damn-vulnerable-drone