DEV Community: Oli

Spotting GPS spoofing on a drone — and flying on when the signal is gone

Oli — Sun, 21 Jun 2026 16:42:14 +0000

Follow-up to my MAVLink post. Same caveat: I'm a beginner doing this as a hobby. The results below come from two small experiments in ArduPilot SITL on a simple setup, so please don't read too much into the exact numbers.

The weak link: a GPS that believes everything

We secure the comms, encrypt the telemetry… and often forget the drone has another vital sense that's just as exposed: GPS.

The issue is structural. Civilian GPS isn't authenticated — the receiver has no cryptographic way to check that the signals really come from satellites. So two attacks target it:

Spoofing: broadcasting fake navigation signals, stronger than the real ones, so the drone thinks it's somewhere it isn't.
Denial (jamming): drowning the GPS band to blind the drone entirely.

This isn't hypothetical: ships have reported impossible positions at sea, airliners have hit spoofing near conflict zones, and anti-drone "bubbles" exist around sensitive sites. The gear to spoof GPS reportedly costs only a few hundred euros now.

Two problems, two answers: detect the attack, and survive even when you don't.

Part 1 — Catching the liar

You can't verify the GPS signal itself (no authentication). But you can check its consistency with everything else the drone senses.

A modern drone doesn't rely on GPS alone: it runs an Extended Kalman Filter (EKF) that fuses the accelerometer, gyro, barometer, etc., and continuously predicts where it should be. If the GPS position matches the prediction, fine. If it suddenly diverges… that's suspicious.

To quantify "diverge," I used the Mahalanobis distance. Instead of a raw distance in metres, it measures how many standard deviations the GPS reading is from the prediction, weighted by the filter's uncertainty (its covariance). That's the appealing part: tolerate normal GPS noise, but flag a statistically abnormal jump. A simple threshold can trigger the alarm.

And for the clever attacker who slowly drifts the position to stay under the radar? I added a CUSUM test (cumulative sum), which catches a small systematic drift building up over time that an instantaneous threshold would miss.

What I saw in my test

In SITL, drone hovering, I injected fake GPS coordinates. The result was quite visual: the Mahalanobis distance stayed flat while things were normal, then spiked right at the moment of injection. A SPOOF DETECTED alert fired and the failsafe took over. In my (limited) runs I didn't see false positives — but my setup was simple and the scenario clean, so I wouldn't generalise from that.

The nice part is it runs without extra hardware: it reuses the EKF already in the autopilot. No multi-antenna receiver, no atomic clock — just statistics on data you already have. (Real anti-spoofing systems are far more sophisticated; this is very much a learner's version of the idea.)

Part 2 — Surviving with no GPS

Detection is nice. But what if you miss it, or it's pure jamming — no signal at all? The drone still has to stay in control.

First building block, already in the autopilot: dead reckoning. From the IMU alone, ArduPilot keeps flying for a few seconds after GPS loss, then heads home. The snag: dead reckoning drifts — without an external reference, position error piles up fast.

Second block, to bound that drift: optical flow. A small (~€25) sensor that looks at the ground and measures actual movement, a bit like an optical mouse. Fused into the EKF, it gives a motion reference that needs no satellite.

What I measured

I compared three scenarios in SITL, drone flying, then GPS cut:

Scenario	Max drift	Mode after cut
A — Normal GPS (baseline)	0.02 m	normal flight
B — GPS lost, no defense	0.67 m	emergency landing
C — GPS lost + optical flow	0.15 m	emergency landing

An honest reading: without GPS, the drone triggers an emergency landing in both cases — optical flow does not give "free" GPS-denied flight. What it does, and it's already a lot, is cut the drift by roughly 4x (0.67 m → 0.15 m) during that descent, so the drone lands where it is rather than ~70 cm away in the wind. And again — tiny experiment, simulation only, don't over-trust the figure.

The way I'd put it: dead reckoning drifts, but it's better than nothing — enough for the drone to at least head home. I'd rather state that plainly than oversell an "autonomous no-GPS flight" my data doesn't show.

On the ArduPilot side, the gist is three parameters: enable optical flow (FLOW_TYPE), a rangefinder for altitude (RNGFND1_TYPE), and the dead-reckoning failsafe (FS_DR_ENABLE), with GPS staying the EKF's primary source while it's healthy.

Same flaw, two strategies

Stepping back, GPS spoofing and MAVLink command injection seem to share the same root cause: an input the system accepts without being able to authenticate it.

When you control the channel (telemetry), you go for prevention: signing + encryption.
When you don't (GPS, which you can't control), you go for detection + resilience: spot the inconsistency, and stay in control even if detection fails.

