logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda
UV printer on your desk?
UV printer on your desk? Discover eufyMake E1 »
ADVERTISEMENT
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

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

divadiow 8877 93
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  
    Posts: 14637
    Help: 655
    Rate: 12649
    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 38  
    Posts: 5076
    Help: 441
    Rate: 899
    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 31  
    Posts: 1403
    Help: 164
    Rate: 440
    >>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.
  • ADVERTISEMENT
  • #64 21466676
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    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  
    Posts: 14637
    Help: 655
    Rate: 12649
    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.
  • ADVERTISEMENT
  • #66 21466766
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    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 38  
    Posts: 5076
    Help: 441
    Rate: 899
    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  
    Posts: 14637
    Help: 655
    Rate: 12649
    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 31  
    Posts: 1403
    Help: 164
    Rate: 440
    >>21725530
    What exactly is the problem with OTA?
  • #71 21725675
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    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:
    • ENCRYPT_NEW_DOESBOOT_NOOTA_OpenBK7231N_UASCENT_QIO_bk7231m_qio_09b8b111cb80.bin (1.16 MB) You must be logged in to download this attachment.
    • ENCRYPT_DOESNOTBOOTOpenBK7231N_UASCENT_QIO_bk7231m_qio_5ab45f244af1.bin (1.16 MB) You must be logged in to download this attachment.
  • #72 21725681
    insmod
    Level 31  
    Posts: 1403
    Help: 164
    Rate: 440
    >>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 38  
    Posts: 5076
    Help: 441
    Rate: 899
    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 31  
    Posts: 1403
    Help: 164
    Rate: 440
    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 38  
    Posts: 5076
    Help: 441
    Rate: 899
    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:
    • uascent_test_bins.zip (1.04 MB) You must be logged in to download this attachment.
  • #76 21727219
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    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 38  
    Posts: 5076
    Help: 441
    Rate: 899
    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 38  
    Posts: 5076
    Help: 441
    Rate: 899
    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:
    • brickedreadResult_BK7231N_QIO_2025-01-11-07-56-47.bin (2 MB) You must be logged in to download this attachment.
    • OpenBK7231T_App_UASCENT_M_01-11-2025_49480b170a70_OpenBK7231N.zip (4.63 MB) You must be logged in to download this attachment.
  • #80 21737907
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    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 31  
    Posts: 1403
    Help: 164
    Rate: 440
    >>21737907
    0x48-0x57 bytes are only in 1.0.1 bootloader.
  • #82 21738142
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    so it is! ok
    PowerShell screenshot showing output from running findbytes.ps1 script
  • #83 21739290
    divadiow
    Level 38  
    Posts: 5076
    Help: 441
    Rate: 899
    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 38  
    Posts: 5076
    Help: 441
    Rate: 899
    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 38  
    Posts: 5076
    Help: 441
    Rate: 899
    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 38  
    Posts: 5076
    Help: 441
    Rate: 899
    @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 31  
    Posts: 1403
    Help: 164
    Rate: 440
    >>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 38  
    Posts: 5076
    Help: 441
    Rate: 899
    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 31  
    Posts: 1403
    Help: 164
    Rate: 440
    >>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.
Generated by the language model.
Today's popular

FAQ

