[Discussion] Magisk - The Age of Zygisk.

[zgfg]

Does this also mean that it is wrong to flash the magisk_patched.img into both slots?
My device is Poco F4 with A/B partitions.

wrong ? source
fastboot flash boot_a magisk_patched.img
fastboot flash boot_b magisk_patched.img

right ?
fastboot flash boot magisk_patched.img

Are you sure that your inactive slot is bootable (on some devices and ROMs it is not)?

Eg:
fastboot --set-active=b
fastboot reboot

Keep your OTA to switch/manage active slots, flashing with
fastboot flash boot <img>
will flash to the correct (active) one

Even if the other slot is bootable, at the moment it may not be updated to the same ROM version - flashing the wrong boot img there will make it not bootable

 

[11insomnium]

You helped me a lot to understand it. Thank you so much @zgfg & @pndwal

My hopefully last question: To update the ROM + keep recovery and root installed, is this the right order?
- boot into recovery
- flash new ROM.zip
- flash recovery + new magisk_patched.img again (to keep it after next boot)
- reboot to system

When I only update TWRP/Orangefox, it is also necessary to flash again magisk_patched.img afterwards, because both are in boot partition, right?

 

[pndwal]

Does this also mean that it is wrong to flash the magisk_patched.img into both slots?
My device is Poco F4 with A/B partitions.

wrong ? source
fastboot flash boot_a magisk_patched.img
fastboot flash boot_b magisk_patched.img

right ?
fastboot flash boot magisk_patched.img

Generally you'd only flash Magisk to inactivate slot immediately after updating OS and before reboot following these instructions:
https://github.com/topjohnwu/Magisk/blob/master/docs/ota.md#devices-with-ab-partitions
for preserving Magisk thru updates... This method works for some devices, but is broken for current P6 and P7 updates ATM, so many A/B devices must flash only to current slot after updating and rebooting like A-only devices ...

I guess you could flash Magisk to inactive slot in other circumstances if not affected by recently implemented partition digest checks that prevent this from working on newer devices currently, as long as you know exactly which OS version is on that slot... It generally won't match the current slot so boot.img used will differ... Nb. When devices are new, the unused slot is not generally bootable as factory odex files for system apks are shipped on system_b
https://forum.xda-developers.com/t/...7-pro-cheetah-safetynet.4502805/post-87591713

Many users want to put an OS on both slots immediately for safety reasons, and in this case there may be identical systems and partitions incl. boot.img. However flashing to inactive slot can be fraught and can break updates, so why not simply swap active slots to install Magisk while slot is marked as active to have root on both slots?... Then change active slot back... PW

 

[zgfg]

You helped me a lot to understand it. Thank you so much @zgfg & @pndwal

My hopefully last question: To update the ROM + keep recovery and root installed, is this the right order?
- boot into recovery
- flash new ROM.zip
- flash recovery + new magisk_patched.img again (to keep it after next boot)
- reboot to system

When I only update TWRP/Orangefox, it is also necessary to flash again magisk_patched.img afterwards, because both are in boot partition, right?

If you are on Xiaomi.eu (recovery) ROMs, then TWRP or OFox will be already in the boot.img, hence you will just patch and flash the Magisk

In case of stock MIUI you can install OFox upon OTA upgrading, reboot to OFox, backup your Boot partition, then reboot to (not yet rooted) System, patch the backed-up boot.emc.win, then reboot to OFox and flash it to Boot (or flash from Fastboot)

Or, OTA, then install OFox, reboot to OFox and flash Magisk directly from OFox

(Btw, your inactive slot might really be not bootable with MIUI 13+

Also, if you first patch Magisk and then install TWRP/OFox to your device with Recovery integrated to the Boot, you will loose Magisk and you will have to patch the Magisk again)

 

[shoey63]

I use payload-dumper. You cannot select only a single img file to extract but you can kill it once it extracts what you needed

I use Payload dumper go by @osm0sis .
It's a Magisk module and you can extract specific partitions from payload.bin on device without unpacking the whole thing.
Really handy

 

[rseiler]

[Metro Bank] Work fine, i can go into login screen

