logo elektroda
logo elektroda
X
logo elektroda

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

divadiow 5682 84
ADVERTISEMENT
📢 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 36  
    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
  • ADVERTISEMENT
  • #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 36  
    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:
    
    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?
    
    	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.
  • ADVERTISEMENT
  • #66 21466766
    divadiow
    Level 36  
    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
  • #67 21468839
    divadiow
    Level 36  
    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 36  
    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
  • #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 36  
    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?
  • #75 21725785
    divadiow
    Level 36  
    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/viewtopic.php?p=21725131#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/
  • #76 21727219
    divadiow
    Level 36  
    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 36  
    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 36  
    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
  • #80 21737907
    divadiow
    Level 36  
    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 36  
    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 36  
    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
📢 Listen (AI):

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.
ADVERTISEMENT