yous.dev

47CON: reversing a WiFi drone

A field note from 47CON, where we took a cheap WiFi-controlled drone apart — not the radio, the protocol — and ended up flying it autonomously with a computer.

Reversing a WiFi drone at 47CON
47CON — hardware on the table.

This drone didn't talk over some exotic RF link. It did something much more familiar and much more interesting: it exposed its own WiFi network, and the phone app controlled it over that. Which means the entire control channel was just network traffic — and network traffic can be captured, read, and replayed.

Capture, decipher, rebuild

The work was a clean reversing loop. First we captured the traffic between the official app and the drone and stared at the packets until the structure gave way. Then we deciphered the control protocol — which bytes meant throttle, yaw, pitch, takeoff, land. Once the protocol was legible, we stopped needing the app at all.

So we wrote our own. A small control application that ran on a laptop and exposed an open API: each endpoint translated into the corresponding command and was sent straight to the drone. Suddenly the aircraft answered to HTTP instead of a phone.

Once you can speak a device's protocol, the app it shipped with is just one client among many — and not the privileged one.

Then it flew itself

An open API is an invitation. With the drone reachable by code, we put a vision model in the loop: a YOLO object detector reading the camera feed, deciding where to go, and driving the API directly. The same cheap toy that came with a clumsy phone app was now doing autonomous, AI-driven flight the manufacturer never designed for — tracking and reacting on its own.

The point isn't the drone

The lesson generalises to most of the cheap connected world. A WiFi control channel is a public, often unauthenticated surface; the moment its protocol is understood, control belongs to whoever decodes it. The cost pressure that makes a fun gadget is the same pressure that ships an open channel and trusts the bundled app to be the only thing talking to it.

  • Treat the WiFi channel as public. Anyone in range can listen.
  • If commands aren't authenticated, the "owner" is just the first client to speak the protocol.
  • An open, undocumented API is an open API. Someone will write the second client.

Thanks to 47CON for the stage, and to everyone who came up afterwards with their own drones and their own captures. The best conversations always happen with hardware on the table.

The talk on LinkedIn ↗

← back to field notes