Via which method (there are a million of them)? I'm just using what's worked for everything else I use, which is:
-Magisk 25.2 (Zygisk, Denylist enforced and various apps checked, and using the Hide feature) + kdrag0n's safetynet-fix 2.4.0 module + Airfrozen

Using LineageOS 20.

 

[zgfg]

I use Payload dumper go by @osm0sis .
It's a Magisk module and you can extract specific partitions from payload.bin on device without unpacking the whole thing.
Really handy

Does it really work satisfactory on the phone when extracting from payload.bin of 6+ GB?

That's the reason I prefer PC

 

[J.Michael]

Does it really work satisfactory on the phone when extracting from payload.bin of 9+ GB?

That's the reason I prefer PC

Plus, it sounds like you need Magisk installed, so you can use a Magisk module to extract a file you need to install Magisk. Possibly useful if using one phone as a workstation to install Magisk on another phone.

 

[zgfg]

Plus, it sounds like you need Magisk installed, so you can use a Magisk module to extract a file you need to install Magisk. Possibly useful if using one phone as a workstation to install Magisk on another phone.

There is still a case when you already have Magisk prior to OTA and you want to extract boot img on the same phone before patching, upgrading the ROM and flashing the patched boot.img

Btw, in that case you could also use.ADB & Fastboot Magisk module on that 'workstation' phone, to run ADB and/or Fastboot from that phone instead of from the PC (it works fine over the two-side USB-c cable)

 

[Lughnasadh]

Generally you'd only flash Magisk to inactivate slot immediately after updating OS and before reboot following these instructions:
https://github.com/topjohnwu/Magisk/blob/master/docs/ota.md#devices-with-ab-partitions
for preserving Magisk thru updates... This method works for some devices, but is broken for current P6 and P7 updates ATM, so many A/B devices must flash only to current slot after updating and rebooting like A-only devices ...

I've seen several people say they successfully updated via "Install to Inactive Slot" method on the Pixel 6 and 7 series in the last several months, but it's still very hit or miss. A few issues concerning this matter have been opened (and closed) in the Magisk Github, but so far no one has provided logs, so until then the reasons for the hit or miss remain unknown.

 

[wkn000]

Installed Magisk.zip with TWRP on LOS 20 (payton). No need to manually reinstall Magisk after any OTA since, all done automatically in background (addons.d).

 

[pndwal]

I've seen several people say they successfully updated via "Install to Inactive Slot" method on the Pixel 6 and 7 series in the last several months, but it's still very hit or miss. A few issues concerning this matter have been opened (and closed) in the Magisk Github, but so far no one has provided logs, so until then the reasons for the hit or miss remain unknown.

That's interesting...

This was broken for Pixel 6 and 7 at least for late A12 and A13 updates due to new partition digest checking by update engine... The linked Google documentation doesn't seem to have changed... Still says:

Once the user reboots the system, it will boot into the updated partition and it is marked as active. At this point, after the reboot, the update_verifier program runs, read all dm-verity devices to make sure the partitions aren't corrupted, then mark the update as successful.

... This new check was identified as the issue because boot.img partition digest doesn't match after Magisk flashing so dm-verity devices indicate corrupt boot image and update/slot will be marked as failed/corrupted... I believe disabling verity/verification can't help since vbmeta can't be tampered for delta updates using update engine either...

I mentioned this here:
https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-87762979

The issue is still marked in GitHub as wontfix...

Do you know if Google has in fact changed/reverted their digest checks, or if this actually works w/ up-to-date releases for some?... And perhaps you could link a user's success story?... Thanks, PW

 

[pndwal]

Installed Magisk.zip with TWRP on LOS 20 (payton). No need to manually reinstall Magisk after any OTA since, all done automatically in background (addons.d).

