Is it possible to somehow leverage the in-built OTA mechanism to install any custom ROM, while keeping the bootloader unlocked on a A/B device?
No, unless you're a rocket scientist...
galaxys said:
No, unless you're a rocket scientist...
Click to expand...
Click to collapse
Why not, where is the verification happening? Is there a signature verification after downloading the file, which can maybe be bypassed with root?
I could be wrong but I think a couple ROMs have their own OTA service baked in.
Also, I don't think it's too difficult/much more of a hassle to download the zip, reboot to recovery and flash.
nithinmanne said:
Is it possible to somehow leverage the in-built OTA mechanism to install any custom ROM, while keeping the bootloader unlocked on a A/B device?
Click to expand...
Click to collapse
If you were looking to flash a custom ROM with the stock recovery, required for sideloading an OTA, it wouldn't work. Each factory image or OTA image is signed by Google. The stock recovery is coded to look for that signature. If the recovery finds the signature it allows installation to continue. Any other signature or no signature at all will cause the process to halt with an error. In order to get a custom ROM to install using the OTA system you'd have to spoof Google's key in the ROM package so the stock recovery "thinks" it's installing a factory image or OTA.
What I described above applies regardless of whether the bootloader is locked or not. If your bootloader is unlocked, flash TWRP and call it a day.
Strephon Alkhalikoi said:
If you were looking to flash a custom ROM with the stock recovery, required for sideloading an OTA, it wouldn't work. Each factory image or OTA image is signed by Google. The stock recovery is coded to look for that signature. If the recovery finds the signature it allows installation to continue. Any other signature or no signature at all will cause the process to halt with an error. In order to get a custom ROM to install using the OTA system you'd have to spoof Google's key in the ROM package so the stock recovery "thinks" it's installing a factory image or OTA.
What I described above applies regardless of whether the bootloader is locked or not. If your bootloader is unlocked, flash TWRP and call it a day.
Click to expand...
Click to collapse
In A/B devices, it happens without a recovery, right, using update_engine. Do you know if there's a way to point it to a custom URL, instead of OEM's?
I don't believe the recovery is used for updates in the off slot on A/B devices. However, regardless of whether the recovery is required or not you still have to contend with the signing key requirement. So even if you could change the path to point to a particular download server, the absence of a Google signature will prevent the download from ocurring.
What you want is not possible because of the signing key requirement.
Strephon Alkhalikoi said:
I don't believe the recovery is used for updates in the off slot on A/B devices. However, regardless of whether the recovery is required or not you still have to contend with the signing key requirement. So even if you could change the path to point to a particular download server, the absence of a Google signature will prevent the download from ocurring.
What you want is not possible because of the signing key requirement.
Click to expand...
Click to collapse
All this validation happens in HLOS, right? Can this not be manipulated using root by replacing Google's OTA key?
nithinmanne said:
All this validation happens in HLOS, right? Can this not be manipulated using root by replacing Google's OTA key?
Click to expand...
Click to collapse
I don't know where it is, but a good guess would be the bootloader itself. And if that guess is right, not even root will help. You'd need to replace or modify the bootloader, which is a task beyond any of us.
If it were as easy as you make it sound, LineageOS and ROMs based on it wouldn't need their own OTA download systems.
Strephon Alkhalikoi said:
I don't know where it is, but a good guess would be the bootloader itself. And if that guess is right, not even root will help. You'd need to replace or modify the bootloader, which is a task beyond any of us.
If it were as easy as you make it sound, LineageOS and ROMs based on it wouldn't need their own OTA download systems.
Click to expand...
Click to collapse
The flashing happens when HLOS is still running(in Pixel, atleast), right? The bootloader can only verify when booting after flashing.
nithinmanne said:
The flashing happens when HLOS is still running(in Pixel, atleast), right? The bootloader can only verify when booting after flashing.
Click to expand...
Click to collapse
Again, I don't know. I do know however that this rabbit hole is deeper than I can go. You'll have to continue on your own from this point, because I simply have nothing left to add to the discussion.
Good luck. Hopefully you manage to avoid bricking your $1000 device in trying this.
Strephon Alkhalikoi said:
Again, I don't know. I do know however that this rabbit hole is deeper than I can go. You'll have to continue on your own from this point, because I simply have nothing left to add to the discussion.
Good luck. Hopefully you manage to avoid bricking your $1000 device in trying this.
Click to expand...
Click to collapse
Thanks, I'm not testing on my phone, I'm doing it during free time at work, where I can test on a debug 845 device, running android P. Its way easier, as I have access to more logging, and it takes 2 minutes to flash, even if I brick it. So I can try any solution you can think of. I eventually want to get it working on my phone though.
Related
I know it can't be done right now but all I want is the stock rom with superuser installed. When the one-click comes out do you guys think it will have the option?
Sent from my Nexus 7 using Tapatalk 4 Beta
Why not just unlock? You can always lock it again if you want to return to factory.
^^ This, plus if you don't want to replace the recovery you can always use ADB to boot do a different recovery like TWRP to flash the SuperSU :good:
Will an unlocked bootloader still be able to accept OTA updates?
If not, will it accept OTA updates after relocking the bootloader?
Thanks.
Godswrath said:
Will an unlocked bootloader still be able to accept OTA updates?
Click to expand...
Click to collapse
Yes.
Unlocking your tablet doesn't really make changes to your system. It sets a flag that allows you to modify partitions which were previous read-only and also allows you to boot unsigned kernels/recoveries.
Whether you can accept OTAs or not depends on whether you have modified or removed any OS files. Adding files (like you would to add root) will not affect your ability to get OTAs. However with root capabilities, you will sometimes be tempted to modify or remove OS files. That could prevent you from a successful OTA update.
sfhub said:
Whether you can accept OTAs or not depends on whether you have modified or removed any OS files. Adding files (like you would to add root) will not affect your ability to get OTAs. However with root capabilities, you will sometimes be tempted to modify or remove OS files. That could prevent you from a successful OTA update.
Click to expand...
Click to collapse
So I mentioned above that root wouldn't affect your ability to get OTAs.
I actually went through the process of flashing JWR66N, rooting, then applying the JSS15J OTA.
What I found is that SuperSU actually does cause the OTA to fail somewhere near the end when it is setting permissions. All the files are patched successfully but there is a failure when the OTA tries to unpack the new recovery. This is due to SuperSU install marking a file immutable to support its "survive" OTA feature. If you undo this attribute change on the one file, the OTA works fine.
If you do not undo the change, effectively you'll have all the files for the JSS15J ROM, except your build fingerprint will still say JWR66N.
sfhub said:
So I mentioned above that root wouldn't affect your ability to get OTAs.
I actually went through the process of flashing JWR66N, rooting, then applying the JSS15J OTA.
What I found is that SuperSU actually does cause the OTA to fail somewhere near the end when it is setting permissions. All the files are patched successfully but there is a failure when the OTA tries to unpack the new recovery. This is due to SuperSU install marking a file immutable to support its "survive" OTA feature. If you undo this attribute change on the one file, the OTA works fine.
If you do not undo the change, effectively you'll have all the files for the JSS15J ROM, except your build fingerprint will still say JWR66N.
Click to expand...
Click to collapse
Great, thank you so much for the info sfhub! May I ask how you undo the attribute change on the file? I'll really want root, but for the moment I don't want to stick with OTAs, I spend enough time messing around with ROMs on my phone, (EG4T).
Why not just learn android some more? It's a nexus device. It's meant to be easily unlocked / rooted / returned to stock / relocked. If anything, there are tons of resources in this forum to help you return your device to stock if you mess things up so you can return the tablet or get warranty done.
Godswrath said:
Great, thank you so much for the info sfhub! May I ask how you undo the attribute change on the file? I'll really want root, but for the moment I don't want to stick with OTAs, I spend enough time messing around with ROMs on my phone, (EG4T).
Click to expand...
Click to collapse
you just do
chattr -i /system/etc/install-recovery.sh
I attached an UPDATE-SuperSU-ota.zip install file you can run from TWRP to do it for you. You just run it after UPDATE-SuperSU-v1.51.zip and it will set you up to receive OTAs successfully (you'll need to re-install the two files after the OTA to put root back on)
So basically you do this
adb reboot bootloader
fastboot boot twrp.img
within TWRP
install UPDATE-SuperSU-v1.51.zip
install UPDATE-SuperSU-ota.zip
You can even "chain" install them, just select UPDATE-SuperSU-v1.51.zip first.
Aria807 said:
Why not just learn android some more? It's a nexus device. It's meant to be easily unlocked / rooted / returned to stock / relocked. If anything, there are tons of resources in this forum to help you return your device to stock if you mess things up so you can return the tablet or get warranty done.
Click to expand...
Click to collapse
IMO you can actually learn a lot trying to understand out why things fail
I've successfully flashed my first ROM. My purpose in doing so was to get the monthly Android security updates, and more broadly have my phone as secure as practical. In that vein, can I safely relock the bootloader? Should I? I am aware that many (most?) people here choose to keep the bootloader unlocked, and I respect that choice, but I'm seeking maximum security.
Searching here at XDA I see conflicting guidance. Some folks say that re-locking the bootloader with a custom ROM installed is begging to be bricked, while others say they have re-locked with no trouble. So what is your advice, why is that your opinion, and do you speak from experience?
I have not rooted the phone, nor do I plan to. I'm running AICP 8.1 on Nextbit Robin and don't plan to make any changes other than receive OTA updates. Should I make future changes beyond that I would not be bothered by the very minor inconvenience of having to unlock then relock it.
I too want to simply flash the stock recovery and lock my bootloader, but from what I've read to update the ROMs we need an unlocked bootloader. So that needs to be unlocked again does that mean everytime I lock-unlock I will be wiping my data all over? Thats would be a pain.
So this is an experiment I want to run from quite long and might do it sometime next month maybe. I will be wiping-unlocking-flashing-locking and see again if I can unlock without wiping my data and lock again, this way I can know for sure if this is doable because most online answers are weirdly confusing.
javelinanddart found that locking the bootloader on the Robin results in similar behavior as on the Nexus devices. The phone will check and make sure that the key used to sign the recovery partition remains the same as it was when your device got relocked, so as a result, TWRP should still work, and updating to a new version of TWRP would work too since it's (presumably) signed with the same key. System partition checking is handled by the kernel itself (dm-verity), but all the custom roms for the Robin have that disabled, so that wouldn't be a problem.
I've also been running custom roms with my bootloader locked and haven't run into any issues with flashing roms with TWRP.
I will be honest though, since TWRP lets you do so much to your phone, relocking your bootloader wouldn't really help security wise. You can pull up a damn root shell right in TWRP, for crying out loud.
@jabashque
Wait so are you saying despite locking the bootloader I can still go in custom recovery? Whats the point then?
I mean for me why I a considering locking the bootloader is so that if I lose my phone no one can access my data. As of now with custom ROM anyone has free access to my data via TWRP/custom recovery.
/root said:
@jabashque
Wait so are you saying despite locking the bootloader I can still go in custom recovery? Whats the point then?
I mean for me why I a considering locking the bootloader is so that if I lose my phone no one can access my data. As of now with custom ROM anyone has free access to my data via TWRP/custom recovery.
Click to expand...
Click to collapse
I suppose you could flash Lineage recovery instead, which was designed to be an OEM-grade recovery and doesn't include the ability to pull up a root shell or use adb.
Grab that here: http://downloads.codefi.re/jdcteam/javelinanddart/ether/ether-lineage-recovery-20180310_170949.img
Personally, I locked my bootloader so that I could actually see my custom splash screen without having to press the power button to dismiss the warning message.
EDIT: the build of Lineage recovery I linked still has adb shell access enabled it seems; I was wrong on that. Also, I haven't tried flashing another rom's system partition that's been signed with different keys.
jabashque said:
I suppose you could flash Lineage recovery instead, which was designed to be an OEM-grade recovery and doesn't include the ability to pull up a root shell or use adb.
Grab that here: http://downloads.codefi.re/jdcteam/javelinanddart/ether/ether-lineage-recovery-20180310_170949.img
Personally, I locked my bootloader so that I could actually see my custom splash screen without having to press the power button to dismiss the warning message.
Click to expand...
Click to collapse
So for an OTA update do I have to wipe all data to unlock again? I am on Omni btw.
I only unlock my bootloader to flash a cool splash screen then relock it. Even if the bootloader is locked I can still flash custom ROMs using ADB sideload. Works like a charm every time. I'm running the AEX custom ROM with Android 8.1.0
akeemk said:
I only unlock my bootloader to flash a cool splash screen then relock it. Even if the bootloader is locked I can still flash custom ROMs using ADB sideload. Works like a charm every time. I'm running the AEX custom ROM with Android 8.1.0
Click to expand...
Click to collapse
But you still locking it while on TWRP isn't it? Which means anyone has access to shell via TWRP defeats the purpose of security provided by a locked bootloader, isn't it?
/root said:
But you still locking it while on TWRP isn't it? Which means anyone has access to shell via TWRP defeats the purpose of security provided by a locked bootloader, isn't it?
Click to expand...
Click to collapse
I guess that's why Nextbit never had a problem with us unlocking the phone's bootloader.
Hello,
Is it possible to get root access on the Moto Z Play without needing TWRP? I tried to use this guide but my phone doesn't want to flash TWRP. It may require a unlocked bootloader. My question is that is it possible to get root on this phone without TWRP or unlocked bootloader?
PS. I only want root access to get Viper4Android/ Dolby. If there are any other alternatives, please let me know below.
Thanks,
mPreet
mPreet said:
Hello,
Is it possible to get root access on the Moto Z Play without needing TWRP? I tried to use this guide but my phone doesn't want to flash TWRP. It may require a unlocked bootloader. My question is that is it possible to get root on this phone without TWRP or unlocked bootloader?
PS. I only want root access to get Viper4Android/ Dolby. If there are any other alternatives, please let me know below.
Thanks,
mPreet
Click to expand...
Click to collapse
Your title says without unlock bootloader - no
Your text says without twrp - you can fastboot boot twrp.img - that will boot to it but not flash it permanently. But, again, not if the bl is not unlocked - gotta have that.
KrisM22 said:
Your title says without unlock bootloader - no
Your text says without twrp - you can fastboot boot twrp.img - that will boot to it but not flash it permanently. But, again, not if the bl is not unlocked - gotta have that.
Click to expand...
Click to collapse
So just to make sure that I understand, I have to get the unlock key from Motorola in order to unlock the bootloader. There is no other way around it, right.
mPreet said:
So just to make sure that I understand, I have to get the unlock key from Motorola in order to unlock the bootloader. There is no other way around it, right.
Click to expand...
Click to collapse
Pretty much - the process of obtaining your key will void your remaining Motorola warranty (though you may still have some protection depending on your local consumer laws), and the process of actually using the unlock key on your device will wipe your device in a factory reset. Ensure you back up your device (and adopted SD card as well) beforehand.
After that, you should be able to flash or boot TWRP, then root and flash Viper4Android (or ARISE Soundsystems) or Dolby. If you get OTA updates, you will not be able to flash them unless you can revert back to full stock, so ensure you have a TWRP backup without modifications or access to a stock ROM of the same build that you have now.
mPreet said:
So just to make sure that I understand, I have to get the unlock key from Motorola in order to unlock the bootloader. There is no other way around it, right.
Click to expand...
Click to collapse
correct. afaik.
echo92 said:
Pretty much - the process of obtaining your key will void your remaining Motorola warranty (though you may still have some protection depending on your local consumer laws), and the process of actually using the unlock key on your device will wipe your device in a factory reset. Ensure you back up your device (and adopted SD card as well) beforehand.
After that, you should be able to flash or boot TWRP, then root and flash Viper4Android (or ARISE Soundsystems) or Dolby. If you get OTA updates, you will not be able to flash them unless you can revert back to full stock, so ensure you have a TWRP backup without modifications or access to a stock ROM of the same build that you have now.
Click to expand...
Click to collapse
If I just boot off the TWRP instead of flashing, would that backup constitute as stock? So boot the TWRP instead of flashing then make a backup before rooting.
Thanks,
mPreet
mPreet said:
If I just boot off the TWRP instead of flashing, would that backup constitute as stock? So boot the TWRP instead of flashing then make a backup before rooting.
Thanks,
mPreet
Click to expand...
Click to collapse
be aware you will be walking on shaky ground. Be sure you have a spare phone that works in case you brick this one.
Update 12-16-21: As of Magisk 23016, the below is no longer relevant; verity/verification need not be disabled for root.
For instructions on rooting your Pixel 6 Pro, see this guide.
This thread will be closed.
Spoiler: Obsolete information
For those of you who are planning on rooting:
Be aware that Android 12 changed the way boot images are loaded, at least on the Pixel 4, 4a, and 5. We have no reason to believe the Pixel 6/Pro will be any different.
V0latyle said:
Two new Verified Boot features implemented in Android 12 will interfere with attempts to root.
Dm-verity (device-mapper-verity) is a method by which an image on block devices (the underlying storage layer of the file system) can be checked to determine if it matches an expected configuration, using a cryptographic hash tree. If the hash doesn't match, dm-verity prevents the stored code from loading.
Vbmeta verification is the other half of this - it provides a cryptographically signed reference hash which is used to verify the integrity of /boot, /system, and /vendor partitions. The vbmeta image is only used to verify /boot, while vbmeta-system is used to verify /system.
This was implemented to prevent persistent rootkits by means of a hardware level security check, to prevent "potentially harmful applications" such as Magisk from evading detection, as such applications residing within the kernel will have higher privileges than the detection applications.
What this means is that with these two enabled, a modified boot image will cause a verification error when flashed to the device, preventing boot. Interestingly, this check is not performed against "live" boot images loaded via ADB, so with dm-verity and vbmeta verification enabled, a modified image can be booted as long as the image in /boot is intact.
Click to expand...
Click to collapse
Dm-verity and vbmeta verification will need to be disabled in order to flash a rooted boot image. Unfortunately, this means that you will have to wait for the factory firmware to be released.
fastboot flash vbmeta --disable-verity --disable-verification vbmeta.img
We also discovered that a data wipe is required in order to get permanent root; flashing /vbmeta with the disable flags gets you stuck in recovery with "Unable to load Android system, your data may be corrupted" error if you didn't wipe /data when you upgraded. To be clear, this only happens in a specific circumstance:
* You updated to Android 12 without a wipe, AND
* You reflash vbmeta with the disable flags
Here are some threads in the Pixel 5 forum on the matter:
[Guide] Root Pixel 5 with Magisk + Unlock Bootloader + Pass SafetyNet + More
[Guide] Root Pixel 5 with Magisk + Unlock Bootloader + Pass SafetyNet + More Android Security Bulletin—June 2023 Pixel Update Bulletin—June 2023 Introduction This Guide is for Pixel 5 owners that want to Root their phone, and enjoy the benefits...
forum.xda-developers.com
[Guide] Flash Magisk on Android 12
Trying to root the Pixel 5 running Android 12 by flashing a magisk-patched boot image results in the phone only booting to fastboot mode ("failed to load/verify boot images") Some users have reported that booting (instead of flashing) the patched...
forum.xda-developers.com
[GUIDE] Upgrade Beta to Android 12, *keep* root and data (no wipe!)
It seems the trick is to manually sideload OTA upgrade, then flash vbmeta and patched boot image, all without rebooting in between. Important Notes: DO NOT take the OTA directly from your phone's System Upgrade settings item. This assumes you...
forum.xda-developers.com
[Closed] Android 12 Update and Root ***Obsolete***
Update 12-16: I am closing this thread as it is no longer relevant. Please refer to this guide.
forum.xda-developers.com
[CLOSED] Android 12 Upgrade Discussion
I am closing this thread as it is no longer relevant. For rooting instructions or further discussion, please go here.
forum.xda-developers.com
The loss of "Hide Magisk" in the lastest release means a few of my apps (banking and work expense) are not going to work if I root my Pixel 6 P. So disappointing. I will miss GravityBox the most, but will learn to live without it.
swieder711 said:
The loss of "Hide Magisk" in the lastest release means a few of my apps (banking and work expense) are not going to work if I root my Pixel 6 P. So disappointing. I will miss GravityBox the most, but will learn to live without it.
Click to expand...
Click to collapse
Magisk 23010 has DenyList, which works exactly like MagiskHide. However, getting Safetynet to pass is more complicated, as Riru is not compatible with 23010, so you can't use Universal SafetyNet Fix 2.0.0 or newer. So, I went back to Magisk 23001.
That was only for Android 12 beta.
Since official build has been released you no longer need to disable DM verify etc.
But still need boot.img to be patched which requires download of factory image which we can't do atm.
V0latyle said:
Magisk 23010 has DenyList, which works exactly like MagiskHide. However, getting Safetynet to pass is more complicated, as Riru is not compatible with 23010, so you can't use Universal SafetyNet Fix 2.0.0 or newer. So, I went back to Magisk 23001.
Click to expand...
Click to collapse
Thanks for pointing out that Riru is not compatible. I thought I was doing something wrong.
In order to roll back to an earlier version of Magisk, do I need to uninstall Magisk 23010 and unroot, reflash the original boot.img, install Magisk 23001, use it to patch the original boot.img, and then reflash?
Nekromantik said:
That was only for Android 12 beta.
Since official build has been released you no longer need to disable DM verify etc.
But still need boot.img to be patched which requires download of factory image which we can't do atm.
Click to expand...
Click to collapse
Incorrect. DM verity and vbmeta verification MUST be disabled to run a patched boot image. This is true regardless of whether it's the 12 Beta or the public release.
diesteldorf said:
Thanks for pointing out that Riru is not compatible. I thought I was doing something wrong.
In order to roll back to an earlier version of Magisk, do I need to uninstall Magisk 23010 and unroot, reflash the original boot.img, install Magisk 23001, use it to patch the original boot.img, and then reflash?
Click to expand...
Click to collapse
Remove Magisk via the Uninstall option within the app; first use Restore Images, then use Complete Uninstall. This will restore the boot image, so you don't have to. It will then reboot the phone.
At that point, yes, you would install the older version of Magisk, then root as usual by patching the boot image.
V0latyle said:
Incorrect. DM verity and vbmeta verification MUST be disabled to run a patched boot image. This is true regardless of whether it's the 12 Beta or the public release.
Click to expand...
Click to collapse
Will we be able to flash the OTA every month without wiping now? Just add the DM verity and vbmeta stuff before flashing the patched boot image?
Ghisy said:
Will we be able to flash the OTA every month without wiping now? Just add the DM verity and vbmeta stuff before flashing the patched boot image?
Click to expand...
Click to collapse
Had the updates changed at some point? On the Pixel 1 we were able to remove the -w from the update script to flash without wiping.
Ghisy said:
Will we be able to flash the OTA every month without wiping now? Just add the DM verity and vbmeta stuff before flashing the patched boot image?
Click to expand...
Click to collapse
One of our users, @HumorBaby was able to upgrade from the 12 Beta via OTA. See his guide here. This should, in theory, work for the monthly updates as well.
What is currently unknown is whether a data wipe will be required prior to root if updated via other methods (factory image or automatic OTA).
V0latyle said:
One of our users, @HumorBaby was able to upgrade from the 12 Beta via OTA. See his guide here. This should, in theory, work for the monthly updates as well.
What is currently unknown is whether a data wipe will be required prior to root if updated via other methods (factory image or automatic OTA).
Click to expand...
Click to collapse
Oh good, thanks.
I always sideload the OTA via ADB. So I guess that's fine!
roirraW edor ehT said:
Had the updates changed at some point? On the Pixel 1 we were able to remove the -w from the update script to flash without wiping.
Click to expand...
Click to collapse
It sounds like you may update the same way I do. Each month flash the factory image without the -w, patch the boot image and flash the patched boot image?
It sounds like (of course we don't know for sure yet) that we will still be able to do it this way each month except before flashing the patched boot image we'll have to disable DM verity and vbmeta verification first, reboot into bootloader, flash vbmeta.img (or just flash vbmeta with those flags disabled-easier), reboot to bootloader and then flash the patched boot image. Is this the way you're seeing it?
Lughnasadh said:
It sounds like you may update the same way I do. Each month flash the factory image without the -w, patch the boot image and flash the patched boot image?
It sounds like (of course we don't know for sure yet) that we will still be able to do it this way each month except before flashing the patched boot image we'll have to disable DM verity and vbmeta verification first, reboot into bootloader and then flash the patched boot image. Is this the way you're seeing it?
Click to expand...
Click to collapse
Yes, exactly, I use the full image and flash everything else that's necessary afterwards to stay rooted / have my custom kernel (when applicable).
And yes, that sounds right too for what we're likely going to need to do.
V0latyle said:
Incorrect. DM verity and vbmeta verification MUST be disabled to run a patched boot image. This is true regardless of whether it's the 12 Beta or the public release.
Remove Magisk via the Uninstall option within the app; first use Restore Images, then use Complete Uninstall. This will restore the boot image, so you don't have to. It will then reboot the phone.
At that point, yes, you would install the older version of Magisk, then root as usual by patching the boot image.
Click to expand...
Click to collapse
https://forum.xda-developers.com/t/guide-root-pixel-5-android-12.4187609/
Read Index 4, Point 2
Its only for people upgrading to Android 12.
Nekromantik said:
That was only for Android 12 beta.
Since official build has been released you no longer need to disable DM verify etc.
But still need boot.img to be patched which requires download of factory image which we can't do atm.
Click to expand...
Click to collapse
Again, incorrect. This issue is -not- limited to the beta and has been present for users upgrading to the public release.
Nekromantik said:
https://forum.xda-developers.com/t/guide-root-pixel-5-android-12.4187609/
Read Index 4, Point 2
Its only for people upgrading to Android 12.
Click to expand...
Click to collapse
The Pixel 6 is launching with Android 12, is it not? Disabling Android Verified Boot is not specific to the upgrade; rather, it's required for root on Android 12. If AVB is implemented on the Pixel 6 in any similarity to the Pixel 4 and 5 series - which there is an extremely good chance it is - then disabling it will be REQUIRED to use a patched boot image.
Note who is in the credits for that post.
roirraW edor ehT said:
Yes, exactly, I use the full image and flash everything else that's necessary afterwards to stay rooted / have my custom kernel (when applicable).
And yes, that sounds right too for what we're likely going to need to do.
Click to expand...
Click to collapse
As I'm sure you're aware, you can either update using the OTA, or you can dirty flash the factory image.
DM-Verity and vbmeta verification will have to be disabled every time /vbmeta is flashed. Thus, the easiest way to update, and disable AVB at the same time, would be to dirty flash the system update:
Code:
fastboot update --disable-verity --disable-verification raven-image.zip
V0latyle said:
Again, incorrect. This issue is -not- limited to the beta and has been present for users upgrading to the public release.
The Pixel 6 is launching with Android 12, is it not? Disabling Android Verified Boot is not specific to the upgrade; rather, it's required for root on Android 12. If AVB is implemented on the Pixel 6 in any similarity to the Pixel 4 and 5 series - which there is an extremely good chance it is - then disabling it will be REQUIRED to use a patched boot image.
Note who is in the credits for that post.
As I'm sure you're aware, you can either update using the OTA, or you can dirty flash the factory image.
DM-Verity and vbmeta verification will have to be disabled every time /vbmeta is flashed. Thus, the easiest way to update, and disable AVB at the same time, would be to dirty flash the system update:
Code:
fastboot update --disable-verity --disable-verification raven-image.zip
Click to expand...
Click to collapse
hmm ok
this sucks hope devs aint put off and then we get zero development. My OP8 Pro at least has Havoc and AICP
Nekromantik said:
hmm ok
this sucks hope devs aint put off and then we get zero development. My OP8 Pro at least has Havoc and AICP
Click to expand...
Click to collapse
I wouldn't worry too much. Getting past roadblocks has always been part of the fun. I've always loved making technology do what it's not supposed to do.
Nekromantik said:
hmm ok
this sucks hope devs aint put off and then we get zero development. My OP8 Pro at least has Havoc and AICP
Click to expand...
Click to collapse
roirraW edor ehT said:
I wouldn't worry too much. Getting past roadblocks has always been part of the fun. I've always loved making technology do what it's not supposed to do.
Click to expand...
Click to collapse
I don't think this was necessarily intentional; I believe Google is just trying to make Android more secure, and in so doing, may have inadvertently made things harder for us.
The whole point of Android Verified Boot is to prevent malicious code from being loaded at boot time - such as persistent rootkits. Unfortunately, things like Magisk fall into that category.
What's a bit confusing to many of us was that we were under the impression that unlocking the bootloader should have been sufficient to disable AVB, and there shouldn't be extra steps. One would think that there would be a discernable difference between malicious attempts at compromising device and system security, vs deliberate. We all understand that running a rooted device has risk, including a potential attack vector, so why wouldn't Google just let us assume that risk and do whatever we want with the hardware?
V0latyle said:
We all understand that running a rooted device has risk, including a potential attack vector, so why wouldn't Google just let us assume that risk and do whatever we want with the hardware?
Click to expand...
Click to collapse
You bring up some good points. One of the reasons I buy directly from Google is they don't typically invalidate legitimate warranty issues because the bootloader was unlocked.
However, maybe they are concerned about someone rooting their phone, overclocking the processor. blowing the speakers, and then trying to claim a warranty replacement.
However, most people that root won't be so careless and most warranty issues are completely unrelated to whether the bootloader was unlocked.
@Nekromantik I think I misunderstood the point you may have been trying to make.
Yes, we discovered that a data wipe is required to root after upgrading to Android 12.
We do not yet know if a data wipe will be required to root on a device that had an original CLEAN install of Android 12. It's definitely an excellent question, and something us Pixel 4/5 guys can test while you wait for your firmware drop.
V0latyle said:
@Nekromantik I think I misunderstood the point you may have been trying to make.
Yes, we discovered that a data wipe is required to root after upgrading to Android 12.
We do not yet know if a data wipe will be required to root on a device that had an original CLEAN install of Android 12. It's definitely an excellent question, and something us Pixel 4/5 guys can test while you wait for your firmware drop.
Click to expand...
Click to collapse
Yes thats what I was referring to on first point
As long as you dont need to wipe after every update then its all good
I wasn't fully stock and relocked the bootloader (stupid thing to do, i know) and now it seems like it's bricked as I can't boot to recovery or anything.
Is there ANY way I can fix this without replacing the phone? Or is it destroyed?
You can try using these Lineage OS installation instructions to see if you can get the bootloader unlocked again before you can attempt to start over getting the phone working again.
Install LineageOS on taimen | LineageOS Wiki
wiki.lineageos.org
Trixelit said:
I wasn't fully stock and relocked the bootloader (stupid thing to do, i know) and now it seems like it's bricked as I can't boot to recovery or anything.
Is there ANY way I can fix this without replacing the phone? Or is it destroyed?
Click to expand...
Click to collapse
Without a working recovery there is no way to restore the unit short of paying Google for the privilege. The LineageOS instructions provided will not work as they require the bootloader to be unlocked. Flashing an OTA image from Google also will not work as it requires the stock recovery be present.
Strephon Alkhalikoi said:
Without a working recovery there is no way to restore the unit short of paying Google for the privilege. The LineageOS instructions provided will not work as they require the bootloader to be unlocked. Flashing an OTA image from Google also will not work as it requires the stock recovery be present.
Click to expand...
Click to collapse
That sucks, at least I know not to do that again. (I'm glad that I only did that on my backup phone, not my main phone)