> One quirk: the software would always overshoot when reading. A STM32F205RB has 128KB of flash, but the tool would happily read past that boundary, padding everything beyond it with 0xFF. The actual flash contents within the valid 128KB region were correct though, so it's easy enough to just trim the output to the right size.
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.
What specifically might happen in the real world because of this? Which industries have to worry?
>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?
As I understand it this bypasses a "please do not read" level of protection on cheap microcontrollers, not an actual secure element, so only those secrets are impacted that were not properly protected to begin with.
Scraping is almost always for obscurity to try and impede cloning. I don't really know why folks bother; it's not effective. Especially with LLMs, it's never been easier to vaguely describe a chip's connections and get plausible part numbers back. Add in traditional decapping / xray / other microscopy and it's really just not that hard to know what you're holding.
Huh, very interesting. As mentioned, I assume it's probably making use of the existing exploits against STM32 RDP1 but I'd really like to see some analysis of the device to see for sure.
"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.
> One quirk: the software would always overshoot when reading. A STM32F205RB has 128KB of flash, but the tool would happily read past that boundary, padding everything beyond it with 0xFF. The actual flash contents within the valid 128KB region were correct though, so it's easy enough to just trim the output to the right size.
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.
I'd guess they also bin the 128KB flash so that when a defect occurs, they just use the other half so they can improve yields.
> the STM32F103C8
> the STM32F103CB
Damn I have a hard time visually telling these two apart and I'm on a computer...
What specifically might happen in the real world because of this? Which industries have to worry?
>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?
As I understand it this bypasses a "please do not read" level of protection on cheap microcontrollers, not an actual secure element, so only those secrets are impacted that were not properly protected to begin with.
Scraping is almost always for obscurity to try and impede cloning. I don't really know why folks bother; it's not effective. Especially with LLMs, it's never been easier to vaguely describe a chip's connections and get plausible part numbers back. Add in traditional decapping / xray / other microscopy and it's really just not that hard to know what you're holding.
Huh, very interesting. As mentioned, I assume it's probably making use of the existing exploits against STM32 RDP1 but I'd really like to see some analysis of the device to see for sure.
Some context:
"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?