• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[Closed] Android 12 Update and Root ***Obsolete***

Status
Not open for further replies.
Search This thread

V0latyle

Forum Moderator
Staff member
I do wonder though, when the smaller updates do eventually come through, will a data wipe be needed to keep root from version to version? (for those that did the permanent root methods)
I doubt it, but we will see.
I'm not rooted anymore since I dirty flashed A12 stable over beta 5 with disabled flags and I have the same issue
Patch the boot image, and live boot it for temporary root.
 
  • Like
Reactions: andybones

andybones

Forum Moderator
Staff member
May 18, 2010
14,786
15,087
Google Pixel 5
I do wonder though, when the smaller updates do eventually come through, will a data wipe be needed to keep root from version to version? (for those that did the permanent root methods)
I agree with @V0latyle
It should be similar to A11 for monthly updates.

I think Google patching the current Magisk stable is more likely to happen first. Especially with John working at Google. But with 200+ contributors to Magisk source and such an amazing community, it'll be interesting to see what's to come.
 
Last edited:

V0latyle

Forum Moderator
Staff member
I agree with @V0latyle
It should be similar to A11 for monthly updates.

I think Google patching the current Magisk stable is more likely to happen first. Especially with John working at Google. But with 200+ contributors to Magisk source and such an amazing community, it'll be interesting to see what's to come.
I can't see Google trying to actively prevent root access; on the other hand, I wouldn't think it unreasonable for them to try to prevent compromised security from being reported as intact (hardware attestation, SafetyNet for example) due to the potential liability of processes with root permissions having the ability to compromise applications that depend on security.
 

V0latyle

Forum Moderator
Staff member
Notes from the other thread:
Looking at the details on Android Verified Boot, the only other element I can find is rollback protection - but from what I can see, that's disabled on an unlocked bootloader. There's a corrupted data screen for EIO mode, but we already get the UNLOCKED screen during boot.

Here's the odd thing:

The corrupted data message we have been seeing seems to appear in recovery - which resides in the /boot partition along with the kernel.

In the details on how dm-verity works, it says that the protection lives in the kernel.

So maybe we need to use the --disable-verity flag when flashing /boot as well? I'm just guessing here, but perhaps there's some sort of check where dm-verity looks for verification to be enabled on /vbmeta, and if it doesn't find it, goes into recovery mode with the "corrupted data" message.

The problem with this theory is that it happens with older boot images too, such as the beta, where we did NOT see this issue.

I did find this thread which details how Magisk can be used to disable dm-verity

Ultimately, someone is going to have to be the guinea pig and test some ideas while we try to sort this out. Volunteers?
 

optimumpro

Senior Member
Jan 18, 2013
6,904
14,414
**********************************
Current status as of October 21: Data wipe required for permanent root. Patched boot image can be live booted for temporary root. Attempting permanent root (flashing vbmeta and boot image) after OTA or dirty flash results in bootloop ending up in recovery with "Unable to load Android system. Your data may be corrupted" message.
**********************************




With the Android 12 now here, I would like to make sure we have clear instructions on how to update with root.
This may seem redundant compared to other threads, but I wanted to consolidate the relevant information to one place.


WARNING: MANUALLY INSTALLING FACTORY UPDATES OR IMAGES REQUIRES AN UNLOCKED BOOTLOADER. If your bootloader is locked, DO NOT ATTEMPT THIS. You can, however, update using the OTA via ADB Sideload on a locked bootloader.

WARNING: MODIFY YOUR DEVICE AT YOUR OWN RISK. YOU ALONE WILL BE RESPONSIBLE FOR MALFUNCTION, DAMAGE, OR LOSS OF ANY KIND IF SOMETHING GOES WRONG.

Root will be done via Magisk. If you aren't already using it, download and install to your phone.

Warning: For the sake of simplicity, I frequently will use generalizations when referring to files ("[patched boot image]" instead of "magisk_patched-23001_xxxxx.img" for example). It is YOUR RESPONSIBILITY to ensure you are flashing the correct file. The easiest way to do this is type the command in the command line without the file itself, then drag and drop the file you want to flash into the command line window.



For those of you with a locked bootloader:

Simply install the update as usual via OTA, whether automatically through Android Update, or manually via adb sideload.

First, a bit of information on why you need to follow this guide (See this post)

Two new Verified Boot features implemented in Android 12 will interfere with attempts to root. A more detailed explanation is below if you would like.

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.

To update to Android 12 via OTA with data intact and reroot: **AS OF 10/20, DATA WIPE IS REQUIRED for permanent root**

