logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Fiddling with my first Matter device - 10A 1CH switch [CB3S / BL2028N (BK7231N)]

divadiow 6477 90
ADVERTISEMENT
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • #61 21466553
    p.kaczmarek2
    Moderator Smart Home  
    To be sure - does it run on single uascent device, or on multiple pieces?

    Is OTA working? I guess not, as you mentioned earlier/?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #62 21466663
    divadiow
    Level 37  
    p.kaczmarek2 wrote:
    To be sure - does it run on single uascent device, or on multiple pieces?

    I have only tried on 1 Uascent CB3S so far, but apart from the ZemiSmart dump, all other Uascent dumps have booted on this one CB3S - taking this as an indicator of consistency with Uascent keys.

    p.kaczmarek2 wrote:
    OTA working? I guess not, as you mentioned earlier

    Nope.

    This is interesting @insmod looks to have had related chats about this in the past regarding SBER devices, which are another brand of devices with unique keys on Beken chips: https://github.com/libretiny-eu/ltchiptool/issues/24#issuecomment-2003371110
  • #63 21466671
    insmod
    Level 29  
    >>21466663 OTA is working on my device is because i kept stock bootloader.
    Btw, the keys(coeffs) in that topic are probably wrong, obk and lt failed to boot with them. Only ota worked.
    I still have it disassembled, if someone can extract proper keys i can test 1.0.1 bootloader on it.

    Actually, does unencrypted 1.0.1 bootloader contains partitions? I remember when playing with 1.0.13 that partitions had to be inserted into it before encryption.
  • #64 21466676
    divadiow
    Level 37  
    I see. it's the non-working OTA though with Uascent devices we're stuck on.

    TLDR: we're encrypting the standard Tuya BL BK7231N_1.0.1 with the Uascent coeff and adding CRC using a newer encrypt.exe. So we have a bootable QIO and OBK for Uascent devices, but no OTA. Looking in the BL of the Uascent coeff QIO the "01PE" partition section is also encrypted by the new encrypt.exe but it is plain text in the normal Tuya BL, so maybe this is why OTA doesn't work (?)

    Added after 12 [minutes]:

    insmod wrote:
    Actually, does unencrypted 1.0.1 bootloader contains partitions?


    seems to. https://github.com/openshwprojects/OpenBK7231...231n_os/tools/generate/bk7231n_bootloader.bin
    Screenshot showing a hex editor with an open binary file named bk7231n_bootloader (2).bin.

    Added after 3 [minutes]:

    latest https://github.com/openshwprojects/OpenBK7231...b03dd95/platforms/bk7231n/bk7231n_os/build.sh

    which I've just run into my own PR https://github.com/openshwprojects/OpenBK7231T_App/pull/1557
  • #65 21466730
    p.kaczmarek2
    Moderator Smart Home  
    Why does even OTA fail? Do they use the keys to check OTA file?

    Btw:
    Code: text Expand Select all Copy to clipboard
    
OpenBK7231N\platforms\bk7231n\bk7231n_os\tools\generate\package_tool\windows>cmake_encrypt_crc.exe
/**< @author Bekencorp */
/**< @version v5.0.0.7 */
ERROR: Invalid number of arguments

Usage: encrypt_crc tool <command> <options-argument pairs>

 cmd   -options  usage and description/values
------------------------------------------------------------------------

 encrypt_crc
 -enc
     infile.bin                 iutput bin file
     passcode0                  input passcode0
     passcode1                  input passcode0
     passcode2                  input passcode0
     passcode3                  input passcode0
 -crc
 -start-add
     start_address             default value = 0
 -un-skip                      To un-skip keywords in chips ,such as addr = 0x100,default value = 0
 --version | -v  | version     To print the current version of this utility
 --help    | -h  | help        To print this help message

    Maybe we need -un-skip?

    but from what I can tell, they are creating somehow OTA file from already encrypted binary?
    Code: text Expand Select all Copy to clipboard
    
	echo "Using usual Tuya path"
	./${ENCRYPT} ${APP_BIN_NAME}_${APP_VERSION}.bin 510fb093 a3cbeadc 5993a17e c7adeb03 10000
	python mpytools.py bk7231n_bootloader_enc.bin ${APP_BIN_NAME}_${APP_VERSION}_enc.bin
