Guidance on sp9832e_1h10_gofu (Connected but receive 7e ver expected error)

[BenEdridge]

Hi there, great project.

I've attempted running spd_dump on Ubuntu 22.04 with configuration for a sp9832e_1h10_gofu device and using signed fdl1 and fdl2 obtained from a firmware dump but having issues.

I did the following:

1. Cloned and built the repo (Made sure to use libusb)
2. Ran spd_dump before boot mode
3. Removed charging cable
4. Held volume down and then inserted battery
5. Plugged charging cable back into device
6. Confirmed boot mode entered as below

usb 1-1: new full-speed USB device number 16 using xhci_hcd
usb 1-1: not running at top speed; connect to a high speed hub
usb 1-1: New USB device found, idVendor=1782, idProduct=4d00, bcdDevice=24.16
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1: Product: Gadget Serial
usb 1-1: Manufacturer: spreadtrum with musb-hdrc

When using spd_dump I get the following error:

./spd_dump \
	--verbose 2 \
	--wait 300 \
	keep_charge 1 \
	fdl fdl1-sign.bin 0x00005000 \
	fdl fdl2-sign.bin 0x9EFFFE00 \
	partition_list partition.xml \
	blk_size 0x2000 \
	read_part logo 0 8M logo.bmp \
	power_off
Waiting for connection (300s)
send (1):
7e                                               |~|
ver expected

This is similar to an issue raised earlier in: #2 but the differences is that 7e appears to be related to the HDLC_HEADER. So my assumptions are that I'd need to modify the communications to the device or perhaps build a custom fdl that suits the device?

Any suggestions or help would be much appreciated. Thanks.
I've also attached the BMA Configuration file obtained during a a flash.

sp9832e_1h10_xml.txt

[ilyakurdyukov]

This is the command sent to the phone:

send (1):
7e                                               |~|

spd_dump expects a version in response. But there's no answer.

[ilyakurdyukov]

Try running spd_dump first and then connecting the phone.

Please note that modprobe ftdi_sio method only works for feature phones. You need to build with libusb.

[CE1CECL]

I am suspecting an issue with FDL1, which well, I don't know, but how did you get the firmware? I cannot find it online anywhere. Either way, my FDL1 address is 0x5500 (notice the 2 fives not one), so if you are pulling a random FDL1, then I can try to build the FDL1 myself and send it to you with the modification. I do have the leaked BSP source code though I cannot re-share it online, to prevent me from getting DMCAs. However, if FDL1 source code is highly demanded I can try to send it out, but then again, DMCA.

[BenEdridge]

Thanks for the quick response. I've updated the description to provide additional details.

@ilyakurdyukov yes I was running spd_dump about 5-10 seconds before entering boot mode (which requires the battery to be removed and reinserted whilst holding the volume down key).

Perhaps I'll try some various combinations and timeouts. Do you have any suggestions?

@CE1CECL Original firmware was a paydroid file obtained from PAX and sent to me from a partner. I don't know much about the file type or format but I believe I was able to decrypt the file by attempting an update using the PAX PayDroid tool on Windows. This resulted in a temporary directory being extracted in AppData containing all files and an update to the device. I copied the temporary directory shown below and reviewed the firmware.

Original:

file PayDroid_8.1.0_Sagittarius_V11.1.56_20231107.paydroid
PayDroid_8.1.0_Sagittarius_V11.1.56_20231107.paydroid: RAR archive data, flags: EncryptedBlockHeader