TL;DR: For makers converting first-generation Uascent Matter switches, the reliable path is a 2MB dump-based workflow using custom encryption handling; as one expert put it, "both running" once the bootloader and app were rebuilt with the Uascent coeff key. This FAQ explains why stock OBK builds fail, how to recover AP/MAC, and which partitions matter on CB3S/BL2028N hardware. [#21466530]

Why it matters: These devices look like ordinary BK7231N hardware, but their non-Tuya bootloader, efuse keying, and partition layout break standard OpenBeken flashing assumptions.

Option Boots on Uascent BL2028N OTA status Typical use
Classic Tuya BK7231N QIO No N/A Standard Tuya-key BK7231N devices
Zero-keys / BK7231M-style build No on Uascent N/A Devices using zero-key or M-specific paths
ENCRYPT_NEW_DOESBOOT_NOOTA UASCENT QIO Yes No Early proof-of-concept boot on Uascent Matter hardware
Uascent-specific rebuilt bootloader + encrypted app Yes Yes in later testing Proper conversion path for Uascent devices

Key insight: The main blocker is not the BL2028N radio itself. The blocker is the Uascent efuse coeff key plus a matching bootloader and partition scheme; once those match, OpenBeken can boot and later OTA can work too. [#21753785]

Quick Facts

  • The original 10A 1CH Matter mini switch used a CB3S module, but shield removal showed a BL2028N chip, not a plain BK7231N marking match. [#20940846]
  • On these Uascent RT-Thread Matter devices, the observed OTA partition for manual RBL placement was 0x143000 during stock-bootloader experiments. [#21106354]
  • A standard OBK OTA session on converted hardware wrote from about 0x12A000 to 0x1A3400, then rebooted into the new app when the boot path was correct. [#21466523]
  • The recovered Uascent coeff key was 4862379A 8612784B 85C5E258 75754528; reading efuse often returned all zeros even when that key was actually active. [#21465033]
  • A different Matter relay examined later used an ESP32-C3, 4MB flash map, secure boot verification, and 0 plaintext flashes left, blocking normal Tasmota-style reflashing. [#20965795]

How do I flash OpenBeken onto a Uascent uHome Matter switch with a CB3S/BL2028N module and custom efuse encryption keys?

Use a dump-first, key-aware workflow. 1. Read the full backup and use Easy Flasher’s BK7231N Decryption tab to find keys and add default BK7231N partitions. 2. Encrypt a matching bootloader and flash it at 0x0. 3. Encrypt the OpenBeken app partition and burn it at 0x11000, then restore RF from backup if possible. A later working method packaged a full 2MB image so first boot unpacked an OTA RBL and entered fresh OBK. [#21850205]

Why does a BL2028N-based UAM028 Matter device fail to create an AP after flashing standard OpenBK7231N or BK7231M builds?

It fails because the device does not use the standard Tuya encryption and partition assumptions. Standard builds could boot partially, but logs showed mac=00:00:00:00:00:00 and no AP broadcast even after RF restore attempts. The thread tied this to Uascent-specific coeff keys, non-Tuya bootloader behavior, and different RF or OTA layout expectations. Until the bootloader and app were rebuilt for the correct key path, the device did not expose the expected OpenBK7231N access point. [#21115403]

What is the coeff key on BK7231N/BL2028N devices, and why does it matter when converting Uascent Matter hardware to OpenBeken?

The coeff key is the efuse-backed encryption key that the bootloader uses to validate or encrypt firmware on this hardware. "Coeff key" is an efuse-stored encryption parameter that binds firmware images to a device family, preventing ordinary Tuya-key or zero-key binaries from booting when the chip expects a different key set. For the Uascent devices in this thread, the working key was 4862379A 8612784B 85C5E258 75754528. Without that key, standard OBK builds booted poorly or not at all. [#21465033]

What does the 0x143000 OTA partition mean on these Uascent RT-Thread Matter devices, and how is it used during flashing?

It is the stock bootloader’s download area for OTA-style application updates. In early tests, flashing an unencrypted BK-N RBL directly to 0x143000 triggered the Uascent BK7231n_1.0.13 bootloader to inspect that partition on reboot. When the bootloader accepted the payload, logs showed the OTA start marker and then jumped into the app area at 0x10000. That is why direct RBL placement worked even before a fully standard OBK conversion existed. [#21106354]

Which steps are needed in Easy Flasher to restore stock firmware from a backup on a BK7231N or BL2028N module?

Use Easy Flasher’s restore mode and make the backup file recognizable. 1. Enable "allow backup restore". 2. Ensure the filename starts with readResult_BK7231N_QIO.. so it appears in the restore list. 3. Select the backup and flash it back to the device. That method successfully restored factory firmware after failed OBK tests on BL2028N hardware. [#20968329]

How can I tell whether a CB3S module is really BK7231N, BK7231M, or a BL2028N variant when the markings and behavior do not match?

Do not trust the module label alone; confirm by chip inspection and boot behavior. The CB3S module first looked like a normal BK7231N, but removing the shield revealed BL2028N on the die. Even then, boot signatures such as 0x00401C1C suggested an M-flavor or different keying path, which explained why ordinary N images failed. The safest identification method is: inspect the silicon, capture boot logs, and compare behavior after flashing known N or M test images. [#20940912]

What's the difference between classic Tuya BK7231N firmware, zero-keys BK7231M builds, and Uascent-specific QIO builds in OpenBeken?

They target three different encryption assumptions. Classic Tuya BK7231N builds use the normal Tuya key path and standard partition layout. Zero-keys or BK7231M-oriented builds target devices whose efuse path behaves like the all-zero or M-family workflow. Uascent-specific QIO builds use the recovered Uascent coeff key 4862379A 8612784B 85C5E258 75754528 and a matching bootloader build path. That is why a Uascent device could reject release binaries yet boot a Uascent-specific QIO image. [#21725546]

Why does the newer Beken cmake_encrypt_crc.exe tool with CRC produce a bootable Uascent bootloader when the older encrypt.exe does not?

Because the Uascent bootloader path needed the newer encryption flow plus CRC packaging. A direct test showed that encrypting bk7231n_bootloader.bin with cmake_encrypt_crc.exe -enc ... -crc finally booted BK7231N_1.0.1 on Uascent hardware, while the older no-CRC result did not. Later testing also showed that using -un-skip broke booting on Uascent. In short, the newer tool produced a bootloader format that the Uascent device would actually execute. [#21466119]

How do I recover Wi-Fi, MAC address, and AP broadcasting on an OpenBeken-flashed Uascent device when RF restore does not help?

Fix the bootloader and key path first, then revisit RF. In the failing state, OBK booted with SSID OpenBK7231N_8C000000 but logged mac=00:00:00:00:00:00 and still did not broadcast. After a corrected Uascent bootloader and app were used, the low-level log showed a real MAC like 38:1f:8d:d8:14:d7, and the AP path initialized normally. RF restore alone did not solve the issue when the core bootloader and partition assumptions were still wrong. [#21466523]

What is an RBL file in the BK7231/OpenBeken ecosystem, and how is it different from flashing a full 2MB QIO dump?

An RBL is the OTA-style application package, not a whole-flash image. "RBL" is an RT-Thread OTA firmware container that carries an app payload for the bootloader’s download partition, rather than a complete flash layout with bootloader, RF, and data regions. In this thread, users flashed RBL files to 0x143000 or 0x12A000 for OTA processing, while a 2MB QIO dump replaced the complete flash from 0x0. Use RBL for bootloader-managed updates and QIO for full-device recovery or conversion. [#21727545]

When OTA starts but the device reboots or bricks afterward, what should I check in the bootloader, partition table, and 01PE data?

Check whether the bootloader can still parse the partition metadata after encryption. The thread linked failed OTA to bootloaders where the 01PE partition area became scrambled by the newer encryption flow. One working theory was that the app could boot, but OTA failed because the download or app partition header became unreadable after repacking. Also verify that the bootloader’s partition table points to the expected download area, such as 0x12A000 or 0x143000, for that specific build path. [#21725675]

How does BKFIL compare with Easy Flasher and BK Writer for dumping, restoring, and custom-writing BK7231N/BL2028N firmware?

BKFIL was the most useful for staged custom writes, Easy Flasher was best for guided restore and decryption, and BK Writer was one tool among several in the workflow. The thread used BKFIL to queue multiple files, wipe from 0x0, and place bootloader plus OTA pieces exactly. Easy Flasher handled backup restore, RF restore attempts, and later key discovery in the decryption tab. BK Writer 1.7.5 appeared in the toolchain, but the successful Uascent conversion relied more on BKFIL and Easy Flasher. [#21115403]

What can I do with an ESP32-C3 Matter relay switch that has secure boot and flash encryption enabled, when Tasmota or custom firmware won't flash?

Treat it as a hardware-mod case, not a normal serial-flash target. The boot log showed secure boot v2, flash encryption enabled, 0 plaintext flashes left, and a 4MB layout on the ESP32-C3 module, so custom firmware flashing was effectively blocked. In the thread, the practical options were to leave it stock, transplant a different module, or replace the radio board with something pin-compatible like a WB2S, CB2S, or another small module. [#20965795]

Where should I submit GPIO mappings or a template for a new Matter switch so it appears in the OpenBeken device directory?

Submit a pull request that edits the OpenBeken webapp device template list. The thread’s direct guidance was to add the new switch mapping to devices.json in the OpenBeken webapp repository. That is the file used for the device directory entry, so a clean GPIO map and tested template belong there rather than only in a forum attachment. [#21850205]

Why does the ENCRYPT_NEW_DOESBOOT_NOOTA UASCENT QIO image boot on some BL2028 Matter devices while current OpenBeken release binaries and UA files do not?

Because that image was built with the Uascent-specific encryption path that matched the device’s efuse coeff, while normal release binaries used the wrong assumptions. A user with a Matter 4CH BL2028 device reported that release 1.18.264 binaries, UA files, BK7231N T2/T34, T4, and BK7231M options all failed to bring up AP or Wi-Fi. The only image that booted was ENCRYPT_NEW_DOESBOOT_NOOTA_OpenBK7231N_UASCENT_QIO..., which fits the thread’s earlier finding that Uascent hardware needed a custom bootloader and encryption flow. [#21849983]
Generated by the language model.
ADVERTISEMENT