Can you flash a Sonoff Mini D?

ESPHome
1

Assume that it is not possible to flash the Mini D with Esphome as it has something to do with it being matter compatiable? A post i read seemed to indicate that but you can flash the Mini R4M so I am uncertain about that reason.

There are two test pads exposed RST and KEY other than the normal 3.3 GND TX RX.

I have tried a bunch different combonations with the KEY pad to get it to flash esphome with no luck.

Any information would be appeciated.

2

The matter in Sonoff are usually added over WiFi and the chip used is not a special Matte chip, so it should be possible.
It is probably just a question about getting it in flash mode.

3

The chip is the ESP32-D0WD R2-V3. And I don’t think that the exposed push button is connected to GPIO0. As stated I’ve tried pulling the KEY pad to ground at different points during boot and i don’t seem able to get it right.

4

Can’t you find GPIO0 on the board?
Or possibly follow the traces on the board to point where you can connect it to ground

5

Can this be used?

6

Afaik the matter specification does enforce the lock down of a device to get certified. That probably results some technical measurements like a boot lock and/or efuse to prohibit full ownership. :lock:

Which might not be available at all on matter devices :person_shrugging:

7

That is it. From a short read matter mandates secure boot/flash and prohibits “unauthorized” (by the manufacture) firmware to be flashed. :zap:

That means: No right to repair, no right to modify/change/extend functionalities or even full ownership with matter devices :put_litter_in_its_place:

From sonoff you might get some devices as matter and wifi version - the latter mostly can be owned totally (esp, beken, reltek based devices thx to esphome) :trophy:

8

Espressif’s have their zerocode and there is no lock down there and it is certified.
You are probably right that it is locked down when the Matter is flashed to it, but a complete reflash should not be blocked.

9

I don’t think that this is the case, accordingly CSA:

Espressif provides the most comprehensive solutions for Matter, including support for Wi-Fi or Thread end-point devices, Thread Border Routers, and Matter gateway devices.

The espressif docs tell us more bluntly

Matter Certification

ESP ZeroCode products that implement the Matter framework need to be Matter-certified, before they can be shipped in the market.

10

You are right.
Zerocode devices are not certified.

I am pretty sure you are correct with the secure boot requirement, but I see nothing that prevents another firmware to be flashed.
Such a flashing would void the Matter certification, but since it would also remove the Matter certified firmware, then the issue is non-existing.

The fact that some devices can flashed to Matter OTA from a nin-Matter firmware means no boot lock can be installed then.

11

There seems to be no secure boot as such, but there is a private key encoded in certified firmwares that needs to match a public key on the CSA DCL.
My guess is that the Matter server is the part that makes these checks.

12

https://docs.espressif.com/projects/esp-idf/en/v5.5/esp32/security/secure-boot-v2.html

Secure Boot protects a device from running any unauthorized (i.e., unsigned) code by checking that each piece of software that is being booted is signed.

Restrictions After Secure Boot Is Enabled

  • Any updated bootloader or app will need to be signed with a key matching the digest already stored in eFuse.
  • Please note that enabling Secure Boot or flash encryption disables the USB-OTG USB stack in the ROM, disallowing updates via the serial emulation or Device Firmware Update (DFU) on that port.
  • After Secure Boot is enabled, further read-protection of eFuse keys is not possible. This is done to prevent an attacker from read-protecting the eFuse block that contains the Secure Boot public key digest, which could result in immediate denial of service and potentially enable a fault injection attack to bypass the signature verification. For further information on read-protected keys, see the details below.

There really is! Mostly in combination with flash encryption :lock:

https://docs.espressif.com/projects/esp-idf/en/v5.5/esp32/security/flash-encryption.html

You are not wrong, still your conclusion lacks :person_shrugging:

The fact that matter allows to brew your own DIY devices (without certification) doesn’t mean you can buy such “unlocked” device as that would violate the matter specification itself :bulb:

IMG_20250921_212033
IMG_20250921_2120331346Ă—1277 184 KB

13

I found this:

Secure boot is an optional recommendation, not a requirement, and so is fusing.
That means not all devices are like that, but OP’s device might be.

14

Are you sure, the CSA (they are actually in charge for the matter standard) tell us on their website:

What is product security and how does it differ from protocol security?

Standards such as Zigbee and Matter define requirements for the security of network protocols. The Product Security Working Group supplements these by creating a certification program for the security of products as a whole, including security features such as secure boot that are inherent in the product but not part of a network protocol.

:thinking:

15

So it is not a direct requirement in the Matter protocol, but it can be in the product security certification, which is an additional certification, that can be used with both Matter and Zigbee and even other products too.
It is a bit vague if it is a product security certification is a requirement Matter and Zigbee certifications, in which way they might be indirect requirements.