(...)
echo "generate ota file"
./${RT_OTA_PACK_TOOL} -f ${APP_BIN_NAME}_${APP_VERSION}.bin -v $CURRENT_TIME -o ${APP_BIN_NAME}_${APP_VERSION}.rbl -p app -c gzip -s aes -k 0123456789ABCDEF0123456789ABCDEF -i 0123456789ABCDEF
./${TY_PACKAGE} ${APP_BIN_NAME}_${APP_VERSION}.rbl ${APP_BIN_NAME}_UG_${APP_VERSION}.bin $APP_VERSION 

    Would that mean OTA is also encrypted with those keys? I remember reading that it's not encrypted, so now I'm confused.

    Maybe we actually need to run RT_OTA_PACK_TOOL on our binary for Uascent, generate our own Uascent RBL and then package it?
    Helpful post? Buy me a coffee.
  • #66 21466766
    divadiow
    Level 37  
    p.kaczmarek2 wrote:
    Why does even OTA fail? Do they use the keys to check OTA file?


    No sign of a cause in the log out. At a guess, the BL isn't checking 12A000 for whatever code so doesn't know to start OTA? If so, I guess this ties in with the encryption/partition thing perhaps. What I don't understand is why the normal Tuya key QIO OBK has the 01PE unencrypted still after build.

    p.kaczmarek2 wrote:
    Maybe we need -un-skip?


    could try but that didn't produce bootable BLs yesterday:
    Code: Text
    Log in, to see the code

    https://www.elektroda.com/rtvforum/topic4032988-30.html#21466119

    p.kaczmarek2 wrote:
    Would that mean OTA is also encrypted with those keys? I remember reading that it's not encrypted, so now I'm confused.


    This was also my understanding, which is what I thought explained flashing normal N rbl to 0x143000 meant a successful OTA on factory Uascent - this was tried in the early days of this type of device to get OBK half working.

    It was my understanding, from the discovery of others, that Uascent uses default ota and iv keys

    Code: Text
    Log in, to see the code


    excerpt info copied from elsewhere:
    Code: Text
    Log in, to see the code
  • ADVERTISEMENT
  • #67 21468839
    divadiow
    Level 37  
    is the file created here retrievable somehow after each build?

    Code: Text
    Log in, to see the code


    Added after 2 [hours] 45 [minutes]:

    in an attempt to confirm coeff is consistent across the Uascent devices, I have flashed the OpenBK7231N_UASCENT_QIO_1.0.0.bin to the CB2L/UAM022 module on this bulb https://www.elektroda.com/rtvforum/topic4032988-30.html#21231617 and it does boot.

    so do these other Uascent dumps
    Screenshot showing Uascent and Capureye binary files.
  • #69 21725546
    p.kaczmarek2
    Moderator Smart Home  
    Nice, so we would need 3 binaries in relases? Zero keys (M), Uascent and classic N?
    Helpful post? Buy me a coffee.
  • #70 21725560
    insmod
    Level 29  
    >>21725530
    What exactly is the problem with OTA?
  • #71 21725675
    divadiow
    Level 37  
    p.kaczmarek2 wrote:
    Nice, so we would need 3 binaries in relases? Zero keys (M), Uascent and classic N?


    yes, a fixed classic M QIO and now a Uascent QIO - assuming OTA can be sorted.

    insmod wrote:
    What exactly is the problem with OTA?


    this I think. With having to use ENCRYPT_NEW (for some reason old didn't work) it also scrambles the 01PE partition bits

    https://www.elektroda.com/rtvforum/topic4032988-30.html#21466530

    Here is build with Uascent using original ENCRYPT (not booting)
    https://github.com/divadiow/OpenBK7231N/compa...68...34a9b68cbeb793a79549541342ab6f29bae8b509
    https://github.com/divadiow/OpenBK7231T_App/actions/runs/18644124343/artifacts/4314543665

    Here is build with Uascent using ENRCYPT_NEW (boots, no OTA)
    https://github.com/divadiow/OpenBK7231N/blob/...7cae725/platforms/bk7231n/bk7231n_os/build.sh
    https://github.com/divadiow/OpenBK7231T_App/actions/runs/18635901774/artifacts/4312295715

    it feels like build.sh is quite messy generally, so maybe it needs a general overhaul. dunno
    Attachments:
  • #72 21725681
    insmod
    Level 29  
    >>21725675
    Use rt_partition_tool on already encrypted bootloader to readd partition table
    Either figure out how to use it in cli, or use gui tool (https://github.com/NonPIayerCharacter/beken_freertos_sdk/tree/master/tools/rt_partition_tool)
  • #73 21725688
    divadiow
    Level 37  
    hmm. I can never get it to show anything apart from when it gets fed the pure ones that come with the SDKs.

    RT-Thread Partition Tool window with empty partition table and log messages
  • #74 21725731
    insmod
    Level 29  
    What if you use bootloader_bk7231n_uart2_v1.0.15.bin, cut last 192 bytes, encrypt it and then readd partitions?

    I think old partitions can't be read because there is no CRC32 (?) at the end?

    Will re-encrypted BK7231N_1.0.1 properly encrypt OTA firmware during unpacking?
    Tuya keys are at 0x48-0x57

    Added after 20 [minutes]:

    Does OTA work on BK7231M?
  • ADVERTISEMENT
  • #75 21725785
    divadiow
    Level 37  
    insmod wrote:
    Does OTA work on BK7231M?


    new clean branch for M testing only: https://github.com/divadiow/OpenBK7231T_App/tree/BKM

    one change, not 2 as stated here: https://www.elektroda.com/rtvforum/topic4107851.html#21725131

    OpenBK7231M_QIO_BKM_9c744401e40d.bin = boots on 00000 module.

    OTA:

    Code: Text
    Log in, to see the code


    Code: Text
    Log in, to see the code


    comes back up as 1.18.202

    Back later to play properly with Uascent too in new branch.

    Added after 7 [hours] 33 [minutes]:

    modified bootloader_bk7231n_uart2_v1.0.15.bin to required partition sizes (partitions_modifiedbootloader_bk7231n_uart2_v1.0.15.bin)
    Partition table for BK7231N showing bootloader, app, and download regions

    cut off last 192 bytes (missing_last192bytes_partitions_modifiedbootloader_bk7231n_uart2_v1.0.15.bin) and fed the remainder into cmake_encrypt_crc.exe
    Code: Text
    Log in, to see the code
    to produce missing_last192bytes_partitions_modifiedbootloader_bk7231n_uart2_v1.0.15_crc.bin

    Added unenc 192 bytes onto missing_last192bytes_partitions_modifiedbootloader_bk7231n_uart2_v1.0.15_crc.bin = FINAL_bootloader_bk7231n_uart2_v1.0.15_crc.bin

    replaced length of FINAL_bootloader_bk7231n_uart2_v1.0.15_crc.bin into new build OpenBK7231N_UASCENT_QIO_UASCENT_393af485b0d8.bin

    boots but:
    Code: Text
    Log in, to see the code


    OTA not work.

    https://github.com/divadiow/OpenBK7231T_App/commits/UASCENT/
    Attachments:
  • #76 21727219
    divadiow
    Level 37  
    well, I've tried all sorts of things at this point, even replacing all keys with Uascent one in ALT SDK. I have QIOs from ALT SDK but none boot - I suspect it's because the older encrypt is used, which is why we tried cmake_encrypt_crc.exe in the old because that at least booted. No change: booting is possible but never OTA.

    https://github.com/divadiow/beken_freertos_sdk/commits/uascent/
  • #78 21727545
    divadiow
    Level 37  
    posting what I've done before I forget.

    Take BK7231N_1.0.1 from Tuya SDK. strip off 192 bytes of wrong partition info. Encrypt what's left with

    Code: Text
    Log in, to see the code


    Add standard OBK partition with rt tool json import
    Code: JSON
    Log in, to see the code


    Remove new 192 bytes, save to file and add crc with
    Code: Python
    Log in, to see the code


    add CRCd partition bytes to encrypted and CRCd 1.0.1 BL. Flash to Uascent - boots. Add OBK RBL to 12a000 - OTA appears to run but then next boot freezes:

    Code: Text
    Log in, to see the code




    Flash previous QIO from PR build that boots (non-working OTA), flash BL above to 0, boots into OBK. Try OTA - same result as above.



    Take BK7231N_1.0.13 from Uascent device dump. Uncrc. Remove partitions, add CRCd partitions as above, flash to 0, flash rbl to 12a000 - OTA begins but fails, as above.

    Code: Text
    Log in, to see the code


    Note: Uascent factory BL has RBL header at FE9A
    Hex editor screenshot showing binary data with the text bootloader


    tested flashing entire Uascent factory and flashing OBK rbl to 143000 and, as expected, OTA successful and OBK boots (but of course BL thinks ota is 143000)
    BKFIL software window showing completed binary file download message

    Code: Text
    Log in, to see the code
  • #79 21737901
    divadiow
    Level 37  
    divadiow wrote:
    Ok cool. We'll feed that into the build for the uascent section and can finally, hopefully, release Uascent QIO in the BK7231N zip?


    following on from that thread.

    https://github.com/divadiow/OpenBK7231T_App/commits/UASCENT_M_01-11-2025/
    https://github.com/divadiow/OpenBK7231N/commits/UASCENT_M_01-11-2025/

    OpenBK7231N_UASCENT_QIO_UASCENT_M_01-11-2025_49480b170a70.bin is in OpenBK7231T_App_UASCENT_M_01-11-2025_49480b170a70_OpenBK7231N.zip and it boots. OTA from OBK starts correctly but then dies, wdt reboot, no log. bricked, requiring re-flash.

    Code: Text
    Log in, to see the code


    but if you flash UASCENT QIO to blank and rbl file to 12a000 in one write session, it'll complete OTA and boot fine. So that's where I'm at right now.

    If you compare the bricked dump to the QIO build the first difference isn't until 11C1A

    Comparison of two binary files in a hex editor with highlighted differences
    Attachments:
  • #80 21737907
    divadiow
    Level 37  
    but then wtf. flash the bricked dump back to blank Uascent and it boots and performs OTA and boots OBK

    Code: Text
    Log in, to see the code


    Added after 6 [minutes]:

    interesting. flash Uascent QIO to blank, join AP then doing a restart from GUI also bricks the device, so not actually OTA killing it

    Code: Text
    Log in, to see the code


    Added after 2 [hours] 7 [minutes]:

    trying v15 BL - bootloader_bk7231n_uart2_v1.0.15.bin

    -replaced x48-x57 with Uascent 9A 37 62 48 4B 78 12 86 58 E2 C5 85 28 45 75 75 (4862379A 8612784B 85C5E258 75754528)
    -removed 192byte partition info
    -encrypted with
    Code: Text
    Log in, to see the code


    added partitions to bootloader_bk7231n_uart2_v1.0.15_enc.bin then put through the PR for crcing with beken packager.

    getting this currently when QIO boots. same if crcing manually outside of build

    Terminal screen showing repeating “BIN&gt;” prompt in multiple rows

    @insmod I've been through your posts from last night several times but I'm still missing something. what have I missed?
  • #81 21738104
    insmod
    Level 29  
    >>21737907
    0x48-0x57 bytes are only in 1.0.1 bootloader.
  • ADVERTISEMENT
  • #83 21739290
    divadiow
    Level 37  
    this is interesting https://github.com/mildsunrise/bk7231_key_calculator

    we should be able to get coeff from Beken dumps with it. In the zip file in the 1 issue there is a decrypted Uascent bootloader

    We see the little-endian Uascent key 9A 37 62 48 4B 78 12 86 58 E2 C5 85 28 45 75 75 at 1F2D alongside the ota key and iv
    Screenshot of a hex editor with highlighted little-endian Uascent key

    @insmod do you still have an unknown Sber coeff device?
  • #85 21739331
    divadiow
    Level 37  
    ah ok ok. not to worry, just curious. could add to collection though I guess

    i'm still on the case of the no-OTA Uascent situation.

    BK7231n debug screen with OTA update failure message and processor register dump

    Screenshot of firmware tool showing BK7231N firmware download progress and success

    OTA seems to finish but then nothing on boot. dead.

    Added after 7 [minutes]:

    but I guess not finishing. this takes longer and doesn't have upgrade error. this is full Matter dump flashed + OBK rbl at 143000

    OTA error on BK7231N console with message requiring recovery firmware
  • #86 21745386
    divadiow
    Level 37  
    divadiow wrote:
    this is interesting https://github.com/mildsunrise/bk7231_key_calculator


    I grabbed as many SBER dumps as I could and these are the tested keys for each. It appears keys are unique to the SBDV model.

    FileNameSBDVCoeffCoeff LEota.keyota.iv
    readResult_BK7231N_QIO_bulb_sber_e14_cblc9_2024-10-3-17-50-08.binSBDV-001177d1ff9b3e3ffefde5d93b57eefefeb8bB3 F9 1F 7D DE EF FF E3 7E B5 93 5D 8B EB EF EF908f771bac2ff1aa619b897c14c5a88b1e647fab598d727c
    readResult_BK7231N_QIO_sbdv_00050.binSBDV-00050d34fbdd3efcbeadefd97bbffc7bfff3bD3 BD 4F D3 DE EA CB EF FF BB 97 FD 3B FF BF C7b4f9937b63a7c365f27bf8d06fb6797853de9074383e2223
    OpenBK7231N_QIO_Sber_Fck.bin (contains LibreTiny)SBDV-0011579bffed7a3fbeafd5dd3abffdfbfff5bD7 FE BF 79 FD EA FB A3 FF AB D3 5D 5B FF BF DFBDB4CE110F4787C2F539BF50E30A14E046DE464946314329
    readResult_BK7231M_QIO_sbdv-00115_2025-29-8-16-28-19.binSBDV-0011579bffed7a3fbeafd5dd3abffdfbfff5bD7 FE BF 79 FD EA FB A3 FF AB D3 5D 5B FF BF DFBDB4CE110F4787C2F539BF50E30A14E046DE464946314329
    readResult_BK7231N_QIO_SBDV-00027_2025-24-4-10-45-49.binSBDV-00027TUYA
    readResult_BK7231N_QIO_bulb_sber2_2024-18-3-14-40-51.binSBDV-001177d1ff9b3e3ffefde5d93b57eefefeb8bB3 F9 1F 7D DE EF FF E3 7E B5 93 5D 8B EB EF EF908f771bac2ff1aa619b897c14c5a88b1e647fab598d727c
    sber_lamp_BK7231N_1.0.8_stock_dump.binSBDV-000197fefb6fbabdbfbddffffaf7fc7edef17FB B6 EF 7F DD FB DB AB 7F AF FF FF 17 EF ED C7CE11F17490393890CD149E0F25FBE10DE5F12CB853A63E30
    readResult_BK7231N_QIO_2024-17-3-11-58-59_sber_e14-2.binSBDV-001177d1ff9b3e3ffefde5d93b57eefefeb8bB3 F9 1F 7D DE EF FF E3 7E B5 93 5D 8B EB EF EF908f771bac2ff1aa619b897c14c5a88b1e647fab598d727c
    readResult_BK7231N_QIO_2343_2024-28-1-10-44-05_sber_e14.binSBDV-001177d1ff9b3e3ffefde5d93b57eefefeb8bB3 F9 1F 7D DE EF FF E3 7E B5 93 5D 8B EB EF EF908f771bac2ff1aa619b897c14c5a88b1e647fab598d727c
    OpenBK7231M_QIO_SBER_DEL.binSBDV-00123d74ff1d7a3dbefdc5fdfa77fdfafffd3D7 F1 4F D7 DC EF DB A3 7F A7 DF 5F D3 FF AF DF5AC0EE0B2379005E3F52CCA49B2D741D8BCC2EF2EDEC53C7
  • #87 21753785
    divadiow
    Level 37  
    @insmod this now boots and OTA works on Uascent device. Uses uncrcd N_1.0.13 from decryption EF build.

    https://github.com/openshwprojects/OpenBK7231...OpenBK7231T_App:refs/heads/UASCENT_16_11_2025
    https://github.com/divadiow/OpenBK7231N/tree/UASCENT_M_01-11-2025

    ignore bootloader_1.0.13_4862379A_8612784B_85C5E258_75754528.bin that was for testing dd overwrite

    shall I do PR, any suggestions? or are are you about to drop a load of SBER and Uascent variants anyway? Not sure what your plans were, if any.
  • #88 21753871
    insmod
    Level 29  
    >>21753785
    I don't think it's really needed anymore.

    I didn't have any plans, i thought why not and did it.
    A guide about how to convert custom-encrypted device to OBK via EF would be better.
  • #89 21753885
    divadiow
    Level 37  
    oh I see.

    Do I read that to mean you envisaged users could just

    1. dump device flash and find key with EF
    2. re-encrypt BK7231M app partition with their device's key
    3. create bootloader of choice with key
    4. flash those two bits to their device
  • #90 21753893
    insmod
    Level 29  
    >>21753885
    For 2nd - not M, but non-QIO non-UA binary.
    Or flash bootloader first, and then rbl via custom write.
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
Report a violation of the law

Topic summary

The discussion centers on reverse engineering and firmware modification of a 10A 1CH Matter smart switch featuring a CB3S module with a BL2028N chip, initially thought to be BK7231N but later identified as BK7231M. Attempts to flash OpenBeken (OBK) firmware failed to produce a working access point or UART output, likely due to encryption key differences and firmware partition layout issues. The device uses uHome (Uascent) firmware rather than Tuya, with a unique coefficient key (4862379A 8612784B 85C5E258 75754528) that must be applied during encryption for successful booting. A newer encryption tool supporting CRC is required to generate a bootloader compatible with the device, as older tools produce non-booting images. Flashing the bootloader with correct keys and CRC enabled allows OBK to boot, but OTA functionality remains non-functional, possibly due to encrypted partition sections (e.g., 01PE) that differ from standard Tuya layouts. The community is working on integrating the new encryption method into OpenBK7231N build scripts to support these devices. Additional observations include the presence of ESP32-C3 based Matter devices with secure boot preventing flashing, and exploration of alternative modules (WB2S/CB2S, ESP32-C2) as replacements. Firmware dumps and boot logs have been collected and shared for further analysis. The challenges highlight the complexity of adapting open-source firmware to newer Matter devices with proprietary encryption and partition schemes.
Summary generated by the language model.
Today's popular
ADVERTISEMENT