nRF52 Debug Resurrection (APPROTECT Bypass) Part 2

After the Part 1 describing the APPROTECT Bypass, this new post presents how to:

• exploit a real product based on nRF52840 to extract the Firmware and reactivate the SWD interface.

• reproduce the attack on others nRF52 SoCs to confirm the vulnerability in all the nRF52 versions.

Exploit Validation on real Product

Let’s start by a classic scenario, where an hacker needs to access the Firmware of a product. If this product is based on nRF52, it is likely protected to avoid the firmware readout, in order to prevent reverse-engineering.

The Target: Logitech G Pro

For the exploit validation, I selected the first device I have on hand. It is my Logitech G Pro Mouse based on nRF52840.

Note: My goal is not to attack the Logitech product here.

Getting Access

I skip the teardown part but for people interesting in, here is a nice YouTube video.

The device is dismantled to access the main board:

The SWD pins (SWDCLK, SWDIO) are silkscreened, so these are easy to identify (red frame).

Then, some pin headers are soldered to connect the target to a Segger J-Link Debug probe:

Any attempt to connect via OpenOcd and GDB is rejected:

$ openocd -f /usr/local/share/openocd/scripts/interface/jlink.cfg -c "transport select swd" -f /usr/local/share/openocd/scripts/target/nrf52.cfg

$ arm-none-eabi-gdb

Of course, the APPROTECT feature is enabled on this device.

Reproducing the APPROTECT Bypass

Preparation

The nRF52840 is located on the PCB back-side and acts as the main processor of the system.

The PCB design matches perfectly the nRF52840 reference design (found in the Nordic Datasheet). It’s like a copy-paste design.

Decoupling capacitors C5 and C15 are removed and the glitch output is connected to VDD_CPU (DEC1) :

The VDD_CPU (DEC1) is connected to the glitcher via an SMA connector. Here is a view of the full attack setup:

Fault attack Time

The fault attack is launched by running a python script, which is in charge to synchronise the glitch system, the oscilloscope and to reset the device after each fault attempt.

This screenshot shows a normal boot-up (classic behaviour of the device):

Then, the result you want to obtain, after a successful fault:

The VDD_nRF signal on the board is used as scope trigger reference. After a specific delay, the injected fault is disrupting the normal initialisation of the nRF52840.

From the shell point-of-view, the external debugger can now connect to the mouse:

Firmware extraction

Once connected, the next step is to dump the Firmware and the UICR:

#openocd via telnet
dump_image FLASH.bin 0x0 0x100000
dump_image UICR.bin 0x10001000 0x1000
#optional
dump_image FICR.bin 0x10000000 0x1000

Here are the boot loader version and the Device Name at 0xE5CD8 in the flash memory:

Static Code Analysis can then be performed, in order to find vulnerabilities (or just to understand how it works).

Permanent Debug Reactivation

In order to reactivate persistently the debug interface, the APPROTECT is disabled (see Part 1) and re-flashed with the extracted FLASH.bin and the UICR.bin (of course with APPROTECT patched to 0xFFFFFFFF):

The mouse is back to “Development Mode” where dynamic Code Analysis is a tremendous advantage (especially during exploit development).

The Family Burden

Until now, all the results have been obtained on the nRF52840. 

The nRF52 SoCs shares the Cortex-M4 CPU, the same Debug Ports, the same Flash Memory (except the memory array), and the same NVMC. In this context, it is likely the vulnerability is common to the entire nRF52 series SoC family. Here is my vision of the nRF52 ecosystem:

Results on nRF58233

Once more, similar tests are achieved on the nRF52833-DK, based on nRF52833.

Schematic and PCB view for reference:

On the nRF52833, the initialisation of the Flash Controller is equivalent to the previous analysed nRF52s. Fault injection is performed on CPU Power line DEC1:

Same here, SWD is reactivated:

The nRF52833 is vulnerable to the APPROTECT exploit.

After these tests, no doubt all nRF52 versions are vulnerable.

Impact

Nordic confirmed the security issues in their information notice sent to all their customers the 12th of June 2020.

in my opinion, the nRF52 APPROTECT feature can be defeated in a short amount of time and with a very limited budget.

CVSS Score is 7.6 (Severity = High) CVSS:3.0/AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H.

The following Nordic nRF52 versions are vulnerable:

• nRF52810
• nRF52811
• nRF52820
• nRF52832
• nRF52833
• nRF52840

and by consequence, Modules based on nRF52 are vulnerable too.

These modules can leverage all the features of Nordic’s SoC Hardware and Software architecture to make a ‘single module product’ without the need for an additional microcontroller to run your application.

Nordic provides references of third-party modules here, such as:

• Fanstel Corp.
• Laird
• Minew
• Raytac
• Taio Yuden
• U-blox
• Wurth Elektronik
• Murata
• Dynastream
• Fujitsu
• …. and more

Conclusion

The APPROTECT Bypass has been demonstrated on a commercial device, the Logitech Pro G Mouse.

Additional tests have been achieved on nRF52832 and nRF52833. The results show these platforms are vulnerable too. NordicSemiconductor confirmed all their nRF52 versions are vulnerable.

This is impacting a tremendous number of devices on the field right now, from nRF52-based products to Third-party Modules (using nRF52 platforms).

The vulnerability resides in Silicon. There is no way to patch without HW revision.

Timeline Disclosure

NordicSemiconductor and LimitedResults did not agree on a responsible disclosure. (See Part 1 for more details). They made their decision and I respect that. Life goes on.