ESP8266 Community Forum

- Sun Oct 25, 2020 4:49 pm #89215

First, very often, bosses don't expect to release image outside, even though esp8266 does not protect flash image.

Secondly, some parameters specific to this hardware have to be flashed online of whole module such as RF calibration, serial number if any etc. -- sure, it is feasible to burn most of the flash image and only burn those data specific to module one by one.

That is the thing - the ESP8266 doesn't protect the flash so anybody can reverse engineer your code if they truly want to. The thing is most bulk manufacturers couldn't care less about it.

I just use the various chip IDs as the serial number - you have the MAC address as well as the flash ID that can be used, unless you want to completely write your own. You should also supply the initial RF calibration data with your flash and burn that at manufacturing time, but you still need to run an RF cal once the module is installed at its final site. I do that on first startup and on any factory reset command.

If you're really concerned about your code and your device specific parameters then give them a multi step flash
- build your main program as a flash image and then encrypt it and keep the key private
- build a loader flash that connects to an AP and gets the key and any device specific parameters, and decrypts and writes the main program from a payload into a second flash area and then reboots
- give the manufacturer that as a flash image

Then when your modules come back from the manufacturer, they start up and connect to a server to get the key and any device specific data, then write the production image from the encrypted payload, reboot to the main image and then you're good to go. You can also include any unit testing code in that initial loader as well.

Then your code can't be installed outside of your company, and you are only transferring a few bytes. Any OTA updates just write over the initial loader area like a normal OTA once the first image has been installed and run

- Sun Oct 25, 2020 11:53 pm #89217

Davy Norris is quite knowledgeable on the subject.

I've seen other claims of such high throughputs, but I am sceptical. To begin with it probably counts the whole frames, including L2 and L3 metadata (which is considerable with IP and 802.11). Furthermore they probably count in bits per second, which I honestly find quite senseless, because I am working with bytes, not bits. 426 kBYTES/s = 3.4 megaBITS/s.

Hi

To clarify in a simple way, here are some testing data fyi:

1. Our current OTA procedure takes around 9-10 seconds to OTA and flash a new BIN image of nearly 600KBytes successfully. Tested in a wlan.

2. As per the model of MCU---(SPI)--- 8266 WIFI Module ----(tcp over wifi)---- PC, a 100MBytes file data could be transmitted to the PC in around 100 seconds without any data errors.

Unit is BYTES other than BITS.

- Mon Oct 26, 2020 12:01 am #89218

That is the thing - the ESP8266 doesn't protect the flash so anybody can reverse engineer your code if they truly want to. The thing is most bulk manufacturers couldn't care less about it.

I just use the various chip IDs as the serial number - you have the MAC address as well as the flash ID that can be used, unless you want to completely write your own. You should also supply the initial RF calibration data with your flash and burn that at manufacturing time, but you still need to run an RF cal once the module is installed at its final site. I do that on first startup and on any factory reset command.

If you're really concerned about your code and your device specific parameters then give them a multi step flash
- build your main program as a flash image and then encrypt it and keep the key private
- build a loader flash that connects to an AP and gets the key and any device specific parameters, and decrypts and writes the main program from a payload into a second flash area and then reboots
- give the manufacturer that as a flash image

Then when your modules come back from the manufacturer, they start up and connect to a server to get the key and any device specific data, then write the production image from the encrypted payload, reboot to the main image and then you're good to go. You can also include any unit testing code in that initial loader as well.

Then your code can't be installed outside of your company, and you are only transferring a few bytes. Any OTA updates just write over the initial loader area like a normal OTA once the first image has been installed and run

Nice Reply, Great. Thanks!

- Mon Oct 26, 2020 12:53 pm #89224

Davy Norris is quite knowledgeable on the subject.

I've seen other claims of such high throughputs, but I am sceptical. To begin with it probably counts the whole frames, including L2 and L3 metadata (which is considerable with IP and 802.11). Furthermore they probably count in bits per second, which I honestly find quite senseless, because I am working with bytes, not bits. 426 kBYTES/s = 3.4 megaBITS/s.

Hi

To clarify in a simple way, here are some testing data fyi:

1. Our current OTA procedure takes around 9-10 seconds to OTA and flash a new BIN image of nearly 600KBytes successfully. Tested in a wlan.

2. As per the model of MCU---(SPI)--- 8266 WIFI Module ----(tcp over wifi)---- PC, a 100MBytes file data could be transmitted to the PC in around 100 seconds without any data errors.

Unit is BYTES other than BITS.

I still think 10 seconds for 600 kb of flash is quite normal and to be expected. The flash memory simply can't be written to any quicker.

I don't understand the whole code protection thing. If you don't want to throw your source code onto the street, I can understand. But compiled code is quite some work to reverse engineer. If you're really that secretive about your (binary) code, I almost inclined there is something nasty or illegal inside. Often the crux is a secret key is present in the code, used for authentication. Fair enough, but for that you don't need to hide all of the code. Also one way or another, such a key can be retrieved, if interesting enough. Sony did a real good job on the PS3 and still it got hacked.

Also don't forget the customer can simply solder off the flash chip and address the contents itself, so every workaround in the ESP8266 itself won't make a difference.

If it's obligatory in some way that the code is encrypted, switch to ESP32, it has support for encrypted flash contents (which I actually am quite sad of).