In this post we’ll explore the differences between the new -E revision ESP32 modules verses previous revision modules (-D and older). This post will highlight the differences between both ESP32-WROOM-32D / 32E and WROVER-I /WROVER-IE.
At the beginning of 2020, Espressif announced the new series of modules, which ended with the letter E, namely
All these modules share the ESP32 ECO-V3 chip, which is the newest ESP32 core silicon release (at the time of writing). The standard ESP32 SoCs, the ESP32-D0WD and ESP32-D0WDQ6, have been updated and named ESP32-D0WD-V3 and ESP32-D0WDQ6-V3. In the next section we will see which are the main differences between the ECO-V3 and the previous ESP32 versions and in the third section we’ll look at one very important improvement. We will then see when to use the -E modules and when to use the older ones.
Regarding firmware and pinout compatibility, the older and new modules are interchangeable.
Improvements in the ECO-V3 chip #
There are six main differences reported by Espressif – four bug fixes and two improvements.
Listed in the order chosen by Espressif:
- External PSRAM bug fix: Previously when accessing the external PSRAM in a specific sequence a read/write error could occur.
- CPUs simultaneous reading error fix: Reading certain different memory regions at the same time with both CPUs could previously yield an error.
- Crystal oscillator start-up fix: In the previous silicon release the crystal sometimes couldn’t start if certain environmental conditions are met.
- Fault injection security issue fix: this problem is detailed in the next section.
- Minimum CAN baudrate reduced: ECO-V3 can use a baudrate as low as 12.5kHz instead of 25kHz.
- Download boot mode can now be disabled
For more information, please refer to the Official ECO-V3 User Guide.
Fault Injection Vulnerability #
In September 2019, LimitedResults described in his post a serious ESP32 vulnerability. He showed how a timely glitch on the supply rails of the ESP32 can lead to the reading of both secure bootloader encryption key (SBK) and flash encryption key (FEK).
The ESP32 eFuses and boot process #
To understand the exploitation, we must first understand the ESP32 eFuses. eFuses are non-volatile memory blocks which can be written only once: When a 1 is written in an eFuse bit, it cannot be reverted to 0. eFuses are organized in four blocks:
- BLK0: contains configuration bits, among which read and write disabled flags for blocks BLK1 and BLK2.
- BLK1: Flash encryption key (FEK)
- BLK2: Secure bootloader key (SBK)
- BLK3: Non-security related configuration bits
The ROM bootloader uses the SBK to verify the user bootloader on flash, which then checks trough ECDSA whether the application firmware is signed properly. After the reset, the eFuse controller reads the fuses and checks all the BLK0 flags.
LimitedResults was able to inject a glitch on the supply rails at the time when the eFuses controller reads the configuration bits, thus allowing him to read both SBK and FEK – even if the chip was secured and all the BLK0 flags are set to disable the reading. For detailed explaination, please read the ESP32 Fault Injection Vulnerability Press release.
The required equipment for this attack is fairly common and inexpensive but on the other hand the attacker needs physical access to the device to exploit this vulnerability. Our only recommended solution is to upgrade to the new ECO-V3 chip, but note that this will require re-certification of your product.
Previous revision modules are still available to buy, but using them is not recommended.