Unknown bootloader CRC - 0xAE323E12

[msacharewicz]

Bootloader CRC: 0xAE323E12

Device: OXT M222 cheap 2-channel relay advertised as "Tuya/WiFi/Matter", Matter works, device presents itself as "Uascent Smart Switch (1031)".

Board layout is identical to CB2S, but it's hard to be sure without looking at the front, and unsoldering this whole contraption is obviously well beyond my skills. Where you'd expect CB2S to be printed, there's "UAM02..." instead:

ESPHome fails to boot. Kind of. Got a terminal output once, never again. Then flashed back the original dump, worked. Then tried flashing ESPHome again, few different approaches, nothing worked. Doubt it's an issue of 3V3 power from UART, doesn't boot on 230VAC too.

Dump not parsing, "doesn't contain known storage area".

[divadiow]

you probably need to build with the Uascent coeff

board_build.bkcrypt_coeffs: "4862379A8612784B85C5E25875754528"
board_build.bkota.key: "0123456789ABCDEF0123456789ABCDEF"
board_build.bkota.iv: "0123456789ABCDEF"
board_flash.download: "0x143000+0xAE000"

[msacharewicz]

@divadiow If you mean, like, adding this:

esphome:  
  platformio_options:
    board_build.bkcrypt_coeffs: "4862379A8612784B85C5E25875754528"
    board_build.bkota.key: "0123456789ABCDEF0123456789ABCDEF"
    board_build.bkota.iv: "0123456789ABCDEF"
    board_flash.download: "0x143000+0xAE000"

then I cannot compile it at all:

Linking .pioenvs/bk72-oxt-lazienka-sufit/raw_firmware.elf
|-- Image 1: raw_firmware.elf
|   |-- image_bk7231n_app.0x011000.rbl
|   |   |-- raw_firmware.bin
|   |-- image_bk7231n_app.0x011000.crc
|-- ZeroDivisionError: integer division or modulo by zero
|   |-- File "/root/.platformio/penv/.libretiny/lib/python3.12/site-packages/ltchiptool/soc/bk72xx/util/crypto.py", line 161, in encrypt_u32
*** [.pioenvs/bk72-oxt-lazienka-sufit/raw_firmware.elf] Error 1
========================= [FAILED] Took 370.90 seconds =========================

[msacharewicz]

you probably need to build with the Uascent coeff

board_build.bkcrypt_coeffs: "4862379A8612784B85C5E25875754528"
board_build.bkota.key: "0123456789ABCDEF0123456789ABCDEF"
board_build.bkota.iv: "0123456789ABCDEF"
board_flash.download: "0x143000+0xAE000"

I'm a little out of my depths here, but judging from the code and behaviour I believe the bkcrypt_coeffs you gave me is not internally valid and doesn't calculate properly, hence the compilation error. Tried to compile with some randomly googled value and the compilation went through properly (though obviously code was not matching the board).

Still, I'm new to this, but from my understanding of what I already read (and this may be wrong, please correct me):

• the encryption is enforced by the bootloader, which is flash (not ROM) residing usually at the first 0x11000 of the flash memory,
• therefore replacing the bootloader with a one dumped from a sufficiently similar device that I was able to flash and boot properly would mean I could "bypass" the need for encryption...

...unless there's some other mechanism that's setting additional hurdles?

Anyways, attaching the bootloader part for reference.

bk7231n-cb2s-uam02-bootloader-0xAE323E12.zip

[divadiow]

well your bootloader boots on my Uascent module which I know has key 4862379A8612784B85C5E25875754528 in the efuse. It's been quite a while since I built binary for ESPHome so forgive my lack of detail.

The bootloader and app partition will be encrypted using that key. The efuse key is not changeable

Maybe your ESPHome run failed because of indentation or placement of that block, I seem to recall it being quite fussy. Maybe @kuba2k2 can confirm

[divadiow]

try
board_build.bkcrypt_coeffs: "9A3762484B78128658E2C58528457575"

[kuba2k2]

The encryption is baked into the chip, both bootloader and app are encrypted this way. It's decrypted transparently by the internal decryption peripheral before executing code, so it cannot be bypassed. In theory, the eFuse can be changed, but that's not something that has been tested before.

The error you're getting is due to the non-perfect implementation of the encryption algorithm in ltchiptool. With certain coefficients it will attempt to divide by zero. It's a bug, but it's not known yet why it exists.

That being said, not all bits of the coefficient are used, and while that doesn't solve the issue directly, there do exist multiple coefficients that result in the same encryption values.

The right way would be to find where the integer division crashes, and find out why it doesn't in the original "encrypt_crc" binary (there are C sources for that somewhere).

[msacharewicz]

try board_build.bkcrypt_coeffs: "9A3762484B78128658E2C58528457575"

Yeah, this one compiles, yet does not boot. But in light of what @kuba2k2 said, it pretty much explains everything.

