Post navigation

Preventing Reverse Engineering: Enabling Flash Security

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:

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.

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.

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

💡 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

💡 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 😉

About Erich Styger

I got the same error message when trying to secure Kinetis K10 with J-Link. It seems to me that you are using Kinetis Design Studio in yout solution. I’m using CodeWarrior and I can’t find a device with “allow security”.
Can you help me to enable security flashing with CodeWarrior and J-Link?
Many thanks.

I created a connection configuration and connected to the secured MCU. The JTAG adapter was not able to get the disassembly from the MCU That’s OK, I think.
But I can’t look into the flash security bits. Also the MCU doesn’t run its application. Furthermore, after disconnection and resetting the device it doesn’t run the application until I flash the application again.
Any idea what is going wrong?

Hi Peter,
Can you connect/attach to a non-secured device to verify that the setup is working?
If it is secured, then it makes sense that you cannot read the memory/disassemble it.
Does the program run without security enabled? At least that would be a starting point.
Erich

if I connect to an unsecured device with the connection configuration everything looks fine. I see the disassembly and the registers. The MCU is running and I can pause and start it. After disconnecting the MCU is still runing.

Hi Peter,
ok, then this will be a difficult one to debug. What you could do is to spread some LED blink debug code into your application. First start with the startup code to see if the processor cames through reset, and then see how far it goes. If you put in some blink codes, you could hook up a scope and find out until where it goes.
Good luck!
Erich

Don’t suppose you know how to secure device using KSDK 1.2 or 1.3 within Eclipse Mars or Neon? I’m using segger j-link. I thought I could perhaps do this by modifying the values in the startup_{board}.s just after .”section .FlashConfig, “a”. When I run the debugger I can see memory at 0x40C is updated with the values I set but when I restart board the device ends up hard faulting and values in FSEC register tell the board is still unsecure.

Yes, you would have to set the flash protection values in the flash configuration section of the startup code/file. But make sure you use the ‘allow security’ device name for Segger so that these bits are actually written to the target.

Thanks Erich. Sorry I should have mentioned that I had already done that. If I choose device with ‘allow security’ then memory at 0x40C gets changed to the value I want (0xFFFFFFFD) but even after restart the FSEC register still reports unsecure. If I do not use ‘allow security’ then memory at 0x40C seems to always be set to a value of 0xFFFFFFFE. I think the j-link might still be forcing FSEC to be FFFFFFFE even though memory at 0x40C is set to FFFFFFFD. I’m using a FRDM K64F board and I thought maybe its the built in Open SDA debugger doing something, so I tried it with my external J-Link probe but same result. Wondering now if this isn’t a bug with the J-Link software 😦

I am trying to used flash security with a KL25Z128 processor and the Multilink Universial (using the pegdbserver and gdb. I have a program that works fine when programming with Flash Security disabled, but fails to start when it is enabled. Any idea what I could be doing wrong? Can I even use Security with the Multilink?

Hi Ralph,
I know that the P&E debug protocol tries to prevent you to permanently lock the device. Other than that, everything should be possible. Which microcontroller are you using? In any case, I would go ahead and contact P&E?
Erich

Hi Erich,
after a long time I got the answer from PEMicro:
“the problem is, when you set flash security during programming we then reset
the part to debug it.

If the part is secure on reset, we unsecure the part which erases the flash,
rendering the code blank and hence the debug session fails..”
And sure enough, the server console (see below) seems to support this.
Do you have any idea how to prevent the final reset/erase – I had no luck getting a response from PEMicro on that, other than that they want to sell me an expensive programming solution?
It seems you tested with at least Segger J-Link, which I don’t have and FRDM-KL25Z, which I do. For the FRDM-KL25Z, do you still know which bootloader you flashed onto the board and what the Startup and Debug settings in KDS need to be?
Thanks,
Ralph
—————–
Server Console:
PS C:\Users\aze\Desktop\prog> ./pegdbserver_console -startserver -device=Freescale_KL2x_KL25Z128M4 -attachonly

thanks a lot. It works perfectly with those settings.
The problem I had really only occurs for the Multilink Universal using the gdb tools, where enabling security always causes the extraneous unpreventable mass erase after program.

I’ve defined “BUILD_CONFIG_DEBUG” in the project Properties>C/C++ Build>Settings>Cross ARM C Compiler>Preprocessor>Defined Symbols.
I’m using that define in several places in my code to enable/disable things which are appropriate for debug vs. production.

Is it possible to enable/disable flash security based on which build configuration is selected at compile time?

Hi Paul,
There is no easy way to do this I think. If you don’t need to regenerate code, then you could disable code generation (see https://mcuoneclipse.com/2012/03/23/disable-my-code-generation/) for the CPU component, and do your changes in Cpu.c.
What I do most of the time is to use Processor Expert configurations (see https://mcuoneclipse.com/2012/03/07/configurations-with-processor-expert/). The configuration creates a #define I can use in my application.
The thing to keep in mind that this is not linked in anyway with the Eclipse CDT ‘build configuration’ (like debug or release). So you would have to select/switch the Processor Expert configuration and generate code for it.