9
\$\begingroup\$
  1. What is the best way to protect code flashed onto any AVR based device from reverse engineering?
  2. What is an easy way to provide updates to end users to flash on their own without disclosing the code? (Is it with a bootloader that decrypts an encrypted image?)

Don't flame me for promoting DRM, I am in favor of open platforms--I am just curious how this would work.

\$\endgroup\$
1
  • \$\begingroup\$ Don't. There is NO WAY to entirely prevent the possibility of a malicious person reverse engineering your hardware/software. All that Anti-RE measures do is make it take longer to reverse. \$\endgroup\$
    – Connor Wolf
    Aug 17, 2011 at 5:37

3 Answers 3

Reset to default
10
\$\begingroup\$

First:

There are fuses on the chip that can be set to prevent external tools from reading the code off the chip. Look for the protection fuses in your datasheet and/or programmer documentation.

It's not perfect, but it protects you from simple attacks.

Second:

You cannot download firmware securely. The AVR cannot self-program protected areas:

http://www.atmel.com/dyn/resources/prod_documents/doc1644.pdf

The best you might be able to do is to use an encrypted token language (such as basic, or forth) and have the interpreter protected on the chip with a bootloader that can program the encrypted tokens into an open area. When running, the chip would decrypt and execute the instructions on the fly.

\$\endgroup\$
4
  • 3
    \$\begingroup\$ If fuses bit not perfect, what kind of attact can bypass it ? \$\endgroup\$
    – Anonymous
    Jul 12, 2010 at 4:16
  • 1
    \$\begingroup\$ @Anonymous - Chemically etching away the cover of the chip and using electron microscopes, lasers, and microprobes to view, interface with, and edit the silicon. Costs at least $500, but can be cheaper than whatever work stbra is putting into the device. \$\endgroup\$
    – Kevin Vermeer
    Aug 16, 2011 at 21:46
  • \$\begingroup\$ @KevinVermeer Did you mean $500? It seems to me it would be a lot more expensive than that. \$\endgroup\$
    – NickHalden
    Nov 17, 2012 at 21:08
  • \$\begingroup\$ Adam, there was an error, so I deleted my comment \$\endgroup\$
    – hulkingtickets
    Oct 15, 2013 at 20:08
4
\$\begingroup\$

If it's that important and you're particularly worried about competitors stealing your code, take out IP protection on your code segments. You should be looking into this if you're going to try and make money out of a project anyway.

Certain elements of code can be either patented (for specific processing methods and novel algorithms) or registered as industrial designs (the look, layout and application of your code to a device). You may wish to consult an IP lawyer on this.

\$\endgroup\$
1
\$\begingroup\$

If you wrote your own bootloader which accepted encrypted data over the serial port, decrypted it and stored it into code storage area, you could have secure code firmware update. Each device could even have its own unique decryption key in your custom bootloader.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ I think what @Adam Davis is saying, though, is that if you use a bootloader (even one you wrote) then you can't program lock bit protected areas. So, if you did write your own encrypted bootloader, you couldn't prevent the chip from being read (issue 1). That seems to be what I'm getting from the link and the datasheet, anyway. \$\endgroup\$
    – Lou
    Mar 17, 2010 at 12:23
  • \$\begingroup\$ if the bootloader and the code is encrypted it would solve the second problem, the first problem is almost solved if he uses a secure enough encryption. (the speed of uC may be a bottle neck). \$\endgroup\$
    – Rick_2047
    Mar 17, 2010 at 15:14
  • \$\begingroup\$ True. @Adam Davis suggested an encrypted token language above. \$\endgroup\$
    – Lou
    Mar 17, 2010 at 15: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.