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

[Guide] Flash Magisk on Android 12

Search This thread

CarinaPDX

Senior Member
Jun 30, 2013
268
90
Google Pixel 5a
I have found that I was able to go from 12b5 to 12 release without wipe and keeping root.

The main difference I am seeing between what I have done and others is that I manually applied the OTA update with adb sideload then I was able to flash vbmeta (with verity disabled) as well as the patched boot img from the factory image, all in one go WITHOUT a reboot.
It would be nice to know if that works upgrading from 11 to 12; I'm guessing it does.

My guess is that when a system is upgraded to 12 via the OTA software update, verification is installed before reboot, and after the reboot the verification doesn't allow for removal of verification without a data wipe. The key is to install first, remove verification, root, then - and only then - reboot. That way verification is never allowed to execute before it is disabled. Perhaps someone would give that a try... (and document the commands)
 
  • Like
Reactions: elong7681

killchain

Senior Member
Oct 6, 2012
326
71
30
Google Pixel 4a 5G
It would be nice to know if that works upgrading from 11 to 12; I'm guessing it does.

My guess is that when a system is upgraded to 12 via the OTA software update, verification is installed before reboot, and after the reboot the verification doesn't allow for removal of verification without a data wipe. The key is to install first, remove verification, root, then - and only then - reboot. That way verification is never allowed to execute before it is disabled. Perhaps someone would give that a try... (and document the commands)

In this line of thought, I don't think I've seen this discussed, but... has anyone tried also flashing system besides boot and vbmeta? Would that work for removal of verification?

Edit: also, what's up with vbmeta_system.img? I've never seen it mentioned.
 
Last edited:

V0latyle

Forum Moderator
Staff member
In this line of thought, I don't think I've seen this discussed, but... has anyone tried also flashing system besides boot and vbmeta? Would that work for removal of verification?

Edit: also, what's up with vbmeta_system.img? I've never seen it mentioned.
I would guess that it's used to verify the integrity of /system. I don't think it really affects what we are trying to do, because Magisk is systemless.

Guys, I think I just ran into a problem with the new Magisk Canary: I can't downgrade Magisk and keep root. I've tried wiping the app data, uninstalling it, and flashing boot images patched with previous versions (22.1, 23.0, 23001, 23003) and every singe one except for the newest does not show as rooted.

Sucks for me, because ever since updating Magisk, my bank app doesn't work.


I'm a facking moron and forgot to completely uninstall Magisk before downgrading. I'm back on 23001.
 
Last edited:

Homeboy76

Senior Member
Aug 24, 2012
2,886
1,509
Google Pixel XL
Speaking of older Magisk releases...Does anyone know how to get to the old Canary/beta versions? I'm pretty terrible at navigating Github, and I can only seem to find the stable releases.
Magisk Canary 23001: Click 3 dot Menu => Click app-debug.apk => Click 3 dot Menu above View raw => Click download
 
Last edited:

V0latyle

Forum Moderator
Staff member
An excellent point that was brought up from a Pixel 6 user:

Data wipe is required for permanent root after upgrading to Android 12. That much we know.

But what about a device that had an original clean install of Android 12?

Who here wiped when upgrading to Android 12, and did not reflash vbmeta until AFTER you set up your device?

Basically, we need to determine if it matters when you flash vbmeta. Here's what needs to be tested:
- Factory flash Android 12 with a wipe; do NOT disable verity and verification
- Set up and use your device
- After everything is set up (download all your apps) attempt to reflash vbmeta with verity and verification disabled, as well as a patched boot image.

If this is successful, this means we shouldn't have to wipe every time we take a monthly update.
 
Last edited:

CarinaPDX

Senior Member
Jun 30, 2013
268
90
Google Pixel 5a
Data wipe is required for permanent root after upgrading to Android 12. That much we know.
I think that this is unclear. Certainly once the upgrade has been performed and the system rebooted it does look like a wipe is needed (because verification is active). And taking the offered OTA would reboot automatically IIRC and thus root would require a wipe. But as I posted earlier if the OTA is sideloaded and then verification is turned off and boot.img flashed before reboot, verification should never be active (i.e. it would be disabled before it was ever executed).

As for whether security updates can be installed and rooted without a wipe I think we will have to wait to find out. For an update we do have to remove root but I don't think we know yet if verification has to be enabled first for the OTA to start - it all depends on what Google decides to do. As long as the OTA doesn't check or enable verification then we should be good to update and root without a wipe. If an OTA enables verification then a sideload of the update followed by disabling verification and root before reboot might do the job. Even if verification must be enabled before the OTA it might still be possible to enable, sideload, disable, root in one go before reboot.

