now i have invested a lot of time into my application, ready to be flashed on the devices and shipped. but wait: i don’t want that someone can read out the code from my device and have it reverse engineered. for this, i can ‘secure’ the device.

flash security settings

there are several ways to prevent unauthorized access with a debugger to the device:

1. disabling the debug interface : this is a rather weak method, as there might be still a small time slot after reset of the device until the device has disabled the debug interface. and if the debugger is fast enough, it might stop the target before it disables the debug interface. but this method in combination with other methods is still very valuable.
2. enabling flash security : this is typically a setting which prevents the debug block on the chip to access the flash memory. you only can regain access to the device if a complete erase of the flash memory is done first. this still protects the code on the target (it gets erased), and allows to regain access to the device during the development process.
3. disabling flash mass erase. only having the flash security set still would allow a person to gain access to the device and program it with a different (malicious) firmware. to prevent this, the mass erase can be disabled. so disabling flash mass erasing in combination with the security setting is a one way thing: once set, there is no way back to regain access to the device, except some backdoor has been implemented.

accidentally setting the wrong bits can be very bad, as outlined in “ how (not) to secure my microcontroller “. every microcontroller has some specific bits and settings which need to be set, and different ways how to implement a back door to regain access. typically it is best if the backdoor is implemented through another hidden channel, e.g. with an encrypted password sent over usb or rs-232.

i show in this example how to enable the security for the freescale kl25z which is an arm cortex-m0+, using processor expert. the setting is in the cpu component. i enable the ‘flash security’ option, and as explained above, i keep ‘mass erase’ enabled:

enabled flash security

after downloading such an application to the microcontroller will prevent that i can debug it: the p&e interface tells me that the device is secure:

device is secure

i only get access to the device again with erasing the device with a new binary, and because mass erase is *not* disabled.

if somehow that does not work, there is an option in the p&e gdb panel which does an ‘early’ mass erase:

always mass erase on connect

:idea: i do not have a board to spare now, so i do not show here an example with the mass erase disabled. ;-)

with segger j-link, i get a warning:

segger security warning

:idea: that dialog might be hidden behind eclipse, so make sure you move that dialog to the foreground.

so the segger j-link will automatically disable the security bit to protect me from doing a mistake. to bypass that safety check, i need to specify the device with “(allow security)”:

segger j-link device name to allow security bit programming

but just to be clear: with this i need to make sure that i do not accidentally brick my board!

summary

enabling the flash security setting will prevent that someone is able to read out the (assembly/binary) code from the device for reverse engineering. segger has a protection built in to prevent me doing a mistake. if mass erase is still enabled, i can erase the memory and get access to my device again. all in all, this is a very handy feature, but like a sharp knife: used with care ;-)

happy securing :-)