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.
Top comments (0)