Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 37 of 37

Thread: Setting flash security byte

  1. #26
    Member gimpo's Avatar
    Join Date
    Mar 2018
    Location
    Munich
    Posts
    51
    Very interesting. That would be a "game changer" for me and my needs.

  2. #27
    Member gimpo's Avatar
    Join Date
    Mar 2018
    Location
    Munich
    Posts
    51
    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

  3. #28
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,473
    Quote Originally Posted by Darcy View Post
    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.

  4. #29
    Junior Member
    Join Date
    Mar 2020
    Posts
    5

    Question In summary, how secure is flash security?

    Quote Originally Posted by PaulStoffregen View Post
    ...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

  5. #30
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,543
    You simply might want to read the reference manual to reach your reliable conclusion.
    Paul answered this above, too.

  6. #31
    Junior Member
    Join Date
    Mar 2020
    Posts
    5
    Quote Originally Posted by Frank B View Post
    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).

  7. #32

  8. #33
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,566
    Quote Originally Posted by paf View Post
    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.

  9. #34
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,473
    Here's the FSEC documentation. I've highlighted the words you need.

    Click image for larger version. 

Name:	sc.png 
Views:	10 
Size:	93.4 KB 
ID:	19251

    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.

  10. #35
    Junior Member
    Join Date
    Mar 2020
    Posts
    5

    Quote Originally Posted by PaulStoffregen View Post
    ... 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.

  11. #36
    Junior Member
    Join Date
    Mar 2020
    Posts
    1
    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.

  12. #37
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,543
    No it isn't.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •