Nozomi Networks Labs recently conducted research on the security of a DJI Mavic 3 Series drone, with a special focus on the WiFi-based protocol called QuickTransfer Mode. This protocol enables a user to quickly download videos and pictures from the drone directly to their mobile phone when the drone is not flying.
After successfully downloading and analyzing the firmware, we discovered several vulnerabilities that have yet to be patched. As the patching process is still ongoing, we are unable to provide specifics on these vulnerabilities. However, we plan to share further details in a future blog once the patches have been released.
In the first part of this blog series, we describe the firmware upgrade procedure implemented by DJI via their cloud-based infrastructure, analyze the official DJI mobile app, and detail how we were able to bypass its protections to download and analyze the official firmware.
Typically, when conducting a security evaluation on a device, the initial phase involves extensive analysis of the firmware. This allows the researcher to obtain and inspect binaries and configuration files that make up the operating system and primary services running on the device.
To connect to the radio controller, the mobile device must have the official DJI Fly application, which can be downloaded and installed from the official DJI website. This app enables users to get new firmware releases and push them to the drone through the radio controller. Whenever a new firmware release is available, DJI Fly sends a notification to the user who can choose whether to install it or not. The firmware is signed by DJI and will only be accepted by the drone if the signature validation is successful. Figure 1 displays an image from official DJI documentation that provides an overview of the entire process.
After conducting a quick analysis of the mobile application, we were able to gather some additional details which are summarized in Figure 2. Although we attempted to passively sniff the traffic between the mobile application and cloud infrastructure, we quickly realized that this was not sufficient due to the encryption provided by HTTPS.
Our initial attempt at a man-in-the-middle (MitM) attack also failed due to certificate pinning implemented in the mobile application, which only allows connections with services that provide a trusted TLS certificate. The certificate pinning can be implemented in several ways, with standard libraries or implemented with custom code directly inside the application. To avoid further blind attempts and overcome numerous obstacles, we decided to conduct a more thorough analysis on the DJI Fly mobile application and develop a targeted attack scenario. The good news is that inspecting the application can provide valuable insights to enhance our analysis.
Once unpacked, the chunk was found to be a JAR archive, shown in Figure 10. Upon inspection, it was found to have the same structure as an Android OTA package as described in the official documentation. This leads us to believe that the Mavic 3 drone series runs an Android-based operating system.
The decrypted chunks primarily consist of the Linux kernel image along with its required files to run, and an additional archive that contains the root file system partition that can be unpacked using cpio. Copying the previously extracted vendor and system folders inside the root partition completes the file system Android layout, in Figure 12, with everything necessary to analyze and reverse engineer the services running on the drone.
Thorough analysis of the init scripts (including init.rc and all imported configuration scripts), it is possible to figure out which the main services run on the drone and which binaries implement them. This allows us to potentially statically reverse engineer them and, if possible, dynamically analyze them through emulation.
During the update everything hung at 48% for a while. The battery then showed two dots in the middle, with one of those two flashing, while the outer two dots remained off. I was a bit concerned at this point but it soon sorted itself out though and carried on nicely.
Great read, i have been very busy so when I finally had time to switched on the bird straight away it was asking for firmware update:triumph:, im getting so sick of updates and I do find when I bought the bird when first released it flew fantastic and no distance problem or video lagging, updates are noticeable on restrictions more annoying alarms distance reduced video lagging.
im getting so sick of updates and I do find when I bought the bird when first released it flew fantastic and no distance problem or video lagging, updates are noticeable on restrictions more annoying alarms distance reduced video lagging.
Will the new RID update for the Mavic 2 Pro cost you Litchi support?The reason I ask is that the release notes for the software caution that you will lose support for DJI Gs Pro, their mapping application if you update to the new firmware.Has...
I can personally confirm that Litchi WILL work on my M2Pro with the new RID compatible firmware updates.
RID is being transmitted and seen using the Air Sentinel app.
Now, if DJI and FAA would formally add it to the Declaration of Compliance, everyone will be in full compliance.
Not sure if the forums have been updated but had to re-create my account here for some reason. Anyhow... Just saw the episode on the mavic, there was a thread on mavicpilots.com that was discussing the reversing of the mavic firmware, though it seems to not be available anymore so I grabbed a cached copy of the thread, I was able to get page 1,2,3,5 so if anyone can find page 4 it would be appreciated. Anyways, I'll post a blurb but wanted to check if I'm allowed to post the txt of the thread as DJI was likely the people who had it pulled off the other site. Let me know if I'm allowed to post it here, don't want you in trouble with DJI...
"We extracted the Mavic Pro firmware. You can download here things:- The Mavic runs Android KitKat.- A secret command can be sent over USB which would switch a debug flag, and would run ADB over USB on the next boot. This ADB server allows regular debug root shell (basically, fully owning the Mavic).- There seems to be a whilelist of device for which this "super debug" mode is enabled once present on the same network.- OcuSync, like LightBridge, seems to be a regular SDR interface with IP stack running on top it.- BusyBox FTPD is running on all interfaces, but unlike Phantom 3, in Mavic it's restricted to '/ftp' directory. Luckily, there are underground 0day exploits for FTPD for path traversal. I can confirm that you can traverse out of the '/ftp' directory and reach the init scripts to set debug flag. After reboot, now USB has ADB running on it, with root shell.- Bypassing the 500m ceiling turned out significantly easier than we anticipated. An exercise left for the readers - Finally, with our debug root shell, we're currently trying to poke around with the SDR interface to see how EC restrictions are applied (we of course know it's GPS-based on boot-time). If we manage to reverse-engineer this part, this means we can bypass the restriction. At the moment, the only way to bypass the EC restriction and enabled FCC mode in EU is to falsify GPS signal on boot time using HackRF GPS signal generation.Fingers crossed! Any results we achieve with the Mavic can pretty much be translated to Phantom 4."
Pay particular note to 1:21 seconds into this iFixit tear down of the mavic where they show an onboard microsd card that is GLUED in under a metal shield, might wanna have a look at what's on that card...
"Anybody interested in reversing the Mavic firmware?
Discussion in 'Mavic Pro Discussions' started by P0V, Nov 19, 2016 at 8:57 AM.
P0V
We extracted the Mavic firmware ExpireBox Mavic_Latest_Firmware_01.02.7z
We're doing some reverse-engineering on it right now. So far, we're getting some very good progress.
If anybody is interested, hit me up so we can exchange ideas.
Any news on this? Sadly I cant find any FTP-path traversal vulnerabilitys on android kitkat systems :/
I analyzed the leaked firmware-files, there are "whitelist" hosts (in /data/wm330_debug_whitelist.xml.sig but no access on this)
Tried to find out something about the "FTP-path traversal" with the "DotDotPwn"-tool in Kali linux. This would be the key - you can scan the directorys for specific filenames, find out the secret hostname/MAC-Adress in the whitelist-file and boot the mavic in ADB/root-mode....
But this FTP-exploit was patched in the 01.03.0000-Firmware. My bird was already on 01.03.0200. I downgraded to 01.03.0000, but sadly cant downgrade to anything below this to find out more :(
First post says "Anything should work with the Phantom 4" ... so far, I've been able to binwalk the P4 file... but I haven't been able to get ADB access.
Any progress on dealing with newer P4/Mavic firmwares?
Here is a tar of the latest Firmware I could find ( which I have unpacked ) for the Phantom 4.
Thanks for that Martin... that was quite generous of you to share. Does anyone still have the original MAVIC firmware images? I didn't have the pleasure of my ftpd having dir traversal issues, so I am late to the party.
Since the JTAG connectors are so prominently accessible in the corner of the main board, it might be possible to read and write the firmware through this interface using a bus pirate or riff box or similar... as a suggestion.
2. Standard Startup
Next, simply set up your drone as per usual by turning on the drone and remote controller. Connect your smartphone to your remote controller and ensure your smartphone has a stable wi-fi connection. Pair your drone and controller like normal.