yashsingh1/xdaforums huggingface dataset:
[Magisk] V0latyle:
Full OTA includes all previous changes. Incremental OTA only includes the current changes.

All Google releases are full updates, meaning that if you're on the first build available for your device, you do not need to incrementally update - you can just flash the latest build

Very few OEMs publish incremental updates, these are generally limited to "minor" things such as Play Services updates
[Magisk] osm0sis:
It's not about changes, it's about complete partition images. Full contains full images where incremental contains only a differential patch to get the current ROM build partition updated to the new build.

I think Google does do incrementals to save on bandwidth and time to download/flash, since I've definitely had like a 185mb OTA for my Pixel 8 Pro before and that obviously can't be full, but they don't post them for public download.
[Magisk] V0latyle:
Good point. So OTAs would be incremental while factory images would be full.

Why then can you sideload an OTA much newer than your current version?
[Magisk] osm0sis:
Because you're still talking about Full OTAs. Full OTAs are basically just factory images in a zip. You can't do that with Incremental OTAs.
[Magisk] V0latyle:
Ok....so the OTA we might receive over the air is not the same payload as what we'd find on https://developers.google.com/android/ota?
[Magisk] osm0sis:
Yes. Those are only Full OTAs.
[Magisk] zgfg:
Hello @osm0sis, I've observed a problem with your migrate.sh script, if JSON file is compacted.

Ie, when EOLs are omitted, and the whole JSON file goes to the single line, or only some EOLs are omitted and few fields are concatenated - it's still formally correct JSON format.

In that case, the migrate.sh script will incorrectly read all subsequent values from from the first field value in the corresponding concatenated line.

For the illustration, let's take only the partially concatenatedJ SON (for better readibility here):

{
"SECURITY_PATCH": "2016-07-01", "DEVICE_INITIAL_SDK_INT": "25", "PRODUCT": "griffin_retcn",
"DEVICE": "griffin",
"MANUFACTURER": "motorola",
"BRAND": "motorola",
"FINGERPRINT": "motorola/griffin_retcn/griffin:6.0.1/MCC24.246-37/42:user/release-keys",
"MODEL": "XT1650-05",
}

Btw, this JSON is fine, it passes Device Integrity.

However, the migrate.sh will take API level and Product values from the Security Patch value and the resulting JSON will fail even the Basic Integrity:

{
// Build Fields
"MANUFACTURER": "motorola",
"MODEL": "XT1650-05",
"FINGERPRINT": "motorola/griffin_retcn/griffin:6.0.1/MCC24.246-37/42:user/release-keys",
"BRAND": "motorola",
"PRODUCT": "2016-07-01",
"DEVICE": "griffin",
"RELEASE": "6.0.1",
"ID": "MCC24.246-37",
"INCREMENTAL": "42",
"TYPE": "user",
"TAGS": "release-keys",
"SECURITY_PATCH": "2016-07-01",
"DEVICE_INITIAL_SDK_INT": "2016-07-01",

// System Properties
"*.build.id": "MCC24.246-37",
"*.security_patch": "2016-07-01",
"*api_level": "2016-07-01"
}

Seems that the problem is coming from the function:

