Memory Protection Exploit on WCH chips

[EEVblog]

Nasty:

[ataradov]

But that's not really a device issue, it is a bootloader firmware issue. Don't use vendor-supplied code.

[brucehoult]

TLDW: it's not a memory protection thing, it's that flashing new firmware doesn't completely erase any old firmware. Easily fixed with a software update, at some cost in programming time and flash rewrite cycles.

[peter-h]

Watched the video. That is a really stupid weakness, surely?

Do the 32F4 chips have this problem? IIRC, Level 2 protection disables the boot loader (RS232, USB, CAN) because STM refuses to honour warranty on L2 secured chips and they must be doing that for a reason.

it is a bootloader firmware issue. Don't use vendor-supplied code.

which almost nobody will do, because almost nobody expects this.

[magic]

TLDW: it's not a memory protection thing, it's that flashing new firmware doesn't completely erase any old firmware. Easily fixed with a software update, at some cost in programming time and flash rewrite cycles.

Looks like a classic MCU bootloader bug then, because I happen to know at least one other example

which almost nobody will do, because almost nobody expects this.

To the first approximation, you should expect all software to be more trouble than it's worth, unless it really is worth something to you.
A bootloader on a mass produced device, probably not so much.

[peter-h]

AIUI, a boot loader resides in some undocumented area of FLASH, and when the boot pins are suitably set up when /reset is de-asserted, the CPU jumps to that code.

If protection is enabled, fairly obviously the boot load stuff should be disabled otherwise anybody can boot load some short program which reads the main FLASH and sends the bytes out of a UART.

[amyk]

Now you can do it yourself instead of paying few k$ to the existing Chinese companies who will be able to bypass the read protection for you anyway.

Their insecurity, our freedom

[Sacodepatatas]

TLDW: it's not a memory protection thing, it's that flashing new firmware doesn't completely erase any old firmware. Easily fixed with a software update, at some cost in programming time and flash rewrite cycles.

That happens to me aswell with the STM32G030F6P6. My code uses the last 2kB flash page (page 31 of the hidden flash) for emulating an EEPROM. Nothing critical, it's just an optional feature for my device. Whether i use the cubeIDE or the ST-FLASH utility (if the code is bigger than 32kB), the content of the last page is unchanged because the flash image is always smaller than 62kB. In fact, if i read the full content of the flash and then write it back, my code doesn't work as intended, because a written page entirely with 0xFF values is quite different than erasing a page and then having all cells with 0xFF (I had a nightmare with that while debugging  😒)

[boB]

Was that guy in the video using all  un-insulated wire ?

I would be real careful.

[ataradov]

Looks like enameled wire. Pretty typical for this kind of quick hacks. Easy to solder, reasonably robust.

[boB]

It didn't look like typical enameled wire to me but maybe he has another option that looks more shiny than enameled ?

I would not want to have to strip enameled wire for prototyping this kind of stuff. 

Kynar maybe.

[ataradov]

Looks like a typical enamel wire. Something like this https://www.amazon.com/BNTECHGO-AWG-Magnet-Wire-Transformers/dp/B07H7GS7F3/ I don't see any difference in now shiny it is.

You don't need to strip it, just heat and the enamel falls off. That's the whole advantage for quick prototyping like that. Plus very thin insulation lets you get much denser soldering, if target board is small.

[boB]

OK.  Low temperature (155C) Polyurethane wire.
 
I hadn't seen that before but makes sense if it is low temp enamel.

We use those roto-blade magnet wire strippers for larger wire.

boB

[Dave]

AIUI, a boot loader resides in some undocumented area of FLASH, and when the boot pins are suitably set up when /reset is de-asserted, the CPU jumps to that code.

If protection is enabled, fairly obviously the boot load stuff should be disabled otherwise anybody can boot load some short program which reads the main FLASH and sends the bytes out of a UART.

Nothing wrong with keeping the ROM bootloader enabled, as long as full flash memory erasal AND RAM clearing is enforced before you're allowed to flash new firmware onto a chip with protection enabled.

[magic]

And that's the problem. You think the bootloader enforces it, the bootloader supplier also thinks it does, but somebody finds that sometimes it actually does not.