I would like to know if there is a 100% safe option today to prevent firmware copy from MCUs. Most MCUs can have an option set at programming that will block any code extraction, but this is usually easy to hack, specially if you use acids to get acess to the die and probe it.

I saw once that some MCUs use cryptographic solutions, but I am not sure how they work, I assume they probe some external hardware for specifc keys, but this is easy to change in the code once it's extracted.

  • 8
    \$\begingroup\$ 100% safe option to prevent firmware theft is to never create the product. There is no 100% safe option. A dedicated person/team/company will get it if they want it bad enough. \$\endgroup\$
    – Passerby
    Commented Apr 29, 2014 at 22:57
  • 2
    \$\begingroup\$ There is no such thing. Best you can do us to try to make it too expensive for the adversary. \$\endgroup\$ Commented Apr 29, 2014 at 23:00
  • 1
    \$\begingroup\$ Crypto is all a matter of time; eventually it will be broken, so all you can do is make sure it would take 10,000 years to break. So maybe use a microprocessor to break down the code on the fly? But if the code is encrypted, the key is somewhere on the board, and might be retrieveable. So... I guess the entire operating system has to be encrypted. Just a thought. \$\endgroup\$
    – user39962
    Commented Apr 29, 2014 at 23:06
  • 2
    \$\begingroup\$ If an interested party can obtain your device, he can observe its actions, and probably create his own program to duplicate the actions of your device. \$\endgroup\$ Commented Apr 29, 2014 at 23:17
  • 7
    \$\begingroup\$ When governments have to seriously prevent firmware theft, they detect the physical attack (attacker getting inside the enclosure) and erase the firmware. The assumption is that if an attacker can get his hands on the circuit board, he can do anything from that point. \$\endgroup\$ Commented Apr 29, 2014 at 23:23

3 Answers 3


If you know that your MCU will always have power, you could in theory keep your firmware in RAM and apply external measures which will cut power to the RAM/erase it so the firmware is lost if the user does something like remove a cover. This is done for some banking applications (though they usually just erase crypto keys). It's not 100% guaranteed, but it'll probably get you close enough there that it's in-feasible for nearly every attacker.

You can find more ideas from this teardown video of a credit card machine.

In reality, I don't see the need for this level of hardware protection for firmware. It won't be cheap to do and an opportunistic competitor could just as easily reverse-engineer the functionality and sell a cheaper product than you.

  • 1
    \$\begingroup\$ Sometimes protecting an algorithm is what makes your system unique, like precision motor control algorithms and etc...and storing in RAM is not as erasable as people think, data remains in memory for a minute or so...writting on top of it should be better...thanks for the link though \$\endgroup\$
    – mFeinstein
    Commented Apr 30, 2014 at 2:55
  • \$\begingroup\$ Depends on the type of RAM you have. Some are specified for this purpose where you have critical data which needs protecting. I am of the opinion that cases which involve protecting special codes/algorithms to such a high degree are those which are "national safety" issues, for example missile guidance systems (though if the attacker has access to the hardware, you're in trouble already). Just remove debug headers and possibly potting your device will stop pretty much all nefarious entrepreneurs. \$\endgroup\$ Commented Apr 30, 2014 at 4:04
  • 1
    \$\begingroup\$ I don't know about SRAM, but I think there have been experiments where the contents of DRAM have been preserved using cryogenics long enough to get usable information out of them. I think typically, though, the software would perform a zeroization of the sensitive region which would vastly increase the difficulty of recovering data. \$\endgroup\$
    – rjp
    Commented Apr 30, 2014 at 14:07
  • \$\begingroup\$ @RJP I have seen this cryogenic experiment too, zeroing the RAM is preferable, but this only applies to systems where there will be power all the time \$\endgroup\$
    – mFeinstein
    Commented May 1, 2014 at 1:55

If you think acid die access is easy then there are few hard solutions :-).

An external "box" which processes supplied data with a useful and unknown algorithm or process and which is accessed by cryptographically secure means (eg public key cryptography) and returns a useful result makes the system as secure as either the external device or as the difficulty of replicating the algorithm or process. Both can be made "very hard". [eg an internally powered device with power or intrusion detection via a semi-randomly scrambled net of fine copper wire which is wrapped around the device with the whole set in a ceramic matrix would resist most sensible attack methods.]

Here is one such system from long ago {1987!} -
describing a system titled "Ninox"*. This paper was meant to also have my name attached but I failed to make the attachment cryptographically secure :-). The currently perceived merit of this 'suggestion' may be indicated by the fact that the paper is now available for purchase for $1.98.


This paper describes a software protection system which will probably become widely used over the next few years in an effort to control the software piracy problems experienced by the developers of microcomputer software.

The system described was developed by the author and an associate. A number of other researchers have independently come up with similar techniques, but we believe that the work described in this paper includes some useful new developments. We have called the system Ninox.

The system uses a serialized device in each computer system and provides facilities so that software supplied to the user will be able to execute only on the user's machine and it is effectively impossible for the software to be modified to execute on another machine.

Public key cryptography is used to encrypt programs and a method of program distribution is described. The paper also examines some of the difficulties with the system and suggests some of the methods by which the system might be attacked and how it stands up to these attacks. It is generally held (and supported by formal information theory analysis) that a totally secure system is impossible to create.

  • Ninox novaeseelandiae is the NZ Owl - commonly termed a Morepork (from its call) or Ruru in Maori (also from its call). I chose the name because 'Ninox' can (more than most) see in the dark. More

enter image description here

  • \$\begingroup\$ Very interesting, thnks! \$\endgroup\$
    – mFeinstein
    Commented May 1, 2014 at 1:59

Recently I made a custom ARM board for my combat robot, and the Atmel SAM3S4 I used on it has an erase pin on it, which when exerted literally blanks your microcontroller.

This is intended as a safety feature for industrial espionage, where you can rig up a sensor/switch/tricky device that triggers this upon intrusion detection. All that is left is the SAMBA boot loader which these Atmel devices restore upon erasing everything else.

That feature is actually used to USB Flash programs onto the device as well, unless of course you have a JTAG connection that process is unnecessary.

  • \$\begingroup\$ Yes this pins helps, but they depend on your sensors functioning well, look the video helloworld922 send from mike, its shows this kind of pin too \$\endgroup\$
    – mFeinstein
    Commented May 1, 2014 at 1:57
  • \$\begingroup\$ Out of curiosity, do you really needed an ARM for a Combot? I used to compete a lot in the USA and Brazil, and most robots are really simple in therms of embedded electronics for the need of an ARM MCU \$\endgroup\$
    – mFeinstein
    Commented May 1, 2014 at 1:58
  • \$\begingroup\$ @mFeinstein the flea weight combat robot was just an initial application for my board, the final goal is to do low resolution robot vision for target acquisition and for visual SLAM (ratSLAM) amoung other things. Also for personal interest in ARM MCUs because I've done too many embedded 8Bit AVR microcontrollers I thought I would venture into ARM land. \$\endgroup\$
    – KyranF
    Commented May 1, 2014 at 4:56

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.