logo elektroda
logo elektroda
X
logo elektroda

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

divadiow 4482 66
ADVERTISEMENT
  • #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 34  
    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 22  
    >>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 34  
    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 34  
    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 34  
    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.

Topic summary

The discussion revolves around the user's experience with a Matter device featuring a CB3S module and BK7231N chip. The user attempted to flash the device with OpenBeken (OBK) firmware but encountered issues, including failure to boot and lack of output from the TX UART log. Various suggestions were made, including flashing original firmware from compatible devices and experimenting with different firmware dumps. The conversation revealed that the device might actually contain a BL2028N chip, which is known to work with OBK. Users discussed the challenges of flashing non-Tuya firmware, the significance of encryption keys, and the need for adjustments in the SDK to support the BK7231M variant. The user also explored the possibility of using other modules and shared insights on restoring stock firmware and the implications of secure boot on flashing processes.
Summary generated by the language model.
ADVERTISEMENT