Nordic Semi nRF52 WiSoCs are Susceptible to Debug Resurrection using APProtect Bypass

Nordic Semi nRF52 are popular wireless Cortex-M4 SoCs with Bluetooth 5.0 and 802.15.4 radios. APProtect (Access Port Protection) is a new security feature of nRF52 MCUs designed to enable readback protection and disable the debug interface. This is supposed to prevent an attacker to obtain a copy of the firmware that would allow him/her to start the reverse engineering process or access some sensitive data such as keys and passwords.

It’s all good, except “LimitedResults” managed to bypass APProtect and permanently resurrect the debug interface on nRF52840-DK and a Bluetooth mouse. This requires physical access to the hardware and relies on a fault injection technique.

nRF52 APProtect
APProtect on nRF52 – Click to Enlarge

The APProtect background and hacking technique are all explained in detail on LimitedResults blog post, but basically he first had to remove some capacitors and use a low-cost homemade voltage glitching system combines with an oscilloscope to try to locate a particular pattern into the power consumption. The goal was to find when the User Information Configuration Registers (UICR), where APPROTECT value is stored, may be copied to the core to configure the Debug Ports (AHB-AP, CTRL-AP) and set the APPROTECT to finally disable the debug interface.

nRF52 Hardware Hack Enable Debug
Hardware Hack Required!

A python script would be in charge to arm the oscilloscope, set the different glitch parameters, and reset the board to allow access to the AHB-AP debug board and sent command via OpenOCD. After the glitch, the CPU is stuck in an endless loop but it’s still possible to access the register and read data from the flash and SRAM. That trick is not permanent though, as the glitch method would have to be used after each reboot. He eventually found a method to make the hack permanent:

  1. Dump the Flash memory at 0x00000000
  2. Dump the UICR at 0x10001000
  3. Erase the device: nrfjprog -f NRF52 –recover
  4. Reflash the nRF52 again to write the Flash memory content and the UICR (with a proper patch of the APPROTECT value set to 0xFFFFFFFF).

He’s also posted about the Bluetooth mouse hack in a separate blog post.

The hack will not be a problem for most nRF52 devices, as it’s unlikely somebody decides to hack your Bluetooth mouse,  and wearables are worn most of the time. Cryptocurrency wallets may be another issue, as somebody who stole your wallet, may also be able to steal your Bitcoin. That would however require much more hacking besides just being able to access the debug port on nRF52. One such product is SecuX V20 crypto hardware wallet, but there may be others.

Nordic Semi already issues an informational notice about the security vulnerability, and since that’s a hardware issue the only mitigations are to prevent physical access to the device, or detect and respond to product enclosure breach. Nordic also notes that “the nRF52-series of SoCs, like many standard microcontroller circuits, are not hardened against fault injection techniques”.

Thanks to “Anonymous” for the tip.

Share this:

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK Pi 4C Plus
Subscribe
Notify of
guest
The comment form collects your name, email and content to allow us keep track of the comments placed on the website. Please read and accept our website Terms and Privacy Policy to post a comment.
2 Comments
oldest
newest
David Willmore
David Willmore
3 years ago

As a hacker, this makes me happy. But, I can imagine the grief it will give comercial designers.

zoobab
3 years ago

JTAG resurrection. The Debugger waking up from its grave.

Khadas VIM4 SBC