[ESP32] FlashDownloadTool_v3.6.4 [Win10x64] Report Error after enable Flash Encryption

[human890209]

Hi,
I'm using ESPFlashDownloadTool_v3.6.4
My OS is win10x64
My device is MH-ET ESP32MiniKit which uses an ESP-WROOM-32 module.

I tested download bins files with default security.conf, it worked.
But I tried to download with Flash Encryption enabled, it failed.

Here is my security.conf

Code: Select all

[DEBUG MODE]
debug_enable = False
debug_pem_path = 

[SECURE BOOT]
secure_boot_en = False
burn_secure_boot_key = False
secure_boot_force_write = False
secure_boot_rw_protect = False

[FLASH ENCRYPTION]
flash_encryption_en = True
burn_flash_encryption_key = True
flash_encrypt_force_write = True
flash_encrypt_rw_protect = True

[AES KEY]
aes_key_en = False
burn_aes_key = False

[DISABLE FUNC]
jtag_disable = True
dl_encrypt_disable = True
dl_decrypt_disable = True
dl_cache_disable = True

I closed the downloader and restarted again, I got the Window as expected

Window.PNG (83.21 KiB) Viewed 16655 times

Here are my settings:

Settings.PNG (121.61 KiB) Viewed 16655 times

The settings are not changed, they worked with the default security.conf with no Secure Boot or Flash Encryption

Click the START button, and it reports errors:

Log.PNG (37.79 KiB) Viewed 16655 times

A text copy of the error log:

test offset : 4096 0x1000
case ok
test offset : 32768 0x8000
case ok
test offset : 57344 0xe000
case ok
test offset : 65536 0x10000
case ok
======
CONNECT BAUD: 115200
============
...Efuse CONSOLE_DEBUG_DISABLE is already burned.
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Exception in thread Thread-1:
Traceback (most recent call last):
File "threading.pyo", line 801, in __bootstrap_inner
File "download_panel_info.pyo", line 790, in run
File "espDownloader.pyo", line 432, in flash_download_test
File "espDownloader.pyo", line 599, in flash_download_func
File "espDownloader.pyo", line 1562, in esp_write_flash
File "espDownloader.pyo", line 1535, in esp_gen_secure_key
NameError: global name 'path_str' is not defined

Hope someone could help.

[costaud]

Oh, that is a bug in the download tool, we will fix it and post an update here, as well as on the official website.

[human890209]

Hi, @costaud,
thanks.

I read these instructions:
https://docs.espressif.com/projects/esp ... ption.html
https://docs.espressif.com/projects/esp ... -boot.html

and this (the diagrams are welcomed):
https://blog.csdn.net/espressif/article ... s/79362094
This blog explains how the download tool does with the secure boot and flash encryption.
But I still got confused. Cause generating and burning key with download tool is very different from the IDF instructions

More instructions or examples of using secure boot & flash encryption with the download tool are very welcomed.
For example, I don't understand the setting of

flash_encrypt_rw_protect

Will it process

Code: Select all

espefuse.py --port PORT write_protect_efuse FLASH_CRYPT_CNT

after the download?
Cause the secure boot and flash encryption effects can't be reversed, and I already brick some dev boards during testing.
More details are welcomed.

[costaud]

If flash_encrypt_rw_protect is set to true, the tool will disable read/write ability for flash encryption key after the flash encryption key is burnt into efuse.

Same way for secure_boot_rw_protect.

[human890209]

Hi, @costaud
Even the flash encryption key is read/write protected, but if the FLASH_CRYPT_CNT is not write protected and secure boot is not enabled, flash encryption will be ineffective.
The best way to figure out the eFuse setting result is run espefuse.py summary after using the FlashDownloadTool to check the eFuse's states.
Any news of the fixed FlashDownloadTools?

I guess the Downloader's procedure is similar to Reflashable Secure boot and Pre-generated Flash Encryption Key.
The downloader generated the secure boot and flash encryption key by PC and calculate the bootloader's digest, then encrypts the digest, bootloader, partitions table, and app binary file. Then flashed all these to the ESP32 chip, at last burn the keys into eFuse and burn some other marking and disabling eFuse. Cause each boards' keys are different, the codes are safe. It's faster and more reliable than doing all the job by bootloader on first boot.

But the configurations are really confusing.
I don't know the point to set burn_secure_boot_key and burn_flash_encryption_key to false. If the keys are not burned, is the procedure skip the digest generation and pre-encryption part? If not skip, the bootloader and app can't run without the keys in the eFuse.
I don't know the point to set secure_boot_rw_protect and flash_encrypt_rw_protect to false. If the keys can be read, what's the point?
And secure_boot_force_write and flash_encrypt_force_write, I get it now eFuse can't be set from 0 to 1, so if there is already a key burned, burn again with force could set the key wrong. But I don't know why should set this to true.
I guess some of them are designed for debugging, but there is already a debug setting. If debug is set to false, will these confusing settings take effects?
Hope there is a flowchart to explain how these configurations affect the procedure.
The configuration seems some traps to makes the flashing unsafe now...

[costaud]

Yes, you are right, some of the options are for debugging.
I think it would be easier to change the default option accordingly as you said.
You can find some documentations here:

https://gitlab.espressif.cn:6688/rd/esp ... rypt_cn.md
https://gitlab.espressif.cn:6688/rd/esp ... tool_en.md

[costaud]

You can try the temporary fix here:
download.espressif.com/release/flash_download_tools_v3.6.5.zip

[human890209]

Hi, @costaud
I won't try the new version until you tell me you succeeded with both secure boot and flash encryption enabled.
Buying new dev boards takes both time and money.