Sadly that link means that not even Zigbee devices are safe from such lockdowns and with EU pushing for more and more product security with its laws, then it will soon only be cheap Chinese products that do not care about these laws.

16

Can’t you just test with espefuse.py if SB is enabled or not?

17

Thanks for everyones input, pushed me in the right direction. I looked at the serial output…

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 153911750, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:2, clock div:1
secure boot v2 enabled
secure boot verification succeeded
load:0x3fff00c0 len:0x3c10
load:0x40078000 len:0x62a0
load:0x40080400 len:0x4
load:0x40080404 len:0xf40
entry 0x40080640
e[0;32mI (54) boot: ESP-IDF v5.2.1-dirty 2nd stage bootloadere[0m
e[0;32mI (54) boot: compile time Sep 20 2024 07:14:28e[0m
e[0;32mI (54) boot: Multicore bootloadere[0m
e[0;32mI (59) boot: chip revision: v3.1e[0m
e[0;32mI (62) boot.esp32: SPI Speed      : 80MHze[0m
e[0;32mI (67) boot.esp32: SPI Mode       : DIOe[0m
e[0;32mI (72) boot.esp32: SPI Flash Size : 4MBe[0m
e[0;32mI (76) boot: Enabling RNG early entropy source...e[0m
e[0;32mI (82) boot: Partition Table:e[0m
e[0;32mI (85) boot: ## Label            Usage          Type ST Offset   Lengthe[0m
e[0;32mI (92) boot:  0 esp_secure_cert  unknown          3f 06 0000f000 00002000e[0m
e[0;32mI (100) boot:  1 nvs_matter       WiFi data        01 02 00011000 00006000e[0m
e[0;32mI (107) boot:  2 nvs_matter_bkp   WiFi data        01 02 00017000 00006000e[0m
e[0;32mI (115) boot:  3 nvs              WiFi data        01 02 0001d000 0000f000e[0m
e[0;32mI (123) boot:  4 otadata          OTA data         01 00 0002c000 00002000e[0m
e[0;32mI (130) boot:  5 phy_init         RF data          01 01 0002e000 00001000e[0m
e[0;32mI (138) boot:  6 ota_0            OTA app          00 10 00030000 001e0000e[0m
e[0;32mI (145) boot:  7 ota_1            OTA app          00 11 00210000 001e0000e[0m
e[0;32mI (153) boot:  8 fctry            WiFi data        01 02 003f0000 00006000e[0m
e[0;32mI (160) boot: End of partition tablee[0m
e[0;32mI (165) esp_image: segment 0: paddr=00030020 vaddr=3f400020 size=2a270h (172656) mape[0m
e[0;32mI (225) esp_image: segment 1: paddr=0005a298 vaddr=3ffbdb60 size=05c10h ( 23568) loade[0m
e[0;32mI (233) esp_image: segment 2: paddr=0005feb0 vaddr=40080000 size=00168h (   360) loade[0m
e[0;32mI (233) esp_image: segment 3: paddr=00060020 vaddr=400d0020 size=133600h (1259008) mape[0m
e[0;32mI (614) esp_image: segment 4: paddr=00193628 vaddr=40080168 size=1c7c0h (116672) loade[0m
e[0;32mI (655) esp_image: segment 5: paddr=001afdf0 vaddr=00000000 size=001e0h (   480) e[0m
e[0;32mI (655) esp_image: Verifying image signature...e[0m
e[0;32mI (657) secure_boot_v2: Verifying with RSA-PSS...e[0m
e[0;32mI (667) secure_boot_v2: Signature verified successfully!e[0m
e[0;32mI (682) boot: Loaded app from partition at offset 0x30000e[0m
e[0;32mI (682) secure_boot_v2: enabling secure boot v2...e[0m
e[0;32mI (683) secure_boot_v2: secure boot v2 is already enabled, continuing..e[0m
e[0;32mI (690) boot: Checking flash encryption...e[0m
e[0;32mI (695) flash_encrypt: flash encryption is enabled (0 plaintext flashes left)e[0m
e[0;32mI (702) boot: Disabling RNG early entropy source...e[0m
        w  commission_status = 0, flag = 0 matter_ble_complete = 0
ets Jul 29 2019 12:21:46

Assume the secure boot locks the device from being flashed?

If I pulldown GPIO0 this is the output…

Download mode is disabled. Restart with GPIO0 high.
18

IMG_20250921_211406
IMG_20250921_2114061367Ă—1156 229 KB

19

The same can be true for Zigbee devices according to your links.
Only selfmade devices can have full ownership.

1 Like
20

Not quite correct

Also you can buy devices already running esphome or tasmota and don’t require inital flashing :zap:

Some practical example could could be some wall switches based on esp32 being (solely software wise with two lines of yaml) extened beings a Bluetooth proxy :blue_heart: