The nRF51 Series SoCs is a family of low power Bluetooth chips from Nordic Semiconductor that is based on ARM Cortex cores. The nRF51822 has the Cortex M0 core and is used in a lot of products. [Loren] has written a blog post in which he claims to be able to circumvent read back protection on the chip, thus giving access to the ROM, RAM and registers as well as allow for interactive debugging sessions.
The hack stems from the fact that the Serial Wire Debug or SWD interface cannot be completely disabled on these chips even if the Memory Protection Unit prevents access to any memory regions directly. The second key piece is the fact that CPU can fetch stuff from the code memory. Combined with the SWD super powers to make changes to the registers themselves, this can be a powerful tool.
The ARM instruction set contains a number of Indirect-Addressing Load Instructions and [Loren] points to a pseudo-instruction for LDR R2,[R0] which permits copying data from the location in the ROM that is specified by R0. The idea is to search for the instruction within the code that is already inside the ROM since we cannot write to the memory ourselves. So how do we do that? Easy just use the Program Counter to cycle through all the code-space keeping R0 and R2 as zero. When you hit an instruction that makes R2 the same value as the stuff in 0x00000 (as R0 is 0x00000), we have found the instruction. The value at 0x00000 is incidentally identified by the SWD initially as the value in the stack pointer.
Once you have the address (in the PC) for the instruction that can copy info from the ROM, its just a matter of setting R0 to different values, setting the PC to the LDR instruction location and single stepping it to watch it copy it to R2. Loop and you can dump the entire ROM. [Loren] has packaged the whole thing in a Python script (Github) which you can try out with an ST-Link at home.
The nRF51 is used in a lot of places including the BBC microbit as well as other devices that can be sniffed using cheap SDRs for a start. The game is afoot.
Read protect is the lowest protection level I have seen on ARM chips. While it is a neat hack and all, it is like 007 gadget that are only useful in one very specific case. Not that I won’t carry a bat shark repellent if there are any risk of running into one on land.
How do you access SWD if your uC completely disable the interface? I have bricked one chip because the source code was relying on non-portable across compilers and wrote a wrong value that disable the SWD. i.e. debugger cannot connect – end of story.
Usually you recover by holding reset pin low while connecting from debugger application, stopping the CPU and then releasing the reset. OpenOCD can do that automatically with some setting.
The reset would work if it was a mis-configured I/O pin setting in user code. I had to attach the /reset pin in the past.
It won’t work if the protection register deliberately disable the SWD interface. It was a one way with no option for full chip erase. The only thing that might work is glitching the power to disrupt the hidden internal supervisor code that does all the magic during a reset.
Recovering from total lockout depends on the chip. On STM32 it is possible, but the application software that is in the chip needs to do it, and it will erase the flash in the process. (According to the datasheet, I never did this myself)
But on STM32 it isn’t that easy to get into this state, as it requires a specific sequence of register writes.
It was a NXP/Freescale Kinetis part. I have switched to STM32 part these days.
It’s a nice feat, but isn’t it exactly the same as this from 2018? https://www.pentestpartners.com/security-blog/nrf51822-code-readout-protection-bypass-a-how-to/
Yes. This is a really old hack.
This script just automates the process a bit.
I wrote a GDB script to do the same thing several years ago, but the readout was rather slow.