Hacking the DJI Phantom 3
Finally, during Christmas time, I had some spare time to play with my flying beast; I’m speaking about trying to hack my DJI Phantom 3.
It was my first time that I operate with drones or similar embedded system and at the beginning I didn’t have any clue about how I could interact with it.
The Phantom 3 comes with an aircraft, controller and an Android/iOS app.
Let’s start from the beginning:
As a first step, I have analysed the protocols, the connection between the aircraft and the controller is done with Wi-Fi 5.725GHz – 5.825GHz (and not the Lightbridge protocol, for long range), while the connection between controller and mobile device is operating at 2.400GHz-2.483GHz, the controller is acting like an AP.
Wi-Fi encryption is WPA2 and the default SSID is derived from the MAC address of the remote controller: PHANTOM3_[6 last digits of MAC address]. The default associated password is: 12341234
Inside the network, I was able to find out these IP addresses:
- Controller: 192.168.1.1
- Aircraft: 192.168.1.2
- Camera: 192.168.1.3
- Phone (DJI GO App): 192.168.1.20
Interestingly, the camera is separated from the aircraft, I suppose because in that way, image feedback won’t interfere with the aircraft navigation.
Here the nmap result for every device:
Nmap scan report for 192.168.1.1 21/tcp open ftp syn-ack vsftpd 3.0.2 22/tcp closed ssh conn-refused 23/tcp closed telnet conn-refused 2345/tcp open landesk-rc syn-ack LANDesk remote management 5678/tcp closed rrac conn-refused Nmap scan report for 192.168.1.2 21/tcp open ftp syn-ack vsftpd 3.0.2 22/tcp filtered ssh no-response 23/tcp filtered telnet no-response 2345/tcp filtered unknown no-response 5678/tcp open tcpwrapped syn-ack Nmap scan report for 192.168.1.3 21/tcp open ftp syn-ack BusyBox ftpd (D-Link DCS-932L IP-Cam camera) | ftp-anon: Anonymous FTP login allowed (FTP code 230) | total 0 | drwxr--r-- 2 0 0 0 Dec 23 2016 DCIM | drwxr--r-- 6 0 0 0 Dec 23 2016 MISC |_drwxr--r-- 2 0 0 0 Dec 23 2016 System Volume Information 22/tcp open ssh syn-ack OpenSSH 6.2 (protocol 2.0) 23/tcp open telnet syn-ack BusyBox telnetd 2345/tcp filtered unknown no-response 5678/tcp filtered rrac no-response
How you can see from the above scan, some services draw my attention:
- FTP
- SSH
- Telnet
- landesk-rc
- rrack
Since I didn’t have any passwords for these services I decided to give a look at the Android App (DJI GO) and surprisingly, I found these details while reversing it:
- res/raw/upgrade_config.json
- res/raw/flyforbid.json
While the first file contains the root password for the FTP access to every device inside the network, the second file contains some areas where the drone cannot fly (no-fly zones/virtual fence) like: airports, stadiums, military bases, cities, etc.
Unfortunately, on the latest firmware (V01.07.0090), the root ftp access to the drone is chrooted and I wasn’t able to escape the /tmp directory, plus, Telnet and SSH access are disabled.
I tried to replace the firmware with a modified version but the firmware is signed and resilient to tampering.
Downgrading the firmware to its precedent version (V01.06.0080) result in an unrestricted root FTP access, so, I dumped the file system and started diving into it.
root:x:0:0:root:/root:/bin/ash daemon:*:1:1:daemon:/var:/bin/false ftp:*:55:55:ftp:/home/ftp:/bin/false network:*:101:101:network:/var:/bin/false nobody:*:65534:65534:nobody:/var:/bin/false
The drone underlying system is a fork of OpenWRT 14.07 “Barrier Breaker, r2879, 14.07” built for “ar71xx/generic“, same version for the controller.
Root access to the aircraft is something hard to achieve because the root password is strong, I tried to crack it but it resists to some days of cracking (thanks to the Hacktive Security’s guys)
So, I decided to take another path, re-enabling the Telnet service. Searching inside the filesystem I found these files:
- /etc/init.d/rcS
- /etc/init.d/rcS_ap
- /etc/init.d/rcS_aphand
- /etc/init.d/rcS_cli
These script runs during the boot process, enabling the code on line 61 will start the telnet server
telnetd -l /bin/ash &
In that way, I managed to get root access to the aircraft and the controller underlying system:
Further work:
- Check the rrac and the landesk-rc services for some cool exploit
- Check the device queue trying to de-authenticate mobile phone and perform the takeover
- Check the SDK to hijack an inflight drone
- GPS Attack