Emui 9 possible root method need input on if it might work - Huawei Mate 20 X Questions & Answers

So in emui 9 there is no ramdisk.img file so everyone says no root. I dont want to write 30 pages so ima make it short. I was wondering that since ramdisk.img files are intergrated into system.img i could extract these files and repack into a ramdisk.img file then patch boot image e.g ramdisk.img with magisk, then upack patched ramdisk.img into sub files like init.rc etc. And repack into the system.img and flash that? Will this cause issues with dm_verity.

I heard there's more mechanism built in right now into the rom package and the hardware to make sure that the rom size is not altered and the correct region is being flashed on. So to counter all these require additional files and counter flags to be set.
I remembered hikvision cctv also has this mechanism builtin but it can be overwritten via telnet and changing a flag in hex.
So I guess if someone looks hard enough, maybe we can have unlocked bootloader, root, etc until the next Mate 30 comes along in a year's time.

Related

[Q] Modifying init.rc

I'm looking to modify my init.rc file. I've able to dump the boot.img with a straight dd from mmcblk0p7 and double checked it with the backup from CWM. I've been using the bootimg-tools (extractboot and packboot) and can successfully extract the boot.img down to modify the actual init.rc file. However when I pack the new boot.img back up and dump it onto the phone it gets into a reboot cycle. At this point I'm simply unpacking and repacking the original, no modifications to any files, and it is still unable to boot. I'm also aware that this exact method has worked for my Motorola Atrix and Nexus One. Is there something different that I need to be doing on the GS3?

[GUIDE] Recovering from a magisk bootloop without twrp

