yashsingh1/xdaforums huggingface dataset:
[Magisk] sbanskot:
Nope, not only patched AP. Flashed simultaneously with stock BL, CP, CSC.

After flashing those successfully with ODIN and then rebooting, I get that AVB fail page with the vbmeta HASH MISMATCH. When I try to get into recovery mode (to do the whole factory reset step), it does not seem to let me. The workaround I found for this is to flash the stock BL again (this time just BL) while the device is on the AVB Fail page. After this step, my device successfully boots.

@J.Michael I think ^ should answer the first part of your question.

The device was first released at the end of 2020. I am not sure what you mean by installed to recovery. I flashed while the device was in ODIN mode and KG (Samsung specific Knox Guard) State: Normal. While on the first boot with the patch, I actually cannot get to recovery mode because of the AVB VBMETA hash mismatch page comes up right away. That's why the only solution I found was to flash just the stock BL while the device was on that AVB VMETA fail page. After ODIN flashes that successfully, then I can boot up the device successfully with all of the Magisk patches.

Yes I can confirm that stock BL contains VBMETA based on what ODIN logs as it is being flashed. I just extracted it to be sure and there it is:

That's a great question. There is actually a partition called vbmeta_samsung also on the device. This is part of the partition list. I am wondering what vbmeta_samsung.img is handled since it seems like patching vbmeta.img in the AP is enough to disable verification.

This issue does not occur when I flash with the 4 unpatched tar files. It goes back to the stock FW.
[Magisk] ipdev:
@sbanskot

I am not familiar with Samsung but, what you describe sounds similar to this.

"Patch vbmeta flags in Samsung tar firmware packages optionally"

Magisk - [github] - PR # 7181​

If you go back though the linked issues in the PR, it seems to have been a problem with some devices.

By flashing the stock BL back after the patched version, it seems you are replacing the "patched" vbmeta image with a stock one. (?)

Cheers. :cowboy:
[Magisk] sbanskot:
Yeah that actually sounds like the issue I am getting with my Samsung device.

That's what it seems like. That confuses me though because I thought the VBMETA had to have have the patch that changes the flags so we could disable dm-verity and flash custom patched ROM. Is this now how Magisk expects the patched FW to be accepted by the device?
[Magisk] J.Michael:
I would like to know if the three vbmeta files in the stock ROM are three different files. Extract them from the tar files, rename each as soon as you extract it so the second "vbmeta" doesn't overwrite the first (and to make sure you can keep track of them). I think you can count on two lz4 files being the same if the original files were the same, but expand them just to be sure.

You should really pin down this nonsense about recovery:

Withva stock system, can you boot to recovery?

In the patched AP file, is recovery.img different from what it was in stock AP?

If you are happily using Magisk, and had no trouble booting, then you probably are not installing Magisk to recovery. But you are also running with what seems to be an unpatched vbmeta, which everyone here thought would be impossible. Unless for some reason Samsung put an empty vbmeta in BL.tar for someone like you to find and use.

When Odin is flashing, what is the order in which the three vbmetas are processed?
[Magisk] pndwal:
This had crossed my mind too having seen that PR... I think you may be correct that this may well be an exception to John's rule that vbmeta must be patched for A9+ Sammy also, not that I fully understand why it should work given @BlackMesa123's tests/failures in the first issue thread he linked comment from... Don't think he fully understands either... I also wonder about a compression matching issue after repack based on the second thread/comments by user about boot.img patched succeeding while boot.img.lz4 won't work... I recall this was an issue needing correcting for late devices due to GKI separation of ramdisks to /vendor _boot and those ramdisks wouldn't recombine with init_boot ramdisk after boot because magiskboot recompression for patched init_boot needed to match vendor_boot compression and didn't... This may or may not be significant, but that issue may also simply turn out to be a vbmeta / verity issue...

Further, I can't say I properly understand what makes Sammy special respecting the need for vbmeta patching, but I understand it wasn't needed for many legacy ramdisk (≤A8 excl. Early Pixels) or legacy SAR (A9 + early Pixels) launch version non-sammy devices... It was needed for all 2SI devices (A10+) as Magisk used to patch fstab and execute the original `init` to mount partitions... With refactoring Magisk now patches original init to direct second stage init to magiskinit, so AVB now remains intact (vbmeta in dedicated partitions at least are no longer patched) in most devices as stripping the flags in vbmeta was only apparently needed to patch fstab... We don't generally need this for boot image patching any more...