grep_get_json() { grep "$1" "$FILE" | cut -d\" -f4; }

I tried to fix it by using the object option and a regex:

grep_get_json() { grep -o "$1[^,}]*" "$FILE" | cut -d\" -f4; }

and then it migeates the original JSON to:

{
// Build Fields
"MANUFACTURER": "motorola",
"MODEL": "XT1650-05",
"FINGERPRINT": "motorola/griffin_retcn/griffin:6.0.1/MCC24.246-37/42:user/release-keys",
"BRAND": "motorola",
"PRODUCT": "griffin_retcn",
"DEVICE": "griffin",
"RELEASE": "",
"ID": "",
"INCREMENTAL": "",
"TYPE": "",
"TAGS": "",
"SECURITY_PATCH": "2016-07-01",
"DEVICE_INITIAL_SDK_INT": "25",

// System Properties
"*.build.id": "",
"*.security_patch": "2016-07-01",
"*api_level": "25"
}

which is fine - it does pass Device Integrity but it fails to extract your extensions from the Fingerprint field.

Hopefully, you can fix it that the migrate.sh script will properly process also the compacted JSON source file😁
[Magisk] osm0sis:
As I've always said, I'm not out here trying to do a whole json parser in shell unnecessarily... :p

All of my release posts in my Odds and Ends thread do intentionally say re: migrating:

So you may want to consider just not unnecessarily using compacted json. 🤷‍♂️
[Magisk] Vision:
Thank you. I appreciate.

On A10 had a twrp recovery, after i updated to A11 not install and flash the boot.img with Magisk, but now i want to delete a module if bootloop and if not have pc need it the recovery, and i flsh the previous from A10 works, except have crypto name inside in the /data/adb/
[Magisk] zgfg:
Nevertheless, the proper fix is maybe just around the corner from the given hint

Looks like a challenge for the little grey cells - maybe also for the other masters here in the shell (grep)
[Magisk] pndwal:
Sorry, this has nothing to do with the attestation produced by the device (DroidGuard), only the evaluation of it by Google servers; you may be in good company but you (and others) are conflating the S/N evaluationType response with attestation types actually generated by the device.

To be clear, whether device (DroidGuard) sends "BASIC"-only data or "BASIC, HARDWARE_BACKED" has nothing to do with print/props/field set it sees or with evaluationType Google returns for that matter. 😬

As I said, the fallback to BASIC-only device generated attestation depends purely on whether an intent received by GMS core for key attestation succeeds or not; no amount of manipulating basic signals will cause this to succeed or fail... We take advantage of the fact that use of key attestation is opportunistic (i.e. falls back to basic integrity checks if it fails) and prevent GMS (core) from getting the attestation certificate chain from KeyStore by checking the stack for DroidGuard and 'pretending' that the device doesn't support key attestation... If GMS core does obtain keystore backed measurements however, then that's what's contained in the Protobuf message received by the Google backend and used for the final JWS it generates.

Many have conflated (and are still conflating) S/N evaluationType response with device (GMS Core/DroidGuard) generated attestation types; These are not the same!!! The evaluationType label is simply indicating what attestation types Google's server based algorithms have decided to accept (nb. BASIC attestations will be accepted for some measurements, but HARDWARE_BACKED may be required/enforced for others)...

Comparing scenarios for failed device integrity responses may help understanding:

1) Device (DroidGuard/GMS core) may be sending HARDWARE_BACKED measurements although the API returns only 'BASIC' for evaluationType (read no enforcement for HARDWARE_BACKED evaluationType) so integrity attestation result is a Fail since the API still actually accepts HARDWARE_BACKED measurements and we can't spoof Verified boot state for these measurement types...

2) Device may be sending only BASIC measurements although the API is returning 'BASIC, HARDWARE_BACKED' for evaluationType (read server algorithm is enforcing the use of HARDWARE_BACKED evaluationType for some measurements) so integrity attestation result is a Fail simply because the API (server algorithm) is not allowing BASIC evaluation for some measurements (read requires HARDWARE_BACKED evaluation for an integrity attestation Pass result).

Hope this clarification helps. 🙃 PW
[Magisk] wfred:
Also executing with MiXPlorer. Folder set up pretty much like you describe.

When I run the script I get the following error message
[Magisk] pndwal:
As has been mentioned, online packaged OTA releases are full OTAs since delta (differential/incremental) OTAs can only work if an existing bit-perfect installation exists to build the new updated partitions from... Previous images were used to create the differential data by comparing with new full images and then extracting only changed blocks of data to be used to build new partition either by creating a new image (A-only devices) from existing partitions and delta OTA differential data and data address to be installed by update engine later, or by 'seamlessly' creating new partitions ('streaming' combined data to inactive slot of A/B devices) directly using active slot partitions, delta OTA differential data and data address to be simply made active on reboot...

This makes delta OTA updates both 'seamless' (A/B only) and very small, but as an expected existing OS (bit perfect) is required, OTA will fail if fully stock images aren't restored... There's no such need with full OTAs as these won't check the active installation.

I put more details in a long post here:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-88954299

🤠 PW
[Magisk] kaidelorenzo:
Well I feel like I tried setting every possible build.prop value to the stock one. The one value that I couldn't change is

ro.boot.verifiedbootstate

. It's orange once booted into the OS which is to be expected. Do you think this could be what play integrity is noticing? Or perhaps there is some other "sensitive" prop I missed?
[Magisk] maxim.a.petrov:
In general, such a disaster. I have already written about it here more than once. The Device_Integrity check fails... Only Basic passes. Although the Play Store says that the device is certified, but nothing works in fact. It does not allow you to install applications, etc. I have already installed different modules and firmware, the same thing... I cleaned the data of all services and the framework. Quite recently, everything worked. But one day everything stopped being checked.... What else can be done? MIUI EU 10.3.5, android 9

View attachment 6082890View attachment 6082891View attachment 6082893View attachment 6082894
[Magisk] maxim.a.petrov:
View attachment 6082899
[Magisk] dmenezes:
Don't worry, relief is at hand! And would have been even faster if you tried and had a look at this thread, just looking at the most thanked posts (bottom/side panel depending on whether you're reading this on a phone or on a computer) would have brought you to this: https://xdaforums.com/t/module-play-integrity-fix-safetynet-fix.4607985/post-89390475

