DuckHunter: A Tactical OS for Drone Security Research

The smoke detector was once commercial equipment. So was the surveillance camera. The motion sensor. The doorbell with a lens in it. Each one migrated from specialized security infrastructure to standard household item because the technology got cheap and the threat justified it. Drone proliferation is following the same curve — faster.

There are already more drones in the air than there have ever been. Logistics runs on them. Infrastructure gets inspected by them. Farms get surveilled by them. The commercial operators and the recreational pilots and the people flying things over your property with a camera running — all of it is accelerating. The regulatory framework is not keeping pace. And the protocols underneath all of that movement were designed for hobbyist researchers flying in open fields in 2009.

A consumer drone is a flying computer with a radio stack, a GPS receiver, a flight controller running open-source firmware, and a telemetry link broadcasting its position and status in plaintext. Most of them still ship with the same trust assumptions that plagued enterprise networks in 2005.

DuckHunter is the research platform for understanding that surface before someone less friendly does. Simulation layer for building the understanding. Hardware bridge for validating it. Zero telemetry. Your perimeter, your problem.

The Protocol Problem

MAVLink was designed for the ArduPilot ecosystem in 2009. It solved a real problem elegantly: a lightweight binary protocol for passing telemetry and commands between a ground control station and an aircraft. Simple, efficient, widely adopted. The drone industry built on top of it and never looked back.

The security posture of that original design reflects the context it was built for: hobbyist researchers flying in open fields, not adversarial RF environments. There was no authentication layer because the assumption was physical proximity implied authorization. That assumption no longer holds.

MAVLink 2 added signing support in 2016. Adoption remains inconsistent. A significant portion of commercial and hobbyist vehicles in the field today either don't implement message signing, implement it incorrectly, or disable it for compatibility with older ground stations. The HEARTBEAT message that every MAVLink vehicle broadcasts continuously — announcing its presence, system type, firmware version, and operational state — is unsigned by default on most hardware.

// Simulated MAVLink HEARTBEAT capture
// Passive monitoring — no transmission required

const packet = await pulseSniff({
  band: "2.4GHz",
  protocol: "MAVLink2",
  filter: ["HEARTBEAT", "POSITION"]
});

console.log(packet);
// {
//   type: "HEARTBEAT",
//   system_id: 1,
//   autopilot: "ArduCopter",
//   base_mode: "GUIDED | ARMED",
//   custom_mode: 4,
//   signed: false   // <-- most common finding
// }

A passive HEARTBEAT capture tells you the vehicle is present, what firmware it's running, whether it's armed, and whether its command link is authenticated. That's a complete target profile without transmitting a single byte.

RF as Reconnaissance

Before you can interact with a drone's protocol stack, you have to find it. That starts with the spectrum — real-time signal identification across the three bands drone control links actually use.

2.4GHz is where most consumer and prosumer links live: DJI OcuSync, legacy Spektrum DSMX, ExpressLRS in its most common configuration. 5.8GHz carries a smaller subset of control links and most FPV video downlinks. 900MHz is the long-range tier — TBS Crossfire, ExpressLRS 900, systems designed to maintain link integrity at distances where 2.4GHz degrades.

Each protocol has a signature. Frequency-hopping spread spectrum links like ELRS and Crossfire use pseudorandom hop sequences that look like noise to a naive scanner but have detectable statistical properties. Consumer OcuSync links have characteristic burst patterns. A live power spectral density visualization turns the RF environment into something you can actually read.

The practical value is triangulation: if you know what a target link looks like spectrally, you can track signal strength to determine proximity and approximate bearing. Target acquisition without GPS.

GPS Integrity and the Spoofing Problem

The navigation attack surface is different in kind from the protocol attack surface. GPS spoofing works by transmitting a counterfeit GNSS signal stronger than the genuine signal from orbit. The receiver can't distinguish the spoof — it just sees a stronger signal and locks to it. The vehicle then navigates to wherever the spoof says it is, which may have nothing to do with where it physically is.

The detection method that works relies on sensor fusion. A drone in flight has inertial measurement unit data — accelerometers and gyroscopes tracking actual physical movement — that is independent of GNSS. If the GPS coordinate stream claims the vehicle is stationary while the IMU says it's moving, or claims a velocity vector that contradicts accelerometer data, that divergence is the spoof signature.

// GPS integrity cross-validation
// Divergence between GNSS position and IMU movement vector

const integrity = await trackLock.validateParity({
  gnss_position: { lat: 40.7128, lon: -74.0060, alt: 120 },
  gnss_velocity: { vx: 0, vy: 0, vz: 0 },  // GPS says stationary
  imu_accel:     { ax: 2.3, ay: 1.1, az: 0.2 }  // IMU says moving
});

console.log(integrity.spoof_detected);  // true
console.log(integrity.divergence_score); // 0.94

Meaconing — the subtler attack — doesn't inject a false position. It captures legitimate GPS signals and rebroadcasts them with a delay. The receiver locks to the rebroadcast, which appears to originate from the same satellite geometry but carries time-delayed data. The vehicle drifts from its actual position without the hard discontinuity that naive spoof detection looks for. The divergence score climbs slowly rather than spiking. The countermeasure is tighter IMU cross-validation thresholds and timestamp integrity checking — both tunable in DuckHunter's research mode.

Plug and Play

The standard SDR toolchain is a driver installation problem. Zadig on Windows. librtlsdr on Linux. A daemon running in the background. Half an hour of troubleshooting before you see a signal. It's been the friction point that keeps this class of tooling in the hands of specialists.

DuckHunter's hardware bridge uses WebUSB to eliminate all of it. Three device filters, a browser permission prompt, and a USB claim sequence. This is the actual source:

const SDR_FILTERS = [
  { vendorId: 0x0BDA, productId: 0x2832 }, // RTL2832U
  { vendorId: 0x0BDA, productId: 0x2838 }, // RTL-SDR Blog V3
  { vendorId: 0x1D50, productId: 0x6089 }, // HackRF One
];

const device = await navigator.usb.requestDevice({ filters: SDR_FILTERS });
await device.open();
await device.selectConfiguration(1);
await device.claimInterface(0);

Plug in the hardware, open the browser, click authorize. The browser claims the USB device natively — no driver installation, no intermediary daemon, no setup beyond plugging it in. The raw I/Q sample pipeline routes directly into the visualizer. Chromium-based browsers only, Chrome and Edge, but that covers most of the research audience.

RTL-SDR is the entry point: $30, receive-only, covers the full frequency range drone links operate in. Sufficient for passive reconnaissance — spectrum analysis, protocol identification, HEARTBEAT capture, PSD visualization. HackRF One adds transmit capability for controlled injection exercises. That's where the Faraday cage requirement stops being a suggestion and starts being a federal statute.

The $30 dongle is already on your desk, or should be. The software layer is what's been missing. Personal drone defense isn't standard home security yet — most people don't need it today, the way most people didn't need a security camera in 1990. But the deployment curve is steep and the hardware is already cheap. The architecture for when it matters is worth building now.

---

GhostInThePrompt.com // The HEARTBEAT was unsigned. The rest was methodology.