STM32 Read-out protection via OpenOCD

Question

The STM32 family of microcontrollers features a read-out protection feature so proprietary code can't be read out via the debug interface (JTAG or SWD).

Using OpenOCD, how can I enable/disable the read-out protection via a SWD/JTAG interface? How secure is the RDP read-out protection?

If possible, please give an answer valid for the entire STM32 family.

Gerrald

@halfer Here's the meta question: meta.https://mcmap.net/q/828412/-what-is-the-easiest-way-to-determine-the-dependencies-of-a-net-assembly/2597135 – Nancynandor

Answer 1

RDP levels

First, you have to know which level of readout protection you want to set (refer e.g. to section 3.7.3 of the STM32F4 reference manual):

• RDP level 1: This level is reversible. Once you disable it, the system memory is mass-erased and you can re-program
• RDP level 2: This level is irreversible and disables the debug interface altogether. The only way of updating your firmware is via some bootloader mechanism.

Usually you want to activate RDP level 1. In order to avoid mistakes that will certainly brick the microcontroller, I will not show how to enable RDP level 2 in this answer. Refer to the reference manual for details.

Activating it using OpenOCD

The activation feature is actually built-in into OpenOCD using the lock command. Just like executing the program command to flash your firmware, you can use the stm32f1x lock command (or stm32f2x lock for STM32F2/F4) to activate it.

A typical OpenOCD configuration file would look like this (you need to flash the correct firmware before running this):

# Set RDP to level 1
init
reset halt
stm32f1x lock 0
reset halt
exit

Note that the readout-protection will only be in effect once the microcontroller is reset or powered off (that's why there's a second reset in the command sequence).

A typical OpenOCD call could look like this:

openocd -d0  -f stlink-v2.cfg -f ocd-stm32f0.cfg -f ocd-lock.cfg

where ocd-lock.cfg contains the command sequence shown above.

Once activated, you can verify that the RDP is active by trying to flash the MCU using your usual programming command sequence

Deactivating RDP

Deactivating it is just as simple: Just use stm32f1x unlock (or stm32f2x unlock for F2/F4 devices) like this:

# Set RDP to level 0
init
reset halt
stm32f1x unlock 0
reset halt
exit

How secure is it?

That's a tough question that can't really be answered without additional information. One summary answer I can give is that it's pretty secure if you assume the protection has no inherent bugs and someone uses software tools only.

One of the most popular methods of resetting the RDP bit without mass-erasing the flash is to disable the RDP with a laser. Given the fact that the STM32 family is not a family of dedicated security microcontrollers with specific countermeasures, this is rather easy if you have the right equipment and sufficient experience in this area. Even some specific security MCUs have some security issues, see e.g. the Security from the IC backside talk. However, most low-level attackers will usually refrain from the cost of doing so.

Gerrald

It doesn't work for STM32F072, but tested successfully on STM32F107. @halfer What is the content of your file ocd-stm32f0.cfg ? – Subcontraoctave

@Motla: my avatar is attached to this answer because I edited it (the "edited" link in the centre). Uli is the owner of the answer, they will be pinged now you have commented. – Tadd

@Subcontraoctave There are a lot of details to get right. I would suspect you've got the wrong TAP ID (look it up for the F072 in the datasheet or Refman). FYI I tested this (and I am regularly using this) using STM32F030, STM32F042 and STM32F407. This is my ocd-stm32f0.cfg but you really need to set the correct parameters, e.g. CPUTAPID, for yours: gist.github.com/ulikoehler/6395994c623059e184971908d01c600f – Nancynandor

In ref. manual corresponding to STM32F072, at section 32.5 apparently IDCODE corresponds well to your TAP ID. Moreover "stm32f1x options_read 0" command seems to work fine, but not "stm32f1x options_write 0 .."so it may be a bug from OpenOCD which can't write option bytes on this particular device, idk why because it's at the same address... – Subcontraoctave

Answer 2

Another solution is using Segger Jlink 6.60c (or later if available) with J-Link unlock STM32 software. Just run it, it will notify about following: "If read protection of the device is enabled, reset the option bytes will cause a mass erase". Click OK. It will ask for device family. Enter device family (my choice was 12 for STM32L4R9ZI) and press Enter.

If all good the output will be like this:

Please select the correct device family: 12
Connecting to J-Link via USB...O.K.
Using SWD as target interface.
Target interface speed: 1000 kHz.
VTarget = 3.396V
Reset target...O.K.
Reset option bytes to factory settings...
Resetting FLASH_OPTR...
Reset target...O.K.
Reset target...O.K.
Resetting Write protection (WRP) and PCROP...O.K.
Reset target...O.K.
Option bytes reset to factory settings.
Press any key to exit.

Brandnew