[Guide] Flash Magisk on Android 12

[warrencoakley]

No...we can still temp boot the patched image without flashing it. Reboot obviously loses root but it's a good temporary solution.

Yeah but honestly that's not really a logical solution

 

[V0latyle]

Yeah but honestly that's not really a logical solution

Why not? If you rarely reboot your phone, it's at least enough to use it with root until we find a permanent solution. It's working for several people here who don't want to wipe data.

 

[PablosCorner]

Why not? If you rarely reboot your phone, it's at least enough to use it with root until we find a permanent solution. It's working for several people here who don't want to wipe data.

I can say for sure it's working for me until a permanent solution is discovered.

 

[CarinaPDX]

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)

 

[killchain]

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.

 

[V0latyle]

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.

 

[V0latyle]

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.

 

[Homeboy76]

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

 

[V0latyle]

Magisk Canary 23001: Click 3 dot Menu => Click app-debug.apk => Click 3 dot Menu above View raw Click download

Thanks!

How in the world did you find that? How would one go about finding older Canary releases?

 

[V0latyle]

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.

 

[CarinaPDX]

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]

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.

 

[CarinaPDX]

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]

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.

 

[V0latyle]

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]

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?

 

[pierreantoine-cheron]

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]

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.

 

[ggkameleon]

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.

 

[pierreantoine-cheron]

If you aren't worried about wiping, then yes. Follow the instructions at the beginning of this thread.

Thank you it worked like a charm.
So far the only tutorial that worked for me.