This change may actually allow many SAR+ Sammy devices to boot with AVB intact where other considerations don't make vbmeta patching necessary... It may also allow some devices to become Magisk compatible if vbmeta patching became optional or triggered only when plum necessary... I now wonder if this has simply been overlooked...

I'll be watching @BlackMesa123's PR closely...

I don't think vbmeta patching is needed for custom ROMs... Guess that will be included anyway if needed... It's certainly not now generally needed for custom kernels, although many were produced requiring this; I believe that most later custom kernels have adopted Magisk's approach of keeping AVB intact...

Of course AVB will intentionally allow a device to boot with any signing key and (all?) verification errors where B/L state is unlocked (unverified) / Orange in any case, so vbmeta strut hash/key data needn't be considered AFAIK...

🤠 PW
[Magisk] HippoMan:
Quick follow-up:

I just found out that Xiaomi phones provide abbreviated coverage in the U.S. (limited bands, no VOLTE, etc.).

I'm in the U.S. and use T-Mobile, so I guess I'm out of luck with Xiaomi.

Oh well ...

But thank you again for all the info!
[Magisk] zgfg:
Check on GSMArena for each particular phone. You can see exactly which 3G, 4G or 5G frequencies it supports

Models that are officially sold should support However, not if resellers by phone models for other regions, reflash them with 'global' or Xiaomi.eu ROM and resell

And VoWiFi/VolTE is supported but again don't buy a model released only in China or India, reflashed by a reseller and sold as 'global'

Again, check on GSMArena specs and frequencies for the PARTICULAR model, I would not believe to generalizations made by users who bought certain Redmi phones from resellers on the Net who sold them as 'global' but in reality, they don't support all global frequencies.

Also, register to Xiaomi.eu forum and ask eg in that Stable MIUI thread for a model you are interested in, does 5G and VoLTE work for your specific Operator

Also, for VoLTE it could be that a given Mobile Operator.doesn't officially support certain model (although its modem properly supports frequencies, etc), but people then manually create APN files and voila
[Magisk] pndwal:
As above...

Further, Xiaomi offers the best specs / hardware / quality you'll find for any price point... Usual frustrations with (too much) bloatware however... Easily sorted with custom ROM or root solutions however...

Re, VoLTE, VoWiFi, these are normally provisioned on phones but options to activate don't show for some reason on many networks... I think this relates to a plethora of carrier implementations available and inadequate or prohibitive carrier checks... Maybe it's device model checks as mentioned above... I've had no issue activating these on several models by simply disabling the carrier checks per this well known method:

... and VoLTE works fine with the networks I've used... Never needed custom APN for this...

👍 PW
[Magisk] HippoMan:
Thanks to both of you, @zgfg and @pndwal, for encouraging me. I'll now spend more time investigating, and I hope I will indeed find a Qualcomm Xiaomi device that I can use.
[Magisk] pndwal:
👍

... Do do your homework... There are really just too many options available and many very similar models, eg many Note series features are duplicated on Poco, Mi series etc...

Check specs carefully for features you want, eg NFC, AMOLED, ip53, fast charging, QComm soc, sim and memory slots, stereo speakers, cameras etc as sub variants can differ and the nomenclature can be confusing...

And check XDA / XiaomiEU for custom ROM support... There shouldn't really be issues with any QComm models for Magisk root however...

😆 PW
[Magisk] m0han:
May I add 3.5mm audio jack too - if one doesn't wanna have trouble (maybe) with wired headsets of the USB Type C kind.
[Magisk] zgfg:
FYI: HuskyDG is back in the mood.

Latest Magisk Delta supports systemless early-mount and initrc via Magisk modules:

Magisk Delta Internal Documentation
[Magisk] zgfg:
First time ever in my life

Besides, I was also able now to remove the two modules and still fully passing TBChecker and S-Check (screenshots were taken before rebooting and retesting)
[Magisk] pndwal:
👏 🎉

... Please can you show results from NativeDetector / NativeTest v12, MemoryDetector and Momo?... 👍 PW
[Magisk] zgfg:
If I disable Shamiko (still passing TBChecker, S-Check) then Momo as on the screenshot - but then there is again Injection in Minotaur

With Shamiko, Momo as above + detecting Zygisk