Just to add my experience here, I flashed MARS_SOM magisk rom module which entered a seemingly unrecoverable endless bootloop. This was likely as it conflicted with another magisk module or xposed that I have installed, so not the fault of the rom!
However given we've no twrp yet, the best way (after a LOT of research!) to fix this wasn't easy or obvious. I thought I could just flash stock kernel, uninstall magisk, flash magisk again and uninstall the module. Which unfortunately you can't as they remain in the system files and without root, you can't touch them, though with root, it loads and you get the bootloop - so a vicious endless cycle!
The solution I managed to work out, rather than a full clean wipe was to extract the stock boot from downloaded firmware (using Xperifirm), convert it to an img file using UnSIN, use to unpack, place a certain folder in there (found via the link below), repack and then fastboot flash. This makes magisk operate in core root mode only allowing you to uninstall the module. Once the module is uninstalled, you can simply disable core only mode from the magisk settings.
This saved me from a full wipe!
See here for more details about that unpacking the img, copying a folder etc see here:
https://forum.xda-developers.com/pi...modules-disabler-booting-magisk-t3976621/amp/
This worked for me and so hope it helps someone out too!
cd993 said:
Just to add my experience here, I flashed MARS_SOM magisk rom module which entered a seemingly unrecoverable endless bootloop. This was likely as it conflicted with another magisk module or xposed that I have installed, so not the fault of the rom!
However given we've no twrp yet, the best way (after a LOT of research!) to fix this wasn't easy or obvious. I thought I could just flash stock kernel, uninstall magisk, flash magisk again and uninstall the module. Which unfortunately you can't as they remain in the system files and without root, you can't touch them, though with root, it loads and you get the bootloop - so a vicious endless cycle!
The solution I managed to work out, rather than a full clean wipe was to extract the stock boot from downloaded firmware (using Xperifirm), convert it to an img file using UnSIN, use to unpack, place a certain folder in there (found via the link below), repack and then fastboot flash. This makes magisk operate in core root mode only allowing you to uninstall the module. Once the module is uninstalled, you can simply disable core only mode from the magisk settings.
This saved me from a full wipe!
See here for more details about that unpacking the img, copying a folder etc see here:
https://forum.xda-developers.com/pi...modules-disabler-booting-magisk-t3976621/amp/
This worked for me and so hope it helps someone out too!
Click to expand...
Click to collapse
With Unsin (on windows at least) you can just drag your file over the cmd without having to mess with command lines
AJHutchinson said:
With Unsin (on windows at least) you can just drag your file over the cmd without having to mess with command lines
Click to expand...
Click to collapse
Yeah that's a handy little feature, makes converting it super simple!
cd993 said:
Just to add my experience here, I flashed MARS_SOM magisk rom module which entered a seemingly unrecoverable endless bootloop. This was likely as it conflicted with another magisk module or xposed that I have installed, so not the fault of the rom!
However given we've no twrp yet, the best way (after a LOT of research!) to fix this wasn't easy or obvious. I thought I could just flash stock kernel, uninstall magisk, flash magisk again and uninstall the module. Which unfortunately you can't as they remain in the system files and without root, you can't touch them, though with root, it loads and you get the bootloop - so a vicious endless cycle!
The solution I managed to work out, rather than a full clean wipe was to extract the stock boot from downloaded firmware (using Xperifirm), convert it to an img file using UnSIN, use to unpack, place a certain folder in there (found via the link below), repack and then fastboot flash. This makes magisk operate in core root mode only allowing you to uninstall the module. Once the module is uninstalled, you can simply disable core only mode from the magisk settings.
This saved me from a full wipe!
See here for more details about that unpacking the img, copying a folder etc see here:
https://forum.xda-developers.com/pi...modules-disabler-booting-magisk-t3976621/amp/
This worked for me and so hope it helps someone out too!
Click to expand...
Click to collapse
Hi there; I was in the same situation, flashing a corrupted magisk boot image from standard firmware for XQ-AT51, provided by same author for simple rooting Xperia 1 II; my phone was without xposed, it was in clean factory state. the magisk boot image was taken from another thread "[ROOT] Magisk patched Boot Images & Instructions" designated for rooting of Xperia 1 II;
unfortunately is the same author who build your ROM, he delivered also corrupted magisk image.
It was not enter in bootloop if you flash only one image on phone, not both; his instructions are wrong. the correct flashing instruction is below, at end of my comment.
I solved in smilar way like you: using flashtool to obtain XQ-AT51 ftf file: XQ-AT51_58.0.A.3.39_1321-7706_R13A.ftf;
Attention: the name of file depends of region firmware you want to flash and type of phone (single or dual sim); the given names are with title of example.
Then from download folder of flashtool form your disk C:\Users\username\.flashTool\firmwares\Downloads (username is your username on pc); check for file: boot_X-FLASH-ALL-2389.sin ( applicable for XQ-AT51) and convert the file to .img using unsin; check on xda for unsin, extract unsin archive in exe file and then drag & drop over unsin.exe the file boot_X-FLASH-ALL-2389.sin; will be generated boot_X-FLASH-ALL-2389.img file.
This name file can be other, is just an example, if you have another phone with firmware for other region, pay attention to this!
This can be flashed then back to phone using adb comands; fastboot flash boot boot_X-FLASH-ALL-2389.img;
The same image can be transfered to phone and used later to generate correct magisk image and root the phone.
Best to you all!
daphix said:
Hi there; I was in the same situation, flashing a corrupted magisk boot image from standard firmware for XQ-AT51, provided by same author for simple rooting Xperia 1 II; my phone was without xposed, it was in clean factory state. the magisk boot image was taken from another thread "[ROOT] Magisk patched Boot Images & Instructions" designated for rooting of Xperia 1 II;
unfortunately is the same author who build your ROM, he delivered also corrupted magisk image.
It was not enter in bootloop if you flash only one image on phone, not both; his instructions are wrong. the correct flashing instruction is below, at end of my comment.
I solved in smilar way like you: using flashtool to obtain XQ-AT51 ftf file: XQ-AT51_58.0.A.3.39_1321-7706_R13A.ftf;
Attention: the name of file depends of region firmware you want to flash and type of phone (single or dual sim); the given names are with title of example.
Then from download folder of flashtool form your disk C:\Users\username\.flashTool\firmwares\Downloads (username is your username on pc); check for file: boot_X-FLASH-ALL-2389.sin ( applicable for XQ-AT51) and convert the file to .img using unsin; check on xda for unsin, extract unsin archive in exe file and then drag & drop over unsin.exe the file boot_X-FLASH-ALL-2389.sin; will be generated boot_X-FLASH-ALL-2389.img file.
This name file can be other, is just an example, if you have another phone with firmware for other region, pay attention to this!
This can be flashed then back to phone using adb comands; fastboot flash boot boot_X-FLASH-ALL-2389.img;
The same image can be transfered to phone and used later to generate correct magisk image and root the phone.
Best to you all!
Click to expand...
Click to collapse
Thanks for that, glad you managed to fix your situation too!
cd993 said:
Thanks for that, glad you managed to fix your situation too!
Click to expand...
Click to collapse
What to posted you is very very usefull; it helps you to fix after flashing wrong magisk module.
:good:

