ESP8266 Community Forum

- Wed Aug 19, 2015 2:49 pm #26504 thats not correct since the code is not executed from flash. it is transfered to iram by the bootloader.
The bootloader cannot be read back. Consider a encrypted fw in flash and a decrypting bootloader ...
ok, code in iram possibly could be debugged ... but ...what is 100% secure???

read more here

Last edited by schufti on Wed Aug 19, 2015 3:00 pm, edited 1 time in total.

- Wed Aug 19, 2015 2:59 pm #26507 Even then, since the bootloader will have to execute a second temporary bootloader, this second one won't be encryptable, and therefore hacker will reverse engineered that to decrypt the rest of the application.

- Wed Aug 19, 2015 3:19 pm #26509 First of all, with a few exceptions (like SD library), Arduino libraries are LGPL, not GPL. See [code="https://www.arduino.cc/en/Main/FAQ"]Arduino FAQ[/code], section "Can I build a commercial product based on Arduino?". Basically, you must release object code of your sketch, but there is no requirement to release the source code.
This may be tricky in some cases (i.e. when you use header-only libraries), but overall this is possible.

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...

- Wed Aug 19, 2015 3:35 pm #26510 igrr , big thanks for clearing up the GPL issue

The encryption sounds really cool and makes sense to use the chip ID as part of the key / seed encryption process therefore making it unique to the device being written to.

The general is to secure code object would be to stop Joe Blogs who has a programmer reading and cloning of your device code. Yes there will always be some high level hackers who can reverse code down to levels where they strip down to silicon level but that is in an extreme case.

Please keep us posted on your work with protection. I am sure quite a few of us intend to use the ESP for more commercial projects but due to a lack of protection will seek other devices.

Keep up the great work mate, you are doing an amazing job.

Dans