SkyJack: hijacking a drone that trusts anyone on its Wi-Fi

TL;DR

Back in 2013 the researcher Samy Kamkar strapped a small computer to a drone, sent it into the air, and had it hunt down other drones nearby, knock their owners off the controls, and fly away with them. He called it SkyJack, and it looked like something out of a film. The reason it worked is almost disappointingly simple: the drones it targeted broadcast their own open Wi-Fi network with no password, and took their flight commands over it, in plain text, from anyone who connected.

That attack is more than a decade old now, and the specific drones it hit are legacy hardware. The design mistake behind it, though, a machine that does whatever the nearest radio tells it to, is very much alive in the cheap connected gadgets around us. I keep a SkyJack demo in the Evil-M5Project because watching a drone stop listening to its owner, just once, makes « authenticate your control channel » a rule people actually keep. The drones are gone. The flaw is not.

The drone that flew away

Some attacks are frightening because they are subtle. SkyJack is frightening because it is not: a drone rises into the air, finds another drone, kicks its owner off the controls, and simply flies off with it, like one bird of prey taking another in mid-flight. When Kamkar demonstrated it, it looked like science fiction, the kind of thing that surely required deep wizardry to pull off.

It did not. Underneath the drama was one of the plainest security mistakes there is, and that gap between how cinematic it looked and how trivial it actually was is exactly why it is worth understanding. Let me walk you through how those drones were flown, how the takeover worked, why the real lesson has nothing to do with drones at all, and how the same mistake keeps getting shipped in gadgets that never leave the ground.

How you fly a drone like that

The Parrot AR.Drone, the star of the original attack, did not join your home Wi-Fi the way a laptop does. It broadcast its own network, an open one with no password, and you connected your phone directly to it, the same way you would connect to a cafe hotspot. That was the whole setup, and it felt perfectly normal to the person flying it.

From there the app sent the drone its flight commands as plain text over that link, telling it to climb, turn, hover, or land, with no login and no encryption anywhere in the exchange. If you could reach the network, you could fly the drone, full stop. And the network was open to anyone within range, which on an outdoor Wi-Fi signal is a good deal further than most people would guess. The drone was, in effect, a flying open hotspot that would do whatever anyone connected to it said.

The takeover

SkyJack chained two simple moves, and neither of them was clever in isolation. First, it knocked the real pilot’s phone off the drone’s Wi-Fi using deauthentication frames, the exact same forced-disconnect trick from the deauth episode earlier in this series. That did more than just silence the pilot for a moment.

These drones talk to only one controller at a time, so bumping the pilot off frees the single control slot, and SkyJack then has to grab that slot faster than the pilot’s phone can reconnect. Win that short race, connect to the open network, and it could speak the drone’s own control language and issue commands, anything from a gentle « land » to full control of where it flew. The drone had no way whatsoever to tell the difference between its rightful owner and a complete stranger, because it was simply never built to ask the question. That is also exactly why blocking the deauth defeats the whole thing, as we will see in a moment.

It was never really about drones

Strip away the flying, which is the part that makes it a spectacle, and SkyJack is a very ordinary kind of flaw: a device with a control channel that has no authentication. The drone does whatever the radio says, and the radio is open to anyone who comes within range. Nothing about that sentence requires the thing being controlled to have propellers.

That exact shape turns up far from the sky, in cheap smart toys, some home robots, budget pan-and-tilt IP cameras, and all manner of connected gadgets built to be driven from a phone over an open or barely-protected link. The drone just makes the lesson impossible to ignore, because the consequence literally falls out of the air in front of you. A smart plug or a toy car with the same flaw fails just as completely, but quietly, so nobody makes a video about it, and the mistake survives to be shipped again.

Technical deep dive: the open AP, the deauth, and the race

This is the part worth slowing down on, and you can skim it if you only want the takeaway. Three technical facts stack up to make the takeover work. The first is the drone’s open access point: it runs its own unencrypted Wi-Fi with no password, so association is free to anyone, and it answers on a fixed, known network address that never changes, so an attacker always knows exactly where to send commands. The second is the command protocol itself, which is plain text with no authentication: the drone accepts movement commands from whatever is connected, with nothing in the message proving it came from the real controller.

The third fact is the one that turns a theoretical weakness into a clean takeover: the drone bonds to a single controller at a time. That is why SkyJack opens with a deauthentication frame, an 802.11 management message that forces the pilot’s phone to disconnect, and because those management frames are not protected, forging one is trivial. The instant the pilot is dropped, the control slot is free, and the attack races to associate and claim it before the pilot’s phone automatically reconnects. The Evil-M5Project version reimplements exactly this on a tiny ESP32 Wi-Fi chip, the same hardware class the idea was built around, which is both why it is a faithful demo and why its reach is limited to the legacy drones that still work this way. Protect the management frames, or authenticate the control channel, and the chain snaps at the first link.

Does this still work?

As a live attack in the wild, this one is mostly a museum piece now, and it is only honest to say so. The legacy Parrot drones are old, and today’s mainstream and premium drones use encrypted, authenticated control links that shrug the whole thing off without blinking. If you buy a serious drone today, it is not flying on an open hotspot.

