Drones have become a potent military threat, particularly on the small scale. Nimble multi-rotor drones are fast, difficult to spot, and can cause plenty of harm if allowed to go about their work unhindered. The first step to dealing with this issue is detection—a problem that [Agam Rossen] has put some work into.
The result is VolAnti—an open-source drone detector. This route was chosen as a reliable way to detect incoming multi-rotors, since spinning propellers tend to create a telltale sound that can be plucked from the noise quite specifically. In a world where fiber optic drones eschew RF emissions, it also proves particularly useful for early warning of such craft.
VolAnti relies on a small four-microphone array, with the I2S output of all four mics summed together. The output is then fed into a 2048-point FFT running every 32 ms on an ESP32-S3. A comb score is given to try and pick out different blade rates from 70 Hz to 2000 Hz. Multiple detection algorithms run in parallel, because [Agam] noted a problem—using an adaptive noise floor would miss drones that arrived in the area and hovered in place. With the noise not varying, it would get filtered out by the adaptive floor, so one algorithm in the four runs with no floor to catch drones that aren’t moving. Files are on GitHub for those curious to learn more.
LeVanta Tech said it demonstrated its HALIA unmanned system at ANTX Coastal Trident last month, showing how the platform can link air, surface, subsea and seabed assets over long distances. Photos of HALIA show an unusual design. The drone sits low in the water with a dark, angular hull riding hull-down, mostly submerged. Two cylindrical […]
San Diego-based unmanned surface vessel maker Seasats said its Quickfish interceptor-class USV has entered production and is now available at scale. The company said Quickfish is built on Seasats’ existing technology stack and can sprint at more than 40 knots (74 km/h) while remaining at sea for weeks at a time. It has a large […]
A bobcat inside a home as seen on video captured by a Kirkland Police Department drone. (Kirkland Police Department Image)
Most high-tech police drones are deployed for high-speed chases or search and rescue missions, but officers in Kirkland, Wash., recently launched one indoors for a wilder reason: tracking a live bobcat sitting at the top of a resident’s staircase.
According to a Kirkland Police Department Facebook post, the incident unfolded in the Moss Bay neighborhood last week after a resident heard loud banging inside their home and called 911 to report a break-in.
Responding officers expecting a human burglar were surprised to find the intruder was a bobcat.
In order to maintain a safe distance and manage the response, officers deployed an unmanned aircraft to monitor the cat’s movements inside the home.
The bobcat was corralled into an isolated room until the Washington Department of Fish and Wildlife arrived, according to the Facebook post. The bobcat was sedated and later released near Forbes Creek, close to the natural habitat where it was found.
The bobcat is believed to have climbed a tree and jumped through an open window to gain entry possibly drawn inside by the resident’s cat, which was later found unharmed.
The indoor operation highlights how Kirkland has expanded its use of aerial technology since launching a public safety drone program in 2022. Managed centrally across the city’s Police, Fire, and Public Works departments, the program maintains five aircraft and 17 FAA-licensed pilots specifically trained for tactical searches, search-and-rescue missions, and scene documentation.
Police recommend that if a bobcat enters your home, move people and pets away from the area and call 911.
The FCC is considering restrictions that could prevent some previously approved DJI drones from being sold in the US. Existing owners would not be affected.
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.
Battery Spoofing
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.
Login
