ESP32 Forum

Hi,

We have a device using ESP32. We have turned on secure boot V2 and flash encryption with a device-generated flash encryption key. For development, we use flash encryption in "development" mode so we can re-flash easily, although for production we enable "production" mode to lock it down.

I have been doing some tests which involve downloading the flash contents from the device to a PC with esptool:
My understanding is that the read-flash command can't decrypt the encrypted flash contents during the transfer, so I would expect the entire file of downloaded data to be "gibberish", including the empty parts of the flash, because "decoding" the empty data (0xFF) will result in garbage data.

However, when I examine the file I generated with read-flash, the empty sections are still 0xFF. E.g., here is the start of the bootloader:
The bootloader binary data looks to be encrypted as expected.

Why is the empty space coming out as 0xff?

Does the hardware flash decryption somehow know which areas of the flash are not used, and so avoid trying to "decrypt" them?

My understanding is that the read-flash command can't decrypt the encrypted flash contents during the transfer, so I would expect the entire file of downloaded data to be "gibberish", including the empty parts of the flash, because "decoding" the empty data (0xFF) will result in garbage data.

This doesn't make sense. You expect it to try to decrypt erased memory (hence outputting gibberish) but not decrypt regions written with encrypted data (also outputting gibberish)?

It's returning the data exactly as it is stored in the flash memory. The flash chip has no knowledge of any encryption scheme on any attached ESP32.

If you erase the flash contents, then read-flash, you should expect to see all 0xFF.

If you write an encrypted bootloader binary to 0x1000, you should expect to see 'gibberish' (ie. the encrypted bootloader binary verbatim) at that address via read-flash.

Instead, if you want to read the "decrypted" flash contents via the ESP32's MMU, then you'll need to find another way (is there a command for it, such as read-encrypted-flash?). In that case, you should expect the erased regions to appear as gibberish (ie. 0xFFs mangled by decryption) and to find the decrypted plaintext bootloader at 0x1000.

Thanks, I think I confused myself. Are you saying that the "read-flash" esptool command bypasses the hardware decryption completely? I suppose if it didn't, it would do the opposite of this (i.e. decrypt the encrypted data and also turn the empty data into gibberish...).