This is likely because in many cases, ST will sell microcontrollers with more flash than advertised. For example, the STM32F103C8 on the popular "bluepill" dev board is advertised as having 64 KB of flash. It actually has 128 KB of flash because it's the same chip as the STM32F103CB (this simplifies manufacturing because they can use the same die for both), it's just that ST never tested the second half of flash. In most cases you can use the second half of flash and it'll work just fine, but obviously it's not something you'd want to rely on for a commercial product.
> the STM32F103CB
Damn I have a hard time visually telling these two apart and I'm on a computer...
>Finally, other than glancing at the PCB, which has an SOP-16 IC with the label scraped off (presumably the microcontroller), I haven't tried analyzing how this device works yet.
Scraped off for obscurity, not export/customs, right?
Not world shattering, but damn annoying (I myself handle a few millions of those in a connected object deployment and at the very least it warrants a revision of the risk analysis, as the attacker level got lowered some scenarios became more likely).
"STM32 Read-Out Protection (RDP) secures flash memory through three levels (0, 1, 2) configured via option bytes. Level 0 allows full access (default). Level 1 restricts debugging and flash access, allowing regression to Level 0 by erasing flash. Level 2 permanently locks the device, disabling debug features, and cannot be reverted."
I actually have a half-defective device with an STM32 MCU that I would like to dump. Its a noise machine with a flash card containing the sounds, but the content is encrypted. I'd like to get at the decryption key to salvage it.
Has Level 2 been cracked?
It's tricky because you have to chain multiple exploits, but yes. You can temporarily downgrade from RDP2 to RDP1 via glitching. At that point, you have to move directly into RDP1 techniques without causing a reset.
The protection levels are set in the RDP register. [listed out of order...] Level 0 = 0xAA, Level 2 = 0xCC, Level 1 = anything else. Flip just a single bit and you get out of RDP2.
Edit:
https://sec-consult.com/blog/detail/secglitcher-part-1-repro...
https://www.usenix.org/system/files/conference/woot17/woot17...
This dongle is very likely to be this original attack https://github.com/JohannesObermaier/f103-analysis/tree/mast... but now packaged. If you want to read more this repo has the best doc: https://github.com/CTXz/stm32f1-picopwner. It's a multi-step attack where a payload is executed from persisted SRAM (RDP1 means you can read/write to it) after a quick reset. The fact that they mention freezing the chip heavily weighs in that direction since it's needed for higher clock chips.
If it's the attack I believe it to be, basically it:
1. Acts as a debugger (core blocks touching flash) and writes a 2-part payload to SRAM.
2. Detaches the debugger, straps the boot pins to boot from SRAM (payload 1)
3. Resets the board via reset pin (keeping SRAM)
4. SRAM payload 1 runs (core blocks touching flash), configuring the FPB to 'overlay' the reset vector on flash with a pointer to payload 2
5. Flicks off the power just long enough for the hardware to reset, but not long enough for the SRAM to clear (this is where I think being cold helps).
6. Device boots 'unlocked' into 'flash', but the FPB hijacked the vector table and so the CPU immediately jumps to payload 2.
7. Payload 2 can now do whatever with flash (e.g. dump it out over UART or SPI)