The whole point of verification is to ensure that Google-signed images are used to boot and for system. This ensures that the system has not been rooted or persistent malware installed, in order to protect the user data from compromise. If the device could be rooted without a data wipe then verification could be circumvented. Hence when rooting one must turn off verification, and when turning off verification the data must be wiped to ensure that the rooting is not done for the purpose of unauthorized access to the user data. Since they just added verification in 12 as a default we are having to work around that either with a sideload or just a wipe. The question is whether going forward future updates respect the verification status or whether they require or re-enable it - which is unnecessary but Google does have a history of unilaterally imposing security decisions. We''ll have to wait to find out.
 

V0latyle

Forum Moderator
Staff member
I think that this is unclear. Certainly once the upgrade has been performed and the system rebooted it does look like a wipe is needed (because verification is active). And taking the offered OTA would reboot automatically IIRC and thus root would require a wipe. But as I posted earlier if the OTA is sideloaded and then verification is turned off and boot.img flashed before reboot, verification should never be active (i.e. it would be disabled before it was ever executed).

As for whether security updates can be installed and rooted without a wipe I think we will have to wait to find out. For an update we do have to remove root but I don't think we know yet if verification has to be enabled first for the OTA to start - it all depends on what Google decides to do. As long as the OTA doesn't check or enable verification then we should be good to update and root without a wipe. If an OTA enables verification then a sideload of the update followed by disabling verification and root before reboot might do the job. Even if verification must be enabled before the OTA it might still be possible to enable, sideload, disable, root in one go before reboot.

The whole point of verification is to ensure that Google-signed images are used to boot and for system. This ensures that the system has not been rooted or persistent malware installed, in order to protect the user data from compromise. If the device could be rooted without a data wipe then verification could be circumvented. Hence when rooting one must turn off verification, and when turning off verification the data must be wiped to ensure that the rooting is not done for the purpose of unauthorized access to the user data. Since they just added verification in 12 as a default we are having to work around that either with a sideload or just a wipe. The question is whether going forward future updates respect the verification status or whether they require or re-enable it - which is unnecessary but Google does have a history of unilaterally imposing security decisions. We''ll have to wait to find out.
Well, that's why data wipe is required when unlocking the bootloader. If what you're saying about verification is correct, then you would have to wipe /data every time there's a new system configuration, such as an update.

Another problem with this theory is the fact that we can still live boot a rooted kernel on an otherwise stock system, without modifying any partitions.
 
Last edited:

CarinaPDX

Senior Member
Jun 30, 2013
268
90
Google Pixel 5a
Well, that's why data wipe is required when unlocking the bootloader. If what you're saying about verification is correct, then you would have to wipe /data every time there's a new system configuration, such as an update.

Another problem with this theory is the fact that we can still live boot a rooted kernel on an otherwise stock system, without modifying any partitions.
No, that is not so. There is no reason an update can't be done that preserves /data and verification status. That is a choice that Google will make but is not inherent to verification. The whole point is to protect user data, which is why /data is wiped when verification is removed: that data is protected and protection extends to removal when that defense is removed. 12 installs verification across the board, but if it is then removed (and the data wiped) then any later data is in an unverified environment - as chosen by the user. There is no need to re-install verification - the user's decision should be respected - but Google might anyway.

Yes, there are probably still some ways around verification but your example is flawed. That vulnerability only exists if you are sloppy enough to leave USB debugging enabled. And enabling USB debugging requires device access through the user authentication, so is not a work-around to authenticated access if you just know what you are doing - an assumption for developer mode. For the great majority of users that never enable developer mode (and thus never enable USB debugging) this is not a vulnerability - the stock system can't be accessed from a PC via USB for fastboot or adb (at least that is my understanding). And Google has been very clear that USB debugging should be disabled when not actively being used, because it is a vulnerability.
 

V0latyle

Forum Moderator
Staff member
No, that is not so. There is no reason an update can't be done that preserves /data and verification status. That is a choice that Google will make but is not inherent to verification. The whole point is to protect user data, which is why /data is wiped when verification is removed: that data is protected and protection extends to removal when that defense is removed. 12 installs verification across the board, but if it is then removed (and the data wiped) then any later data is in an unverified environment - as chosen by the user. There is no need to re-install verification - the user's decision should be respected - but Google might anyway.

