Setting flash security byte

[gimpo]

Very interesting. That would be a "game changer" for me and my needs.

 

[gimpo]

No news about resetting the Teensy 3.x via software?

My Teensy 3.2 is equipped with a TFT screen. My idea is to propose to the user a menu option that allows to reprogram the Teensy.
When user confirm its choice then:

1. the flash memory is erased
2. a new sketch can be uploaded

 

[PaulStoffregen]

It appears that reprogram initialisation can be done in software:

_reboot_Teensyduino_();

I am guessing: if the security byte is set and the program button is inaccessible, calling the above command in my sketch should put the teensy into program mode ready for a new sketch upload.

I can confirm this does *NOT* work when FSEC sets the code read security lock.

As explained in the comments where you edit FSEC, when the security lock is set, pressing the button is the only way to initiate bootloader mode, and pressing the button causes a full wipe of the flash memory. That is the consequence of setting the security lock. The bootloader is fully locked out of access to the chip, and access can only be restored by a full wipe of memory. The security lock wouldn't be effective if it allowed some way for an external chip to access memory. This restriction is strictly enforced by the hardware. No amount of software trickery can work around it. The security lock simply always works this way!

I tried to clearly document how it works in the comments where you edit the code to set FSEC. Please, read that carefully and avoid the mental trap of tricking yourself of believing it might be able to work some other way simply because another way would be more convenient for you. This is a hardware enforced security feature. It is designed at the hardware level inside the chip to have no way to cheat. The only way to unlock security is a full erase of all flash.

 

[paf]

In summary, how secure is flash security?

...This is a hardware enforced security feature. It is designed at the hardware level inside the chip to have no way to cheat. The only way to unlock security is a full erase of all flash.

Hi

Do I interpret correctly that with the flash security enabled, it is impossible to read the firmware of a Teensy 3.5 without opening physically the main processor chip, and especially not by linking a diagnostics tool to external pins of the processor?

This question has been discussed before but I'm not able to reach a reliable conclusion based on all the comments

Thanks and regards
Patrick

 

[Frank B]

You simply might want to read the reference manual to reach your reliable conclusion.
Paul answered this above, too.

 

[paf]

You simply might want to read the reference manual to reach your reliable conclusion.
Paul answered this above, too.

I have read it and I think that you need to saw the chip to reach the individual modules to read the flash.

But I'm not completely sure that I have understood everything right so I allowed myself to ask for confirmation, as I haven't much experience on chip security matters and because it is a fundamental parameter in my project.

I still would be very grateful if somebody with more experience and competence than I could confirm my assumption (or not).

 

[Frank B]

https://www.google.com/url?sa=t&sou...FjAAegQIBRAB&usg=AOvVaw0S5SpYsnM4f4REOg9y_uzN

 

[WMXZ]

I still would be very grateful if somebody with more experience and competence than I could confirm my assumption (or not).

If you do not believe Paul's answer, why will you believe other's?
We only can confirm what Paul has stated.

 

[PaulStoffregen]

Here's the FSEC documentation. I've highlighted the words you need.



You might also notice the "NOTE" Freescale put in their documentation. I'm guessing that also receive broadly worded questions very similar to your "Do I interpret correctly that with the flash security enabled, it is impossible to read the firmware" (not clearly asking about specific ways of reading), so they explain that *YOUR* program running on the chip is still able to read all memory. Only the programmer interfaces are disallowed from reading by FSEC.

If your program has a feature to read memory, or a bug or vulnerability which could be exploited, FSEC will not prevent your program from reading the memory and doing anything you can write the code to do (like transmit that info over a serial port, either by design or mistake).

FSEC disables access to the memory on the debug and ezport interfaces. That is all.

Regarding your other question "without opening physically the main processor chip", I do not know what sorts of reverse engineering techniques exist (if any) for these chips. I do not personally know of any exploits or weaknesses. But I can not comment on the design of the chip. Only Freescale (now NXP) could comment on the chip design. But they almost certainly consider that sort of information a trade secret, so I do not believe you will find any definitive answers to that sort of question.

 

[paf]

... Regarding your other question "without opening physically the main processor chip", I do not know what sorts of reverse engineering techniques exist (if any) for these chips. I do not personally know of any exploits or weaknesses. But I can not comment on the design of the chip.

Thank you very much for the answers to my questions. It confirms that those processors offer a good level of protection against reverse engineering, if programmed correctly.

 

[SkinnyRaD]

Is the FSEC functionality available on the Teensy 4.0 platform? If it is, I am having a hard time finding an equivalent file or code piece. Thanks for any help.

 

[Frank B]

No it isn't.