If you update via automatic OTA:
1. Download the factory image (Yes, this is required) to your computer. Connect your device via USB.
2. Extract the contents of the factory image, then extract both boot.img and vbmeta.img from the image-[device].zip (where [device] is the codename for your device, such as Redfin for Pixel 5
3. Continue to Reflash vbmeta below

To manually install the OTA:
1. Download the OTA for your device, as well as the factory image (Yes, you need both) to your computer.
2. Install the OTA
3. Extract the contents of the factory image, then extract both boot.img and vbmeta.img from the image-[device].zip (where [device] is the codename for your device, such as Redfin for Pixel 5
4. Let the update complete, including reboot. Wait until you are in /system with the update process finished (no update notification)
5. Continue to Reflash vbmeta below

Reflash VBmeta
1. With device connected via USB, Developer Options enabled and USB Debugging enabled, reboot to bootloader using ADB:
Code:
adb reboot bootloader
2. Reflash vbmeta with dm-verity and boot verification disabled:
Code:
fastboot --disable-verity --disable-verification flash --slot=all vbmeta vbmeta.img
3. Reboot to bootloader:
Code:
fastboot reboot bootloader
Continue to Patch Boot Image below.

To update to Android 12 via factory image using Android Flash Tool: (Wipe required)
1. Open this link in Google Chrome (DO NOT USE MICROSOFT EDGE OR MOZILLA FIREFOX) Here is the link for beta
2. Connect your device via USB (make sure USB Debugging is enabled)
3. Enable ADB access in the browser
4. Select your device
5. Select the Android 12 build
6. IMPORTANT: Click the pencil icon next to the selected build
7. Ensure Wipe Device, Disable Verification, and Disable Verity are checked. DATA WIPE IS REQUIRED when updating from an older version of Android. Don't lock your bootloader if you want root. Force flash all partitions should not be necessary (but use this if you've run into problems and are starting over). Skip Secondary and Force Debuggable should be unchecked, unless you want to use ADB for root access on the stock kernel for some reason.
8. Click Install Build.
9. Wait until the update finishes.
10. Continue to Patch Boot Image below.

To update to Android 12 via factory image using ADB: (Wipe required)
1. Download the factory image to your computer and connect your device via USB, with USB debugging enabled.
2. Extract the contents of the factory ZIP
3. Reboot to bootloader:
Code:
adb reboot bootloader
4. If necessary, update the bootloader: WARNING: IF DONE INCORRECTLY THIS WILL BRICK YOUR DEVICE!
Code:
fastboot flash bootloader [bootloader image]
Reboot back to bootloader.
5. If necessary, update the radio:
Code:
fastboot flash radio [radio image]
Reboot to bootloader.
6. Install the update:
Code:
fastboot --disable-verity --disable-verification -w update [factory image zip]
DATA WIPE IS REQUIRED when updating from an older version of Android.
7. Let the update complete
8. Continue to Patch Boot Image below

Patch Boot Image:
1. Extract boot.img from the factory image ZIP if you haven't done so already
2. Install Magisk on your phone
3. Move the boot image to your phone via USB, and patch it using "Select and Patch a File" in Magisk
4. Move the patched boot image back to your PC
5. Reboot to bootloader
6. Flash the patched boot image:
Code:
fastboot flash boot [patched boot image]
7. Reboot to system.

For subsequent updates to Android 12:
Either install the update via OTA Sideload, then reflash vbmeta with disable flags set, or dirty flash the factory image with disable flags set.
Live boot your patched boot image from bootloader (as long as you're still on Android 12, the old kernel should work fine):
Code:
fastboot boot [patched boot image]
In system, launch Magisk then select "Direct Install" to patch the stock image in /boot.

Key reminders:
* The OTA does not have a way to set the disable flags for vbmeta, so if you update via OTA, you will have to reflash vbmeta with the disable flags every time you update.
* If you forget to do this and have a patched boot image, bootloader will return an error: "failed to load/verify boot image"
* The fastest and easiest way to update is via OTA, but remember you will lose root until you're able to reflash vbmeta and repatch the boot image.
* Manually patching the new boot image in Magisk via "Select and Patch a File" should be unnecessary every time you update. You can, instead, just keep the image you originally patched, boot it every time you update, and flash the stock image in /boot using Magisk.
* If, after flashing a patched boot image, you get the "unable to load/verify boot image", you probably didn't get the flags quite right. Just reflash vbmeta with the disable flags and that should fix the problem.


If you run into problems, or just want to share your results, please feel free to post your method and results in this thread.
Nice guide except one: the new AVB features that you say were introduced in Android 12 are present in Android 11 too. It's just that in custom roms, courtesy of Lineage, they have been disabled via:

Code:
BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS += --set_hashtree_disabled_flag
BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS += --flags 2

The first one disables hashtree verification, the second one allows roll backs, which are not needed anyway since there is no hashtree verification. As a matter of fact ALL of their multiple AVB entries including AVB_ENABLED=true are pretty much useless, as nothing gets enforced on unlocked bootloader.

But, when you remove the two entries mentioned above, you will get all of your described features in Android 11.
 
Last edited:

V0latyle

Forum Moderator
Staff member
Nice guide except one: the new AVB features that you say were introduced in Android 12 are present in Android 11 too. It's just that in custom roms, courtesy of Lineage, they have been disabled via:

Code:
BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS += --set_hashtree_disabled_flag
BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS += --flags 2

The first one disables hashtree verification, the second one allows roll backs, which are not needed anyway since there is no hashtree verification. As a matter of fact ALL of their multiple AVB entries including AVB_ENABLED=true are pretty much useless, as nothing gets enforced on unlocked bootloader.

But, when you remove the two entries mentioned above, you will get all of your described features in Android 11.
So why is it we could flash patched boot images without messing with /vbmeta on Android 11?

I still think this has something to do with kernel verity.
 

V0latyle

Forum Moderator
Staff member
On locked bootloader you can't.
I think you misunderstood me. Most of us here have unlocked bootloaders. My point is, rooting on Android 11 was extremely simple - just patch and flash the boot image. But when the Android 12 Beta hit the Pixel 5, we noticed that modifying the boot image caused a verification error - "unable to load/verify boot image" in bootloader. The solution to this was flashing /vbmeta with --disable-verity and --disable-verification.

So, my question to you is, if AVB was already implemented in Android 11, why could we run patched boot images without any other changes, while we can't do the same on Android 12?

If dm-verity and vbmeta verification had been implemented on Android 11, we would have had to do the same thing we have to do now. But, since we didn't, it's pretty clear they weren't.
 

andybones

Forum Moderator
Staff member
May 18, 2010
14,786
15,087
Google Pixel 5
I can't see Google trying to actively prevent root access; on the other hand, I wouldn't think it unreasonable for them to try to prevent compromised security from being reported as intact (hardware attestation, SafetyNet for example) due to the potential liability of processes with root permissions having the ability to compromise applications that depend on security.
No you're right, actively block root entirely, no, absolutely not.. that isn't what I meant, or Google wouldn't allow topjohnwu to continue on with Magisk at all.. But I didn't say this in my other post, and don't expect you to read my mind, my apologies.
However, as we know one stipulation for the continuation of Magisk is the removal "Magisk Hide" and the removal of the online Modules Repo.
Hopefully we will be alright using v23 on our phones.

This explains better what is currently going on. State of Magisk: 2021
 
  • Like
Reactions: V0latyle

optimumpro

Senior Member
Jan 18, 2013
6,904
14,414
I think you misunderstood me. Most of us here have unlocked bootloaders. My point is, rooting on Android 11 was extremely simple - just patch and flash the boot image. But when the Android 12 Beta hit the Pixel 5, we noticed that modifying the boot image caused a verification error - "unable to load/verify boot image" in bootloader. The solution to this was flashing /vbmeta with --disable-verity and --disable-verification.

So, my question to you is, if AVB was already implemented in Android 11, why could we run patched boot images without any other changes, while we can't do the same on Android 12?

If dm-verity and vbmeta verification had been implemented on Android 11, we would have had to do the same thing we have to do now. But, since we didn't, it's pretty clear they weren't.
All right. I did misunderstand. So, you are saying that with unlocked bootloader, you can't flash patched images? That indeed would be something new, that is, they enforce avb stuff even on unlocked bootloader. By the way, are you talking beta Android 12?
 

optimumpro

Senior Member
Jan 18, 2013
6,904
14,414
So, my question to you is, if AVB was already implemented in Android 11, why could we run patched boot images without any other changes, while we can't do the same on Android 12?

If dm-verity and vbmeta verification had been implemented on Android 11, we would have had to do the same thing we have to do now. But, since we didn't, it's pretty clear they weren't.
Because dm-verity and vbmeta verification are supposed to be disabled on unlocked bootloader. On Android 12, bootloader might be doing verification in unlocked state, but what's the point of unlocking, if verification still persists? On the other hand, what's the point of requiring verification in unlocked state if you can still disable it by flashing something else?
 

V0latyle

Forum Moderator
Staff member
All right. I did misunderstand. So, you are saying that with unlocked bootloader, you can't flash patched images? That indeed would be something new, that is, they enforce avb stuff even on unlocked bootloader. By the way, are you talking beta Android 12?
I am talking about Android 12 in general.

Again, rooting on Android 11 was extremely simple - just patch and flash the boot image.

But when the 12 Beta hit, we discovered that doing this would result in getting stopped at bootloader with "unable to load/verify boot image". This is due to dm-verity and vbmeta verification. Interestingly, this does not prevent a live boot of a modified boot image as long as the image in /boot is stock.

So, what we had to do was flash either the system image, or reflash the vbmeta partition, with the "--disable-verity --disable-verification" flags. This allowed flashing of a modified boot image.

The problem we have run into now with the 12 Stable release (which we did not see on the beta) is that a factory wipe seems to be required in order to fully disable dm-verity and vbmeta verification. We haven't quite figured out why.

What I suspect is that dm-verity has also been implemented in the kernel. Magisk used to have a function that would disable this.
 

V0latyle

Forum Moderator
Staff member
Because dm-verity and vbmeta verification are supposed to be disabled on unlocked bootloader. On Android 12, bootloader might be doing verification in unlocked state, but what's the point of unlocking, if verification still persists? On the other hand, what's the point of requiring verification in unlocked state if you can still disable it by flashing something else?
At this point the only thing the bootloader lock seems to do is prevent external flashing of partitions, as well as disabling any verification of -what- is flashed to those partitions.

Verified Boot on the other hand is a boot time security measure that compares a hash of /boot with a reference hash in /vbmeta; if a mismatch is found, it halts boot. This is not controlled by the bootloader lock.
 

optimumpro

Senior Member
Jan 18, 2013
6,904
14,414
At this point the only thing the bootloader lock seems to do is prevent external flashing of partitions, as well as disabling any verification of -what- is flashed to those partitions.

Verified Boot on the other hand is a boot time security measure that compares a hash of /boot with a reference hash in /vbmeta; if a mismatch is found, it halts boot. This is not controlled by the bootloader lock.
This all could be overcome in a custom build.
 

optimumpro

Senior Member
Jan 18, 2013
6,904
14,414
We will see. There are no custom Android 12 builds or kernels yet.
At this point, on Android 11, you can even apply Magisk patch during the build, and before the generation of vbmeta. So, when your rom is built, no Magisk flashing is required, which means, bootloader could be locked with custom key and you can have prerooted rom, which will pass all verifications.

I don't think Google cares about root. What it does care is that custom roms would fail Safetynet. That's why, they won't allow Magisk hide.
 
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 18
    Update 12-16: I am closing this thread as it is no longer relevant. Please refer to this guide.
    7
    Magisk Canary was updated to 23016 last night. This includes a fix for the vbmeta header issue, meaning that disabling verity/verification should no longer be required, and we should be able to root as we did before. This needs testing, make sure you back up your data and photos before you try this!

    Q: "If verity/verification are disabled, do I need to enable them now?"
    A: No. The only thing you have to do is update to Magisk 23016.
    Q: "Will enabling verity/verification wipe my data?"
    A: No.

    I will be updating the OP to reflect this.
    6
    Who is calling you stupid?!?! It's an American expression: for example, your costume is ruined by rain, so, you say: it's the weather stupid.

    Anyway, I am trying to help, so, there is no reason to seek insults where there isn't one.
    It's just the way you worded it is all. I am born in America, and actually thought the same thing when I read it.
    It's confusing to me though..

    I would say, not "it's the weather, stupid"
    but rather
    "it's the stupid weather"

    so reading "It's the bootloader stupid"
    I feel should be,
    "it the stupid bootloader"

    but thank you for clearing up that you aren't passing insults.
    And it's hard to tell through text whose being argumentative, and whose being helpful.
    Glad you're the latter.
    5
    Or he/you could add this to it when flashing factory image via ADB only. Why? Because it works on the pixel 4a 5(G) and may work on the Pixel 5. It would not confuse anyone, just provide another less complicated option for upgrading/updating those phones. Seems pretty black and white to me.
    Agreed.

    The confusion arises from this:
    PS :
    Pixel 4a 5(G) phone owners need to know for the initial upgrade (Android 11 to Android 12), they do not need the fastboot flash --disable-verity --disable-verification --slot-all vbmeta vbmeta.img step in this case
    This implies that verity and verification need not be disabled when upgrading from Android 11...which if you want permanent root, is not true. This can be omitted if one flashes the factory image, as they can incorporate the flags into the command:
    Code:
    fastboot update -w --disable-verity --disable-verification image-device-buildnumber.zip
    However, if the update is performed via the OTA, then vbmeta must be specifically disabled.

    If you understand what he is saying, why not add the Pixel 4a 5(G) note to the Reminders?
    This is true across ALL affected devices - Pixels on the SD765G and Tensor. It is not specific to one device.

    Still, I will update the notes for the sake of clarity.
    4
    Who is calling you stupid?!?! It's an American expression: for example, your costume is ruined by rain, so, you say: it's the weather stupid.

    Anyway, I am trying to help, so, there is no reason to seek insults where there isn't one.
    I didn't seek one, I guess I misunderstood. I have never heard of that expression before, at least not in that context. I'm American too, and I've generally heard it like this:

    "Hey, what's making that howling noise?"
    "It's the wind, stupid!"

    I digress.

    I'll have to pick this up later; it's late, my wife is demanding....attention, and I want to enjoy the weekend.