Yup, @osm0sis is trying to keep this working/as is (it's his handiwork/baby after all), but Magisk Devs have in mind to remove addon.d:
https://github.com/topjohnwu/Magisk/issues/3820#issuecomment-1364700096

Shana has produced a POC addon.d module:
https://github.com/topjohnwu/Magisk/issues/3820#issuecomment-1364699640

It remains to be seen how such module support will work for custom ROM users or how long native addon.d will stay, but hopefully all @osm0sis' code/work can be retained/keep working for LineageOS users etc as before...

PW

 

[shoey63]

Does it really work satisfactory on the phone when extracting from payload.bin of 6+ GB?

That's the reason I prefer PC

Takes about 20 seconds for 2.9 GB

Plus, it sounds like you need Magisk installed, so you can use a Magisk module to extract a file you need to install Magisk. Possibly useful if using one phone as a workstation to install Magisk on another phone.

True that.
Totally useless if you have only one unrooted phone
However, the pc version should do the same, without bothering with python.

 

[Lughnasadh]

That's interesting...

This was broken for Pixel 6 and 7 at least for late A12 and A13 updates due to new partition digest checking by update engine... The linked Google documentation doesn't seem to have changed... Still says:

... This new check was identified as the issue because boot.img partition digest doesn't match after Magisk flashing so dm-verity devices indicate corrupt boot image and update/slot will be marked as failed/corrupted... I believe disabling verity/verification can't help since vbmeta can't be tampered for delta updates using update engine either...

I mentioned this here:
https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-87762979

The issue is still marked in GitHub as wontfix...

Do you know if Google has in fact changed/reverted their digest checks, or if this actually works w/ up-to-date releases for some?... And perhaps you could link a user's success story?... Thanks, PW

Yeah, I'm aware that back in June vvb2060 stated that the OTA feature in Magisk doesn't work on Pixels because the partition digest calculations were not overwriting the original values . To my knowledge, no one has submitted a PR for that issue. Nor am I aware of any changes since then to the digest checks.

There is also a related issue here.

Nonetheless, as stated earlier, some people have had success as recently as last month's January security update. It still holds, though, that the majority of people are unsuccessful, at least in my observation. So I wouldn't say it was "broken", per se, but rather "much of the time does not work as intended". I still advise people to not use this method.

On a side note, I have also seen a few people who were able to successfully take an OTA while rooted. Of course they lost root after they rebooted, but they were still able to successfully update while rooted even though the update should have failed due to the pre-OTA block verifications.

Below is a quick sample of success stories, from July to last month (I think 3 of them are in December). There are others and I have also seen people report on Telegram that they were successful.

[Guide] Root Pixel 7 Pro with Magisk + Unlock Bootloader + Pass SafetyNet + More

[Guide] Root Pixel 7 Pro with Magisk + Unlock Bootloader + Pass SafetyNet + More Android Security Bulletin—Febuary 2023 Pixel Update Bulletin—Febuary 2023 Introduction This Guide is for Pixel 7 Pro owners that want to Root their phone, and...

forum.xda-developers.com

Updating after root

I have my pixel 7 rooted and I cannot get automatic updates. What would be the best way for me to get updates on my system? Going by the name I'd guess the pixelflasher is used, but I honestly just don't want to brick my Christmas gift so I'm...

forum.xda-developers.com

Updating after root

I have my pixel 7 rooted and I cannot get automatic updates. What would be the best way for me to get updates on my system? Going by the name I'd guess the pixelflasher is used, but I honestly just don't want to brick my Christmas gift so I'm...

forum.xda-developers.com

Updating after root

I have my pixel 7 rooted and I cannot get automatic updates. What would be the best way for me to get updates on my system? Going by the name I'd guess the pixelflasher is used, but I honestly just don't want to brick my Christmas gift so I'm...

forum.xda-developers.com

"Your device is corrupt" after November Update with Magisk OTA method.

I followed this guide exactly: https://topjohnwu.github.io/Magisk/ota.html Before starting the guide, I had a pretty new Pixel 7 Pro with the latest version of Magisk successfully installed (with bootloader UNLOCKED) and some small Magisk...

forum.xda-developers.com

February 22, 2023 - QPR2 Beta 3.2 (T2B3.230109.006.A1) - Pixel 7 Pro [Cheetah] - [thread also for future Android QPR Betas]

Pixel 7 Pro [Cheetah] QPR Betas QPR stands for "Quarterly Platform Release". Android 13 QPR1 went final in December 2022. See main thread here for final/non-beta releases. You can officially opt into the Android Beta Program there, or use the...

forum.xda-developers.com

Method to upgrade every month, without wiping data and retaining root

Caution: I originally wrote this guide when it was necessary to disable verity and verification before flashing patched boot.img. Now Magisk has overcome this requirement and some users have reportedly flashed updates without disabling...

forum.xda-developers.com

[GUIDE] Pixel 6 "oriole": Unlock Bootloader, Update, Root, Pass SafetyNet

⚠️⚠️⚠️WARNING! IF YOU ARE UPDATING TO ANDROID 13 FOR THE FIRST TIME, READ THIS FIRST! ⚠️⚠️⚠️ If you are looking for my guide on a different Pixel, find it here: Pixel 3 Pixel 3XL Pixel 3a Pixel 3aXL Pixel 4 Pixel 4XL Pixel 4a Pixel 4a (5G)...

forum.xda-developers.com

[GUIDE] Pixel 6 "oriole": Unlock Bootloader, Update, Root, Pass SafetyNet

⚠️⚠️⚠️WARNING! IF YOU ARE UPDATING TO ANDROID 13 FOR THE FIRST TIME, READ THIS FIRST! ⚠️⚠️⚠️ If you are looking for my guide on a different Pixel, find it here: Pixel 3 Pixel 3XL Pixel 3a Pixel 3aXL Pixel 4 Pixel 4XL Pixel 4a Pixel 4a (5G)...

forum.xda-developers.com

 

[pndwal]

I use Payload dumper go by @osm0sis .
It's a Magisk module and you can extract specific partitions from payload.bin on device without unpacking the whole thing.

So that'd be Payload Dumper Go for Android...

payload-dumper-go (ported the original Python payload_dumper into Go) is officially pre-built for macOS, Windows and Linux...

it sounds like you need Magisk installed, so you can use a Magisk module to extract a file you need to install Magisk. Possibly useful if using one phone as a workstation to install Magisk on another phone.

True that.
Totally useless if you have only one unrooted phone
However, the pc version should do the same, without bothering with python.

So Payload Dumper Go may now be the go-to, way-to-go solution for PC etc...

But, aside from initial Magisk installation it seems Payload Dumper Go for Android can be used for OS updates while being very useful for avoiding transferring full OTA to PC to me, no?

I have no experience with A/B devices and payload.bin format for seamless streamed updates, but for updating already rooted A/B devices can't we avoid transferring full OTA to PC this way by
1) downloading full OTA directly to device
2) extracting boot.img using Payload Dumper Go for Android
3) taking update* and rebooting to new unrooted slot
4) patching boot.img w/ Magisk App
5) Transferring patched-boot.img (only) to PC
6) using patched-boot.img to fastboot boot (temp boot) system with root and then Magisk App Direct install to permanently root system, or
6b) fastboot flashing patched-boot.img to permanently root system?

