The encrypted bootloader.bin file can be burned twice, and the device is not scrapped (ESPTOOL-729)

[li-shu-hang]

Operating System

Windows

Esptool Version

esptool.py 4.6.2

Python Version

Python3.9.0

Full Esptool Command Line that Was Run

esptool.py --chip esp32 --port COM3 --baud 921600 write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0x1000 bootloader.bin 0xa000 partition-table.bin 0x20000 gl-s10-Blyott-producttest-v2_0_3.bin

Esptool Output

result_list esptool.py v4.6.2
Serial port COM3
Connecting......
Chip is ESP32-D0WD (revision v1.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 70:b8:f6:d3:e0:c0
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Flash will be erased from 0x00001000 to 0x00009fff...
Flash will be erased from 0x0000a000 to 0x0000afff...
Flash will be erased from 0x00020000 to 0x0017ffff...
Compressed 34640 bytes to 21288...
Writing at 0x00001000... (50 %)
Writing at 0x00007b1e... (100 %)
Wrote 34640 bytes (21288 compressed) at 0x00001000 in 0.9 seconds (effective 317.4 kbit/s)...
Hash of data verified.
Compressed 3140 bytes to 211...
Writing at 0x0000a000... (100 %)
Wrote 3140 bytes (211 compressed) at 0x0000a000 in 0.1 seconds (effective 316.9 kbit/s)...
Hash of data verified.
Compressed 1441780 bytes to 864895...
Writing at 0x00020000... (1 %)
Writing at 0x00031280... (3 %)
Writing at 0x0003e264... (5 %)
Writing at 0x00049ece... (7 %)
Writing at 0x00053dc5... (9 %)
Writing at 0x0005fce4... (11 %)
Writing at 0x0006627c... (13 %)
Writing at 0x0006c36f... (15 %)
Writing at 0x0007249d... (16 %)
Writing at 0x000782e7... (18 %)
Writing at 0x0007e02b... (20 %)
Writing at 0x00083b15... (22 %)
Writing at 0x0008a8a1... (24 %)
Writing at 0x00090af0... (26 %)
Writing at 0x00096ec1... (28 %)
Writing at 0x0009d2a1... (30 %)
Writing at 0x000a3596... (32 %)
Writing at 0x000a9731... (33 %)
Writing at 0x000af7f7... (35 %)
Writing at 0x000b556d... (37 %)
Writing at 0x000bb8db... (39 %)
Writing at 0x000c16d8... (41 %)
Writing at 0x000c7a6f... (43 %)
Writing at 0x000cdca2... (45 %)
Writing at 0x000d39a4... (47 %)
Writing at 0x000d960a... (49 %)
Writing at 0x000def41... (50 %)
Writing at 0x000e4e32... (52 %)
Writing at 0x000ead1b... (54 %)
Writing at 0x000f164d... (56 %)
Writing at 0x000f756e... (58 %)
Writing at 0x000fd544... (60 %)
Writing at 0x0010271c... (62 %)
Writing at 0x00107c52... (64 %)
Writing at 0x0010cf56... (66 %)
Writing at 0x001126bb... (67 %)
Writing at 0x00117c43... (69 %)
Writing at 0x0011d2e5... (71 %)
Writing at 0x00122dde... (73 %)
Writing at 0x0012881a... (75 %)
Writing at 0x0012e579... (77 %)
Writing at 0x00134cbf... (79 %)
Writing at 0x0013a92c... (81 %)
Writing at 0x0014034d... (83 %)
Writing at 0x00145d65... (84 %)
Writing at 0x0014d139... (86 %)
Writing at 0x001549a5... (88 %)
Writing at 0x0015c3e4... (90 %)
Writing at 0x00162939... (92 %)
Writing at 0x00167fb5... (94 %)
Writing at 0x0016dd92... (96 %)
Writing at 0x001733ad... (98 %)
Writing at 0x00178971... (100 %)
Wrote 1441780 bytes (864895 compressed) at 0x00020000 in 13.7 seconds (effective 844.0 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

What is the Expected Behaviour?

The bootloader.bin file that needs to be burned is encrypted. If the previous version is burned twice, the device will become brick. However, with the latest version of esptool.py, the device can start normally after repeated burning of the encrypted bootloader.bin file, so it is a little confused. This encrypted bootloader should be in order not to let others brush the firmware twice, to protect the device from being changed, is this normal?

More Information

My colleague repeatedly burned this encrypted bootloader, and the device became bricked and could not connect to the serial port

Other Steps to Reproduce

None

[radimkarnis]

Hello @li-shu-hang,

can you please give more information about the issue? I am sorry, but I am not sure I fully understand it:

1) Have you or your colleague activated any security features (secure boot, flash encryption) of the ESP? Have you burned any eFuses? 2) Has your colleague flashed the same exact binary twice or has it changed? Has it been signed? 3) You are referencing an older version of esptool. Which one is it?

It is not possible to brick the device without burning any eFuses. Also, if an encrypted bootloader is burned, it can be burned again and will correctly execute if its signature is verified (more info here).

[li-shu-hang]

Hello @radimkarnis Thank you very much for your reply. Now we are ready to use the latest version of esptool.py for burning, which meets our needs. In addition, I asked my colleague, who originally used idf release4.2, a tool integrated with esptool, before he found that using esptool in this tool, repeated burning of encrypted firmware would cause problems on the device, so he prevented the device from repeated burning and told me this conclusion.

[radimkarnis]

@li-shu-hang thank you for the reply. I am glad this got resolved!

Yes, IDF v4.2 packs a quite outdated version of esptool. The recent versions of esptool are more mature in this regard.

Closing this issue.