Yes, there are probably still some ways around verification but your example is flawed. That vulnerability only exists if you are sloppy enough to leave USB debugging enabled. And enabling USB debugging requires device access through the user authentication, so is not a work-around to authenticated access if you just know what you are doing - an assumption for developer mode. For the great majority of users that never enable developer mode (and thus never enable USB debugging) this is not a vulnerability - the stock system can't be accessed from a PC via USB for fastboot or adb (at least that is my understanding). And Google has been very clear that USB debugging should be disabled when not actively being used, because it is a vulnerability.
I'm not sure I follow. Unlocked bootloader has always permitted live boot of an image regardless of what's actually in the /boot partition. This has been true of all Pixel phones, and in fact many other devices from other OEMs. In the case of the Pixel 5 (and 4a and 5a), you can live boot a patched image on an otherwise stock ROM without wiping data - as long as the image actually in /boot is stock. Once you decide you want permanent root by flashing a patched image, you have to disable verification, which will require a data wipe, at least in the case of an upgrade.

The bootloader lock itself is supposed to protect against attack in this manner. Android Verified Boot is designed to prevent a persistent rootkit from being loaded with the kernel; dm-verity is a process by which the code is hashed directly from the storage device, then compared to a reference hash in /vbmeta; if the code doesn't match, the bootloader doesn't load the kernel.

I'm not quite sure what changed between Android 11 and Android 12, but we discovered with the 12 Beta that vbmeta had to be flashed with the --disable-verity (supposed to disable dm-verity) and --disable-verification (the hash check itself) flags to disable Android Verified Boot.

The data wipe should not be necessary with an unlocked bootloader.

And, the verification status is -not- persistent. I just tested the theory, and I got the corruption error after I reflashed /vbmeta with the disable flags.

As far as USB debugging goes...there isn't much you can do with a locked bootloader. it's not necessarily a vulnerability, because the PC has to be authorized on the phone via user input; in the same grain, you can't externally change the "get_unlock_ability" flag - you can only do this via the OEM Unlocking toggle in Developer Options.

If USB debugging is enabled and the PC is authorized, one could potentially use ADB to access user data.

If USB debugging is enabled but the PC is not authorized, ADB will reject any commands. The worst that could happen is the attacker manually reboots to recovery and sideloads an OTA, or wipes data.
 
Last edited:

V0latyle

Forum Moderator
Staff member
Is there any possibility Rollback Protection could be part of the issue here? This can be disabled the same way as verity and verification, with --disable-rollback.

Looking at the same page, I see this:
The main job of avbtool is to create vbmeta.img which is the top-level object for verified boot. This image is designed to go into the vbmeta partition (or, if using A/B, the slot in question e.g. vbmeta_a or vbmeta_b) and be of minimal size (for out-of-band updates). The vbmeta image is cryptographically signed and contains verification data (e.g. cryptographic digests) for verifying boot.img, system.img, and other partitions/images.

Seeing as we have systemless root via patched boot images, I don't know how this would be a part of it, but still...
 

V0latyle

Forum Moderator
Staff member
I just found this! Seems to be exactly what we are dealing with when the "Your data may be corrupted" screen comes up.
Rescue Party receives information about boot and crash events and starts if:

  • The system_server restarts more than 5 times in 5 minutes.
  • A persistent system app crashes more than 5 times in 30 seconds.
When one of these situations is detected, Rescue Party escalates to the next rescue level, processes the task associated with that level, and lets the device proceed to see if it recovers. Each level is progressively more aggressive in what it clears or resets. The final level prompts the user to factory reset the device.

No special hardware support is required to support Rescue Party. If implemented, a device's recovery system must respond to the --prompt_and_wipe_data command and devices must surface a way for users to confirm any destruction of user data before proceeding. The recovery system should also give the user the option of attempting to boot their device again.

Question is, what is crashing, what is causing the crash, and why does it depend on a data wipe?

Edit: Has anyone tried patching the boot.img with Magisk 23011?
 
Last edited:
Oct 28, 2021
2
0
I'm not sure to understand, I have just updated my new Pixel 5 to Android 12, so I'm not worry to wipe my data or reset the phone, can I install Magisk and root my phone?
Thank you
 

V0latyle

Forum Moderator
Staff member
I'm not sure to understand, I have just updated my new Pixel 5 to Android 12, so I'm not worry to wipe my data or reset the phone, can I install Magisk and root my phone?
Thank you
If you aren't worried about wiping, then yes. Follow the instructions at the beginning of this thread.
 