Seems I'll be stuck in a peculiar scenario where I do know, thanks to @divadiow, the correct encryption key — but will not be able to use it due to a bug 😅

[divadiow]

Yeah, this one compiles, yet does not boot.

OK, that makes sense. I was sure the key should be in config as the non-little endian form, the first expression.

[kuba2k2]

Try replacing (0, 0), with (1, 0), on line 127 of the crashing file (util/crypto.py). Since it looks like you're compiling in HA/Docker, you have to either modify the file directly in the container, or use ESPHome without containers.

[msacharewicz]

Try replacing (0, 0), with (1, 0), on line 127 of the crashing file (util/crypto.py). Since it looks like you're compiling in HA/Docker, you have to either modify the file directly in the container, or use ESPHome without containers.

Well, that moved things forward, thanks!

I've dropped a local instance of esphome into my WSL along with the board yaml, run the compiler once, modified the downloaded crypto.py along Your instructions and run the compiler again. No error on the second run.

Uploaded the firmware onto the CB2S with the original bootloader, and...

Well, something did boot.

ESPHome integration does discover the device, the addon shows the board config tile as "online", and that's probably all the good news. I guess the module keeps rebooting.

No output in UART terminal despite logger: and debug:.

The only think I get from ltchiptool's ESPHome OTA addon is:

D: Zeroconf service added: bk72-oxt-lazienka-sufit._esphomelib._tcp.local.
W: Couldn't read service info

[kuba2k2]

What makes you think it keeps rebooting?

UART output is on TX2 by default, not on TX1/RX1 which is used for firmware download.

Try shortening the device name, I think mDNS has some limitations.

[msacharewicz]

What makes you think it keeps rebooting?

At the moment I was writing this, only the faint network presence:

PING 192.168.1.117 (192.168.1.117) 56(84) bytes of data.
64 bytes from 192.168.1.117: icmp_seq=15 ttl=254 time=7.66 ms
^C
--- 192.168.1.117 ping statistics ---
30 packets transmitted, 1 received, 96.6667% packet loss, time 29645ms
rtt min/avg/max/mdev = 7.664/7.664/7.664/0.000 ms

UART output is on TX2 by default, not on TX1/RX1 which is used for firmware download.

Try shortening the device name, I think mDNS has some limitations.

Took me some time to solder it 🤣

Well, it's weird...

Intially, I saw repeating patterns of having trouble with connecting to WiFi:

I][wifi:351]: Connecting to 'Beaver's'
[W][wifi_lt:296][wifievent]: Disconnected ssid='' bssid=00:00:00:00:00:00 reason='Association Leave'
[W][wifi:755]: Unknown connection status 0
[I][wifi:351]: Connecting to 'Beaver's'
[W][wifi_lt:294][wifievent]: Disconnected ssid='' reason='Probe Request Unsuccessful'
[W][wifi:734]: Connecting to network failed
[D][wifi:519]: Starting scan
[W][wifi_lt:296][wifievent]: Disconnected ssid='' bssid=00:00:00:00:00:00 reason='Association Leave'
[W][wifi_lt:296][wifievent]: Disconnected ssid='' bssid=00:00:00:00:00:00 reason='Association Leave'
[W][wifi_lt:294][wifievent]: Disconnected ssid='' reason='Probe Request Unsuccessful'
[E][wifi:595]: Scan timeout
[D][wifi:519]: Starting scan
W [    210.120] WIFI: Scan timeout, discarding
[W][wifi_lt:296][wifievent]: Disconnected ssid='' bssid=00:00:00:00:00:00 reason='Association Leave'
[W][wifi_lt:294][wifievent]: Disconnected ssid='' reason='Probe Request Unsuccessful'
[W][wifi_lt:296][wifievent]: Disconnected ssid='' bssid=00:00:00:00:00:00 reason='Association Leave'
[E][wifi:595]: Scan timeout
[W][wifi_lt:296][wifievent]: Disconnected ssid='' bssid=00:00:00:00:00:00 reason='Association Leave'
[D][wifi:519]: Starting scan
W [    245.142] WIFI: Scan timeout, discarding
[W][wifi_lt:294][wifievent]: Disconnected ssid='' reason='Probe Request Unsuccessful'
[D][wifi:608]: Found networks:
[I][wifi:579]: - 'Beaver's' (B0:98:2B:CC:64:D2) ▂▄▆█

Note the original firmware had no such problems, even when powered the same way via UART.

Then, after some time, it decided to launch the captive portal, and before I tried to connect, restarted, only to this time properly connect to my WiFi 😶 which lasted for around 10 minutes and then it went awry again 🤣

[kuba2k2]

Power source is the most common issue with WiFi problems.

Since this device has a different partition table, the calibration data could possibly be missing. Check and report the MAC address of the device after it connects to your network.

[Cossid]

If it doesn't connect to your network and you can connect to AP mode, AP mode webpage also lists the MAC address at the top of the page.

[divadiow]

my Uascent TLV was at 0x1F6000