Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 14 of 14

Thread: Does Teensy lock the flash memory ?

  1. #1
    Senior Member
    Join Date
    May 2015
    Posts
    116

    Does Teensy lock the flash memory ?

    Hello Paul

    1.)
    I could not find information if the Teensy 3.2 protects the flash memory from reading.

    I know that there are other micro controllers that allow to read the flash memory with the stored program code out.
    How does Teensy 3.2 manage this ?
    Can anybody read my compiled sketch out of a Teensy 3.2 ?

    2.)
    And what about RAM content.
    Supposed I have a sketch code that works with cryptographic keys.
    Supposed that an attacker wants to make a memory dump of the Teensy RAM memory to serach for any interesting information, would it be possible that he uploads another sketch to the Teensy that dumps all the RAM ?
    Or is the entire RAM erased, when a new sketch is uploaded ?

  2. #2
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,927
    There is a lock bit that locks read and write, but it's not set by default since it causes other issues in the hobby enviroment but it's easy enough to set it once you are really really certain you want to brick the Teensy and have nobody including yourself make changes.

    In terms of reading flash any normal programing of the Teensy in situ will wipe program memory but I believe it currently does not touch EEPROM space to make it easier to keep settings there and NOT lose them by accident. So a default Teensy that keeps the key in EEPROM space could have that key read very easily by just loading up code that pulled the EEPROM contents. Simple block to that is to salt your user key with a key in flash. As long as that key isn't leaked or extracted (see below) the EEPROM key is safe.

    RAM should be reset as part of the reprogramming cycle so should be fine unless somebody work out a way to detect the analog state of a memory location with a digital read. Not going to say impossible but seriously tricky. So you can lock down a default Teensy reasonably well against normal attack.

    If you are prepared to pull the chip off the board you can access the programing port and this may allow pulling of data and memory at will, unsure if this blocked in the default loadout but can be blocked by setting the right bits yourself if not.

    Final state is mechanical assault of the IC, which is not impossible if enough money is involved and the IC doesn't have any special features to prevent flash memory being read with a scanning electron microscope etc. So you can protect your Teensy up to those people who use fuming nitric acid and scanning electron microscopes to read memory.

    Edit: see https://forum.pjrc.com/threads/28215...r-private-keys
    Last edited by GremlinWrangler; 05-10-2016 at 09:01 AM. Reason: Added link

  3. #3
    Senior Member Epyon's Avatar
    Join Date
    Apr 2013
    Location
    Belgium
    Posts
    443
    Quote Originally Posted by GremlinWrangler View Post
    If you are prepared to pull the chip off the board you can access the programing port and this may allow pulling of data and memory at will, unsure if this blocked in the default loadout but can be blocked by setting the right bits yourself if not.
    Can't this also be done by using SWD, which only requires soldering two additional wires to the Teensy?

  4. #4
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,642
    Quote Originally Posted by Epyon View Post
    Can't this also be done by using SWD, which only requires soldering two additional wires to the Teensy?
    Not sure with Bootloader chip still attached, but certainly with lines cut.

  5. #5
    Senior Member Epyon's Avatar
    Join Date
    Apr 2013
    Location
    Belgium
    Posts
    443
    Quote Originally Posted by WMXZ View Post
    Not sure with Bootloader chip still attached, but certainly with lines cut.
    With the Tan54 you can pull down the reset line (test point on the back) to avoid cutting lines. Maybe with the MKL02 this could work too.

  6. #6
    Senior Member
    Join Date
    May 2015
    Posts
    116
    Hello

    > There is a lock bit that locks read and write

    I'm not interested in blocking the code forever.
    I just want to know if code programmed in the flash memory can be read out or if it can be protected against reading out.

    > it currently does not touch EEPROM space

    I know that after uploading a new sketch the EEPROM content is not changed.
    I'm not planning to store cryprographic keys in the EEPROM.
    This would not be clever.

    > RAM should be reset as part of the reprogramming cycle..

    This souds like an assumption.
    I would like to know this for sure.

    Paul, do you know that ?


    > programing port and this may allow pulling of data and memory at will....
    > unsure if this blocked ....

    This is what I want to know.
    Is this possible ?

  7. #7
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,882
    Yes, with debugging, it can be read out. Both, flash and ram.
    But i think there are some security-bits that can prevent this. Teensyduino does not set them.

  8. #8
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    there's an option to erase all of flash (chip erase) and clear the flash read/write protect bits.
    You'll need a JTAG or SWD device to do this, and a professional setting and tools.

    Beware, Teensy has some flash or OTP locations it relies on.

  9. #9
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,827
    This is a small detail I've failed to document.... So here goes... (maybe someone will save this for the upcoming wiki)

    On Teensy 3.0 & 3.1, the bootloader wouldn't let you turn on the lock bits. Not matter what you tried to load at location 0x40C, it would discard your data and write a fixed (unlocked) value. It also wasn't very good at recovery if you did write your own code to lock the chip. Locking the security wasn't really supported at all on 3.0 or 3.1.

    Teensy 3.2 & LC do allow you to write to the lock bits. The default value inside the core lib is 0xFE, so by default the chip isn't locked. However, you can't just choose any value. 3.2 & LC pre-program some of the bits. Programming can only change 1s to 0s, so the pre programming of certain bits places some small restrictions on what values you can load. If you put a 1 into any of the bits which are preprogrammed to 0, they remain 0. This is meant to be a safety feature to prevent bricking your Teensy. You can't set to bit pattern the disables erasing the chip. The NMI pin is also disabled, which solves the pin 33 bugs of Teensy 3.0 & 3.1.

    Locking the chip meant the bootloader must perform a full chip erase to gain access. Obvious as the sounds, you should carefully consider the not-so-great usability consequences. When you press the button on Teensy, the board enters bootloader mode. Normally the chip is erased when Teensy Loader begins sending data. If you accidentally touch the button, Teensy stops, but just power cycling gets it running again. But if your program locked the chip,then the bootloader must do a full chip erase to gain access. If you power cycle without completing a code upload, your Teensy no longer has its program. The push button becomes a cub bigger liability!

    Full chip erase also wipes anything you wrote to the EEPROM. That's probably also obvious... but I mention this because the very early Teensy 3.0 boards did the erase this way (but when code started arriving). The loss of EEPROM data during normal upload was the most common compliant for 3.0. Well, also the Mini54 not using low power modes was a big issue too. Both of those were fixed in early 2013. But when you lock the security, the EEPROM must be wiped.

    I should also mention you can defeat all of the safety measures if you use both erase and program commands directly to the flash controller. The safety features in 3.2 & LC only protect against programming wrong values. Once you do your own erase, you can cm\ompletely control all the bit (except the 8 bytes where the serial number & MAC address are written). If you lock the security and disable mass erase, the bootloader chip will be permanently locked out. If your code doesn't implement a recovery mechanism to unlock or erase (restore the ability to do mass erase), then your Teensy can become permanently bricked. Or at least permanently set to whatever your program does.

  10. #10
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,522
    Quote Originally Posted by PaulStoffregen View Post
    This is a small detail I've failed to document.... So here goes... (maybe someone will save this for the upcoming wiki)
    SAVED in Wiki Thread

    English Please:
    Quote Originally Posted by PaulStoffregen View Post
    The push button becomes a cub bigger liability!
    Last edited by defragster; 05-11-2016 at 06:37 AM.

  11. #11
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,522
    Quote Originally Posted by PaulStoffregen View Post
    (except the 8 bytes where the serial number & MAC address are written)
    So write ONCE really MEANS write ONCE! Safe from full chip erase.

    Paul: Can you share code that would allow after market Teensy (those with PJRC program chips) place a 'maker' signature/serial # in those 8 bytes when they are left at the factory processor 1's state?

  12. #12
    Junior Member
    Join Date
    Jun 2019
    Posts
    3
    Quote Originally Posted by defragster View Post
    So write ONCE really MEANS write ONCE! Safe from full chip erase.

    Paul: Can you share code that would allow after market Teensy (those with PJRC program chips) place a 'maker' signature/serial # in those 8 bytes when they are left at the factory processor 1's state?
    I'm also interested in this
    I would like to have something to identify the hardware version of my different custom T32s.
    I have a tendency to change the sensors attached between different versions and would like a way for the code to realize what version it's running on.
    Right now I'm planning to add an external i2c EEPROM that I can lock, but if I can do it directly on the Teensy that would be fantastic!

  13. #13
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,522
    Quote Originally Posted by Jollerprutt View Post
    I'm also interested in this
    I would like to have something to identify the hardware version of my different custom T32s.
    I have a tendency to change the sensors attached between different versions and would like a way for the code to realize what version it's running on.
    Right now I'm planning to add an external i2c EEPROM that I can lock, but if I can do it directly on the Teensy that would be fantastic!
    The T_3.2 has 2 KBytes of inbuilt EEPROM storage area that could hold such information without adding anything. It survives across uploading new code.

    See : pjrc.com/teensy/td_libs_EEPROM.html

  14. #14
    Junior Member
    Join Date
    Jun 2019
    Posts
    3
    Quote Originally Posted by defragster View Post
    The T_3.2 has 2 KBytes of inbuilt EEPROM storage area that could hold such information without adding anything. It survives across uploading new code.

    See : pjrc.com/teensy/td_libs_EEPROM.html
    Yes that one is very useful, I'm using it to store various parameters and also a compile version so I know at boot if it's a new code, or a simple restart.
    But what I'm after is a something to reflect the hardware, and that's preferably write protected.
    I guess I could use a dedicated section and never write to that, but I'm not the only one writing code for these Teensys so I would prefer if it's not changeable at runtime.

Posting Permissions

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