Memory detector finds YT and Music RvX, and debloated apps. I have to double-check does report Zygisk (currently on the beach, without that reserve phone and WiFi)
[Magisk] m0han:
Here are mine with latest Magisk Delta Canary in 'Riru mode'. Results of all the other testing apps on my device are as before. I'm not using Zygisk. I can't find NativeDetector while trying to 'Configure Unmount'.
[Magisk] pndwal:
So Zygisk = Yes on Magisk App home screen and Momo not detecting?... 👍

Interesting ... 🤔

Interesting that Shamiko kills Zygisk detection in Momo... Wonder if 'Minotaur' (NativeDetector/Test) v12 will detect... Probable...

Thanks... Wonder if @huskydg will build Metagisk NB-Zygisk soon instead of old Maru NB-Z...

Unmount is interesting... 🙂 PW
[Magisk] huskydg:
Ain't they same?
[Magisk] pndwal:
Ta... But I'm interested in Zygisk implementations really...

Alpha and Delta both load it with Native Bridge (current WIP Metagisk and original Maru POC implementations respectively) so there should really be no advantage using Riru hooking (using even older/original NB loading to facilitate it's inbuilt RiruHide solution)... As you can see, while it's memory is anonymous and hidable (thanks to original native bridge loading concept introduced by @canyie to Rikka's Riru 22.0; remarkably Canyie would have been only 15yo at the time), other traces can still be detected... 🤠 PW
[Magisk] pndwal:
Well my Alpha tests seem to allow banks that others couldn't use with Delta...

As mentioned above, original NB was @canyie's idea for Riru, and she has contributed much to Shana's Metagisk implementation in Zygisk too... The Maru fork was an early adventure with POC NB for Zygisk...

Metagisk Zygisk is still not fully mature even with countless commits to fix/debug since March... It works very well but still apparently has conflicts... Still not fully hidable with @canyie's Shamiko either...

So not the same AFAICS... 🤠 PW
[Magisk] m0han:
Cool. I posted screenshots since your post did not state that. In any case, I don't think I can move to Zygisk soon; I don't get to use this device as often as in the past. And, I'd have to go 'module hunting'. If you could - after seeing my modules from this post and this - point me to replacement modules, I could give Zygisk a try, maybe.
[Magisk] huskydg:
Well, Native bridge is zygote behaviour, make zygisk extremely depends on zygote behaviour is also not a long good solution. What if an OEM break or cut that function for optimization?
[Magisk] pndwal:
Interesting... But Magisk users want injection into zygote for device integrity API fixes, LSPosed modules, countless other Magisk Modules etc (and want hidability to boot)...

But was original libmemtrack method (apart from hiding) better? Or are there other usable methods OEMs are less likely to kill with optimisation? PW
[Magisk] pndwal:
Sorry... It was apparent that @zgfg was using Zygisk...

I had a look... Appears all you would need for standard Magisk with Zygisk, incl. Alpha fork (only in case you want bleeding edge native bridge now as NB-Z should be appearing in TJW builds whenever we get 27.0 if you can wait) would be Shamiko and a USNF or PIF solution... Unless you need a solution for certain broken keymaster implementations prohibiting deviceIntegrity verdict on a OnePlus or similarly flawed device, I'd go for @Displax's USNF 2.0 or 1.3 (in case of issues with 2.0) ATM...

For Delta fork I think @huskydg has Zygisk compatible alternatives to USNF and Shamiko hiding in his GitHub... 🙂 PW
[Magisk] zgfg:
Native Test (I found v2.2), with or without Shamiko, as on the screenshot

Memory Detector does not detect Zygisk

(If missed, tests with latest Magisk Delta 261105 0bb64ac4)
[Magisk] amk316:
what is "abnormal size of dynamic partition"???
[Magisk] zgfg:
Some custom ROM maybe (and some parameterss not aligned)?
[Magisk] amk316:
No

Its stock rom
[Magisk] J.Michael:
Do you have Magisk installed?

Post your partition layout. (Maybe "fdisk -l")
[Magisk] J.Michael:
No, I was thinking the partition table might give you a clue, like a size that's not a multiple of a large cluster.

@osm0sis' Busybox has an fdisk.

I don't recognize anything in the toybox that came with my tablet as a partition manager.

I think the partition information is available through some magic Linux device. If you are rooted, you could use dd to read the beginning of the device. Maybe coax some Linux utility to interpret the dump file on a PC.

cat /proc/partitions

will give you sizes. /dev/block/by-name will give you meaningful names.

Here's hoping somebody who knows what he's talking about replies.
[Magisk] mGforCe:
For me, with latest Magisk Delta (26105) 0bb64ac4 with Zygisk, Shamiko, USNF Displax v1.3

Native Test gives : Found Injection, Abnormal Environment, Property Modified

I have hidden Native test in Zygisk. What else is needed?

TB Checker results

Xposed Check - all good except Xposed Hooks & XprivacyLua

Play Integrity - Basis & Device Integrity passes

Also confused how to hide Xposed Hooks?
[Magisk] zgfg:
You must uninstall XLua. Even more, read their GitHub page, FAQ and find which remaining files must be manually removed (even when you uninstall XLua, they remain and get detected)

For XPososed hooks you must use LSPosed (Xposed) module Hide My Applist (HMA) to hide all LSPosed modules (incl HMA) from TBChecker. Use HMA also to hide Magisk app

Search for HMA thread on XDA, follow the link to GitHub Guide you will find there in the OP post #1)
[Magisk] WhoIsJohnGalt1979:
For some odd reason, Ruru is detecting HMA under Libc File Detection and Syscall File detection. Canary 26105, Displax 2.4.0_1.3 and Shamiko. Never seen this before. Not sure if this is due to new lsposed modules. Any thoughts?
[Magisk] zgfg:
Are you hiding HMA from Ruru (by use of HMA)?

Either by use of Whitelist mode (screenshot) or Blacklist with a template (two screenshots). In both cases fully passing Ruru as on the blue screenshots
[Magisk] pndwal:
Re. hiding bootloader unlocked from Momo:

Not sure if her innovations will get her handle on the Magisk App home page per:

but I fully agree with this...

What a contributor in the Magisk and Magisk-hiding arena! ... which is what some modders believe is the primary purpose of root. 🤪

Just as @RikkaW's Riru is part of the inspiration for John's Zygisk hooking framework in Magisk, looks like the next major refactor (in the works) will be based on Riru's last hooking method which was originally discovered/utilised for Riru by Canyie (found to be ideal/simple but used mainly in other instruction sets such as x86 devices running arm apps but generally turned off on arm devices). It's the native bridge hooking method with anonymous memory that allowed RiruHide, the inbuilt hiding method in Riru from Haruue Icymoon, to work (from Riru 22.0).

Canyie's hooking method is being developed for Magisk Zygisk by Shana (@yujincheng08, LoveSy) ostensibly to fix issues like:

•Fix executing app_process failed if magiskd restarted #6920

• Magisk Zygisk breaks NDK C++ native breakpoints and stacktraces #6229

• Zygisk modules stacktraces cannot show function name #4776

• Opening apps causes the system to crash and reboot sometimes, if Zygisk is used. #6569

• [Wontfix] Zygisk cannot activate on some old Samsung devices with old kernel (3.19-) #5395

• BYD XDJA container support #6743

• Allow Zygisk hook more native methods #6744

but the benefits for hiding injection aren't to be sniffed at either.

Both the NB loading concept and Shamiko hiding module are @canyie's... Previously her MomoHider was the go-to MagiskHide addon for hiding MagiskHide itself, isolated processes and app zygotes, and modified init.rc traces.

Pine is a dynamic java method hook framework on ART "Allowing you to change almost all java methods' behavior dynamically" and developed for her own "Dreamland" Xposed framework implementation when YHAFA, SandHook and others proved inadequate... She published both the XPosed and the hook frameworks at age 15...

A prolific contributor to Magisk code since that age also, Canyie turned nineteen a fortnight ago... Just thought it worth mentioning here...

👍 PW
[Magisk] WhoIsJohnGalt1979:
@zgfg all okay now. Not sure what was acting up. Set up HMA one more time. Specific theming elements of aospmods which require a reboot and some iconify theming sections inject zygote in momo. I don't use those specific options.
[Magisk] pndwal:
PSA

Samsung Devices section

https://topjohnwu.github.io/Magisk/install.html#samsung-devices

in Magisk Installation Instruction page has replaced Samsung (System-as-root) section (thanks @BlackMesa123), so it now encompasses Sammy devices generally, not just SAR/2SI boot method devices.

Any Samsung users should get familiar with instructions/caveats for Magisk root on Samsung outlined there...

Still watching for action on Patch vbmeta flags in Samsung tar firmware packages optionally #7181, opened 3 weeks ago by BlackMesa123...

👀 PW
[Magisk] newbie1113:
Hi, guys i am in a trouble. Recently, I got a software update (it's a major version upgrade from a12 to a13). So, in magisk manager (it's magisk canary version) I click on uninstall then restore images (after restoring images, magisk was still showing as installed and apps can still get root access, idk why).I downloaded the update and after installation is done i again opened magisk and click on install then install to inactive slot after ota and reboot. But the phone is showing dm-verify corruption and it's keep on turning on and off. Luckily i observed that i can boot into the os as i press power off + volume down to enter fastboot it actually boots the os instead. (the update hasn't been applied)

Now i am seeking for a solution to fix this (and also I don't want any data loss). Can someone please help me. Also i would like to know why did this happened.
[Magisk] Homeboy76:
What phone make/model are trying to upgrade/upgrade from Android 12 to Android 13?

Did you download the update or is it an OTA?

Is Android 12 rooted?
[Magisk] newbie1113:
Sorry that i was unclear it's an OTA.

My phone is Lava Blaze 5G.

Yes it was rooted (no custom recovery for this phone available, so have to root via patch boot.img method). Also the stock os doesn't have any recovery.img so it's a device with A/B partitions.

I was rooted using magisk canary version. (now root is gone, but i have my pc anyways)
[Magisk] pndwal:
So looks like since OTA failed for some reason (I think you did restore slot to stock however, but Magisk was still available as you hadn't yet rebooted)... If booting to opposite updated slot fails, original active slot remains marked as active and you can still boot.

A delta OTA may fail as these build the new images for opposite slot by combining the small incremental change package (only contains changed blocks in updated files) with the previous ROM version images extracted from the current slot and these must be bit perfect stock images to succeed in swapping slots which is only done after the first successful boot... Perhaps you previously flashed some partition or modification other than Magisk?... Anyway you appear to be landing back in original slot due to update failing...

However you should be able to download the latest full OTA package (not delta OTA) or full ROM and install that to get updated slot booting, then just extract the boot image, patch and fastboot flash to root the system on the new current slot per general Magisk initial installation instructions...

Nb. If you wish to ensure the current slot is really restored to stock, dirty flash a full OTA/ROM package corresponding with current version to current slot or extract and flash any partitions you may have altered by modding, eg boot, vbmeta etc via fastboot...

Nb. I understand that the 'install Magisk to inactive slot' method is broken for most Pixel 6 and 7 users installing current updates, so it seems it cannot be relied on for other devices either ATM...

🤠 PW
[Magisk] Homeboy76:
Sorry, I am not familiar with this phone make/model.

Maybe these links will help you:

a. How To Root Lava Blaze/Lava Blaze

b. LAVA Blaze 5G Update Software
[Magisk] newbie1113:
@pndwal I even don't know if magisk is supposed to still work and show installed as i uninstall (restore images).

I don't think i ever flashed some partition or modification other than Magisk and didn't alter any partition other than the boot.

Also i forgot to mention that initially i didn't get any software update (it was showing no updates available) but due to i flashed dreamland i have to boot the phone into safe mode to disable all the magisk module bcz my launcher wasn't working and i was using Pixelify (stuck at "phone is starting") then idk i randomly opened setting to check for any software update and found this update(with all magisk modules disabled and magisk installed) but before that everytime i checked for update it showed no updates available, can you say why ?)

The problem is this brand "Lava" doesn't provide offical stock rom/OTA package from their end and there is rarely any custom rom/recoveries available for any devices under this brand (idk why). I luckily found this old stock rom from some site (i wonder how did these sites get it) and then rooted my device by extracting the boot.img and patching via magisk.

Nb. I searched the everywhere but didn't get the new stock rom or full OTA package.

But now i want to fix the dm-verify corruption and stay with the current os and wait until some site uploads the latest stock firmware (i don't think i will ever get the full OTA updates, have to rely on full stock firmware). How would i do that ?

Also if there's any other possible way to apply the OTA.
[Magisk] zgfg:
Years ago I played with MTK phones, hence just guessing

Couldn't you use MTK Tools to backup Boot partition from the slot it still boots and flash it to the other slot

It seems that the boot.img you used is not from the same ROM. But the original boot.imgs for both slots should be identical
[Magisk] newbie1113:
I don't use windows and can't even run in inside vm (bcz vt-x is not supported by my pc)

No i can assure the boot.img is from the same rom as i extracted it from the official rom and then patched it with magisk.