In that regard this news is bad since it means a security tool has been broken. But it is good in that the security tool was very often used by evildoers.
Of course both of these examples rely on you trusting the bios & rdp implementation - ideally they would be open source.
Trying to hide your code is a stupid thing to do. Trying to hide cryptographic keys is more useful (though still often only used for DRM applications) but preventing people from dumping your firmware is misguided.
That's not what I hear from reputable reverse engineers, at least for IoT devices.
Even though security by obscurity should be frowned upon, and being understood that hiding code might give a false sense of security, most RE workflows assume availability of firmware, and it is a giant pain to start breaking platforms where the unknown firmware must be manually extracted first, especially the boot loader.
I've said before on this site, obscurity is a totally valid tactic to impose additional costs on attackers. It's best to think of it more as a preemptive strike than a defensive layer. Thinking of it as a defensive layer can lead to complacency, but thinking of it as an opening gambit is totally fine.
One shouldn't be obsequious to heuristics like "never use security through obscurity," one should understand the systems they're building and make considered choices.
Additionally, preventing people from dumping your firmware is usually not about security as much as it is preventing some fly-by-night company from reversing your product & selling it as their own. Why engineer a product when you can steal someone else's IP?
Not a big impediment.
But there's the rub: you'll only impose additional costs to the least sophisticated/determined adversaries. While that works to keep random scriptkiddies/scans out, I'd argue it has little to no effect if you require serious security guarantees.
You could have a completely bug-free, constant-time, constant-power cryptographic library running on one of these microcontrollers, and debug access would allow you to reliably extract encryption keys just by examining the execution path.
The amount of processor and system state that you have access to with a hardware ARM debugger is crazy, but that isn't really the problem -- you can extract a ton of state with a minimal debugger too. Just a log of instruction pointer values would get you 90% of the way there.
I think it's reasonable to assume that microcontrollers with exposed debug interfaces simply cannot be made secure, just as people generally assume that it's game over once someone has physical access to a computer.
Working on these specific processors around 5 years ago, we implemented a serial port based "unlock" that would generate a challenge/response from the device that if correctly acknowledged, would unlock the JTAG whilst the chip has power (it locks again when it looses power). This worked great - we spent a lot of time on the UART driver to make sure it was super simple and robust during the period when it could listen to incoming bytes (no interrupts etc...).
If a debugger can read out registers or memory you can just read out the sensitive material of course.
Instead, you might see instructions like addlt, so you'd also need to inspect the value before and after, which, as you correctly state, the debugger will happily let you do.
PS. I actually have yet another STM32F1 RDP bypass in my archive, waiting to be published. It used a technique where the MCU writes its own debug registers... pretty crazy stuff. If only I had some free time to write a proper publication about it...
You could just drop some hints on a hardware forum and let the community figure out the rest.
As recently as a few years ago, it was unusual to see standalone debugging hardware in the $2-20 range. Sometimes I wonder if ST bristled at the...reuse...of their IP, but it probably did more to promote STM32s as a learning platform than anything that ST did in that time period.
...and thus drive further product sales in the future. If you think about it, sales of development hardware are not going to be frequent nor recurring, while sales of the actual product dominate their profits.
I'm personally glad that companies are starting to see the advantages of freely available documentation and cheap development hardware, and the days of 4/5-figure development boards with secret NDA documentation are slowing passing; ST was (and in some ways still is) one of the notoriously closed ones.
Come to think of it, I think it was actually TI and the MSP430 that started the trend with the $4.30 kits with a socketed msp430 micro and onboard programmer. ST was the first to try it with an ARM as far as I know...
I wonder if it was lifted using a ST-Link debugger…
How? Turns out they physically have more flash memory, but the accessible flash area is limited by programming tools and documentation to 64KiB (most likely price segmentation, but maybe there's a flash page remapping mechanism that would allow to bin devices based on manufacturing yield).
You can even debug on a $2 "blue pill" or wirelessly on a $1 esp8266 board. It has certainly not hindered STM32 popularity.