Does Teensy lock the flash memory ?

[Elmue]

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 ?

 

[GremlinWrangler]

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-Teensy-as-a-secure-storage-for-private-keys

 

[Epyon]

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?

 

[WMXZ]

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.

 

[Epyon]

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.

 

[Elmue]

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 ?

 

[Frank B]

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.

 

[stevech]

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.

 

[PaulStoffregen]

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.

 

[defragster]

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:

The push button becomes a cub bigger liability!

 

[defragster]

(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?

 

[Jollerprutt]

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!

 

[defragster]

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

 

[Jollerprutt]

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.

 

[bobijo]

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.

Hello, just to be 100% :

Is there a way to just prevent people from reading the flash on Teensy 3.2 thanks to writing some fuse and without having troubles if I inadvertantly press the programming button ? ( Eg : having to just power off and power on to have the whole thing running back ) I don't need to fully lock the chip... (I don't care if someone overwrite the programme in the chip as long as they can't read what previously was... And I don't care if eeprom data can be read... )

If yes what are the fuses I should write to do so?
Am I asking an impossible thing by nature and I can only choose beetween locking the chip and have a problem if the programming button is pressed or having a flash that can be easily read and no problems with the programming button?

I am working on a project for a client that want to secure the code in the board and I want to know if I have to change the board we plan to use ( teensy 3.2) or if I can set up a solution ...

Is the only option is a 'full chip locking' to permanantely " set the teensy to whatever the program does " , removing the programming button problem but preventing from reflashing it forever at the same time ? ( If it is the only option, how should I do that ? Of course in such case I will do that only when the program is fully ready ... )

Thank you in advance for your reply!

Best regards.

 

[defragster]

@bobijo - this thread was hit yesterday - see if it answers your issue:

Teensy-3-6-and-FSEC-security-register

It shows the setting for the fuse setting building with Arduino and TeensyDuino, and it should give the desired results.

 

[bobijo]

First, thank you very much for this very fast reply !
Then I think I asked too much question in only one message ...

So



A) Do you mean that I can prevent people from reading the flash on Teensy 3.2 thanks to writing the fuse without having troubles if I inadvertantly press the programming button by following what is said for the teensy 3.6 in this thread : https://forum.pjrc.com/threads/65070-Teensy-3-6-and-FSEC-security-register ? ( wich is what I would like to do... It would be the best case for me ... )

Or

B) do you only answered to the last question ... Meaning => " No you can't do exactly what you wanted to do, your only remaining option is the full lock, and you can do it as said in the thread related to the teensy 3.6 ... " and by telling that I guess that you mean that the exact same fuse should be set to fully lock the chip for both 3.2 and 3.6 ?

Thank you !

 

[defragster]

Using that change to FSEC as indicated works the same on T_3.2 and 3.5 and 3.6. I may not be clear on the question and what is desired - but what is in the comment and posts describes the response to uploading with that altered value for FSEC.

The code cannot be read
It requires a Button press to reprogram :: THIS WILL FULL ERASE the PROGRAMMED CODE

EDITED FOR DETAILS HERE:

// requests from Arduino. Pressing the program button will cause a full chip
// erase to gain access, because the bootloader chip is locked out. Normally,
// erase occurs when uploading begins, so if you press the Program button
// accidentally, simply power cycling will run your program again. When
// security is locked, any Program button press causes immediate full erase.

Opps - reread the entire two lines after post #19 that follows ....

 

[PaulStoffregen]

Is there a way to just prevent people from reading the flash on Teensy 3.2 thanks to writing some fuse and without having troubles if I inadvertantly press the programming button ?

No. Once you set the security lock, pressing the button to get back into programming mode must fully erase the flash. When the security is locked, there is no other way to return to being able to program new code. Required full chip erase is a fundamental design of the chip by Freescale / NXP. There is no way to get the code security lock without the full erase for reprogramming.

You can't have the safety and convenience of power cycling to recover from an accidental button press when security is locked.

 

[bobijo]

I thank you very much for all your reply this is very helpfull!

I continued my research and I came to the conclusion that now I only have to find a way to write to location 0x40C in flash with my own code on the teensy in order to get the fancy functionnality I am looking for!

=> I plan to send a special command to my teensy to fully lock or fully unlock the teensy ...

0xDE is the default value in the fsec register
0xDC is the value to prevent reading but allow to reprogram and have the button problem ...
0xEC would be the value to " Brick the teensy " ( Security enabled and mass erase disabled )
=> This third config will allow to secure the code and prevent anyone to put a new program and erase the code ( and thus prevent the button problem) right ?

What line should I wrote in my code to write 0XEC on the location 0x40C in the flash to overwrite the Fsec config ?
I fully assume the risk if I brick my teensy...
"With great power comes great responsability ... "

thank you.

 

[PaulStoffregen]

"With great power come great responsability ... "

Search the core library code until you find the comment with those exact words!

You very likely will brick your Teensy. I recommend buying several spares to have on hand...

 

[bobijo]

I put this line because I know this was the comment I am looking for ...
But I just don't understant the 3 parameters of the function...

"static void flash_write(const uint16_t *code, uint32_t addr, uint32_t data) "

I have only a data : 0xEC and an address : 0x40C

the only example were this function is used is for the eeprom_write ...

There is : flash_write(do_flash_cmd, flashaddr, val);

and I found uint16_t do_flash_cmd[] = {
0x2380, 0x7003, 0x7803, 0xb25b, 0x2b00, 0xdafb, 0x4770};



So would the answer I was looking for is simply :
flash_write(do_flash_cmd, 0x40C, 0xEC ); ???

Thank you.

 

[WMXZ]

So would the answer I was looking for is simply :
flash_write(do_flash_cmd, 0x40C, 0xEC ); ???

I'm pretty sure that nobody on this forum is experimenting with intentionally bricking a teensy.
So you will not get an affirmative answer, but we all are waiting that you tell us that this instruction indeed bricks the teensy.

 

[bobijo]

Before trying it I would just wait that I can have the confirmation that the line I wrote is actually doing what I think
=> updating only the register I want to update with the exact value I want ... ( I am not expecting someone confirming that he bricked his teensy with this exact same line )

And of course I hope that by doing the reverse line of code :
=> flash_write(do_flash_cmd, 0x40C, 0xDE );

It will "unbrick" my teensy ! =)

If Paul confirm that in pure theory this should work as intended. ( that the usage of the function is correct) Then I will give it a try


The confirmation I am looking for is more about the fact that I use the correct command ...

 

[PaulStoffregen]

If Paul confirm that in pure theory this should work as intended. ( that the usage of the function is correct)

Only looked briefly, but my impression is it's not correct.

Then I will give it a try

I do not recommend it. You're almost certainly going to end up bricking your Teensy.

Buy spares... lots of them!