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

Thread: Teensy 3.2 Lock Bits and firmware updates

  1. #1
    Senior Member
    Join Date
    Jun 2013
    Posts
    296

    Teensy 3.2 Lock Bits and firmware updates

    Is it really not possible to have a secure device while also allowing its firmware to be updated without pressing the program button? If we enable the lock bits, then _reboot_Teensyduino_() doesn't seem to work. Does anyone have a workaround for this?

    Code:
    // Flash Security Setting. On Teensy 3.2, you can lock the MK20 chip to prevent
    // anyone from reading your code.  You CAN still reprogram your Teensy while
    // security is set, but the bootloader will be unable to respond to auto-reboot
    // requests from Arduino.

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,171
    Would dedicated hardware, like 555 timers chips to "press" the button, be considered an acceptable workaround?

    When security is locked, the bootloader chip has no access. To unlock security, you need to perform the special flash mass erase, and then reboot. I've never tried doing mass erase while the chip is running (eg, running code from RAM), so not sure if it's even possible without the processor halted. Let's assume that can work, and you get the chip to mass erase. Or you can erase the 2nd sector (and presumably other parts of flash you want to keep confidential) and reprogram the config bytes to an unlocked setting. You need to reboot for the new security setting to take effect. But if you reboot with the flash blank, you'll go into an infinite watchdog rebooting loop. Before initiating a reboot (with the ARM SCB AIRCR register), you'd also need to program the first flash block with a minimal program, with at least has the first 2 entries of the vector table (initial stack address and reset vector), and at least one ARM breakpoint instruction. It might need more, but that's the stuff I can imagine right now.

    Doing all that would be tough. If you mess with changing the security bytes, be warned you can permanently brick your hardware if you disable mass erase and turn on security. The Teensy bootloader tries to protect you as much as possible from this scenario. If you do only the mass erase command, you're pretty safe. But if you both sector erasing and writing to the config bytes after an erase, you can permanently brick your hardware.

  3. #3
    Senior Member
    Join Date
    Jun 2013
    Posts
    296
    Thanks, Paul. Thanks for taking the time to answer this question so thoroughly. The sector writing seems to be exactly what I would need, but I'm worried that it's a bit above my skill level. I'll think about it for a bit; It's probably worth sacrificing a few chips to figure out if it's even possible. Failing that, it's good to know there's a hardware solution to my problem.

  4. #4
    Junior Member
    Join Date
    Aug 2015
    Posts
    4
    Is it documented somewhere how to secure a Teensy 3.2 from an inadvertent update? I've been searching for a while and not find any clear answers. I'm not trying to prevent hackers, I just have this fear sending my download to the wrong Teensy. It sounds like there is someway to program one so that the Teensyloader can't update it until the onboard button is pressed?

    Tim

  5. #5
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,825
    This may be ...
    ...\hardware\teensy\avr\cores\teensy3\mk20dx128.c
    // Flash Security Setting. On Teensy 3.2, you can lock the MK20 chip to prevent
    // anyone from reading your code. You CAN still reprogram your Teensy while
    // security is set, but the bootloader will be unable to respond to auto-reboot
    // 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.
    // Special care must be used with the Program button, because it must be made
    // accessible to initiate reprogramming, but it must not be accidentally
    // pressed when Teensy Loader is not being used to reprogram. To set lock the
    // security change this to 0xDC. Teensy 3.0 and 3.1 do not support security lock.

  6. #6
    Junior Member
    Join Date
    Aug 2015
    Posts
    4
    Defragster, thanks for the info. Not quite what I wanted, as pressing the button will erase the current code even when not trying to download.

  7. #7
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,825
    Not quite how I read it … didn't seem it was what you wanted - but what came to mind as what I've seen :: Unless the button is pushed reprogramming is not possible. If the button is pushed, then any attempt to program before restarting the existing code will then be wiped.

  8. #8
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,171
    Quote Originally Posted by TWrecks View Post
    Is it documented somewhere how to secure a Teensy 3.2 from an inadvertent update?
    Nope, like so many things that fall into the realm of hacking to change the default behavior, there's no formal documentation on how to do this. But hopefully this message will suffice, any maybe a findable by others who might wish to do this too.


    I've been searching for a while and not find any clear answers. I'm not trying to prevent hackers, I just have this fear sending my download to the wrong Teensy.
    You'll need to edit the core library code. Its inside Arduino, in hardware/teensy/avr/cores/teensy3. On Windows, the default Arduino install location is C:\Program Files (x86)\Arduino. On Mac, control click on Arduino and click "Show Package Contents", then look in Contents/Java for the hardware folder.

    The file you need it edit is usb_dev.c. Look for the _reboot_Teensyduino_() function. In the current version, it's on line 855. When Teensy's USB code hears the request from Arduino, it runs that function ~15 ms later. If you just delete or comment out the code inside that function, then Teensy will ignore Arduino's request.

    Of course, once you've programmed your Teensy with this edited code, the only way to upload code again will require pressing the pushbutton.

    This usb_dev.c file is always written when you run the Teensyduino installer, so if you upgrade or reinstall, don't forget to redo your change to the code.

  9. #9
    Junior Member
    Join Date
    Aug 2015
    Posts
    4
    Paul, that's great info, thanks.

Posting Permissions

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