STM32F4xx firmware protection

[PZhan.11]

I am developing some products based on STM32F407/STM32F429. What I am trying to do is to protect my firmware that:

1. simply dump the code from one chip's flash (to hex file) will not work in another chip
2. moderate reverse engineering should not be that easy to hack the code

And what I am trying to do is use mbedtls as a crypto library and encrypt part of my code then store it in some flash sector. Then each time when I boot, decrypt the code into SRAM2 and point the function to that region.

It is a good idea to do that? and I have tried to copy the function from flash 0x0800xxxx to SRAM2 (0x2001C000) and made a function pointer to that region. but call the function caused HardFault exception.

[TDK]

Why not just use RDP level 1 to prevent readout? Seems a lot easier with about the same level of protection, maybe even more.

[PZhan.11]

Since I found [this](https://www.usenix.org/system/files/conference/woot17/woot17-paper-obermaier.pdf). I don't carefully read it. but some blog referenced this paper that said one can bypass the protection of read-out.

[Tesla DeLorean]

Well there are people with better reverse engineering skills than your forward engineering ones, so there's that hurdle..

You could do some elliptical curve signing using a private key and the unique id of a specific chip, and the firmware could have the public key to check/validate it.

The RDP methods protect FLASH, but code in RAM could be pulled unless you lock out JTAG/SWD.

Function pointers need odd addresses, it is certainly possible to unpack code to RAM and run it. Compression and Encryption are viable methods, I've worked on firmwares using a variety of methods.

[PZhan.11]

Actually, in a previous version, I use some kind of fingerprint (not EC-like) to verify the firmware. But I think the single point which mark it valid or not would be easy to bypass. So I thought to encrypt some part of my code by the UID to prevent the simple clone and junior skill reverse engineer.

For the senior engineer, I don't think I have enough knowledge to prevent them.

[Tesla DeLorean]

Well it's not always a matter of comparative skillz, someone wanting you break your code has mechanical advantage. ie low skillz but persistent, having the advantage of time and collaboration, and the ability to leverage techniques or holes others have found.​

T​he earlier STM32 have their own vunerabilities.

S​T once claimed it would take $M in equipment, but this misunderstand the threat, you simply need access to the equipment.

[PZhan.11]

Yes, that kind of crack is ignored. We will try another method like minimizing the cost.