I want to prevent someone from connecting an arduino device to a computer and downloading the code (yes, the hex-dump code) because I want to embed a wifi password inside a device that should be kept secret

With that said, I stumbled upon this answer that mentions a security bit

I would like to ask for more details regarding it - i.e. how can I use it, enable it, what are it's limitations, etc. (Preferably for a Teensy v3.2 board, but if it's standard/generic, I would accept such an answer as well).

  • It is neither standard nor generic. Commented Oct 18, 2015 at 18:06
  • @IgnacioVazquez-Abrams then id like a Teensy v3.2 solution if possible Commented Oct 18, 2015 at 19:31
  • Given that the controllers in question don't have on-chip wifi, it is likely that the wifi credentials are going to be sent in the clear across some sort of standard serial interface to the wifi engine, and can be sniffed in flight. So read-locking the MCU won't actually achieve your goal. Commented Oct 19, 2015 at 2:30
  • @ChrisStratton you would be correct, I do intend to eventually make this on my own PCB though and thus sniffing them from the serial interface would be difficult if not impossible without de-soldering the chip(s) - although I think at that point I may as well go with storing them on an embedded SD card or similar as well (yes, one could still write a program to read it from the SD card, after downloading the current code to see where to look on the SD card, and then publish it via the wifi somehow, but that is becoming a complicated procedure). Commented Oct 20, 2015 at 1:26
  • Unless you are using all BGA chips and routing only on internal layers, it doesn't really follow that a custom PCB prevents sniffing. Those Cypress FX2 logic analyzers are cheap, powerful, and frequently employed for this type of purpose (for example, reversing propriety 2.4 GHz RC toy protocols to allow using a transmitter with better sticks) Commented Dec 18, 2015 at 4:04

3 Answers 3


The Teensy 3.2 board is based on MK20DX256. The processor core is an ARM and not AVR. The best way to learn about security on the MK20DX256 is to read the documentation.

Chapter 8 Security 8.1 Introduction This device implements security based on the mode selected from the flash module. The following sections provide an overview of flash security and details the effects of security on non-flash modules.

8.2 Flash Security The flash module provides security information to the MCU based on the state held by the FSEC[SEC] bits. The MCU, in turn, confirms the security request and limits access to flash resources. During reset, the flash module initializes the FSEC register using data read from the security byte of the flash configuration field.

NOTE The security features apply only to external accesses: debug and EzPort. CPU accesses to the flash are not affected by the status of FSEC. In the unsecured state all flash commands are available to the programming interfaces (JTAG and EzPort), as well as user code execution of Flash Controller commands. When the flash is secured (FSEC[SEC] = 00, 01, or 11), programmer interfaces are only allowed to launch mass erase operations and have no access to memory locations.

Further information regarding the flash security options and enabling/disabling flash security is available in the Flash Memory Module.

The next step is to search for an open-source project that uses the FSEC setting. And by chance the mbed does. Here is link to how it is done in the mbed CMSIS Cortex-M4 Core Device Startup File for the MK20DX256. There should be the same setting in the Teensy Arduino core. Locating that is left to the reader.



It is possible for the AtMega processors - like the Teensy 2.0 (see https://www.pjrc.com/teensy/ ).


  1. Work out your exact code. It will be a pain to update it once this is done, so thing carefully.

  2. Upload the code using ICSP (file->upload using programmer). TEST IT HERE!

  3. Work out the fuse you need to set. The important one is "RSTDISBL" - this disables the reset pin (makes it behave just like a regular pin). Use the page at http://www.engbedded.com/fusecalc/ to calculate your fuse settings.


  5. Use an ICSP to set the fuse. You will need to work out the 6 pins to connect the ICSP to, since there is no standard ICSP header.

If you did everything right, and the reset pin no longer works - this will protect the code from download!

If anything went wrong (e.g. you set the wrong fuse values - I've been there), or if you want to change the code, you will run into problems. In theory, you can use a high-voltage programmer - like http://www.societyofrobots.com/member_tutorials/node/239 - to reset everything to factory, but that takes 20 volts, and there's a high chance one of the other components on the Teensy board will be damaged.

Note that, if you do use the High-voltage programmer, the chip's memory will be wiped, so this can't be used to recover your code.

  • Any thoughts for the arm versions? Commented Oct 19, 2015 at 2:13
  • It's only 12V (on the pin), and it's not difficult to build a HV programmer. Commented Oct 19, 2015 at 2:16
  • This is not only targeting the wrong chip (the Teensy 3.x are NOT ATmegas), it is bad advice - the goal is to prevent readback which is a distinct goal from blocking the (re)programming pins. Commented Oct 19, 2015 at 2:29
  • The reprogramming pins are enough to read back the data. It's not difficult to build an HV, but that doesn't get you the data, only lets you wipe it. I missed the bit where it said v3.2, and I believe the "security bit" mentioned in the link in the question is the method I described. Commented Oct 19, 2015 at 2:46
  • You are overlooking the difference between disabling the pins vs disabling readback. Typically, when you lock a chip you can still reprogram it via the most convenient method (if you are willing to erase it), but what you cannot do is read back the existing memory. Commented Oct 19, 2015 at 3:24

While this does not answer your question, I believe it may help you with an alternative approach, which won't hide it completely, but will make it a lot harder to figure out.

Rather than keeping the password in plain text (which will be easy to spot in a hex dump), you can hide it somewhat. For example, exclusive-or each byte of the password with a randomly chosen number, put the result in your code; then, when you want to log in to the wifi, exlusive-or it with the same numbers (which must also be on your code).

Note that all the information required MUST be on the Teensy, so it is not impossible to reverse engineer; however, it will be hidden from casual inspection.

Note that, although more complex obfustication is possible (using any off-the-shelf encryption), since both the code and any keys will be available to an attacker, it is a token gesture only.

The Teensy v3 has JTAG, which means a running Teensy can be inspected, single-stepped, all memory and pin states can be viewed & modified. Once someone has your device, it's pretty much a lost cause against a determined attacker.

  • The Teensy (or at least the primary MCU used on it) can of course be read-secured which should make the jtag access irrelevant; what you miss is that the credentials can still be sniffed in-flight to the wifi engine. Commented Oct 19, 2015 at 3:23
  • @ChrisStratton, since you seem to know the answer to this question, could you post it as an answer (with the caveat that it won't work in this case)? That way, if someone else finds this question and wants it for a different purpose, they don't have to ask a new question? Commented Oct 19, 2015 at 20:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.