Upload Hex file from Teensy 3.1

Status
Not open for further replies.
C

cstack89

New member
Is is possible to read a hex file from the Teensy? i.e pull a hex file from one Teensy and then download it onto a new one?

It looks like this is possible on the Arduino using avrdude, but wasn't sure if it was also supported by Teensyduino.

Thanks,

Chris
 
Not easily. The question has come up a few times over the last few years. Haven't heard of anyone succeeding at it.

Generally the folks asking are either interested because they lost 'their' source code or folks who want to prevent someone else...

As far as I know the Freescale Kinetis chip doesn't encrypt its persistent memory. I'd be very surprised if someone with access to all the tools the Freescale engineers use to develop the chip would be unable to extract the Flash contents. This capability would be awfully handy to sort out RMA claims, etc.

There are some 'protection' bits to prevent reading back the firmware. Given that Freescale isn't making strong anti-tamper claims, e.g. recommending these chips as a system trust anchor, etc. it's probably best to think of the protections as a strong deterrent for folks without proprietary/expensive tools or extraordinary skills.
 
My reasoning is more along the lines of the latter. I need to be able to show nobody uploaded new software to the chip, so my plan was to read out a hex file and compare the two hash's.

Since that doesn't appear to be a possibility, is there any way to perform a factory reset? My other option other then proving it hasn't been tampered with is just to completely wipe the flash. Is the entire flash written when a new program is written?
 
If you don't store anything other than your program hex, then when you upload a new program hex, the old one is erased. If you store settings, etc. using the EEProm library, that information you would need to wipe out by other means, such as a function in your program.

What can you tell us about your threat model? How sophisticated or motivated an attacker are you trying to defend against? What sorts of protections might the rest of the system afford you? For example, if you can live without changing the firmware, you could pot the entire Teensy leaving no (easy) access to the USB connector.
 
It is possible to lock the MK20DX256VLH7 on Teensy 3.1 up nicely enough - program button on Teensy 3.1 fails (to modify flash contents) harmlessly as a reset button and, if you utilise an unlocking method in your sketch, it is possible to unlock and reprogram and you can define what the unlocking mechanism is (certain message via Serial or other, certain sequence/combination of buttons etc etc).

I am pretty sure Frank Boesing is going to accept my pull request and methods which lock and unlock Teensy effectively enough will turn up in his repository @ https://github.com/FrankBoesing/Arduino-Teensy3-Flash soon but in the meantime you can check it out in my fork: https://github.com/robsoles/Arduino...examples/LockoutReadBack/lockoutReadBack.ino\

Any good?
 