The exception, and it is not a small one, is the ocean of cheap Wi-Fi-controlled toy and FPV drones, plenty of which still ride an open, unauthenticated link and remain exposed exactly as the AR.Drone was. That is the same lesson as the budget gadgets everywhere else: the flaw did not get fixed, it just got cheaper. The attack’s real life now is educational, the demo that makes « authenticate your control channel » land harder than any slide ever could, and a cautionary tale for anyone building a new connected device on the same open, trusting foundation. Plenty still do, which is the whole reason it is worth keeping the demo alive.

A quiet Sunday in the park

Say you are Leo, flying your old AR.Drone over a park on a Sunday afternoon, the way you have a hundred times. Someone on a bench nearby has a gadget the size of a deck of cards, which you would never look at twice. Your phone’s connection to the drone drops for no apparent reason, the sort of glitch you would normally just shrug at, and before you can reconnect, the drone stops answering you entirely.

For a few seconds, it is not yours. In a friendly demo like the one I run, it just settles gently onto the grass and that is the end of it. In less friendly hands, it could have flown off over the trees and kept going. You did not crash it, and you did not do a single thing wrong. The drone simply took orders from whoever spoke to it, the way it always had, and this time the one speaking to it was not you. That is the entire attack, and it needed nothing from you but to be flying an old drone on a nice day.

Why it works

Two familiar weaknesses line up to make it happen, and you have met both already in this series. The control channel has no authentication, so the drone obeys any device on its network without ever checking who it is, and the Wi-Fi management frames that disconnect you are not protected, so a stranger can shove your controller off whenever they like. Neither of those is exotic or clever. They are the exact same two gaps behind half of this series, just wearing a propeller this time.

What makes the drone memorable is only that the failure is visible and immediate: a thing in the sky stops obeying you and obeys someone else instead. Strip the altitude away and it is the same quiet story as a camera on a default password or a remote with a fixed code, a machine that trusts a signal instead of verifying the sender. The drone just has the good manners to make the lesson dramatic.

How to protect yourself

This one splits cleanly between the people building connected devices, who can actually fix it at the root, and the people who own one of the vulnerable gadgets.

If you are building the device

• Authenticate the control channel. A device should accept commands only from a controller it has actually paired with, over an encrypted link, never from « anyone who can reach the network. » This is the fix, and everything else is a backstop.
• Put a real password on the device’s Wi-Fi (WPA2 or WPA3), and turn on Protected Management Frames, a Wi-Fi setting that stops those forced-disconnect messages from being forged, so the deauth half of the attack simply stops working. The password hardens the network, but the per-controller pairing above is what actually decides who may fly the drone.
• Treat the radio link as hostile by default. Anything a phone can send over it, an attacker in range can send too, so design as if the pilot might be a stranger.

If you own one

• Do not trust a legacy open-Wi-Fi drone, or any gadget controlled over an open network, with anything you would mind a stranger grabbing mid-use. Keep its firmware updated in case the maker ever hardens it.
• A drone with a paired, encrypted controller is not vulnerable to this, which is one of the few places in security where newer really is straightforwardly safer.

Doing it with the Evil-M5Project

Evil-M5Project, the firmware I build, includes an ESP32 (a tiny, cheap Wi-Fi chip) reimplementation of SkyJack, built to demonstrate the original 2013 idea on the hardware class it was designed around, against a drone you own.

• It scans the Wi-Fi channels for a Parrot AR.Drone’s network, identifies it, sends deauthentication frames to knock off the current pilot, connects to the drone’s open Wi-Fi, and issues a command. For a demo that command is « land, » which brings the drone down gently rather than dropping it.
• The drone’s protocol also has an emergency toggle that cuts the motors outright, so it drops rather than lands, which is only ever sane with the drone already on the ground or on a test rig, and not something to do to an aircraft in flight.
• It targets the legacy AR.Drone 1.0 and 2.0 specifically, the models with the open network, a fixed network address the drone always answers on, and the plaintext command interface, which is exactly the combination that makes the takeover possible.

The honest limits are the whole point. This works on old, open-Wi-Fi Parrot drones and essentially nothing else, because a drone with an encrypted, paired controller is simply not affected, which is rather the moral of the story. You have to be in Wi-Fi range of the drone. And taking control of an aircraft someone else is flying is genuinely dangerous and illegal, so this is a historical, educational reimplementation, to be used only on a drone you own, in a safe and legal setting.

Evil-M5Project is for ethical and educational use only. Only run this against a drone you own, in a safe and lawful place, and follow the laws where you are.

Firmware and docs: https://github.com/7h30th3r0n3/Evil-M5Project.

A machine that trusts the loudest voice

SkyJack stays famous because it is dramatic, but what it actually exposed is dull and important: a machine that does whatever the nearest radio tells it, with no way at all to check who is talking. The drones that fell for it are long obsolete, and the fix was always obvious, authenticate and encrypt the control link, which modern drones duly did.

It is worth remembering anyway, because the same open, trusting design keeps getting shipped in new connected things that do not fly, where the failure is quieter but no less real. A toy, a plug, a little robot that obeys any phone in range is a SkyJack waiting to happen without the cinematic ending. I keep the SkyJack demo in Evil-M5Project because watching a drone stop listening to its owner, just once, makes « authenticate your control channel » a rule people actually keep, long after they have forgotten the slide that told them to.