In this example, we demonstrate how we reverse-engineered the communication between the Parrot Anafi consumer drone and its controller, which connect via Wi-Fi. The Parrot Anafi hosts its own Wi-Fi network, allowing either the controller or a phone running the Freeflight app to connect. Our goal was to understand the signals sent to the Anafi for initiating takeoff and landing sequences.
Test Setup
Start by connecting your PC to the Parrot Anafi’s Wi-Fi network. Next, set up an ARP spoofing attack to place your PC in a man-in-the-middle position between the drone and its controller. This can be accomplished using tools like Ettercap, allowing your device to capture the data exchanged between the two.
The resulting test setup may look like this:
Packet Analysis
Using Wireshark, we can look at the packets, which are send during a landing and a starting sequence (picture shows just a snippet):
We can see that the communication between the drone and the controller is done over UDP. Every UDP packet had some kind of hex string as payload, which was non-ASCII
Next, we looked at the distribution of the packets send, of all packets send during one start and landing of the drone:
To distinguish which packet is responsible for the start and landing we captured 17 start and landings and saw that the amount of third type (length=53 bytes) of messages went from 2 to 34. Could this be the packet which controls the start/landing? since 17*2=34
We can filter in Wireshark with frame.len==53 to filter just for the start/landing packets:
The payload of the packets had a pretty clear structure: (here an example of a few)
After analyzing the protocol more, we could reverse the format of this type packet:
Attack
Let’s see if we can send our own packets from our PC to the drone, in order to start and land it, without using the controller. For that we setup a Python script (see below) to send a UDP packet with the payload 040bff0b000000300001000100 to the drone to start it. Note that we set the counter to FF, as packets are dropped by the drone if the counter value is less than the current counter. Using FF ensures it is always accepted.
And we did it! The drone performed its auto-start maneuver and was hovering above! In order to land the drone again we can send 040bff0b000000300001000300to the drone. Note that the trigger byte (2nd last byte) was set to 03.
Notice, one does not need to change the MAC address to get these results. The Anafi processed the packages even though the laptop was not the primary controller at this time.
If we spam either the takeoff or landing command, the following attacks can be exploited:
-
Possible Attacks
-
Prevent starts
-
The next experiment was to spam the landing command constantly, with the result that the drone was unable to start using the controller. The drone’s rotors were spinning for a second but then the landing command was received and the Anafi stopped the starting process.
-
-
Prevent landings
-
The same result could be achieved with spamming the starting package. If one presses the landing button on the controller or phone the drone started to go down, but as soon as the starting package from the laptop came in the drone stopped the landing and stared to hovering above the ground again. As a result, the phone user was unable to land the drone properly.
-
-
Summary
This case study shows why it is relevant to reverse network protocols when analyzing IoT devices. As an attacker, who has access to the Parrot Anafis WiFi network we can send unauthenticated packets to the drone and control its starts and landings. This can be done by any device, which can connect to WiFi networks.
Resources
Bachelor Thesis, Jonas Rosenberger (me)
https://www.parrot.com/en/drones/anafi