* Nb Users should turn airplane mode on before rebooting to prevent PI deviceIntegrity failure and device becoming uncertified due to loss of root after rebooting... Turn airplane mode off after root and USNF are restored... Thanks @BillGoss!

... Please say if I'm missing something.. PW

 

[BillGoss]

So that'd be Payload Dumper Go for Android...

payload-dumper-go (ported the original Python payload_dumper into Go) is officially pre-built for macOS, Windows and Linux...



So Payload Dumper Go may now be the go-to, way-to-go solution for PC etc...

But, aside from initial Magisk installation it seems Payload Dumper Go for Android can be used for OS updates while being very useful for avoiding transferring full OTA to PC to me, no?

I have no experience with A/B devices and payload.bin format for seamless streamed updates, but for updating already rooted A/B devices can't we avoid transferring full OTA to PC this way by
1) downloading full OTA directly to device
2) extracting boot.img on rooted device
3) taking update and rebooting to new unrooted slot
4) patching boot.img w/ Magisk App
5) Transferring patched-boot.img (only) to PC
6) using patched-boot.img to fastboot boot (temp boot) system with root and then Magisk App Direct install to permanently root system, or
6b) fastboot flashing patched-boot.img to permanently root system?

... Please say if I'm missing something.. PW

You need to turn airplane mode on in step 3 before rebooting otherwise your phone will become uncertified since it's unlocked and unrooted after rebooting.
Once you've rooted it and installed USNF, then you can turn airplane mode back off.

PS: sent you a PM

 

[shoey63]

