Arduino: How to lock the firmware hex file ?

[waqas-ogc]

Hardware

Hardware: WROOM-2 based on ESP8266

Description

I'm designing a commercial product and wants to protect my hex file from reading back. Is there a way for this ? ,like in other microcontrollers there are fuses to lock the firmware.

[igrr]

No, there is no way to do that — flash is external and can be read back trivially.
You may want to look at the ESP32 instead. It has flash encryption hardware which can help keep code in external flash secure.

[human890209]

Hi, I'm wondering if using ESP8285 which has a built-in 1M flash, is it possible to protect the hex file?
Cause ESP8285 is almost the same as ESP8266, I put my question here.
I'm now using ESP8266 with Arduino(thanks igrr and all the contributors) and got half of my work done, then the code protection problem comes. I like ESP8266/ESP8285, it's size, price and functions fit my project. I don't want to switch to ESP32.
I'm not using a lot of Flash right now, I think 1M is enough for my project.
Hope someone could see this. @igrr

[igrr]

In ESP8285 the contents of internal flash can be read out via UART interface using esptool.py, or by connecting a programmer to SPI flash directly (it is connected to the outer package pads). So it is no different from ESP8266 in this aspect.

[human890209]

Hi, @igrr. Thanks for your answer.

Is there any workaround by software? Use ESPChipID or DefaultMacAddress or FlashChipID as a key or something?

EDIT

Hi, igrr. I found your post on ESP8266 forum
https://www.esp8266.com/viewtopic.php?f=33&t=4630&start=8

Now regarding code protection... I have done some work in this direction, not enough to release anything yet though. The problem with 8266 is that since the ROM bootloader doesn't do any signature verification against the loaded firmware, "perfect" (i.e. provable) protection is not possible. Even if you do some decryption while loading stuff from flash to RAM, attacker can reverse engineer your code and modify it to dump plaintext decryption keys to Serial, for instance. So the only possible protection for 8266 is obfuscation.

I have written a piece of code which generates a key at runtime from 8266 chip ID, flash chip ID, and some user-defined salt. This piece of code should be resilient to reverse engineering: i made sure one will not be able to run it in Qemu or step through using a JTAG debugger. Disassembling it will also not be really helpful. But I am not a security specialist, so i wouldn't bet money on it without some kind of third-party review. This piece of code could be used either to decrypt some part of firmware (few critical functions and some data to be protected), or to verify firmware signature to prevent running it on clones with different chip ID/ flash ID combination.
I'll post more info when I make more progress...

Is there any progress of code protection? (Years passed)
I'm planning to add a verification function with ESPChipID/FlashChipID in the setup().
But after I did some research about hex crack. I've found that by using some Disassembler, the hacker could read and modify my code's logic. I guess the verification will be skipped or always return true or something.
I guess my solution could just stop a flash copier, but an attacker with disassembler can't be stopped. What's your final opinion about ESP8266 code protection?

[Suraj151]

Is there any workaround on this. i am not expecting that code in esp8266 should be protected but at least how can i avoid esp8266 chip from flashing once again after production bin is flash.

[rcarlson01]

The best solution is to use an encryption tools for the ESP8266 with custom bootloader from https://www.keeloc.com. It costs $1.00 to register and encrypt each device you want to code protect. Your unencrypted binary of firmware isn't shared with even the company doing the encryption. Basically you download their tools and it will send the proper unique ids and security bits and then these bits are uploaded to their server which returns the encryption key. Encryption is performed local on your linux or windows desktop with the AES that is returned. All this is done in a chain operation of either a batch file for windows or a bash script for linux. Everything is done quickly in the chain with about a 20 second time frame for all operation, including that the encrypted code and bootloader are automatically loaded onto the targeted ESP8266. To truly protect your code you are recommended to seal off the serial port pin(s) by fusing it out, that is putting some code in your firmware after it first loads up that will drive the serial port pins low impedance and high voltage. This pin is then provided a path to ground. By doing this you prevent the serial port usage which can be a disadvantage, but also this prevents hackers from getting information about the unique ID's and secuirty bits to try to decrypt your firmware. It's not totally necessary to blow the pin, but then you allow a vector to possibly derive your AES key and decrypt your firmware by doing that. Truth is it would be better to run it with a bit of protection than none even if you decide not to fuse out the serial pins.