So, go there and follow the link to the release, follow instructions, and in a few minutes you're going to have MEETS_DEVICE back!
[Magisk] dmenezes:
Just keeping y'all posted:

And today's been 10 days already, and MEETS_DEVICE is still holding:

View attachment 6082909

Who knows, depending on how industrious the Goolag PIGs are feeling these days, maybe it will even last a month and this whole SNAFU become at least as manageable as my monthly LineageOS update... 😁
[Magisk] dmenezes:
I just want to say a big "thank you" to @pndwal for the time and patience he spends on his very explanatory posts to try and educate the rest of us about the intricacies and inner workings of SN, PI, TEE and assorted Goolag trickery.

I read them all and while most of it go right through my head, I owe a lot of the little I know on these subjects to him.

So thank you again @pndwal!
[Magisk] zgfg:
Are you testing with SPIC or TBChecker - you must have that app installed. You can manually open them and test PI?

It also calls am and uiautomator, try to execute them from Terminal Emulator (they should be built-in)

Not ro mention that you must have root and MiXPlorer granted root if executed from MiXPlorer

Sorry, from what you showed I have no idea where it that service or transaction. When it happens, right at the beginning, or after the script opens SPIC/TBChecker... Maybe make a screen-recording
[Magisk] maxim.a.petrov:
Thanks, but this method doesn't work
[Magisk] Wolfcity:
Have you inserted your mined props or any prop?
[Magisk] maxim.a.petrov:
No, I don't understand how to do this.
[Magisk] zgfg:
Everything is described in the most liked posts you will find here. Hundredths of other users here made it and it works for them. But ok, things are not that simple

Consider unrooting, reverting to stock, relocking the Bootloader and you will never have problems with GPay, banking apps, etc
[Magisk] skvalex:
Patch the boot.img yourself using magiskboot method described here: https://kernelsu.org/guide/installation.html#using-magiskboot

Just installing precompiled boot.img never worked for me too.
[Magisk] DougMG:
Thanks. Worked perfectly doing it that way.
[Magisk] chiteroman:
You must disable avb, there is a command in fastboot to flash vbmeta with avb disabled. Also Google provide a vbmeta.img with everything disabled.

I'm not sure if it will work on Pixel phone, but in my Xiaomi it works.

EDIT: I just read in KernelSU web that they uses a rare format for boot.img, seems that it's the problem instead avb. Ignore this 😂
[Magisk] chiteroman:
v9.9 didn't work for you?
[Magisk] CiLiBi18:
I didn't test it, do you want me to test?
[Magisk] osm0sis:
You should always be testing with the latest stable before reporting an issue.
[Magisk] CiLiBi18:
That's what I did.

I tested every single latest release before posting a comment. I'm developer IRL, I know how it works. It's just that I was afk since october 18th.
[Magisk] wtf!!droid:
anyone has v9.6 of play integrity fix? looking for specific version i'm on android 13

was able to run Indian banking apps along with also android pay was working
[Magisk] Ginosius:
OnePlus 7T Pro migrated from LineageOS to CrDroid (A13) because it has support for KernelSu builtin.

- KernelSu 0.7.0 (11326)

- ZygiskNext v4-0.8.1 (111-47e515e-release)

- Shamiko v0.7.4 (188)

Tested v9.9 and v10 (pre-release).

Both working fine here.
[Magisk] chiteroman:
New prerelease version! Now the hook is made in preApp (zygote) instead postApp, I don't know if this is better... Also I removed service.sh and only patch ro.boot.flash.locked in system.prop.

You can download here: https://github.com/chiteroman/PlayIntegrityFix/releases/tag/v11

Spoiler content hidden.
[Magisk] martinez2018za:
Did you mean pass strong integrity ??
[Magisk] immortalwon:
Strong will not be passed again so easily. It was a fluke / bug with the keys on google servers. Only a private exploit can bypass strong integrity (which will be worth thousands of dollars on google bounties) or a locked bootloader device with a functional keymaster.

Google has become the "trusted" authority between all android manufacturers so they are essentially the police officer that checks peoples ID's before they enter the building. The integrity system is something similar like that.
[Magisk] V0latyle:
I personally wouldn't give anything access to my phone if it were closed source. You never know if someone is hiding a back door or some other malicious surprise. Magisk alone isn't the issue here, and Google likely doesn't have any interest in its workings. Modules that defeat root detection, on the other hand....
[Magisk] Ginosius:
Still working fine here :)