That, as I understand it, is defense in depth on a drone: planning for your own defenses to fail.

Takeaways (beginner edition)

GPS isn't a source of truth, it's just one more sensor — and one you can't authenticate. So cross-check it against your internal estimate, and plan for the worst, i.e. flying without it.

Good news: most of these protections (EKF, dead-reckoning failsafe, optical-flow support) are already in ArduPilot. The work is enabling, tuning and testing them — not reinventing the wheel. I'm still very much in the testing-and-learning phase, so corrections are welcome.

Happy to share more detail in the comments.

MAVLink: the protocol behind millions of drones (and why it isn't secure by default)

Oli — Sun, 21 Jun 2026 16:40:46 +0000

Quick disclaimer: I'm still learning this stuff. This comes out of a small personal project where I'm trying to secure the link between a hobby drone and its ground station. Everything below was tested in simulation (ArduPilot SITL) and a little on real hardware, on a very modest setup — so please take my own results with a grain of salt.

Context: a protocol everywhere, secured nowhere

If you build an open-source drone today, chances are it speaks MAVLink — the communication protocol between the drone and its ground control station (GCS), used by ArduPilot and PX4, running on millions of devices.

The catch: MAVLink was designed for one thing — performance. Compact packets, low latency, long range. Security wasn't part of the original spec, and it shows.

MAVLink in 30 seconds

The drone and the GCS constantly exchange two kinds of messages: commands going down (take off, go to this point, land) and telemetry coming up (position, altitude, battery, status). It all starts with a HEARTBEAT sent every second to keep the link alive.

Simple, efficient… and, as far as I can tell, wide open.

The problem: MAVLink v1 protects nothing

MAVLink version 1 has no encryption, no authentication, no signing. From what I understand, an attacker within radio range can:

listen to all telemetry in clear (your position, your flight plan);
inject fake commands, since nothing checks who sends them;
run a man-in-the-middle attack, or replay old packets.

This isn't just theory — it's documented in CVE-2020-10282 (CWE-306, "Missing Authentication for Critical Function"), rated around 9.6/10. The weakness isn't an implementation bug; it's in the protocol design itself.

The catch with v2

MAVLink 2 added optional signing based on HMAC-SHA256. On paper that's the right idea: a shared secret key, and each message carries an authentication code over its content plus a timestamp; unsigned or badly signed messages get rejected.

But, from what I've read:

Signing is optional and off by default.
To stay backward-compatible, the GCS and drone negotiate the version — and an attacker can craft packets that force a fallback to MAVLink v1, where there's no protection at all. The classic downgrade attack.

So just turning signing on isn't enough if you don't also force v2 and block the downgrade. (I'm honestly still figuring out the cleanest way to do that.)

What about the radio link?

Telemetry is only half the picture. On a lot of FPV drones the control link runs over ExpressLRS (ELRS). Back in 2022, NCC Group published an analysis worth knowing about: the ELRS binding phrase is not a security mechanism — the developers say so themselves, it's anti-collision.

The uncomfortable detail: a single sync packet apparently leaks about 75% of the unique identifier needed to take over the link, and the rest can be brute-forced. With a standard ELRS radio, an attacker could hijack the control link. (Worth noting the ELRS team pushed back on parts of how this was reported — but the core point stands.)

The general lesson I'm taking from this: don't confuse "pairing" with "authentication."

What I tried on my own build

I'm not trying to reinvent cryptography — way above my level. I just wanted to see whether I could reproduce, on a hobby budget, the basic ideas you find in proper solutions. I went for layered defense on the telemetry link:

Layer 1 — Authentication: MAVLink2 signing (HMAC-SHA256).
Enabled on the autopilot side, it should block injection: without the key you can't forge a valid command, and the timestamp kills replays.

# Force MAVLink2 on the telemetry port (no v1 fallback)
SERIAL1_PROTOCOL = 2
# Signing (32-byte key) is set on the GCS side

Layer 2 — Confidentiality: AES-256-GCM encryption.
Signing authenticates but doesn't encrypt — telemetry stays readable. So I added an encryption proxy on a small companion computer, between the flight controller and the radio. GCM also gives integrity (a tampered packet is rejected).

Layer 3 — Stacking.
Both layers add up: signature and encryption. If one fails, the other still stands. That's the whole idea of defense in depth — at least as I understand it.

Rough takeaway: signing blocks injection, encryption blocks eavesdropping, and together they cover the link. I want to stress these were small tests, not a rigorous evaluation.

The real hard part: keys, not the algorithm

Picking AES or ChaCha20 is the easy bit. The hard part — and the part I'm least sure about — is key management. If a symmetric key sits in the drone's flash and someone gets hold of the drone, they can pull the key and impersonate a legit drone to your GCS.

One idea I find interesting (still reading about it): a drone that stores no permanent secret, deriving an ephemeral session key in RAM at each boot via a Diffie-Hellman exchange, so everything disappears on power-off. If the drone is captured, you'd recover generic hardware and an empty RAM. I haven't implemented this properly yet — it's on my "learn this next" list.

Takeaways (from a beginner)

MAVLink is a great protocol — open, efficient, universal. But "open and efficient" doesn't mean "safe." Security isn't built in; it has to be added on top, ideally from the design stage, and on every link, not just telemetry.

If you run an open-source drone for anything beyond fun, maybe ask yourself: is my telemetry encrypted? are my commands signed and is v1 blocked? does my control link rely on real authentication, or on a "binding phrase" that isn't one?

I'm still early in this, so if you spot something I got wrong, please tell me in the comments — I'd genuinely like to learn.

Next time: the other half of the problem — GPS. How to spot spoofing, and how to keep flying with no satellite signal.

Questions or corrections very welcome below.

Reverse engineering a DJI Mavic Pro remote: meeting the DUML protocol

Oli — Sun, 21 Jun 2026 16:39:33 +0000

A hobby project on the side. I bought a Mavic Pro Gen1 shell and its GL200A remote for a few euros, sold as non-functional. Rather than just repairing them, I wanted to understand how they talk to each other. This is my logbook — and I want to be upfront that I'm a beginner at reverse engineering, standing on the shoulders of a community that did the hard work.

First: is this legal?

It's the question to ask before touching someone else's hardware — and in Europe the answer is nuanced but reassuring.

The EU Software Directive (2009/24/EC) explicitly allows you to observe, study and test how a program works to understand its underlying principles (Article 5). Decompilation (Article 6) is permitted without authorisation when it's for interoperability of an independently created program. Vulnerability research on a device you legally own fits this frame, as I understand it (and to be clear, I'm not a lawyer).

What you can't do: build a substantially similar commercial clone, redistribute the proprietary code you extract, or ignore patents. My case: I bought the hardware, I explore it to understand and learn, I don't resell anything, and I don't break DJI's firmware encryption. It seems within bounds — but if you do this, check your own jurisdiction.

Personal rule: I document interoperability and security, never circumvention. No bypassing flight restrictions, no tweaking the device to do things it isn't allowed to.

The playground: the GL200A over USB

First reflex: plug the remote into a Linux machine and see what it exposes. And for a "closed consumer device," it turns out to be surprisingly chatty.

USB enumeration reveals three interfaces at once:

a serial port (CDC ACM, /dev/ttyACM0);
a network interface (RNDIS), the remote presenting itself as a small gateway;
a mass storage gadget, proudly announced as "DJI File-CD Gadget."

A port scan on the network interface shows about a dozen open TCP ports. And the most telling part: an FTP open to anonymous access, no credentials. Inside, part of a filesystem — logs, panic dumps, SDR configs, update files. The firmware itself is AES-encrypted by DJI (and I didn't try to break that). But the fact that all this is open to anyone who plugs in a cable says a lot.

The heart of it: the DUML protocol

All internal communication in the DJI ecosystem runs on DUML (DJI Universal Markup Language). It's a binary protocol, and the good news for a learner is that it's already well documented by the community — notably the open-source dji-firmware-tools and dji_rev, which include dissectors for DUML packets. I'm mostly retracing steps others mapped out.

The packet structure is regular, which helps a lot: a magic byte (0x55) up front, length fields, a command set and command id identifying the order, an acknowledgement type, the payload, and a CRC. Once you have that template in mind, a raw serial capture becomes readable — you see the 0x55 bytes scrolling by at regular intervals.

The detail that unlocked things

At first the remote answered every message with a universal NACK. Frustrating. The breakthrough: you need the right acknowledgement type. With ack_type = 2 the radio (OFDM) module finally answers; with ack_type = 1 it's NACK every time. (To be clear, I found this by trial and error and by reading the tools, not by any cleverness of my own.)

From there the device starts talking. The module even introduces itself: WM220 SDR_HDVT_GND. I confirmed a handful of bidirectional DUML commands on the remote — a version query (returning something like ldr v08.00.00.09, app v00.00.01.28), device state, RC detection info, and so on.

Exploring the TCP ports, I also stumbled onto a proprietary protocol (I nicknamed it f364) where one stream spits out… plaintext debug logs from the radio stack: MAC-layer internals, scheduler details, security frames. Information that really shouldn't be on an open channel.

A bit of tooling

Most of the exploration used dji-firmware-tools (the comm_serialtalk.py utility, to talk to a specific module), plus a small homemade DUML fuzzer: it sweeps the command space and only counts a reply as valid if it exactly matches the request (matching on seq + command set + command id + ACK type), to avoid false positives. Less glamorous than an exploit, but that's where most of real reversing happens — patiently mapping an unknown surface.

What it teaches, security-wise

Beyond the fun of making an old radio module talk, this is a case study in classic mistakes in embedded security — the ones not to repeat if you design a connected product:

An open anonymous FTP on a consumer device. Plugging in a cable should never be enough to browse a filesystem.
Plaintext debug logs on an accessible channel. The internals of a radio stack are exactly what an attacker wants. Debug should be disabled (or protected) in production.
Lots of interfaces exposed by default. Three USB gadgets plus a dozen ports: every open interface is a door. Attack surface should shrink, not sprawl.

The general lesson, drone or not: a "closed" device is only closed on the surface. As long as there's a physical interface, there's something to observe — and therefore something to harden.

Takeaways (beginner edition)

Reverse engineering hardware you own is a fantastic way to learn: you touch binary protocols, RF, embedded systems, and exploration methodology. And it's legal when you respect the frame (legally acquired hardware, interoperability or research purpose, no clone, no redistribution of proprietary code).

My advice for getting started — as someone who just got started: pick a device with mature community tooling (the Mavic Pro Gen1 is a great choice thanks to dji-firmware-tools), observe before you talk, and document everything. Patience beats exploits.

Corrections and pointers very welcome — I'm here to learn.