So the new program hex does completely erase the program memory? Even if the new hex is smaller? I am storing settings using the EEProm library. My plan for that was to do a 2K (that's the full size of the memory right?) SHA1/SHA256 hash using this library https://github.com/Cathedrow/Cryptosuite. Upon installation a hash would be generated and it could be verified when desired.

We don't need to get too sophisticated just trying to meet guidelines. As there is no USB cable attached in the installation, the current thought is possibly just security tape over the port would be good enough as you can see it's been tampered with. I'm hesitant to pot the Teensy as it's a prototype and could need a new hex file.

Thanks for the library robsoles. That definitely could be an option as well, or a combination of tape and flashing the lock bits.
 
The Cryptosuite library looks good. A couple of things jumped out at me after a quick glance. The PROGMEM declarations aren't needed for the Teensy 3.0 and Teensy 3.1. See https://forum.pjrc.com/threads/23526-PROGMEM-use-on-Teensy-3-0 for details. The implementation is probably optimized for an 8-bit architecture, whereas the Teensy 3.1 is a 32-bit machine, if you care about performance.

The persistent memory in the Freescale chip does perform wear leveling, so the meaning of "completely erase" might be a bit tricky. If security tape is good enough, you probably don't need to worry about this level of detail.
 
The whole process only takes a few seconds, and will be rarely executed so I'm not too worried about performance right now.

I thought I had seen mention of the wear leveling, but thanks for pointing that out. As you said I don't think I need to worry too much just wanted to see what my options were.
 
cstack89 said:
...

Thanks for the library robsoles. That definitely could be an option as well, or a combination of tape and flashing the lock bits.
Click to expand...
You are welcome, although Frank Boesing ought be thanked for the library (imho) which seemed the obvious place to put the locking stuff due the dependency on things already defined in that library.
 
cstack89 said:
Is the entire flash written when a new program is written?
Click to expand...

Yes, the entire 256k flash is erased at the beginning of every upload.

Actually, to be more specific, the entire flash is wiped at the beginning of the first upload after rebooting into bootloader mode. If you turn off auto mode in Teensy Loader, you can upload multiple files, as long as you don't reboot between them. Only the first one causes a complete wipe of flash.

Teensy 3.1 has 32k of extra flash for data storage. Normally, it's allocated to Freescale's "FlexNVM" which uses it to emulate 2K of eeprom, by writing to the 32k with wear leveling. That 32k extra flash is not erased by Teensy Loader.
 
I too am looking to use the security features to prevent a read of the flash. I plan to store a 16Byte AES key in flash and use the security features to prevent reading this. By the way, it looks pretty easy to read out the flash if the security features are not used for people who have the right tools - https://community.freescale.com/thread/322577. From my reading this - http://cache.nxp.com/files/microcontrollers/doc/app_note/AN4507.pdf I think that the proper settings would be as follows:

KEYEN = 00 (backdoor key disabled)
MEEN = 00 (So that mass erase is enabled, otherwise the chip would be write once and could not be erased)
FSLACC = 01 (So that not even the factory can unlock)
SEC = 00 (security enabled)

So assuming that I am on the right path here does anyone know how to invoke a mass erase without JTAG or EzPort (This is in the document, not sure what this is)?

Also any other advice would be appreciated I would prefer to get this right the first time and not brick a teensy.
 
Hey so I am pretty sure I had this working on Teensy 3.1 (setting FTFL_FSEC to 0x64 to secure flash) as robsoles recommended, thanks for that!. But trying to set this using Frank's Library with Teensy 3.2 I am running into an issue overwriting the B5-B6 MEEN Mass Erase Enable Bits. I thought I would ask the experts before I spend too much time on this. By default it looks like the Teensy 3.2 is set to 0xDE, when you use flashSecurityLockBits(); and then reboot it sets to 0x44 even though you wrote 0x64. It is like something is preventing the mass erase bits (B5-B6) from being overwritten. Do you guys know of anything obvious that I am missing here. Or maybe there have been changes to teensy loader preventing this? I understand the disclaimer about bricking devices.
 
Hi cr7pt0 - progress on onlykey - excited to get mine . . . no real help from me, just wanted to say hi - except if this is that magic byte, lots on the forum I suppose you've seen - setting it wrong will make a brick - and depending on how the write is done the Teensy programming chip will prevent it from being overwritten to a fatal value in some fashion. If you subvert the check and do it wrong it will be toast. I worked with Frank with his bootloader code and it worked very well - but that was just writing code not doing an erase - and I was just a guinea pig.
 
Yes, progress is going well, thanks for backing the project. Almost ready for an alpha release of the code so far just a couple of issues like this to work out. For this project setting the flash security to the most restrictive settings is essential. I have used Frank's library before and yes it works very well. I am just trying to find out why with Teensy 3.2 and Teensy loader 1.27 when you run flashSecurityLockBits(); everything writes fine but when it boots back up mass erase bits (B5-B6) are still set to enable. I am trying to determine if this is intentional and I should try an earlier version of Teensyduino or if I am missing something.
 
If it helps and you were using the same copy of Frank's bootloader_hex.cpp I have last dated 10/14/15.

From my downloads I find that would be Teenduino v1.25 I have dated 9/30/15. Easy enough to try that version with a parallel install. I see my arduino-1.6.6-windows is dated 11/7/15 - so probably IDE 1.6.5.
 
Thanks defragster for the help. I finally got it working. It was not a change to anything teesnsyduino related or flash protection it was user error on my part. The answer is you have to find a way to erase the flash block first, you can't just overwrite it. Thanks to Paul for enlightening me. Also if anyone else is crazy enough to try this (Disclaimer not recommended) Don't set 0x40C flash memory address to 0xFFFFFF64. I did and it bricked one. I might have to pick up a value pack to get this feature tested :) I had two methods of recovery, one serial and the other if you press the cap touch button but this flash value makes it so it doesn't even boot. I am thinking 0xFFFFF964 is the correct value to set but will have to wait to try this. If anyone has had success with this on Teensy 3.2 and would share the value they used that would be awesome. I know robsoles recommends FTFL_FSEC set to 0x64.
 
Glad you got there - not sure how I helped - except the obvious error in my prior post - that points to your discovery . . . "writing code not doing an erase" - after I wrote that I knew it was wrong . . . but just getting back.
 
Status
Not open for further replies.
Back
Top