Hacking and Reading Code from STM32 Microcontrollers

Unlocking Secrets: Hacking and Reading Code from STM32 Microcontrollers

When it comes to tiny computers called microcontrollers, STM32 is a big deal. These microcontrollers try to keep their secrets safe with something called Flash Readout Protection (RDP). In this article, we’ll explore the levels of protection these STM32 chips have and how some clever folks found ways to peek inside.

Breaking Down RDP Levels:

STM32 microcontrollers have different levels of protection. Think of it like having three doors – RDP 0, RDP 1, and RDP 2.0.

• RDP 0: This is the default level, and it doesn’t really protect anything. If you connect a special tool called a debug interface, you can access everything in the microcontroller.
• RDP 1: At this level, the debug interface is active, but it puts a limit on accessing the flash memory. Once the debug tool is connected, the flash memory gets locked. No one can read it directly, through DMA, or by executing instructions from it. You can either increase the protection to RDP 2 or decrease it to RDP 0, but if you go down, you lose everything stored in the flash memory.
• RDP 2: This is the maximum protection level. The debug interface is disabled, and you can’t lower the protection level. Despite being the safest, many companies prefer using RDP 1. They don’t completely block the microcontroller because debugging becomes impossible at RDP 2. Also, the STM32f1 series doesn’t support RDP level 2.

Where RDP Lives: The RDP Security Appliance

The level of RDP protection is like a setting saved in the microcontroller’s memory. It’s stored in a specific section called option bytes, using two registers known as RDP and nRDP. These registers act like twins – if one changes, the other follows suit. This redundancy ensures that no one can easily alter the protection level without proper authorization.

Understanding RDP Logic: User Mode and Debug Mode

When it comes to RDP level 1, there are two ways the microcontroller operates: User mode and Debug mode. The User mode is for regular functioning, while Debug mode activates when someone is trying to figure things out using a tool like a debugger. As soon as the microcontroller enters Debug mode, access to the flash is blocked. Trying to read from the flash, as per the manufacturer, should result in a bus error, followed by a Hard Fault interrupt.

In simpler terms, RDP is like the gatekeeper of a tiny computer’s secrets, offering different levels of protection. It ensures that only those with the right permissions can access and modify critical information stored in the microcontroller’s memory.

Cracking the Code: Understanding Cold-Boot Stepping Attack

Imagine a tiny computer that stores its secrets in two places: a locked drawer called FLASH memory and a temporary workspace known as SRAM. When a detective, called a debugger, tries to peek inside, it can only look at the locked drawer (FLASH memory) and not the temporary workspace (SRAM).

Now, here’s where the challenge comes in: Cryptographers, the people who create secret codes, face a problem. The keys to unlock the secrets are briefly stored in SRAM, but it’s like a quick visit – just a few milliseconds.

To overcome this challenge, smart folks developed something called Cold-Boot Stepping (CBS). It’s like taking quick snapshots of what’s happening in that temporary workspace (SRAM) at certain moments.

Let’s break down how CBS works in simple steps:

Step 1: Getting Ready

1. Turn it off: Power off the microcontroller. This step is crucial to let the microcontroller read from its flash memory again.
2. Set RESET: Before turning it back on, set a special reset mode. This allows the system to start without immediately running any secret codes.
3. Power up with RESET: Turn the power back on, ensuring it follows the set RESET conditions.

Step 2: Gradual Start-up

1. Start the code: Remove the RESET condition to kickstart the execution of the code.
2. Wait for a specific point: Let the code run until it reaches a specific point in its execution.
3. Install Reset: Stop the execution by reinstalling the RESET condition. This halts the code but keeps the data in SRAM (temporary memory) intact.

Step 3: Capturing Secrets

1. Connect the debugger: Link the microcontroller to a debugger, a tool that helps analyze and understand what’s happening inside.
2. Remove the reset signal: With the debugger in control, remove the reset signal. This keeps the microcontroller in a halted state, preventing it from running the code.
3. Grab the SRAM content: Take a snapshot of the data stored in SRAM. It’s like capturing a photo of the temporary workspace without letting the microcontroller proceed with its secret operations.

Now, repeat these steps as many times as needed to gather information about what the secret code is up to. The trick here is to precisely control the timing – it’s like having a super-accurate clock.

Just remember, this tricky maneuver requires some special tools to control time accurately. In simpler terms, the CBS attack is like freezing a moment in time to understand what’s going on inside the tiny computer’s brain without letting it spill its secrets.

If you enjoyed this blog and want more, comment to let me know, and I’ll continue. You can also download the original article with all materials and examples provided under the MIT license: Shedding too much Light on a Microcontroller’s Firmware Protection, Download Firmware Under Attack and Firmware Extraction PoC