Risks to non-locked Teensy 4.0

Q

quiver

Active member
Hi folks,

I think something is missing from https://www.pjrc.com/teensy/td_code_security.html which is the why.

I want to know what the risks are with an unlocked (normal) Teensy 4.0. What lengths would someone have to go to, to either read the program off the chip or reverse-engineer a .hex file into something readable?

This would help make the case for lockable Teensy's and could be a helpful addition to the above page.

Cheers!
 
There are at least 2 ways someone could try to capture your raw data (eg, the hex file).

Simplest would be the desolder the flash chip and connect it to the SPI port on another board. Then it's a pretty simple matter to just read the memory.

Not as easy (only because the wires are short and parts so close together) would be severing the JTAG signals between the bootloader chip and main chip, and then connect a J-Link or similar debugger.

Either of these would only give the raw data. Copying would become possible, but quite a lot more work is needed to reverse engineer compiled code back into something readable. I don't have much experience with this, but my limited understanding is two programs are generally used, IDA Pro (expensive) or Ghidra (free).

With Lockable Teensy, after being locked, JTAG debug is disabled and the data stored in the flash chip is encrypted. The startup process also authenticates the encrypted data against a digital signature. The hardware also implements some other security measures which NXP considers proprietary secrets, so I can't discuss that stuff (other than I will say it's not very interesting). The bottom line is you get strong protection against unauthorized access to your code and from your hardware ever running code published by anyone else.

The protection is only for your code. If you use LittleFS to store data in the unused portion of the flash memory, that data is not encrypted. Likewise for writing to a SD card. The Lockable Teensy protection is only for your code. If you also need to protect data your program creates or processes, that part is up to you. But at least having your code well protected gives you a good platform to use.
 
Thanks, that's really helpful! And the raw data they could get off the chip, is that effectively the same as the hex file in terms of vulnerability?
 
You must log in or register to reply here.
Back
Top