Deconstructing the AR.drone: Part 1

When I first became aware of the existence of the AR.drone, made by the Paris-based manufacturer of wireless gadgets Parrot, I knew I was going to own one. To some, the AR.drone is a radio-controlled quad-rotor helicopter. To others, it's a fragile $300 toy. To me, it's nothing less than a sophisticated Linux-based WiFi-enabled flying embedded system just begging for me to peek under its hood. The device has been so popular, I am walking down a road well traveled; but it is scenery I have never seen before.

The AR.drone is piloted by an iPod app, making it usable with any WiFi-enabled iDevice (although Android-based apps are starting to appear). The drone has two video cameras, one front facing and the other down facing, plus an accelerometer, two gyrometers, and an ultrasonic altimeter. It is all controlled by an ARM-based processor running Linux. Both the iOS-based app and the Linux-based embedded system are hackable; Parrot provides an SDK and encourages developers to use it as an application platform. I control my AR.drone with my iPad.

Unlike other RC helicopters of my personal experience, the AR.drone is relatively easy to fly, by virtue of its sophisticated embedded flight control software and sensors. The system can take-off and hover with stability with just the press of a virtual button in the app. A few minutes of practice and I was able to slowly maneuver it around a room in the Palatial Overclock Estate. Roll and pitch are controlled by tilting the iPad; yaw is controlled by a virtual thumbwheel in the app. The controls on the app are superimposed on a video image from the front facing camera. (The very first time I flew the device I was so focused on the controls that I failed to notice the screen-filling face of one of our house cats on the display just as I hit the take-off button. Wackiness ensued.)

As much fun as the AR.drone is to play with, it didn't take long for my child-like curiosity to overcome my child-like glee. I fired up one of my most useful embedded system tools - an HP Mini 110 netbook running Windows 7 and equipped with a raft of useful software - and started poking at the AR.drone.

My drone appeared as an ad hoc WiFi network whose service set identifier (SSID) was ardrone_040582. An ad hoc WiFi network is one which does not require any infrastructure like an access point or router. All members of an ad hoc WiFi network implement a packet radio network, treating their shared radio channel in a collision-sense multiple-access / collision detect (CSMA/CD) manner. This is just like the original unswitched baseband Ethernet architecture circa 1975, which borrowed from the even earlier ALOHAnet, which itself was a wireless packet radio network that first became operational in 1971. Pairing the iPad with the drone network is a simple manner of choosing the right network in the iPad WiFi control.

Notice that the iPad gets its internet address, mask, and default gateway (router) via Dynamic Host Configuration Protocol (DHCP). That means the AR.drone must be running a DHCP server. The upside is this makes pairing the iPad to the drone easy. The downside is this makes integrating the drone into an existing WiFi infrastructure difficult, since running two DHCP servers (one of which you don't control) on the same subnet is problematic. And who is the router? That must be the AR.drone as well.

Next, I used the netbook to scan for WiFi networks, and connected it to the same ad hoc network. (To make my neighbor's lives a little easier, I've obfuscated the other SSIDs in my neighborhood.)

I left the netbook set up for DHCP, so it also acquired its internet parameters from the DHCP server in the AR.drone.

I fired up IPScan on the netbook to see if there were any other hosts responding on the 192.168.1.0 subnet running on the drone's ad hoc WiFi network. 192.168.1.1 is the AR.drone. 192.168.1.2 is the iPad. 192.168.1.3 named gypsum is the netbook.

Next, I pointed Nmap at the AR.drone to scan for TCP ports that the device exposes. The tool can see ports 23 (typically the network terminal protocol TELNET), 21 (typically File Transfer Protocol or FTP), and two other ports: 5559 and 5551.

A service scan of the known ports reveals that port 21 can be accessed for anonymous FTP, making the AR.drone a flying file server which provides three files right out of the box: licenses.txt, repair, and sys_bootldr.bin. Although it's not shown in this screen snapshot, the tool also reveals that the TELNET port delivers a root prompt without requiring a password.

At this point I would be remiss if I didn't TELNET into the AR.drone using my favorite Windows-based virtual terminal tool, PuTTY. Configuring PuTTY to TELNET into the AR.drone is easy given we know its IP address and port number.

Connecting to the TELNET port yields a root shell prompt. Below is a photograph of, from left to right, the netbook TELNETed into the AR.drone, the AR.drone, and the iPad running the AR.drone app. These three devices constitute a tiny wireless IP subnet, one component of which could be flying around the room.

Next up: exploring the host software side of the AR.drone as a flying Linux system.