How Parrot Drone Command Hijacking Works

TL;DR

Parrot drones can be hijacked by injecting valid commands into their unauthenticated Wi-Fi control traffic while the original pilot remains connected. By correlating captured UDP packets with the drone’s command logs and public SDK code, the researcher mapped the binary protocol, identified piloting commands, and demonstrated that protocol-level security matters beyond simply protecting the wireless connection.

Transcript

Thank you all of you for coming today, and of course, I want to thank you the, or say the opportunity to be here with you today, sharing the, the results of my investigation. I really love drones, and, uh, one of the things I'm afraid are open Wi-Fis. I don't know how often you connected to open Wi-Fis. They are really, uh, I don't know. I don't li... Read More

Key Insights

• Parrot drone hijacking is possible when an attacker can inject correctly formed commands into an unauthenticated control protocol. The demonstrated approach leaves the original pilot connected while malicious instructions are sent concurrently, making it different from attacks that first disconnect or deauthenticate the legitimate controller.
• The investigated drones create their own Wi-Fi hotspots for communication with a smartphone application or remote controller. Because the examined connection lacked authentication, proximity to the wireless network could expose the control channel even when an attacker avoided cracking encryption or disrupting the pilot’s connection.
• The Bebop drone runs Linux and uses an application called Dragon to manage onboard components and pilot settings. Its configuration files exposed relevant UDP ports, giving the researcher a practical starting point for capturing and examining traffic exchanged between the controller and the aircraft.
• Most captured communication consisted of binary UDP traffic, alongside an initial JSON exchange and unencrypted, unauthenticated FTP data. The JSON content included controller and drone details, communication ports, and settings that allowed both endpoints to establish how they would communicate.
• The initial protocol breakthrough came from matching date and time packets in Wireshark with corresponding entries in an internal command log. The controller supplied time information because the drone was not connected to the internet, and the drone returned responses acknowledging those messages.
• The protocol’s opening bytes identify message categories and communication direction. Statistical grouping of frames exposed recurring patterns, while definitions in Parrot’s public SDK confirmed that particular byte values represented related command families and directional variants.
• Piloting commands encode movement values directly rather than applying an obscure transformation. Captures from a Linux control sample showed fixed positive and negative movement steps, allowing the researcher to connect keyboard actions with packet contents and identify the messages responsible for drone motion.
• Secure drone design requires protection at the application-protocol level, not merely changes to exposed system services. Closing Telnet in later firmware addresses one access path, but unauthenticated control messages can remain vulnerable if the drone cannot verify that each command came from its legitimate pilot.

Questions & Answers

Q: How can a Parrot drone be hijacked without disconnecting its pilot?

A Parrot drone can be hijacked by sending valid commands in the same protocol used by its legitimate controller. The researcher’s goal was to keep the pilot connected and actively controlling the drone while malicious commands were injected at the same time. This method targets the command communication itself and does not depend on Wi-Fi jamming, deauthentication, or password-cracking attacks.

Q: Why was the Parrot drone’s Wi-Fi connection vulnerable?

The examined Parrot drones created their own open Wi-Fi hotspots so a smartphone application or controller could connect directly. The communication lacked authentication in the investigated setup, which allowed another nearby participant to observe and interact with the control traffic. Earlier models also exposed Telnet by default without a user or authentication, creating an additional route for disrupting the drone’s main program.

Q: How was the Parrot drone communication protocol reverse engineered?

The researcher captured traffic between the drone and its controller, inspected the drone’s Linux configuration and logs, and compared recurring packet patterns. Date and time exchanges provided recognizable events that could be matched between Wireshark captures and internal command-log entries. Statistical grouping and Parrot SDK definitions then helped identify message families, directions, acknowledgments, and piloting commands.

Q: What information was exchanged when the drone connected to its controller?

The early connection traffic included a JSON file containing names and identifying details for the controller and drone, along with settings and communication ports. The capture also contained FTP data and a large share of binary UDP messages. Those UDP messages carried operational exchanges, including date and time setup, device information, acknowledgments, and the piloting commands sought during the investigation.

Q: What role did the drone’s internal command log play in the research?

The internal command log acted like a debugging record that described requests and responses processed by the drone. By matching entries for setting the current date and time with captured UDP packets, the researcher established a reliable connection between visible network bytes and actual drone behavior. That correlation created a roadmap for interpreting later packets and reconstructing the broader protocol.

Q: How did the Parrot SDK help identify command packet structure?

Parrot’s public SDK contained definitions for several network command categories. Their decimal identifiers matched values appearing in the second byte of captured packets when converted to hexadecimal. The comparison confirmed that this byte represented a message family or type. Related values also showed a consistent directional relationship between controller-to-drone commands and drone-to-controller responses or acknowledgments.

Q: How were movement commands identified in the captured traffic?

The researcher used a Linux sample that controlled the Bebop through keyboard input and captured the resulting traffic. The sample labeled PCMD messages as piloting commands and used fixed positive or negative movement steps. Comparing each keyboard action with its packet showed that movement values were inserted directly in hexadecimal form, helping map instructions for actions such as rising, moving forward, and moving backward.

Q: What security practices does the drone research support?

The research supports authenticating the controller, protecting every control message, and avoiding open services that accept unauthenticated access. Encrypting sensitive transfers and validating command origin would reduce opportunities for observation and injection. Manufacturers should also review exposed services, protocol design, firmware behavior, and responsible vulnerability reports, because closing one service does not automatically protect the separate command channel.

Summary & Key Takeaways

• The investigation examines whether an attacker can control a Parrot drone without disconnecting its legitimate pilot. The targeted drones created open Wi-Fi access points, and some firmware exposed services such as Telnet without authentication. The researcher deliberately avoided jamming, password cracking, and deauthentication, concentrating instead on the application communication protocol.

• The reverse-engineering process combined network captures, configuration files, internal command logs, and Parrot SDK source code. Human-readable date exchanges provided an initial reference point for matching UDP packets to logged events. Repeated byte patterns then revealed message families, traffic direction, acknowledgments, device information, and the structure of piloting commands.

• After understanding the protocol, the researcher could construct valid messages and inject movement commands while the pilot remained connected. The work shows that closing an exposed service does not necessarily secure the control channel. Drone systems also need authenticated communications, protected services, and validation that commands originate from the legitimate controller.