See my previous post for rom and kernelsu versions etc..
[Magisk] chiteroman:
If your device has been released with Android 12L or lower you can use this: https://github.com/chiteroman/safetynet-fix-mod instead PlayIntegrityFix. It's a minimized version of Displax's one. It's the one I'm using on my POCO X3 Pro.
[Magisk] chiteroman:
View attachment 6029969
[Magisk] dummytest97:
I got this problem safetynet fail too, but i still using android 10 , I don't know since when it fail, already try safetynet fix by displax and yours and safetynet test still fail. Basic integrity pass, CTS profile match Fail.

My phone is Mi 8

Rom Xiaomi.eu 12.5.2

Android 10

Magisk 23
[Magisk] chiteroman:
Old Xiaomi.eu roms (like yours) need PlayIntegriyFix: https://github.com/chiteroman/PlayIntegrityFix/releases/latest
[Magisk] dummytest97:
It worked , thank you , now using magisk 26.4 and yours module only.
[Magisk] pershoot:
@chiteroman All is well and Tap to Pay use is confirmed working, on November patch set (A14), 7A, PIF v9.9 and Magisk 26400. I wanted to let you know. Thank you.
[Magisk] beeshyams:
Very informative 🙏, though I confess I understand little bit it's still good to read these posts 😂
[Magisk] osm0sis:
That's definitely the one. It requires using resetprop. See the post-fs-data.sh and service.sh scripts in the module for all of the "sensitive" props:

PlayIntegrityFork/module at main · osm0sis/PlayIntegrityFork

Fix Play Integrity (and SafetyNet) verdicts, allowing custom fields and props - osm0sis/PlayIntegrityFork

github.com

If you're on older Android (7-9) on stock you should just install Shamiko, and put com.google.android.gms.unstable on the DenyList (Enforce disabled, per Shamiko instructions). In my testing it'll handle all the props for you and hide root from Play Integrity for you and you will pass.

Android 10 and above seems to require spoofing a fingerprint with a PIF module, even on an older device like OnePlus 5.
[Magisk] maxim.a.petrov:
I managed to collect the fingerprint, json. Well, it doesn't work properly and the Device_Integrity check doesn't pass, only basic. Therefore, in my case, this is not a solution to the problem. And offering to upgrade to the official firmware is not a very good offer.,
[Magisk] dmenezes:
That's why it's not working! 😁

Seriously: without a good, un-banana-ed fingerprint, it's not going to work. You have to get one. And with Autopif.sh (included with the R8 module I pointed you to) it's really easy.

But you have to put in the time and effort to understand it enough to make it work. No one can do that for you.

> I managed to collect the fingerprint, json. Well, it doesn't work properly and the Device_Integrity check doesn't pass, only basic.

This means you messed it up somewhere! Really, it works: I (and a ton of people here in this very thread) have it working right now.

> Therefore, in my case, this is not a solution to the problem.

Mate, I understand your frustration and wanting a 'quick' solution to this, but the quickest is installing @osm0sis' R8 and running autopif.sh. The step-by-step guide works, but you need to follow it to the letter. And you need to remove/undo all the other crap you possibly added/done to your phone while trying to fix this thing.

> And offering to upgrade to the official firmware is not a very good offer.

Sure thing or you'd have done it already: no one wants to go back to unrooted/stock after having root/custom. But again, you have to put in the time and effort to make it work. If can't or won't, @zgfg suggestion stands and the best you can do is go back to stock.

Just a tip: your attitude of simply claiming "it does not work" doesn't help, and make you look rude and entitled. Try and be a little more humble and, after following the instructions here and you still doesn't have MEETS_DEVICE, come back here and post an exact description of what you've done plus additional data (eg logs) and we will try to help. If you don't, no one here will be able to help you, unfortunately it's as simple as that
[Magisk] zgfg:
Then all up to you
[Magisk] wfred:
Thanks, I found the issue.

I was executing through fx, not mix.

Everything worked fine when I executed the script with MiXPlorer
[Magisk] mufcforever:
What does "the device does not support hardware-level key attestation" mean?
[Magisk] Slim2none4u:
Google man!!! Google!! Search! TF

A device might not support hardware-level key attestation if it's an Android version 7.0 or lower, or if it's not a Google Play device. The device manufacturer can create their own root and make claims about what the attestation means.

Verify hardware-backed key pairs with Key Attestation | App quality | Android Developers

A tool for verifying security properties of hardware-backed key pairs.

developer.android.com
[Magisk] maxim.a.petrov:
Tell me where to find it and how to run it? please.
[Magisk] bondik77:
🔧 [MODULE] Play Integrity Fix (SafetyNet fix)