Yeah, I'm aware that back in June vvb2060 stated that the OTA feature in Magisk doesn't work on Pixels because the partition digest calculations were not overwriting the original values . .

Nonetheless, as stated earlier, some people have had success as recently as last month's January security update. . . .

I can think of a few scenarios.

- Updating from old firmware, when the OTA method still worked.

- Forced update, even though rooted.

- Confusing an OTA update they did on an older Pixel where it still works and reporting it as working on 6/7.

- Trolling

 

[Lughnasadh]

I can think of a few scenarios.

- Updating from old firmware, when the OTA method still worked.

- Forced update, even though rooted.

- Confusing an OTA update they did on an older Pixel where it still works and reporting it as working on 6/7.

- Trolling

One problem is that the Pixel 7 was released in October, well after vvb2060 said in June that the method didn't work on Pixels.

Actually a forced update on the Pixel 6 moving from A12 to A13 while rooted isn't inconceivable since they really wanted people to update, especially given the new anti-rollback protection situation that came with the A13 bootloader. If memory serves correctly in this old brain of mine, some of the instances where people were able to update while rooted may have occurred while moving from A12 to A13. But I would think users would know when they had a forced update versus manually updating through the Magisk OTA feature.

Confusion and trolling....well, what can I say

I can actually think of a few reasons why it didn't work when it should have, aside from the partition digest checking scenario:

-They had Magisk mods installed that needed updating and weren't disabled, causing a bootloop. They then assumed the OTA method didn't work because it bootlooped, rather than thinking a mod may have caused it (this happens quite often).

-They were using a custom kernel at the time of the update. The Magisk restore function won't return all the images a custom kernel modifies to stock since custom kernels involve modifying the boot (P6 & 7), dtbo (P6 & 7), vendor_boot (P6 only), vendor_kernel_boot (P7 only), and vendor_dlkm (P6 & &7) images.

Also, on the P7 the vbmeta image has to be modified to flash a custom kernel (via disabling verity and verification). In the early days on the P6 the vbmeta image also had to be modified to be able to flash a custom kernel, although you could do it by just disabling verity and leaving verification alone.

-They modified some other partition/image which wasn't returned to stock beforehand.

Probably a couple more scenarios that aren't creeping into my brain at the moment given the cobwebs and coffee still brewing

I think there are just too many examples where it worked to say that it is completely broken. On the other hand, there are too many examples where it didn't work, and code changes, to say that it does work properly.

 

[shoey63]

So that'd be Payload Dumper Go for Android...

payload-dumper-go (ported the original Python payload_dumper into Go) is officially pre-built for macOS, Windows and Linux...



So Payload Dumper Go may now be the go-to, way-to-go solution for PC etc...

But, aside from initial Magisk installation it seems Payload Dumper Go for Android can be used for OS updates while being very useful for avoiding transferring full OTA to PC to me, no?

I have no experience with A/B devices and payload.bin format for seamless streamed updates, but for updating already rooted A/B devices can't we avoid transferring full OTA to PC this way by
1) downloading full OTA directly to device
2) extracting boot.img using Payload Dumper Go for Android
3) taking update* and rebooting to new unrooted slot
4) patching boot.img w/ Magisk App
5) Transferring patched-boot.img (only) to PC
6) using patched-boot.img to fastboot boot (temp boot) system with root and then Magisk App Direct install to permanently root system, or
6b) fastboot flashing patched-boot.img to permanently root system?

* Nb Users should turn airplane mode on before rebooting to prevent PI deviceIntegrity failure and device becoming uncertified due to loss of root after rebooting... Turn airplane mode off after root and USNF are restored... Thanks @BillGoss!

... Please say if I'm missing something.. PW

For pixel 6 you nailed it, and @BillGoss ,s airplane mode trick is something I hadn't thought of and will try.
My other slot A/B device is (as you are aware) is ROG phone 3, which is a strange beast.
Not only do you unlock the bootloader with their "special app" instead of fastboot (no OEM unlock option in developer options), but updating if rooted is weird as well.
You download the new firmware to internal storage and reboot.
Then you get a notification about a new update and after accepting, it installs to the opposite slot.
From there it's a simple matter of installing magisk to the opposite slot after OTA and rebooting. No restoring of images required.
Different horses for different courses