Secure Flash problem

[offin]

Hello,

Following this topic: https://community.nxp.com/t5/MCUXpresso-IDE/How-to-just-upload-a-binary-file/m-p/1305736 , here is now my new problem.

With
- a KL25 based pcb
- the software MCUXpressoIDE with a KL25 project
- a probe "MCU-link"
- a SWD cable from the pcb to the probe (i shortened it to 10 cm ; see attached picture)
I was able to upload BIN files without problem, until i uploaded a BIN file with secure Flash.
Now each time i execute "Target operation > masse erase" with the script "kinetismasserase.spc", after around 20s (with my oscilloscope, it looks like the probe it trying to communicate with the pcb during this period), there is an error message (see attached screenshot). Then the MCU-link probe is not found anymore even after usb unplug/replug. I have to restart the OS to get the probe visible again.

After the KL25 problem, i tried with
- a KL27 based pcb
- the software MCUXpressoIDE with a KL27 project
- the probe "MCU-link"
- a SWD cable (length 8 cm) from the pcb to the probe
I am able to upload BIN files, and even BIN files with secure Flash. After uploading a BIN file with secure Flash, i execute "Target operation > masse erase" with the script "kinetismasserase.spc", and then the KL27 is unsecure again. So everything works well with the KL27 based pcb.

Another important info
The problem with the KL25 pcb happend already one time some weeks ago. I repeated the "masserase" procedure several times, and i was lucky because after around 20 "masserase" actions, it worked and the Flash has been unsecured. On that time the SWD cable was twice longer. After this problem, i decided to upload only BIN files with unsecure Flash, until i make the mistake again yesterday.

This time, no luck. The KL25 pcb stays desperately locked.

All your tips for new tests will be welcome !

 

 

[offin]

 

Hi

[ErichStyger]

looking at your picture with the debug connection, I only see 4 wires but I would expect 5: GND, Vsense, Reset, SWDIO and SWDCLK.

Erich

[ErichStyger]

Of your 'secure' image, what is the security settings? If mass erase is disabled, then you won't be able to regain access to the device (see https://mcuoneclipse.com/2014/06/22/preventing-reverse-engineering-enabling-flash-security/ and https://mcuoneclipse.com/2012/11/04/how-not-to-secure-my-microcontroller/ ).

The other thing you have to consider as possible difference between your two boards is the reset circuit (RESET line) and what you have there (pull-ups, C): The debug probe tries to reset the MCU, and this can fail for several reasons or if you have a pull-up too strong or a C too big this might be difficult. Or if your reset pin has been re-configured or your debug block on the device. What might help you is a faster debug probe (the MCU-Link is good, but not that fast), so you might have better luck with a J-Link or a Multilink. With a Multilink you can try access to the device with power cycling too, see https://mcuoneclipse.com/2021/05/20/recovering-cortex-m-microcontroller-with-a-power-glitch/

I hope this helps,

Erich

[offin]

Hi Erich,

Thank you for your answer.
Here are the uploaded data (see attached screenshot)

After checking.

The interesting byte is EF (0xef = b11101111).
bxxxxxx11 = SECURED
bxxxx1100 = Factory access granted
bxx10xxxx = Mass erase DISABLED
b11xxxxxx = backdoor key access DISABLED

So, yes the mass erase is disabled. Sorry, i did not know it was possible to disable that.
In my opinion, mass erase should be always possible, because it completly erases the Flash so there is no risk of code hack.

[ErichStyger]

In my opinion, mass erase should be always possible, because it completly erases the Flash so there is no risk of code hack.

You are missing about an important attack vector: with mass erase enabled someone could take over your board/design/product and program it with its own firmware. Depending on your product/company, you very likely don't want this to happen.

I hope this helps,

Erich

[offin]

Yes this is true.
I just thought that microcontrollers products were like computers. I mean no way to avoid such attack vector.

I learn everyday

[offin]

After reading the links above, it looks there can be a chance to unlock the KL25 only with a PEMICRO debug probe, and i unfortunatly do not have this probe.
Could you please confirm that, in my situation, without the PEMICRO probe, there is no way to recover the KL25 like it was before ?

[ErichStyger · Accepted solution]

Could you please confirm that, in my situation, without the PEMICRO probe, there is no way to recover the KL25 like it was before

With mass erase disabled, you have locked out yourself from the device. The approach with power cycling using the PEMICRO does not help you in your situation: it helps if the application is doing things out of reset, but not if things are secured by FPROT (this is not 100% true, but would require other expensive equipment as seen on other devices, but I think would go beyond this discussion).

On a side note: if you would have used the SEGGER J-Link, it would have saved you from getting into this situation: the J-Link has two different flash drivers: a 'non-secure' (default) and a 'allow secure' one. with the non-secure it will automatically detect possible dead-end security settings and changes it so you can recover the device (mass-erase enabled).

I hope this helps,

Erich

[offin]

Thank you for this clear answer.

I give up with this board.
I asked for new KL25 based boards and i will wait for them.
This time i asked for 4 pcs ; this will offer the possibility to make 3 more big mistakes.

I am a beginner in this community. I will click "Accept as solution" in your post. I think this is what i have to do when all is clear and i do not have any other posts to do in this topic. If i have something else to do, please let me know.

Thank you again for your prompt support.

[lpcxpresso_supp]

Have you tried the "resurrect" functionality offered by the GUI Flash Tool?

Greetings,
MCUXpresso IDE Support

[offin]

I confirm that the "Resurrect" function does not help. Here is a screenshot of the result.

And after this operation, the software does not find anymore the MCU-Link probe. I have to restart the OS and then it works again.

So i think this pcb is definitely out of order. I am working now with the new fresh arrived ones.

Regarding the "ultimate" secure flash function for future models, i would suggest to setup this in a more complex way. For instance with 16 bits (two bytes of the Flash). Then, unless an unbelievable bad luck, newbies like me could not lock it fortuitously.

 

[offin]

Hello,

I remember i tried one or two times the "resurrect" functionality, without success as well.
But i will try again more times.
I am presently out of my office for a couple of days.
As soon as back in office, i will do that and i will post the result.

PS: some extra fresh KL25 pcb's just arrived in my office. This pcb is apparently out of order, but i am safe to work with the new pcb's.