Possible to flash gsi to An A10S that has no custom recovery but has a rooted KERNEL?

Just wondering I have tried to flash a gsi but then the phone just bootloops.
Yes, you can install any GSI. I did and it works almost perfectly, but bluetooth audio does not work, I do not use it so I have not research further about this issue, maybe there is a fix.
To flash any GSI rom use this guide:
forum.xda-developers. com/galaxy-s10/how-to/guide-how-to-install-custom-rom-using-t4114435
(Sorry I can not post link).
BE CAREFUL, before you use the script to create your custom AP file, you need to rename the system.img.ext4.lz4 file to its original name (in my case system.img.lz4), you need every file that you get from unzip the AP file with its original name (that includes the modified files like boot.img.lz4, vbmeta.img.lz4, that replace unmodified files). Then run the script to create your custom AP and flash as the guide says
It will loop like 3 o 5 times. And then It will start and work normally. Even after reboots.

Repackage old Stock Rom? Remove Stock Rom Sig?

Hi all
I'm trying to flash and old kernel (boot.img) and system (super.img) to a S20 z1s exynos - SM-G980F/DS with a SW REV. higher than I would like...
I flashed TWRP sucessfully, this tripped knox, so I don't care at all about unsigned code running.
So I tried to:
1. disable AVB using a prebuilt vbmeta.img from here: https://forum.xda-developers.com/t/...root-s20-series-and-upgrade-firmware.4079353/
2. unpacking and then re-packing the stock firmware using "superr"s kitchen, but this produced a zip with which twrp was not happy with, even fixing a lot of updater-script errors... then again I think it does not help that my TWRP thinks the device is a z3s (no other twrp build available)...
3. flashing via ODIN obviously failed due to the device vs binary SW REV. difference.
4. flashing boot and super "by hand" in twrp -> error about SW REV. mismatch (DEVICE: X BINARY: X-1)
I have so many Questions to which I am unable to find answers, just suspicions/opinions....
Qs:
1. Can I simply disable all boot verification somehow?
2. how are vbmeta images created? do I need to fakesign my images? (vbmeta.img and vbmeta_samsung.img)
Thanks a lot for some clarifications
Defekkt said:
Hi all
I'm trying to flash and old kernel (boot.img) and system (super.img) to a S20 z1s exynos - SM-G980F/DS with a SW REV. higher than I would like...
I flashed TWRP sucessfully, this tripped knox, so I don't care at all about unsigned code running.
So I tried to:
1. disable AVB using a prebuilt vbmeta.img from here: https://forum.xda-developers.com/t/...root-s20-series-and-upgrade-firmware.4079353/
2. unpacking and then re-packing the stock firmware using "superr"s kitchen, but this produced a zip with which twrp was not happy with, even fixing a lot of updater-script errors... then again I think it does not help that my TWRP thinks the device is a z3s (no other twrp build available)...
3. flashing via ODIN obviously failed due to the device vs binary SW REV. difference.
4. flashing boot and super "by hand" in twrp -> error about SW REV. mismatch (DEVICE: X BINARY: X-1)
I have so many Questions to which I am unable to find answers, just suspicions/opinions....
Qs:
1. Can I simply disable all boot verification somehow?
2. how are vbmeta images created? do I need to fakesign my images? (vbmeta.img and vbmeta_samsung.img)
Thanks a lot for some clarifications
Click to expand...
Click to collapse
For these and other reasons, I quickly grew frustrated with SuperR's Kitchen and ultimately ended up rolling my own purpose-built solution that peels the layers of the onion of the Samsung package, gets to the point of mountable filesystem images, performs the desired transforms, and then packs everything back up into Odin-flashable .tar.md5 files. It's rough and minimalistic, but it works.
I'm not familiar with the error you mention, but usually those sorts of errors come from flashing a bootloader in Odin that is below the level of the one residing on the device. I haven't done much flashing via TWRP since I'm producing Odin-flashable output and I don't know why you'd have issues on boot.img or super.img. For my own sanity I don't regularly flash bootloader images. boot.img doesn't contain the booatloader though: it's the kernel and initramfs.
vbmeta.img files are generated with avbtool. I created one with a null signature which is identical to the ones floating around on the forum. I also cleaned up my fstab and manifests using the techniques of ianmacd's multidisabler.
sjevtic said:
For these and other reasons, I quickly grew frustrated with SuperR's Kitchen and ultimately ended up rolling my own purpose-built solution that peels the layers of the onion of the Samsung package, gets to the point of mountable filesystem images, performs the desired transforms, and then packs everything back up into Odin-flashable .tar.md5 files. It's rough and minimalistic, but it works.
I'm not familiar with the error you mention, but usually those sorts of errors come from flashing a bootloader in Odin that is below the level of the one residing on the device. I haven't done much flashing via TWRP since I'm producing Odin-flashable output and I don't know why you'd have issues on boot.img or super.img. For my own sanity I don't regularly flash bootloader images. boot.img doesn't contain the booatloader though: it's the kernel and initramfs.
vbmeta.img files are generated with avbtool. I created one with a null signature which is identical to the ones floating around on the forum. I also cleaned up my fstab and manifests using the techniques of ianmacd's multidisabler.
Click to expand...
Click to collapse
Thank you for your reply!
1. any chance you could list the steps you used to re-package a samsung rom?
2. is there a guide on how to create null-sigged vbmetas? can you use avbtool or do I need to manually edit the vbmeta file(s) ?
I did not try to downgrade the bootloader, just boot.img (kernel) and super (system, etc.).
Thanks in advance and best regards!
Sorry for the delay. I am on vacation and have not been regularly checking the forum.
To give you a conceptual overview of the workflow, here is the debug output my script generates for each step when trivially unpacking/repacking a Samsung firmware archive:
Extracting source zip.
Extracting .tar.md5 files.
Unlz4ing, unsparsing, and copying images.
Unpacking super.img.
Unpacking boot.img and up_param.bin.
Mounting filesystem images.
Applying main transforms.
Unmounting and checking filesystem images.
Repacking up_param.bin and boot.img.
Repacking super.img.
Sparsing, lz4ing, and copying images.
Archiving .tar.md5 files.
The real magic, of course, is in the transforms that are performed along the way, of which there are many. Most (notably those that are operations against the filesystem images) are performed during step 7, though some are performed before or after other steps by necessity. At some point I'll probably document this process a bit more and release the scripts since it is nontrivial.
Here is how I created my null vbmeta image:
Code:
avbtool make_vbmeta_image --flags 2 --padding_size 256 --output "${STEP_03_DIR}/BL/vbmeta.img"

Question Kernel updated, root lost

Hi Guys,
For some reasons, my kernel got updated without any change from me, not sure how this is possible.
Now, because of that, I lost root, is there a quick way to restore root (magisk) ?
Thanks in advance !
Yep. Just download the matching factory image zip for your currently installed build of Android. Then, extract the boot.img file, copy it over to your phone, patch it within the Magisk app and it will spit out a patched boot.img file into your "Download" folder. Next, copy that patched boot.img file back to your computer and flash that patched boot file using fastboot.
That may look like a lot of different steps, however, the process usually takes less time than it has taken me to type this comment, haha. Enjoy your root access =)

Categories

Resources