Read protection clarification

[ahill]

Posted on April 19, 2010 at 19:58

Read protection clarification

[Tesla DeLorean]

Posted on May 17, 2011 at 13:47

Basically we're hoping that some of our code (bootloader essentially) could read and validate (CRC check) code in other parts of the flash and upgrade said code if necessary.    Nothing too out of the ordinary I don't think.  Could we still do this with Read Protection enabled?

It's really pretty easy to experiment with. A couple of observations a) Code running in Flash can access the entire Flash space for code, literals, data, etc. so you can CRC or checksum the memory space b) Code running in RAM can also access the entire Flash space. This is code copied to RAM, and called from Flash. There appears to be inheritance. c) ROP breaks any command in the standard Boot Loader (USART1) using a DWORD parameter in them. These include Read, Write and Execute. d) ROP breaks JTAG access, at least to debugging flash and system memory. Code can be loaded into RAM, touching Flash or ROM will fault. e) Updating Flash, writing and erasing, is permitted to flash pages not locked. Some of the boot blocks are locked, so replacing your boot loader will be difficult. a & b mean you can dump the flash via your own application code or boot loader. You can download and run code via your own app/boot. -Clive

[ben239955_stm1_stmicro_com]

Posted on May 17, 2011 at 13:47

So if I combine 'd' and 'b', can the read out protection be bypassed?  It would be pretty easy to write & load RAM-based code that read Flash contents (a chunk at a time) into a RAM buffer, to be examined by the debugger.

[Tesla DeLorean]

Posted on May 17, 2011 at 13:47

There appear to be inheritance issues with that, but it is possible to call into ROM, and have it call into RAM. I exhausted my patience with my platform, but potential vectors of attack remained. I can however run code in RAM on a ROP'd device.

Failing that, some fuming nitric acid might work. -Clive

[damh]

Posted on May 17, 2011 at 13:47

b) Code running in RAM can also access the entire Flash space. This is code copied to RAM, and called from Flash. There appears to be inheritance.

If the system is booted from Flash or internal bootloader, that is correct. If you boot from RAM, the flash interface is permanently disabled by ROM-Startupcode (better way) or only not enabled (worse way, but my suggestion, because it is from ST and disabling flash interface by wrong KEY i.e., disables the complete flash interface, but here only the databus to flash is not enabled, codebus works 😉 ) I am nearly sure, that there is ROM code executed before booting. The contents of the registers after booting with or without ROP contain values, that push me into this direction. So, if someone knows the secret how to completely enable flash, the system is broken completely. I suppose, that you can also get direct access to the internal flashs, so you can enable/disable all protection without side effects and also replace the internal bootloader.