How to enter and re-enter download mode (a5 pro cc) about cve-2022-38694_unlock_bootloader HOT 41 CLOSED

a simple way
adb reboot autodloader
it will wipe splloader and go to fallback download
install libusb driver and change exec_addr to 0x3ee8

from cve-2022-38694_unlock_bootloader.

So far it seems to have frozen my phone. Is that normal while it's doing the wipe? Also, where will I change the exec_addr value once the driver is installed? I'm brand new to rooting, so apologies if these are typically simple questions.

Edit: Phone remains unresponsive, even to a hard reboot. Now what?

from cve-2022-38694_unlock_bootloader.

zadig

hard reset by key combination 10 second

from cve-2022-38694_unlock_bootloader.

The key combination isn't working right now. :/

from cve-2022-38694_unlock_bootloader.

it reset from download to download
phone won't boot until splloader write back to device

from cve-2022-38694_unlock_bootloader.

How do I write splloader back onto it, then? Since it's powered off, MTP is currently disabled and my computer can't find the phone.

Edit: Tried plugging it into another phone as well, but it had no reaction. They're not even trying to charge each other.

from cve-2022-38694_unlock_bootloader.

that is why i don't use autodloader

zadig - list all devices - find 1782 4d00

from cve-2022-38694_unlock_bootloader.

Found it. Which driver should I install, libusb-win32 or libusbK?

from cve-2022-38694_unlock_bootloader.

I've tried all four options, and none of them seem to do anything for the phone, despite saying successful installation. The only thing I've noticed is that the phone briefly disappears from Zadig if I attempt to reboot the phone with its buttons. It seems to be doing something, I just don't know what it is.

from cve-2022-38694_unlock_bootloader.

Here's my log file from installing the libusbK driver, if it helps. USB ID is 1782 4d00, as expected. Still haven't found where to change exec_addr to 0x3ee8, though.
Zadig.log

from cve-2022-38694_unlock_bootloader.

readme.txt in tool folder, 3 command

from cve-2022-38694_unlock_bootloader.

Cool, got that updated. Only the first one needed to be changed, it seems. Do I need to run something now?

spd_dump exec_addr 0x3ee8 fdl fdl1-dl.bin 0x5500 fdl uboot-mod.bin 0x9efffe00 exec write_part uboot uboot-mod.bin erase_part splloader reset

spd_dump exec_addr 0x3ee8 fdl spl-custom.bin 0x5500

spd_dump exec_addr 0x3ee8 fdl fdl1-dl.bin 0x5500 fdl uboot-mod.bin 0x9efffe00 exec write_part uboot uboot.bin write_part splloader spl.bin timeout 100000 write_part userdata userdata.bin reset

from cve-2022-38694_unlock_bootloader.

run one by one or rename .txt to .bat, double click

from cve-2022-38694_unlock_bootloader.

Tried the .bat method, but it doesn't seem to have done much. Seems to have gotten stuck in a loop on the first command. Here's the results.

libusb_control_transfer_ok
CHECK_BAUD FAIL
CHECK_BAUD FAIL
CHECK_BAUD FAIL
...

from cve-2022-38694_unlock_bootloader.

Also tried it with the WinUSB driver installed, same results.

from cve-2022-38694_unlock_bootloader.

use power+up 10s to reset

from cve-2022-38694_unlock_bootloader.

The key combination reset is still not working, though it does enough to make Zadig deselect it.

from cve-2022-38694_unlock_bootloader.

As far as I can tell, it's a hard brick, not a soft brick, but Zadig's reaction is giving me hope that it's still recoverable somehow.

from cve-2022-38694_unlock_bootloader.

with working FDL1 and FDL2, there is no hard brick on unisoc

driver ok, tool ok, reboot and execute command

from cve-2022-38694_unlock_bootloader.

To clarify, I should reboot my computer and then run the .bat file again, or do I need to do anything with FDL1 and FDL2 somewhere as well?

Edit: Seems like the reboot is working so far, it's at least getting further than before.

from cve-2022-38694_unlock_bootloader.

It got stuck waiting for a connection on the third command, eventually closed itself out, and now it's back to the same loop as before.

from cve-2022-38694_unlock_bootloader.

my fault, reuploaded zip,(mistake a byte in uboot-mod)

reboot phone, execute all command again

from cve-2022-38694_unlock_bootloader.

Okay, reinstalled the package and ran things again after changing the first line to 0x3ee8. The .bat file seems to be running properly now, but it hasn't done anything noticeable to the phone. Still can't reboot it. Just to clarify, which driver should I be using, or does it matter? My options are WinUSB, libusb-win32, libusbK, and USB Serial. Thanks again for the help!

from cve-2022-38694_unlock_bootloader.

Also, not sure if this helps to narrow down the issue or not, but if I attempt to run the spd_dump.exe file, it begins to give me the recurring CHECK_BAUD FAIL message, and after that, the .bat file commands all do the same until I reboot.

from cve-2022-38694_unlock_bootloader.

power up down is 3f48
power up is 3ee8
driver use libusbk on win10+, winusb on win7

from cve-2022-38694_unlock_bootloader.

Okay, cool, I'm currently using the libusbK driver. Rebooting with power and up doesn't work, and neither does power, up, and down. Am I missing something there?