$ file *
APV:                         ASCII text
boot.img:                    Android bootimg, kernel (0x8000), ramdisk (0x5400000), page size: 2048, cmdline (console=ttyS1,115200n8 buildvariant=user)
commit:                      ASCII text
fastboot_logo.bmp:           PC bitmap, Windows 3.x format, 480 x 320 x 24, image size 460800, resolution 2835 x 2835 px/m, cbSize 460854, bits offset 54
fdl1-sign.bin:               data
fdl2-sign.bin:               data
flash.cfg:                   ASCII text
logo.bmp:                    PC bitmap, Windows 3.x format, 480 x 320 x 24, image size 460800, resolution 2835 x 2835 px/m, cbSize 460854, bits offset 54
partition_SIG.bin:           data
PAX_Android_scatter_ppq.slp: ASCII text, with CRLF, LF line terminators
PAX_Android_scatter.txt:     ASCII text, with CRLF line terminators
PAX_SP_Monitor_SIG.bin:      data
persist.img:                 data
prodnv.img:                  Android sparse image, version: 1.0, Total of 1280 4096-byte output blocks in 10 input chunks.
recovery.img:                Android bootimg, kernel (0x8000), ramdisk (0x5400000), page size: 2048, cmdline (console=ttyS1,115200n8 buildvariant=user)
sml-sign.bin:                data
sp9832e_1h10.xml:            XML 1.0 document, ASCII text
system_SIG.img_sparse0:      Android sparse image, version: 1.0, Total of 384000 4096-byte output blocks in 141 input chunks.
system_SIG.img_sparse1:      Android sparse image, version: 1.0, Total of 384000 4096-byte output blocks in 507 input chunks.
system_SIG.img_sparse2:      Android sparse image, version: 1.0, Total of 384000 4096-byte output blocks in 602 input chunks.
system_SIG.img_sparse3:      Android sparse image, version: 1.0, Total of 384000 4096-byte output blocks in 314 input chunks.
system_SIG.img_sparse4:      Android sparse image, version: 1.0, Total of 384000 4096-byte output blocks in 148 input chunks.
system_SIG.img_sparse5:      Android sparse image, version: 1.0, Total of 384000 4096-byte output blocks in 240 input chunks.
system_SIG.img_sparse6:      Android sparse image, version: 1.0, Total of 384000 4096-byte output blocks in 202 input chunks.
tos-sign.bin:                data
u-boot-sign.bin:             data
u-boot-spl-16k-sign.bin:     data
vbmeta-sign.img:             data
vendor_SIG.img:              Android sparse image, version: 1.0, Total of 51200 4096-byte output blocks in 742 input chunks.

I have attached my original fdl1 and fdl2 from above and some of the interesting configuration files (flash.cfg, PAX_Android_scatter.txt) if you are interested.
I'm not sure I have enough experience to delve into the BSP source.

Regarding the FDL1 address I pulled this from the sp9832e_1h10.xml file attached. I tried both 0x5500 and 0x5000 both of which failed with the same error.

PayDroid_8.1.0_interesting_files.zip

[BenEdridge]

Update:

On further experimentation it appears I now have device connectivity by running adb reboot autodloader which rebooted the device into PAC AUTOLOADER MODE

I then used spd_dump and was able to further interact with the device. However, this may have removed the spl partition according to the comments in: TomKing062/CVE-2022-38694_unlock_bootloader#6 (comment) so perhaps created more work for me?

Running a similar command as before I get a lot more output but still receive an error as mentioned in the documentation already:

verbose 0:

Waiting for connection (300s)
BSL_REP_VER: "SPRD4:AutoD\0"
BSL_REP_VER: "SPRD4:AutoD\0"
FDL2: incompatible partition
unexpected response (0x00fe)

verbose 2:

<snip>

recv (8):
7e 00 80 00 00 ff 7f 7e                          |~......~|
send (8):
7e 00 03 00 00 ff fc 7e                          |~......~|
recv (8):
7e 00 80 00 00 ff 7f 7e                          |~......~|
send (8):
7e 00 04 00 00 ff fb 7e                          |~......~|
recv (16):
7e 00 96 00 08 01 00 00 00 01 00 00 00 fd 61 7e  |~.............a~|
FDL2: incompatible partition
send (8):
7e 00 2d 00 00 ff d2 7e                          |~.-....~|
recv (8):
7e 00 fe 00 00 ff 01 7e                          |~......~|
unexpected response (0x00fe)

[ilyakurdyukov]

0x2d means BSL_CMD_READ_PARTITION (this command lists partitions)
0xfe means BSL_REP_UNSUPPORTED_COMMAND

send (8):
7e 00 2d 00 00 ff d2 7e                          |~.-....~|
recv (8):
7e 00 fe 00 00 ff 01 7e                          |~......~|

Try other commands, your device may be too old and support fewer commands.

[BenEdridge]

Thanks @ilyakurdyukov that appeared to be the problem!

My device had issues with a number of commands (In this case it was partition_list).

I can now read:

./spd_dump --verbose 0 --wait 300 \
        fdl fdl1-sign.bin 0x00005000 \
        fdl fdl2-sign.bin 0x9EFFFE00 \
        read_part logo 0 5M logo.bmp \
        power_off
Waiting for connection (300s)
BSL_REP_VER: "SPRD4:AutoD\0"
BSL_REP_VER: "SPRD4:AutoD\0"
FDL2: incompatible partition
dump_partition: logo+0x0, target: 0x500000, read: 0x500000

Writing back the same logo.bmp from above seems to failed with a No Signature error on the device and a unexpected response (BSL_REP_OPERATION_FAILED) which appears to be related to the size of of the logo and possible padding/signatures 🤔

