ilyakurdyukov / spreadtrum_flash Goto Github PK

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

Hi there!

I am trying to dump the firmware of an Alcatel 2053, which has the SC6531E.
So, when I tried to find the boot key, I tried the asterisk. The charging message wouldn't display until I stop holding. And it also didn't work.
Is this a sign that I'm getting very close to finding the boot key? My current assumption is that it's a combination with the asterisk and another button.

Hello,when i use this tools to get the system.img from a UD 710 devices , it reported: bad length<8191,expected 12294> on my computer,what should i do

Видел на хабре вашу статью. По ссылке есть даташит на чип, из интересного - в нем кроме ARM9 имеется еще микроконтроллер Cortex-M4, что может быть полезным дополнением для графики.
https://datasheetspdf.com/pdf-file/1455703/Spreadtrum/SC6531E/1

I tried running this on Energizer Energy E12 (which has a Spreadtrum SC6531E according to the specifications). and I got ver expected as an output.
The output seems to be from this ERR_EXIT.
Does this mean that the chipset in the specification page is not the correct one ?
If I understand correctly, this error message is printed if the data received is not in the correct format ?

I should note that I didn't try any other firmware dumper other than this. I will comment here if I ever did.

This is not an issue, just a hint, that you can force bootloader mode by using USB OTG cable (MicroUSB pin 5 is shorted to the ground).

I use USB-OTG adapter (USB-A female to MicroUSB), with USB-A-male to USB-A-male cable. It works much more reliable for 6531E than finding a boot key.

https://github.com/ilyakurdyukov/spreadtrum_flash/blob/6886a85e6e9d80a5e02d8c9afd1c991b20a36b35/spd_dump.c#LL826C2-L826C2

now the packet end with userdata size ff ff ff 7f (BSL_REP_OPERATION_FAILED, 0x84)

add if(size == 2147483647) size = -1; before WRITE32_LE(buf + 0x48, size);

then the packet end with userdata size ff ff ff ff (repartition successfully)

Keep waiting and can't detect SPRD U2S Diag device in windows 11

BSL_REP_VER: "SPRD3\0"
BSL_REP_VER: "Spreadtrum Boot Block version 1.1\0"
FDL2: incompatible partition
file size : 0x100000
Answer "yes" to confirm the "write partition" command: load_partition: vbmeta, target: 0x100000, written: 0x100000
file size : 0x100000
Answer "yes" to confirm the "write partition" command: load_partition: vbmeta_bak, target: 0x100000, written: 0x100000
file size : 0x100000
Answer "yes" to confirm the "write partition" command: load_partition: vbmeta_system, target: 0x100000, written: 0x100000
file size : 0x100000
Answer "yes" to confirm the "write partition" command: load_partition: vbmeta_vendor, target: 0x100000, written: 0x100000
file size : 0x2300000
Answer "yes" to confirm the "write partition" command: load_partition: boot, target: 0x2300000, written: 0x2300000
file size : 0x2300000
Answer "yes" to confirm the "write partition" command: load_partition: recovery, target: 0x2300000, written: 0x2300000
file size : 0xa8c00000
Answer "yes" to confirm the "write partition" command: unexpected response (0xffffffff)
load_partition: super, target: 0xa8c00000, written: 0x2cec6000
root@LenovoLegionT5:/m/e/VBMetaKeysExtractor/VBMetaKeysExtractor# cat xtx.xtx 
( ( clear ) && ( ( yes yes ) | "./spd_dump" verbose 0 keep_charge 1 fdl "fdl.bin" 0x00005000 fdl "uboot.bin" 0x9EFFFE00 write_part vbmeta "vbmeta.nib" write_part vbmeta_bak "vbmeta_bak.nib" write_part vbmeta_system "vbmeta_system.nib" write_part vbmeta_vendor "vbmeta_vendor.nib" write_part boot "boot.nib" write_part recovery "recovery.nib" write_part super "super.nib" reset ) )
root@LenovoLegionT5:/m/e/VBMetaKeysExtractor/VBMetaKeysExtractor# ./xtx.xtx 

However, writing a blank 00 image works, the log for verbose 2 turned out to be 3.4GB, (it seems from the log verbose 2 it wants more data than sent before a "data section done" command or other), here is verbose 1's log:
verbose1.txt