I may have also started in the middle of the process by accident, since again, I'm brand new to rooting devices. I started by trying to follow the steps under the Drivers tab, and I'm still not sure if I need to follow all the steps in all the tabs, or only certain ones that vary based on the method I'm using. What steps should I have already finished before trying to do this part?

from cve-2022-38694_unlock_bootloader.

the first and second command do the unlock
the third will recover device and wipe userdata
although command are different, #5 shows a successful process

phone won't boot until splloader write back to device

you said device deselect in zadig , that is exactly a reboot, don't expect device screen lightup

from cve-2022-38694_unlock_bootloader.

Okay, here's my log history for each command then, since they look a bit different compared to the logs in issue #5.
I assume the unexpected response (0xffffffff) line in the first command is where things are breaking.
ReadmeBat.log

And I'm glad to hear the device is theoretically operating as expected, since I thought we broke something.

To clarify, are these the five commands you're referring to? If so, which file are you editing there?

from cve-2022-38694_unlock_bootloader.

unexpected response seems not my part, maybe change usb cable and port.

yes, the guide is spl method, i compiled binaries directly for a5p(cc).

from cve-2022-38694_unlock_bootloader.

Ah, I think I found part of my issue. When I reinstalled the tool folder after you updated it, I didn't re-add the chsize and spd_dump files. For what it's worth, I installed the Ubuntu terminal on my Windows 10 laptop in order to run the commands on the home page. I wouldn't expect that to cause any issues, but it's possible that something went wrong there. It's also still throwing the same unexpected response with a new cord and port, even after adding those files back in, so there seems to be something else going on as well.

Also, would those commands act as a replacement to manually editing the compiler with spreadtrum? I haven't figured out the compiler stuff yet at all, so I just wanted to confirm whether I need to or not.

from cve-2022-38694_unlock_bootloader.

Hmm, it looks like the Ubuntu commands might not have worked properly. Checking out the spd_dump file, (converted to .txt so I could upload it), and while much of it is illegible, the parts that are human readable seem to indicate an error in the make. Gonna try to build it again and see if it does any better.
spd_dump.txt

from cve-2022-38694_unlock_bootloader.

spd_dump exec_addr 0x3ee8 fdl fdl1-dl.bin 0x5500 fdl uboot-mod.bin 0x9efffe00 exec write_part uboot uboot.bin write_part splloader spl.bin reset

3rd command without wipe data
curious about result

ubuntu way works on native installation and VMware

from cve-2022-38694_unlock_bootloader.

Here's the full result:

C:\Users\tdumm\Downloads\hisense_a5procc_spl>spd_dump exec_addr 0x3ee8 fdl fdl1-dl.bin 0x5500 fdl uboot-mod.bin 0x9efffe00 exec write_part uboot uboot.bin write_part splloader spl.bin reset
libusb_control_transfer ok
CHECK_BAUD bootrom
BSL_REP_VER: "SPRD3\0"
CMD_CONNECT bootrom
current exec_addr is 0x3ee8
SEND FDL1
EXEC FDL1
CHECK_BAUD FAIL
CHECK_BAUD FDL1
BSL_REP_VER: "Spreadtrum Boot Block version 1.1\0"
CMD_CONNECT FDL1
KEEP_CHARGE FDL1
SEND uboot-mod.bin
FDL2: incompatible partition
EXEC FDL2
file size : 0x9c7f4
Answer "yes" to confirm the "write partition" command: yes
unexpected response (0xffffffff)
load_partition: uboot, target: 0x9c7f4, written: 0x9c000
file size : 0xefe4
Answer "yes" to confirm the "write partition" command: yes
load_partition: splloader, target: 0xefe4, written: 0xefe4

from cve-2022-38694_unlock_bootloader.

Update: The phone is booting now? I've got the Vision OS screen and a backlight on. Translation says it's clearing, so I'm guessing it's doing a factory reset. Progress!

Edit: Yep, it just booted up and it's showing the initial setup steps. Neat.

from cve-2022-38694_unlock_bootloader.

seems uboot still has some check not disabled

Answer "yes" to confirm the "write partition" command: yes
load_partition: splloader, target: 0xefe4, written: 0xefe4

wrote spl back
though i think phone is not unlocked yet

from cve-2022-38694_unlock_bootloader.

I'm guessing that's due to the Ubuntu method I was attempting earlier. It saved the files in a different spot entirely, so I'm redoing that now.

from cve-2022-38694_unlock_bootloader.

Hmm, maybe not. Deleted and recreated the folder, copied the whole folder to my normal directory, and moved the two files into the hisense_a5procc_spl folder, then ran the first command. Now that the phone is working again, I tried it with both 0x3ee8 and 0x3f88 just to confirm, but in both cases, it timed out waiting for connection.

from cve-2022-38694_unlock_bootloader.

So, instead of running the Ubuntu commands, what would be the alternate method to create those spd_dump and chsize files?

from cve-2022-38694_unlock_bootloader.

Or maybe it is unlocked, actually. I went to toggle on the OEM Unlocking setting again, and it says Bootloader is already unlocked while showing itself toggled on. Is that what I'm looking for?

from cve-2022-38694_unlock_bootloader.

congratulation
i will upload fdl1 method as fallback for a5procc later

from cve-2022-38694_unlock_bootloader.

Now I'm stuck trying to get Magisk to work. I tried running the first command from the same cmd location at .../hisense_a5procc_spl to get the boot.img file, but it just timed out waiting for connection again.

from cve-2022-38694_unlock_bootloader.