./spd_dump --verbose 0 --wait 300 \
        fdl fdl1-sign.bin 0x00005000 \
        fdl fdl2-sign.bin 0x9EFFFE00 \
        write_part logo logo.bmp \
        power_off
Waiting for connection (300s)
BSL_REP_VER: "SPRD4:AutoD\0"
BSL_REP_VER: "SPRD4:AutoD\0"
FDL2: incompatible partition
file size : 0x500000
Answer "yes" to confirm the "write partition" command: yes
unexpected response (0x0084)
load_partition: logo, target: 0x500000, written: 0x4ff000

However, taking another smaller signed image logo.bmp from an original firmware dump it writes and works as expected:

Waiting for connection (300s)
BSL_REP_VER: "SPRD4:AutoD\0"
BSL_REP_VER: "SPRD4:AutoD\0"
FDL2: incompatible partition
file size : 0x70952
Answer "yes" to confirm the "write partition" command: yes
load_partition: logo, target: 0x70952, written: 0x70952

My only challenge now is the vbmeta and signing bypass. Write appears to also fail when I write a magisk patched image.

[ilyakurdyukov]

You can try read_part user_partition 0 1M gpt.bin to get the raw partition table. Perhaps some of the sections that you are trying to rewrite don't exist, or they have different names, for example vbmeta_a and vbmeta_b instead of vbmeta. Don't forget to backup the original partitions.

[CE1CECL]

Do note that when you do the vbmeta bypass, you have to flash vbmeta first, before boot, else it will fail at the last sector

[BenEdridge]

Thanks @ilyakurdyukov my appears to not support the raw user_partition or something else is blocking it.

./spd_dump --verbose 0 --wait 300 \
        fdl fdl1-sign.bin 0x00005000 \
        fdl fdl2-sign.bin 0x9EFFFE00 \
        read_part user_partition 0 1M gpt.bin
Waiting for connection (300s)
BSL_REP_VER: "SPRD4:AutoD\0"
BSL_REP_VER: "SPRD4:AutoD\0"
FDL2: incompatible partition
unexpected response (0x0084)
dump_partition: user_partition+0x0, target: 0x100000, read: 0x0

I do however have access to the vbmeta partition but when I attempt what @CE1CECL suggested by flashing vbmeta I appear to get issues with signature verification of the vbmeta image itself. Flashing a single modified and signed vbmeta results in the last sector failing.

I guess it sounds like I need to work on getting this working for my device: TomKing062/CVE-2022-38694_unlock_bootloader#39

[CE1CECL]

Thanks @ilyakurdyukov my appears to not support the raw user_partition or something else is blocking it.

./spd_dump --verbose 0 --wait 300 \
        fdl fdl1-sign.bin 0x00005000 \
        fdl fdl2-sign.bin 0x9EFFFE00 \
        read_part user_partition 0 1M gpt.bin
Waiting for connection (300s)
BSL_REP_VER: "SPRD4:AutoD\0"
BSL_REP_VER: "SPRD4:AutoD\0"
FDL2: incompatible partition
unexpected response (0x0084)
dump_partition: user_partition+0x0, target: 0x100000, read: 0x0

I do however have access to the vbmeta partition but when I attempt what @CE1CECL suggested by flashing vbmeta I appear to get issues with signature verification of the vbmeta image itself. Flashing a single modified and signed vbmeta results in the last sector failing.

I guess it sounds like I need to work on getting this working for my device: TomKing062/CVE-2022-38694_unlock_bootloader#39

can you send your stock vbmeta an your attempted modified version?

[BenEdridge]

Sure, I followed the guide from: https://www.hovatek.com/forum/thread-32664.html with a basic script and some minor padding modifications. I've attempted both with and without flags (--flag 2).

#!/bin/sh

# Generate initial image
python3 ./avbtool-master.py make_vbmeta_image \
--internal_release_string 'avbtool 1.0.0' \
--algorithm SHA256_RSA2048 \
--key rsa2048_vbmeta.pem  \
--chain_partition boot:1:keys/rsa2048_vbmeta.bin \
--chain_partition recovery:2:keys/recovery_key.bin \
--chain_partition system:3:keys/system_key.bin \
--chain_partition vendor:4:keys/vendor_key.bin \
--chain_partition l_modem:5:keys/l_modem_key.bin \
--chain_partition l_ldsp:6:keys/l_ldsp_key.bin \
--chain_partition l_gdsp:7:keys/l_gdsp_key.bin \
--chain_partition pm_sys:8:keys/pm_sys_key.bin \
--chain_partition wcnmodem:9:keys/wcnmodem_key.bin \
--chain_partition gpsgl:10:keys/gpsgl_key.bin \
--chain_partition gpsbd:11:keys/l_gdsp_key.bin \
--output vbmeta-sign-custom.img \
--padding_size 8192

