Closed dsfusetrjdsfllkzek closed 3 weeks ago
i think that is a bug in unisoc's uboot/lk code, some digest/hash are not updated after boot changed first try: fastboot flash vbmeta(_a/_b) after fastboot flash boot (_a/_b) if not work: erase userdata
Hi thanks for your comment. I tried the following :
vbmeta_a
partition using vbmeta-sign.img
from original PAC file. Same for vbmeta_system.img
/vbmeta_system_a
and all other vbmeta_...
partitions.userdata
partition using userdata.img
from original PAC file (to erase userdata since I have no access to recovery mode when in bootloops)However it is still in bootloop. Do I need a modified vbmeta.img
instead of the original one ? Did you have success with this method ?
Thanks in advance !
Hi thanks for your comment. I tried the following :
- Flashing
vbmeta_a
partition usingvbmeta-sign.img
from original PAC file. Same forvbmeta_system.img
/vbmeta_system_a
and all othervbmeta_...
partitions.- Flashing
userdata
partition usinguserdata.img
from original PAC file (to erase userdata since I have no access to recovery mode when in bootloops)However it is still in bootloop. Do I need a modified
vbmeta.img
instead of the original one ? Did you have success with this method ?Thanks in advance !
Hey, how do you get into fastboot when it bootloops? In my case I need to execute the bootloader unlocker script to get into it since I have no way to turn off the device.
Hi thanks for your comment. I tried the following :
- Flashing
vbmeta_a
partition usingvbmeta-sign.img
from original PAC file. Same forvbmeta_system.img
/vbmeta_system_a
and all othervbmeta_...
partitions.- Flashing
userdata
partition usinguserdata.img
from original PAC file (to erase userdata since I have no access to recovery mode when in bootloops)However it is still in bootloop. Do I need a modified
vbmeta.img
instead of the original one ? Did you have success with this method ? Thanks in advance !Hey, how do you get into fastboot when it bootloops? In my case I need to execute the bootloader unlocker script to get into it since I have no way to turn off the device.
Hey, I don't go into fastboot mode when bootloop, I can't either. What I tried is the following :
boot.img
, then go into fastboot using adb reboot fastboot
, then :
fastboot flash boot_a magisk_boot.img
fastboot flash boot_b magisk_boot.img
fastboot flash vbmeta_a vbmeta-sign.img # The vbmeta-sign.img from PAC file fastboot flash vbmeta_b vbmeta-sign.img
However none of this worked, I still get bootloop
- Another thing I tried is flashing `boot_a` using magisk_boot.img, vbmeta partitions, and userdata partition all at the same time using `ResearchDownload R22.19.1301` (by pressing Volume DOWN when phone is power off and when pulgging in the USB cable)
But again, none of this worked and I still can't get a rooted device even though the bootloader is unlocked.
@TomKing062 any other suggestion on that ?
have no idea, maybe change magisk version
Yeah, I still get the bootloop too, I flashed the SIGNED magisk_boot.img and the vbmeta-sign.img file in all the a/b partitions, but nothing of this worked.
I was able to flash magisk on another brand using this exploit but unable to make it work on the Realme C35 RMX3511. When no bootloops, we can clearly see the 2 following messages :
LOCK FLAG IS : UNLOCK!!!
WARNING: LOCK FLAG IS : UNLOCK, SKIP VERIFY!
However, when the phone bootloops, we can only see the first message, then it bootloops :
LOCK FLAG IS : UNLOCK!!!
These messages are printed during the second stage FDL2(uboot) if I understood correctly. Isn't there a way to patch FDL2 in order to prevent the bootloop ? Do you think it is possible @TomKing062 ?
I think the problem is the Android Verified Boot (the one responsible for making us have to sign the patched boot.img), if it wasn't, we could just flash the unsigned .img file, so, could there be a way to disable AVB?, so we can skip this verification.
I saw a couple of guides on hovatek on how to disable Android Secure Boot, and after reading I think I have a possible solution.
1.- Download AVBtool
2.- Download rsa4096_vbmeta.pem, thanks @TomKing062.
3.- Create a blank vbmeta.img with
python2 avbtool make_vbmeta_image --key rsa4096_vbmeta.pem --padding_size 16384 --output vbmeta-blank-signed.img
4.- Flash this file on our Android with fastboot flash vbmeta vbmeta-blank-signed.img
.
5.- Flash the UNSIGNED patched boot.img file.
Note: I haven't been able to test this solution on my own since at the moment I can't afford to format my Android, if anyone wants to try it, go ahead!.
fastboot --disable-verity flash vbmeta vbmeta.img
this disable dm-verity
but i don't think this affect boot check process
own-signed vbmeta will not work
fastboot --disable-verity flash vbmeta vbmeta.img
this disable dm-verity but i don't think this affect boot check processown-signed vbmeta will not work
Are you sure that with the flag --disable-verity the device will not enter in a bootloop? And why the signed vbmeta will not work? I mean, it should, isn't?
--disable-verity works on android 11 zte voyage 30s (ums9620) --disable-verification cause bootloop on alldocube android 11 (ums512)
sign boot is uboot/lk check sign status but not check signer after unlock ubook/lk will always check vbmeta signed by exactly same key as manufacturer and realme use their own key while most alldocube devices use unisoc keys
fastboot --disable-verity flash vbmeta vbmeta.img
this disable dm-verity but i don't think this affect boot check processown-signed vbmeta will not work
@dsfusetrjdsfllkzek Can you try?
sign boot is uboot/lk check sign status but not check signer after unlock ubook/lk will always check vbmeta signed by exactly same key as manufacturer and realme use their own key while most alldocube devices use unisoc keys
Ah, I see, so, the private keys you have in your GitHub are only for those devices that use the "default" keys, right?
I did some tests.
First, I reflashed original boot.img
etc to get into NON-bootloop state, then I tried the following :
adb reboot fastboot
fastboot flash vbmeta_a vbmeta-sign.img
fastboot flash vbmeta_b vbmeta-sign.img
Simply doing this causes the device to bootloop, however not at the same place, it now passes the 2 warning messages, but after showing the realme logo for like 30 seconds, it will shutdown. It's pretty weird that simply reflashing vbmeta create (another kind of) bootloop
Same results with :
fastboot --disable-verity flash vbmeta vbmeta-sign.img
However, if I do :
fastboot flash vbmeta vbmeta-sign.img
Then without restarting now, going to recovery and factory reset does not causes a bootloop after logo. (I'm am still testing with original boot.img
so not rooted).
Same for :
fastboot --disable-verity flash vbmeta vbmeta-sign.img
Doing the following causes bootloops (the quick one, with only one warning message), even with factory reset :
fastboot --disable-verity --disable-verification flash vbmeta vbmeta-sign.img
We have the same issue but on RMX3581(Realme C30) phone. We've tried to flash signed patched boot, flash custom vbmeta, blank vbmeta but none of them worked. I'll attach an uboot_log, also I've checked this log but I didn't find out why it rejects custom signed boot
Hi @RadGoodNowYT, thanks for the logs! How did you get them ?
Also, do you have a log where it boots correctly (with original boot.img) ? Checking where it differs may help finding the problem.
Hi @RadGoodNowYT, thanks for the logs! How did you get them ?
adb pull /dev/block/by-name/uboot_log
Ok thks! I pulled the logs from another device (not Realme) that is unlocked with this exploit and do not bootloop when flashing a rooted boot.img. I first noticed the following :
[00003384] allow_verification_error is 1
[00007017] allow_verification_error is 0
Don't know if it is important but I noticed that so I put it here
@RadGoodNowYT how did you get the logs if the device is in bootloop ? Does your logs come from a device that is booting or bootlooping ?
@RadGoodNowYT how did you get the logs if the device is in bootloop ? Does your logs come from a device that is booting or bootlooping ?
via rooted GSI
try change between slot a and b, and may still need to wipe data
попробуйте переключиться между слотами a и b, и, возможно, все равно придется стереть данные
Hello, how to do this? Just if you can change the files in partition a and b this solved 1 problem on my device Realme 8i Maybe it will be possible to solve this problem on this device, what do you think?
Hi, I flashed boot_magisk.img, it works. I used RMX3511_13.F67 stock ROM -> Got root I used RMX3511_13.F.54_20230831010317 stock ROM -> Got root
Hi, I flashed boot_magisk.img, it works. I used RMX3511_13.F67 stock ROM -> Got root I used RMX3511_13.F.54_20230831010317 stock ROM -> Got root
Hi, can you explain how you able to get root on your devices? do you have realme signature.pem to sign the boot?
Well, if anyone stumbling across this. I finally able to root my device. Just flash patched boot to boot_a without flashing any vbmeta partition.
When booting the phone (Realme RMX3511 Android 11, board
ums9230_nico
), I have the following message :So the bootloader seems unlocked. However when I take the boot.img from PAC file, send it to phone, patch it with magisk app, flash it back (using either fastboot or ResearchDownload R22.19.1301), the phone bootloops. The only way to get it working again is to flash the original boot.img from PAC file. I tried the different methods in the wiki get Magisk, but it always ends with the phone bootlooping.
Any idea ?
Thanks for the work done by the way !