Welcome back, cyberwarriors!

Earlier, we wrote an article on the issues that cars have. These issues are still common and car ransomware might soon emerge, hitting not just individual cars but entire fleets as vehicles get more autonomous and packed with different features.

In light of that, we want to show you a tool that makes car hacking more approachable. It’s GearGoat. The tool was built to simulate a car’s internal network so you can play with it.

GearGoat

GearGoat is a car simulator developed by INE Labs. It lets you work with the internal communication network used by most modern vehicles (CAN bus). Every action generates CAN packets on a virtual interface. You can use cansniffer, candump and UDS scanners with GearGoat, just like with any vehicle.

In a real car, you’d connect a CAN adapter (CANable or Macchina M2) into the OBD-II port, located under the dashboard. This port is basically a gateway into the vehicle’s internal network. Your system will treat the adapter as a network interface (can0) and you can start capturing and sending CAN messages. When someone presses the brake or turns on the indicators, it generates messages that travel across the network.

Setting Up

GearGoat runs inside a Docker container, so it’s easy to deploy. Clone the repository and run the script:

kali > git clone https://github.com/ine-labs/GearGoat.git
kali > cd GearGoat
kali > sudo chmod +x initial_setup.sh
kali > sudo ./initial_setup.sh

Then you need to configure the virtual CAN interface (vcan0):

kali > sudo chmod +x vcan_setup.sh
kali > sudo ./vcan_setup.sh

On certain distros you might be missing kernel modules. Here’s how you install them:

kali > sudo apt-get install -y linux-modules-extra-$(uname -r)

It doesn’t always work on Kali Linux though. You can manually load the required modules and create the interface yourself:

kali > sudo modprobe vcan
kali > sudo ip link add dev vcan0 type vcan
kali > sudo ip link set up vcan0
kali > ip link show vcan0

Now everything should be ready. You can start GearGoat:

kali > sudo docker run --network="host" --privileged geargoat

The simulator will be hosted on http://localhost. There you’ll see different car functions. Each button on the interface generates CAN traffic.

Intercepting Traffic

While the simulator’s running, it continuously generates CAN traffic. To see this traffic, use cansniffer.

kali > cansniffer -c vcan0

The output can feel overwhelming. The tool keeps highlighting changing bytes dynamically. It’s very noisy when you’re trying to establish a baseline. You need a way to tell the tool what normal looks like. Press Shift + 3 + Enter multiple times and cansniffer will treat the current state as the baseline. It won’t highlight the background noise anymore, so you’ll only see the changes you make.

Once the baseline is set, you can start playing with the simulator. Click the Left Indicator button and you’ll notice a change in the CAN data.

The first byte of a frame changes and it’s tied to 0x188. That means this identifier controls the indicator state.

When you play with the speedometer, you’ll see a different pattern. The changes happen in the 4th and 5th bytes are associated with 0x244. The speed climbs gradually.

Repeat this with other controls and you’ll see how functions map on the CAN bus.

Sending Input

Now we know which messages control specific functions, so we can interact with them.

To control the indicators, we’ll send CAN frames using cansend:

kali > cansend vcan0 188#0100000000000000  # left
kali > cansend vcan0 188#0200000000000000  # right

These commands will turn on the left and right indicators. The CAN bus runs at high speed, so these changes can be hard to catch. We used the watch command to make it more visible:

kali > watch -n 0.1 "cansend vcan0 188#0200000000000000"

Working with speed gets slightly more complex. Earlier, we found the address (0x244) and that specific bytes that control the value. To set a speed, we need to convert miles per hour into the format the CAN message expects.

To simulate a speed of 50 miles per hour you send:

kali > cansend vcan0 244#0000001F6F

You can see the simulator accelerating. Use the formula V = round(mph / 0.6213751 * 100) to calculate the value, then convert it into hexadecimal using big-endian.

Capturing and Replaying Traffic

You can also capture and replay traffic. That way you can record a sequence of actions and reproduce them.

To capture traffic, you use candump with logging:

kali > candump -l vcan0 

It’ll record the CAN messages into a log file. Once captured, you can replay it:

kali > canplayer -I <log_file_name>.log

Summary

GearGoat can get you started with car hacking. You work with a simulated CAN bus to understand the communication patterns and message structure. It’s easy to set up and it’s not resource intensive, so it’ll run on pretty much any computer.

We also have our three-day Car Hacking training, showing you real attacks. It includes CAN protocol exploitation and the use of Software Defined Radio (SDR). There we show you how modern vehicles are actually compromised.

The post Automobile Hacking: Hacking with GearGoat first appeared on Hackers Arise.

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.