Beken Flash Dump Partition Info Extraction with RT-Threads Partition Tool - Development Thoughts?

It's oftentimes useful to know what the partition offsets and lengths are on any given device that may be up for conversion to OpenBK*. This can be useful when determining if a device should have its bootloader overwritten by using the QIO release in order, for example, to allow OTA updates to work. OpenBK will write the ota file to a fixed offset and if the bootloader isn't looking for updates to initiate from the same location, then OTA will fail.

From the backup of the factory firmware it can usually be worked out from the boot log or by analysing the partition table starting "01PE" what the offsets are, but this requires a bit of sleuthing and getting your head around reverse-byte order little-endian in order to read what's been configured.
eg https://www.elektroda.com/rtvforum/topic4074263.html#21217939

I've been fiddling with the RT-Threads Partition Tool, which lets you edit/add partitions to a virgin bootloader.
eg, open bootloader_bk7231n_uart2_v1.0.13.bin that can be found in the Beken SDK and the tool will show you what's set



That's great, but it doesn't work on a standard 2mb dump.

BK7231N_QIO_ATLO-WB3K-TUYA_2025-16-1-14-11-09.bin



With this in mind:

insmod wrote:

Yes, and it's that way on every beken, whether encrypted or not.
Every 32 bytes of data is followed by 2 bytes of crc

You can create a script that would remove those bytes to get readable strings, if required.

and using @Paver3109's uncrc script from https://github.com/fusetim/insecurity-camera-tools/tree/main/firmware the crc can be removed



but the resultant file is still not readable in the GUI tool nor CLI





This script will scan the first 2mb and extract the section of 2 more where "01PE" is seen 64 bytes apart


It launches a Windows picker for the input file and will give a result summary and output a file suffixed with _partitions to filename



While the result still does not reveal anything if opened with the GUI tool, it will work with the CLI


Let's test with some Bekens of various flavours, 2mb and 4mb.

4MB BK72326 - Tuya_T3-3S_readResult_BK7231N_QIO_7236_fixed-insmod.bin


needs de-deduping

non-Tuya 4MB Matter BK7231M - SparkleIoT_XH-CB2S_Mini_Switch.bin


Non-Tuya BK7231U - Arnoo_Winees_WS010078261_AiDot_RGBW_A60_(2ndGen)_(light.A001139)_Leedarson_CC8000_2.0.4.51.bin


This one was interesting, and why the search for 01PE was set to cover 2mb, There's the 3 01PEs at the beginning of the flash and then another set further in


Interesting, but probably not a reason to scan beyond initial 01PE area.

BK7231T_Denver-SHP-200MK2.bin


non-Tuya BK7238 - Zengge_AK001-ZJ21413_77_24_20240423_ZG-BK_Symphony_USB_SPI_LED.bin


Tuya BK7238 1 - Tuya_Switch_(schemaID-e1mzkfec)_keyfxuj3d5wg53wx_jsejjp8bin9lllh3_T1-2S-NL_1.1.4.bin
Fail - no 01PE in dump

Tuya BK7238 2 - Tuya_IHSENO_HAZ-IR-V3_(schemaID-e1mybg3w)_keycmhjv873dhvsn_kv4htgxocgwjfabc_T1-3S_0.0.5.bin
Fail - no 01PE in dump

non-Tuya BK7252N - Pinmei_A9_BK7252N_BKFIL.bin


4MB Tuya BK7252U - Tuya_Doorbell_IP06-V6.3-BekenSPI_2025-08-10-21-29-16.bin
Fail - no 01PE in dump

4MB Tuya BK7252U - Tuya_A9_Cam_SC-10024_V1.0.0_(VGA卡片机-schemaID-000003uanz)_keyph8vwhadwsx3a_u0kmecmr7j8roazz_NEO_SPI_1.0.4.bin


and so on. If the dump has 01PE partition style then it seems we can easily read it.

So, what next?

-extract Python script from RT tool GUI and CLI EXEs?
-consolidate different steps into one script
-make a C application and integrate with Easy Flasher- new tab?
-add additional checks - eg TLV start location?

thoughts?

I attach the scripts used above, and some extras, including extraction of all groups of 01PE if found. RT Partition Tool too.

Flashdumps tested with can be found at https://github.com/openshwprojects/FlashDumps/tree/main/IoT

Interesting, is it the same as the RBL extraction that I started some time ago in FlashDumps?

https://github.com/openshwprojects/FlashDumps
https://openshwprojects.github.io/FlashDumps/
Or wait, it seems it's not the same... RBL just finds RBL identifiers in the binary, not 01PE

still, interesting. what were you hoping to achieve or was it just to see what was readable from rbls?

I was trying to find how many bootloader versions we know, but it didn't work too well for me. Maybe it needs more work. I think your partition table is also very good and useful to implement