Read Protection For Stm32

[DCtech]

I am using a stm32f4 processor, using the dual bank feature, I have a code that has the code update . In Code update mode, I can perform code update by performing Bank1 and Bank2 management over Ethernet, and when I restart the device, the system starts over the current code. There is no problem in these parts. What I want to do is bring the level-1 read out protection to the device.

According to the information I got from the reference manual, when we booting from Flash memory, we can access and manage the flash memory area from the code by the user code.

1) So can I provide Option Byte management in the Flash Memory area in code? (With read out protection available) This is important because dual bank management is done with the BFB2 bit from the option bytes. Can I provide dual bank management properly? Can I read FB_MODE in SYSCFG_MEMRMP register in application code not from out of code (for level 1)

2) Are there any obstacles to update the code over Ethernet?

3) Is it enough to set the read out protection bit 1 time? (Every time I throw the code - should it change again when updating)

4) Do I have access difficulties in the data I read from eeprom (in-code) or the data I export via communication methods?

[Tesla DeLorean]

You should also be able to control banking in your own loader. For example an identical loader in the first sector of each bank could configure the FLASH controller bank settings and effectively fork() to one bank or the other, ie based on build date and integrity check.​

​

T​he device code should be able to access data in other devices, and also exfiltrate whatever internal data it wants. The method protects from external inbound access, not with what you expose yourself.

[DCtech]

Thank you for your answer,

Is it enough to change the RDP byte only once to protect my code from external access,or Should I set every time when I update or write code?

[Piranha]

Technically it is enough, but it is not enough for a robust security. You can read about this in section 3.2.4 here:

https://www.aisec.fraunhofer.de/content/dam/aisec/ResearchExcellence/woot17-paper-obermaier.pdf

Also interesting:

https://blog.zapb.de/stm32f1-exceptional-failure/

https://prog.world/read-secure-firmware-from-stm32f1xx-flash-using-chipwhisperer/