PLAY INTEGRITY FIX This module tries to fix Play Integrity and SafetyNet verdicts to get a valid attestation. BEFORE YOU START: - Your ROM must be signed with a private key from maintainer, you can check with this command: unzip -l...

xdaforums.com
[Magisk] pndwal:
... will not. Keymaster HAL ver. 3.0 is required. 🙃 PW
[Magisk] forserg:
Hi guys, is it possible to fix somehow not more available Capital one banking app with my old set up?

Samsung S10+ Stock rom Android 12

Magisk 26.1, Hide, Zygisk available, DenyList Capital One

Play integrity Fix 15.9.6

Shamiko 0.7.3

YASNAC : basic and CTS passed

Play integrity API checker:

meets device: green

meets basic: green

meets strong red

Thanks for advance.
[Magisk] pndwal:
Suggest you use lasted stable Magisk (not latest Canary as Hide the Magisk App is currently broken) or at least Magisk 26403+ which introduced new code injection mechanism for Zygisk, ie. native bridge which is much better for hiding Zygisk memory etc in conjunction with Shamiko... Suggest you upgrade Shamiko too for improvements...

Many more bank app root detections can be bypassed with native bridge Zygisk loading... Same loading method Riru injection used... 🤠 PW
[Magisk] forserg:
Tried to update Magisk trough magisk app couple times, got boot loop.

Is twrp option will be better or it doesn't matter?
[Magisk] 에어 론 리:
Good day !

I've used your module Play Integrity Fix, also look into Play Integrity Next, and combine them into one module.

It works perfectly with mine own rom (LG v50, Horizon ROM).

BUT. I replaced your script with a little modified mine and made own app - more simple and little, so overall module takes 4.45mb with standart zip compression.

I want to advice you to make new universal module as I made - it will combine two modules and provides fingerprint substitution and pif downloader inside. one module and no need second.
[Magisk] pndwal:
I assume you have Magisk in /recovery ramdisk (Recovery mode Magisk)... Some recent Magisk builds were messing with Recovery mode toggle and causing bootloops... I'd try patching AP binary with latest Magisk ensuring Recovery Mode is selected, then flash all binaries with HOME_CSC again. Use ADB, not MPT for file transfers... If you still get bootloop you should delete all data in /data/adb for clean Magisk configuration... I'd be inclined to do that before first try if you anticipate issues...

If you need Recovery Mode Magisk, installation via TWRP is not an option. 🤠 PW
[Magisk] shoey63:
Google sometime send full updates OTA, the so called 'forced update'

In this case you don't even need to restore images. It's the same as as sideloading a full OTA.zip in recovery.
[Magisk] zgfg:
Thanks, good to know - and did you find some?

---

Third day of testing, found so far 160 (4%) from the tested 3900 - planning to test 2600 more
[Magisk] DIXES:
But Shamiko requires Android 8.1+ unfortunately.
[Magisk] osm0sis:
In that case (rarer and rarer), I'd suggest USNF MOD and an Enforced DenyList: https://github.com/Displax/safetynet-fix/blob/dev/magisk/customize.sh#L13

I'm considering modifying my PIFork to do a similar scripts-only install for older Android, but Shamiko is generally a better option still wherever supported.
[Magisk] neonblind:
Hi folks,

up until yesterday i pass device integrity. i did not change anything. now it failed. using magisk delta, lsposed, fork from osm0sis with my own custom pif taking from an old lenovo tab shipped with android 7. it worked this way for months. i think it failed since play store updated itself to version 40.2.x yesterday.

what are my options?
[Magisk] osm0sis:
Use my autopif script (linked in Resources in my README) to get the Xiaomi.eu print and see if your setup still works in general.
[Magisk] Toastking:
Hi all,

since today all Microsoft apps (Teams, Outlook etc) stopped working with the reason that my device is rooted. They have been working for many months before that.

I still pass Basic Integrity and Device Integrity just fine. Google Wallet still working. Magisk is hidden. Newest OTA for Pixel 8 is installed.

Newest versions are in use, Magisk 27000 and play integrity fix 15.9.6.

I use a custom pif and have not changed it for months.

Any ideas how to solve this?
[Magisk] pershoot:
Try Shamiko (turn off Enforce DenyList):

Releases · LSPosed/LSPosed.github.io

Contribute to LSPosed/LSPosed.github.io development by creating an account on GitHub.

github.com
[Magisk] Toastking:
Thanks! I do already have shamiko 1.0.1 installed though. I really have no idea why it stopped working, can someone confirm the MS for Business apps are still working for them?