hello, does not the problem come from the fact that the data partition remains encrypted ? Before my Pixel I had a Xiaomi and Oneplus and there was this same problem with the root magisk and custom Rom and I had to format the data partition and keep it to update. After that I don't know much about Pixel and this is the first year that I use. Same I do not understand why on other manufacturers they have Twrp ? bigger community ?
The new update will arrive i don't want to wipe yet.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 20
    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 boot image works and makes root temporarily available but i didn't have any success with that.
    The phone booted up but root didn't work.

    I won't explain how to unlock the bootloader or set up adb here.

    !Warning! This will wipe your phone so take a backup!

    Also i do not take any responsibility if you break your device.
    And if anything goes wrong just factory reset your device using the Android Flash Tool or by following this tutorial.

    Here's what i did to get Magisk v22.0 working on the first developer preview of Android 12:


    Install A12 with disabled AVB & dm-verity:
    1. Make sure USB-Debugging is enabled in developer-options and you have authorized the pc you're using on your phone.

    2. Boot your phone into fastboot mode.
      You can do this by turning it off and then starting it by holding Power + Volume Down
      until fastboot mode appears or just adb reboot bootloader

    3. Go here and click on the link for the Android Flash Tool.
      (I didn't copy the link directly so i don't have to update it everytime google releases a new update)

    4. It should ask you to allow the website to access ADB Keys. Click Ok.
      If the website somehow doesn't work, try using Google Chrome.

    5. Select your Pixel 5. If it's not showing up click add device.

    6. Click on the edit symbol (pen) in the box where the selected build is shown.

    7. Make sure Wipe Device, Disable Verity and Disable Verification are checked.

    8. Install and boot the phone when it's finished.

    Patch & flash boot.img
    1. Download and install the Magisk Canary App from GitHub.

    2. Download the factory image from here and extract boot.img from it.
      (Inside the downloaded zip-file is another zip file containing the boot image)

    3. Copy the extracted boot.img to your phone and open the magisk app.

    4. Click on Install -> Select and Patch a File and let it do its magic.

    5. Copy the magisk-patched boot image that should be found in your phones download folder back to your PC.

    6. Reboot into fastboot mode as i explained earlier and flash the patched boot image.
      (fastboot flash boot magisk_patched.img)
      Then reboot the device.

    Now root should be working. If it bootloops and says your phone has to be factory reset, do it.
    If for some reason you still get an AVB-Error and end up stuck in fastboot mode just flash the stock image and try to patch it again.

    This is my first post on here and i didn't have much time but i'm glad if it helped at least one person.
    6
    @Anonshe posted ths method in the Pixel 6 Pro thread. Does this work for the Pixel 4a 5(G), Pixel 5 or the Pixel 5a?
    Just updated my Pixel 5 to the November Sec Patch without any data loss. Since I'd disabled vbmeta before, steps were simple:
    - Used Payload Dumper to extract the boot and vbmeta images. Patched the former.
    - Rebooted to Recovery
    - Sideloaded the OTA package
    - Reboot to bootloader from the recovery menu
    Code:
    fastboot --disable-verification --disable-verity flash vbmeta vbmeta.img
    Code:
    fastboot boot magisk_patched.img

    After it booted up, opened Magisk Manager, installed via Direct Install. All works fine.
    5
    For those of you who don't have safetynet working, here.
    All credit goes to @kdrag0n, I just modified the shell scripts for B3

    Pull request done if you don't want my zip.
    4
    Has anyone sucefully rooted beta 3?
    Patched boot image with magisk canary if I only boot the image it starts
    Then tried to flash patched boot image and get stuck in bootloader
    For all the updates from beta 2 - 3 I've followed this process without fail:

    - extract boot.img and vbmeta.img from downloaded beta of your relevant device
    - add boot.img to phone (if downloaded, and extracted on another device)
    - patch boot.img in magisk (i like to rename it to patched_magisk.img)
    - move patched_magisk.img to desktop
    - download and install latest beta from the OTA provided
    - tap the reboot button on the OTA install screen once completed
    - once the reboot begins and your screen turns black hit the power and volume down button to get into fastboot
    - run
    fastboot --disable-verity --disable-verification flash vbmeta path/to/vbmeta.img (you can drag img from location)
    - then run
    fastboot flash boot path/to/patched_magisk.img (you can drag img from location)

    This has worked flawlessly, maintaining root while also keeping all my data.
    4
    Yeah I wouldn't do this unless you've started from the initial process op outlined. I did this moving from beta 2 to 2.1 and then beta 2.1 to beta 3. However beta 2 was my first android 12 install, which I used ops procedure to achieve.

    Do this:
    You don't need the Android flash tool. I have been manually flashing full images for a long time:
    I don't like things done behing my back.

    For beta 3:
    I flash both sides hence the skip secondary - it saves a few seconds.
    When flashing - watch what's scrolling by. The vbmeta.img is modified on the fly.
    No need to copy from another build or someone else's hack.
    Below is what I use. Successfully.

    Modify the last line in the flash-all.bat or.sh
    fastboot --skip-reboot --skip-secondary --disable-verity --disable-verification update image-redfin-spb3.210618.013.zip