Flash Keys - How to change?

[damh]

Posted on March 11, 2010 at 14:16

Flash Keys - How to change?

[htp]

Posted on May 17, 2011 at 13:42

Same me I looking for same answers.

Internal bootloader is too much open and reversable as some LPC story before with bootloader exploits this can give a problem and totally unsecure device.

Flash Keys this will be good to have possibility to change default keys, as I understand readout protection is readout protection and have nothing with write protection, so theoretically foolished user which think his system is secured aftere setting readout protection can have very big problem because attacker can make a blind patching of code - pick up a lot of MCU's and start block by block write own code which allow dump whole user memory. This is the most big danger in self updateable systems. Of course this can be solved on custom bootloader like a DFU where must be added first check a checksum of user code to which make jump.

And many many other questions and possible or even tested security bugs.... ST of course ignore all of it and not give answer or new MCU revisions with small ''modifications''.

About some other security hole I mailed with ST few months and they only treated me like a intruder and seems even today same bug exist in the whole STM32 family. So I will don't expect any answer about bootloader and flash keys or further improvements.

WBR

[damh]

Posted on May 17, 2011 at 13:42

I have read most of the internal bootloader code. This bootloader alone cannot read out readout protected code. The code checks the readout flag and NACKs the operation if set.

The bigger problem is, that you can reset the complete flash to delivery/default state and then you can flash and run everything. If you connect the SWD, you can do the same without bootloader. If you activate the User Options (Hardware Watchdog), it isn't possible by hand, but you can write a programm, which is executed in debugger, that executes the trigger. And then you can run, what you want in RAM => Access to complete Hardware even without destroying the flash! ...

[Tomas DRESLER]

Posted on May 17, 2011 at 13:42

Code in RAM has no access to FLASH if ROP is activated, and update of FLASH from code running in RAM shall be safe, too. Dtto for DMA accessing FLASH if ROP is active.

[Tesla DeLorean]

Posted on May 17, 2011 at 13:42

>>Code in RAM has no access to FLASH if ROP is activated, ...

Other commentators on the forum, and my own experience with this on an STM32F103RET suggests/demonstrates this is simply NOT true. Code can be copied from FLASH into RAM, this code when executed in RAM can access FLASH while Read Out Protection is enabled (1FFFF800 : 00 FF) -Clive

[damh]

Posted on May 17, 2011 at 13:42

I guess, ...

there is a unlock sequence to unlock the readout protection of the flash. This is done ''automatically'', if booted without debug from internal bootloader or flash. If they boot from RAM or with debug, this unlock sequence is not executed. If you copy with flash code code from flash to RAM, this unlock sequence is executed before! So it is normal, that you can read it completely. The problem is, can I execute this (unknown) unlock sequence with RAM code or debug access? Is there ROM code, that is executed before Reset_Handler()? Is there an other unlock sequence to unlock the flash of the internal bootloader and option bytes without the parsing effect of flash interface? I think, all 3 questions have the answer YES.

[Tesla DeLorean]

Posted on May 17, 2011 at 13:42

There is no unlock sequence required, and the STM32 runs code from the flash memory directly, it does not start something in ROM and jump into FLASH. The Cortex-M3 permits the hardware to provide an initial vector address, in the case of the STM32 this is controlled by the BOOT pins.

The ROP check is supposedly done in hardware with the value in the option byte being checked along with the value in the program counter (PC/R15) to permit access. I am sure there are multiple ways to exploit this method, if it worked, as code within the flash can always be called and executed directly, and there are PC relative load instructions loading literals. Even without PC relative, text strings embedded in flash can be pulled with regular register references and C pointers. Even if any of that provided a level of protection, someone with $10K of surplus equipment could probably get to the flash content in an afternoon, let alone an army of smart and well equipped Chinese nationals, or other naferious individuals looking to steal your code. I'm pretty sure I could demonstrate code being injected and executed via Motorola S-Records (or Intel Hex). And also executed in RAM by setting the BOOT pins and resetting into it. This however strikes me as a pointless exercise at this point having already demonstrated code in RAM can access the FLASH/ROM while ROP is enabled. The ROP setting does break the JTAG's ability to rewrite flash memory, it appears to erase, but you need to run the J-Link tool JLinkSTM32 to unprotect it. Pretty much complete broke Keil U-Link access until I located the aforementioned tool. The ''ROM'' based boot loader also does not function normally. -Clive

[damh]

Posted on May 17, 2011 at 13:42

@clive1:

(with debug on, ROP on) A call to flash calls directly the hardfault handler. No code is executed. How did you test it? Without debug? I know, that there is nothing mentioned about my guess in the datasheets.

[damh]

Posted on May 17, 2011 at 13:42

Ok, calling is not the reason for the hardfault. But if I call into the internal bootloader, I get a hardfault, when the code tries to read from the same addresses like the executed code.

The first bootloader command 1FFFF020: ldr         r0,[pc,#0000] leads into a bus error at 1FFFF024 (the read address). If I call functions without such accesses, the stm runs fine.

[Tesla DeLorean]

Posted on May 17, 2011 at 13:42

>> (with debug on, ROP on) A call to flash calls directly the hardfault handler. No code is executed. How did you test it? Without debug?

No JTAG, serial console to a simple monitor application. The monitor can dump memory regions, and checksum (CRC) tracts of memory. Code performing some of the checksumming is downloaded into RAM, and reads data from FLASH. The code running in RAM is faster, being single cycle. I can also check and enable the ROP state from the monitor. As I think you've noted already, the ROP is enforced in the boot loader via a software check. -Clive