# Add padding to match original img
python3 ./vbmeta_pad.py

There are two stock files (One from using sprd_dump and the other extracted from the PayDroid_8.1.0_Sagittarius_V11.1.56_20231107 firmware archive file, they differ in padding only). Stock vbmeta consists of a DHTB header, padding and a signature I believe.

Using python3 ./avbtool.py info_image I can see the image is signed with SHA256_RSA2048.

I have attached stock, modified and the scripts I used in a vbmeta.zip file.

[CE1CECL]

Ill try to do it when i can but im having myself trying to reproduce it on my device, trying to flash back a full emmc backup with nothing but problems:

BSL_REP_VER: "SPRD3\0"
BSL_REP_VER: "Spreadtrum Boot Block version 1.1\0"
FDL2: incompatible partition
[0] prodnv, 10
[1] miscdata, 1
[2] recovery, 35
[3] misc, 1
[4] trustos, 6
[5] trustos_bak, 6
[6] sml, 1
[7] sml_bak, 1
[8] uboot, 1
[9] uboot_bak, 1
[10] uboot_log, 4
[11] logo, 4
[12] fbootlogo, 4
[13] l_fixnv1, 1
[14] l_fixnv2, 1
[15] l_runtimenv1, 1
[16] l_runtimenv2, 1
[17] gpsgl, 1
[18] gpsbd, 1
[19] wcnmodem, 10
[20] persist, 2
[21] l_modem, 25
[22] l_deltanv, 1
[23] l_gdsp, 10
[24] l_ldsp, 20
[25] pm_sys, 1
[26] boot, 35
[27] dtbo, 8
[28] super, 2700
[29] cache, 150
[30] socko, 75
[31] odmko, 25
[32] vbmeta, 1
[33] vbmeta_bak, 1
[34] sysdumpdb, 10
[35] metadata, 16
[36] vbmeta_system, 1
[37] vbmeta_vendor, 1
[38] UDC_config, 8
[39] userdata, -1
Answer "yes" to confirm the "repartition" command: file size : 0x3ff000
Answer "yes" to confirm the "write partition" command: load_partition: splloader, target: 0x3ff000, written: 0x3ff000
file size : 0x3ff000
Answer "yes" to confirm the "write partition" command: load_partition: splloader_bak, target: 0x3ff000, written: 0x3ff000
file size : 0x3a5c00000
Answer "yes" to confirm the "write partition" command: unexpected response (0x00a2)
load_partition: user_partition, target: 0x3a5c00000, written: 0x10000000
unexpected response (0x00a2)
root@HP-PAVILION-590:~/spreadtrum_flash# cat d.sh 
( ( clear ) && ( ( yes yes ) | "./spd_dump" keep_charge 1 fdl "fdl1.bin" 0x00005000 fdl "fdl2.bin" 0x9EFFFE00 repartition partitions.xml write_part splloader splloader.bin write_part splloader_bak splloader_bak.bin write_part user_partition user_partition.bin power_off ) )
root@HP-PAVILION-590:~/spreadtrum_flash# 

Cannot figure out what 0xa2 exactly is, anyone know?

[CE1CECL]

@BenEdridge I think I found your issue was with the python vb pad file that you had: https://github.com/CE1CECL/VBHelp/

[BenEdridge]

Sorry late reply. Thanks for looking @CE1CECL
I attempted to make use of your provided files to generate images and it still didn't work as expected.

I feel like perhaps I'm doing things the wrong way adb reboot autodloader which then presents itself as BSL_REP_VER: "SPRD4:AutoD\0"

From above I can see you have BSL_REP_VER: "SPRD3\0" so it looks like we are already doing a slightly different process.

It seems the key combination to enter "SPRD3" is incorrect or somehow this functionality is disabled.

What keys do you use?

[CE1CECL]

Sorry late reply. Thanks for looking @CE1CECL I attempted to make use of your provided files to generate images and it still didn't work as expected.

I feel like perhaps I'm doing things the wrong way adb reboot autodloader which then presents itself as BSL_REP_VER: "SPRD4:AutoD\0"

From above I can see you have BSL_REP_VER: "SPRD3\0" so it looks like we are already doing a slightly different process.

It seems the key combination to enter "SPRD3" is incorrect or somehow this functionality is disabled.

What keys do you use?

I held down the volume down key, but it if i delete splloader & splloader_bak, it auto enters the same mode (it works better with battery removed but it didnt matter.)