Applying Fault Injection to the Firmware Update Process of a Drone

IOActive recently published a whitepaper (https://ioac.tv/3N005Bn) covering the current security posture of the drone industry. IOActive has been researching the possibility of using non-invasive techniques, such as electromagnetic (EM) side-channel attacks or EM fault injection (EMFI), to achieve code execution on a commercially available drone with significant security features. For this work, we chose one of the most popular drone models, DJI’s Mavic Pro. DJI is a seasoned manufacturer that emphasizes security in their products with features such as signed and encrypted firmware, Trusted Execution Environment (TEE), and Secure Boot.

Attack Surface 

Drones are used in variety of applications, including military, commercial, and recreational. Like any other technology, drones are vulnerable to various types of attacks that can compromise their functionality and safety. 

 
 

As illustrated above, drones expose several attack surfaces: (1) backend, (2) mobile apps, (3) radio frequency (RF) communication, and (4) physical device.

As detailed in the whitepaper (https://ioac.tv/3N005Bn), IOActive used EM emanations and EMFI due to their non-invasive nature. We leveraged Riscure products as the main tools for this research.

The image below show the PCB under analysis after being removed from the drone; power has been connected to an external power supply.

First Approach

Our first approach was to attempt to retrieve the encryption key using EM emanations and decrypting the firmware. We started by finding an area on the drone’s PCB with a strong EM signal so we could place a probe and record enough traces to extract the key.

After identifying the location with strongest signal, we worked on understanding how to bypass the signature verification that takes place before the firmware is decrypted. After several days of testing and data analysis, we found that the probability of successful signature bypass was less than 0.5%. This rendered key recovery unfeasible, since it would have required us to collect the tens of thousands of traces.

Second Approach

Our second approach was to use EMFI based on the ideas published by Riscure (https://www.riscure.com/publication/controlling-pc-arm-using-fault-injection). Riscure proposes using a glitch to cause one instruction to transform into another and gain control of, for example, the PC register. The following image shows the setup we used for this approach, which included a laptop (used as a controller), a power supply, Riscure’s Spider (used to generate the trigger), an oscilloscope, an XYZ table, and the EMFI pulse-generator.

After identifying a small enough area on the PCB, we modified the glitch’s shape and timing until we observed a successful result. The targeted process crashed, as shown below:  

Program received signal SIGSEGV, Segmentation fault.

0x2a002f44 in ?? ()

#0  0x2a002f44 in ?? ()

#1  0x2a000f5a in ?? ()

#2  0x2a0011de in ?? ()

#3  0x2a000b04 in ?? ()

#4  0xb6f9b42c in __libc_init () from /system/lib/libc.so

#5  0x2a00099c in ?? ()

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

r0             0x41414141  1094795585

r1             0x41414141  1094795585

r2             0xbefff6dc  3204445916

r3             0x41414141  1094795585

r4             0x41414141  1094795585

r5             0xbefffbc4  3204447172

r6             0x85242d9a  2233740698

r7             0xbefff6f0  3204445936

r8             0xb6b4e008  3065307144

r9             0xb6b4e1e8  3065307624

r10            0xbefffad0  3204446928

r11            0x2d7160  2978144

r12            0xbefff6ec  3204445932

sp             0xbefff6c8  0xbefff6c8

lr             0xde  222

pc             0x2a002f44  0x2a002f44

cpsr           0x60000030  1610612784

Our payload appeared in several registers. After examining the code at the target address, we determined that we had hit a winning combination of timing, position, and glitch shape. The following capture shows the instruction where a segmentation error took place:

The capture clearly shows a load instruction copying our data to registers R0 and R1. In addition, the GDB output also shows that registers R3 and R4 ended up with controlled data. Further details can be found in the whitepaper (https://ioac.tv/3N005Bn).

Having successfully caused memory corruption, the next step would be to design a proper payload that achieves code execution. An attacker could use such an exploit to fully control one device, leak all sensitive content, enable ADB access, and potentially leak the encryption keys.

Disclosure Timeline

The DJI team response was excellent, fast and supportive.

2023-04-04: Initial Contact with DJI including sharing report.
2023-05-04: DJI agrees on publication date.