yashsingh1/xdaforums huggingface dataset:
[Magisk] zgfg:
Your strongbypass.zip now includes only one-line system.prop, nullifying a single ro prop:

ro.product.first_api_level=

I tested on Davinci, Xiaomi.eu, MIUI 12.5/A11 and it works flawlessly: Strong Integrity passing, CTS Profile Hardware backed and no caveats observed.

With no need for safetynet-fix module or its forks

BUT (yeah, a big, big "but") - on Lisa, Xiaomi.eu MIUI 14.0.10/A13, it also passes Strong Integrity BUT I lost the fingerprint (not my finger but fingerprint)

First I observed that I cannot unlock the locked screen by my finger anymore

I went into settings but Settings crashed couple of times when I tried to open Fingerprint unlock

When I succeeded, I found that Fingerprint unlock was disabled (!).

I tried to enable but when I was touching the sensor to add my finger, it didn't react at all

I rebooted, still the same

I disabled your strongbypass.zip, rebooted and I was again able to setup my finger and use it for unlocking

----

Hence I compared the @Displax Test4, and now I'm using a modified service.sh that also nullifies only the ro.product.first_api_level

but 5 seconds after the boot completes

I put that service.sh to /data/adb/modules/hosts

(misusing Systemless hosts module, so I don't need safetynet-fix or other similar modules), it passes Strong Integrity and it works safe (no troubles with fingerprint) on both my Xiaomi.eu phones:

#!/system/bin/sh

until [[ "$(getprop sys.boot_completed)" == "1" ]]; do
sleep 1
done

sleep 5

resetprop --delete ro.product.first_api_level

But of course, this applies to Xiaomi.eu only - for Pixel, etc, the other props are needed as in safetynet-fix Test4
[Magisk] beeshyams:
You are a hero.. Thanks a ton! Unbelievable.

With your mod to @Displax test 4 on Pixel 6a, Android 13, July update, Magisk 25.2 I passed all

Wow, superb.. Take a bow.. @badabing2003
[Magisk] spida_singh:
Pixel 6

GrapheneOS Latest July Update

USNF 2.0 Test 4

Latest Magisk Alpha (https://xdaforums.com/t/...c-released-fork-vvb2060.4424845/post-88706505)

Device Integrity Fails

Meets Basic Integrity

Strong Integrity Fails
[Magisk] shoey63:
Pixel 6 with KernelSU.

Amazing . . .
[Magisk] rushiranpise:
If the custom rom your are using already spoofs gms , and yet you cant pass strong

Eg Crdroid ,EvoX

then shamiko+ modified sensitive props can help passing strong

without usf

Note: Add gplay services to deny list

Tested on a broken tee device
[Magisk] intel_core_i7:
I think I can answer this question already, just asking again for sure: This will never support devices without or with broken TEE, correct? Planning to pull my Redmi note 4 out of the closet but just remembered that the phone doesn't support TEE since maximum official android version was 7
[Magisk] rushiranpise:
with the above method, which i posted

i can pass with broken tee

so must also possible with usf
[Magisk] Stillhard:
Np with broken tee, mine broken too, look at my screenshots
[Magisk] Teleplasma:
Works on OP 8t👍
[Magisk] sawdoctor:
Tested on pixel fold, this one boots fully at least but still fails strong
[Magisk] giociampa:
Strong pass on Moto g 5G plus (nairo) 👍
[Magisk] zgfg:
Not for me on Xiaomi.eu

Btw, Xiaomi(eu) does not have broken TEE

Xiaomi.eu spoofs up to Basic and Device Integrity, I use sensitive_props-v3.zip but it doesn't help to pass Strong Integrity

And of course that DenyList is properly set

It's probably bcs of your broken TEE (as you said)

And it's not only me but also the other Xiaomi.eu users

As said above, that additional prop is needed on Xiaomi.eu to pass Strong Integrity:

ro.product.first_api_level=

Btw for you is maybe that prop already empty (hence you don't need to nullify) - but on Xiaomi eu it is 30 and it must be put to empty to pass Strong Integrity
[Magisk] shadowillusion:
Possible to only expose this 33 to GMS?

I tried on stock MIUI 14, Android 13:

- Default value is 30 and if it set to this, STRONG integrity will fail (other 2 will pass)

- If ro.product.first_api_level is unset/deleted, com.lbe.security.miui will keep crashing but STRONG will pass

- if ro.product.first_api_level is set 33, STRONG will pass and there is no crash. However, opening camera and switching to video mode will disconnect the hardware.
[Magisk] zgfg:
Be careful when playing with ro.product.first_api_level

When I put it to empty through system.prop, I lost Fingerprint and was not even able to set my finger again (sensor did not react) - I have Xiaomi MIUI 24 but Xiaomi.eu ROM (with ro.product.first_api_level=30 as original value)

Hence I use service.sh (posted and attached earlier this morning) where it waits for booting to complete and 5 more seconds, only then I change ro.product.first_api_level

and that way there are no side-effects
[Magisk] Machad3x:
Strong Integrity working in Oneplus 10 Pro with OOS 13.1. Thx!
[Magisk] Displax:
OK, so i decided to release Test3 build as stable version and release Test4 version separately for those people who would like to play with STRONG and maybe find a way to bit challenge with sets deleting *ro.product.first_api_level* not globally to prevent system problems.
[Magisk] badabing2003:
isn't test4 doing exactly that? (what you do in your service.sh)?
[Magisk] badabing2003:
@Displax

In test4, wouldn't it be better to do this only for first api level < 33 ?

This way newer devices would not have to unset it?

# SafetyNet/Play Integrity | STRONG | Hide *first_api_level* in system to open access for *DEVICE_INITIAL_SDK_INT*
sleep 10
resetprop --delete ro.product.first_api_level

change to:

# SafetyNet/Play Integrity | STRONG | Hide *first_api_level* in system to open access for *DEVICE_INITIAL_SDK_INT*
if [[ "$(getprop ro.product.first_api_level)" -le 32 ]]; then
sleep 10
resetprop --delete ro.product.first_api_level
fi
[Magisk] zgfg:
As I noted in my original post with the script, I took the approach from one of the TestX examples by Display - as opposite to Sweer45' who just put it to system.prop (that caused me side effects)

And in the post you quoted now I was answering to a user who described that he.played by changing the ro.product.first_api_level and said that he had side-effects,

but he didn't describe in the post how he changed the prop - hence I wanted advice him to be careful, change must not be executed too early
[Magisk] intel_core_i7:
Thanks guys, I decided to pull my non rooted Redmi Note 4 (mido) out of my closet, installed Magisk Delta (unroot soon becasue I don't want to root that much), zygisk on and with only Test_4 build installed in Modules tab, Strong passed! (Screenshot below)

This is a very rare moment, when a device not supporting TEE (android 7 is the last android version Xiaomi supports for this phone) can pass Strong, which by design is impossible. Wouldn't last long I suppose, but still a very funny thing to see
[Magisk] zgfg:
Yeah, I thing that this leg of the game will not last long

As described in the Whitepaper.pdf (@pndwal linked in one of his earlier posts), the.apk (DroidGuard) pulls the bytecode from Google's backend server, and that bytecode is then executed in the VM for the inspection of integrity

Hence if they have a bug, they can fix it in the bytecode and the improved bytecode will be dynamically downloaded on the future PI API tests, without the need to push new versions of Google Play Services

Besides, as that pdf explaines, DroidGuard is not implemented as part of the GMS (Google Play Services) but in the separated the.apk app

I wrote a simple script (posted yesterday).and found that I have about twenty versions of the the.apk on my /data, all installed during the last three weeks.

It means not just that Google does not clean the old versions but also that they frequently update the DroidGuard and silently push new versions to our phones
[Magisk] intel_core_i7:
In the current status of apps implementing SN/PI we gained nothing and will lose nothing if Google patches this. This is pretty much for showing and flexing with some internet blokes, no real use for this. Enjoy when it lasts, I would expect a few days or few weeks before they patch this
[Magisk] zgfg:
Yeah, that's the whole point

Many people wrongly believe that they cannot use certain 'banking' apps because they don't pass Strong Integrity

Now, with this or that TestX version or one of the forks posted/mentioned here, they will pass Strong Integrity but it will not help them with the stubborn 'banking' apps

Those apps search and find something else - like Momo, who absolutely doesn't care about our joy with green Strong Integrity but insists on its 'abnormal' findings

Or the spinning Native checker that also reports 'injections'
[Magisk] giociampa:
Exactly as I have found with Starling (see the thread here for the cat/mouse games with that one)
[Magisk] intel_core_i7:
They can search for the stupidest things, like if the accessibility services for apps is enabled. :ROFLMAO: Well since we're in a flow, is there any workaround for this?
[Magisk] V0latyle:
What confuses me about this is why the original shipping API level matters in the first place. One would think GMS would just care about ro.vdnk.version or whatever indicates current API level

And this doesn't work for everyone, apparently Pixel Fold still fails STRONG despite shipping with 13.0

But you're much smarter than me in this regard so
[Magisk] sawdoctor:
It's totally baffling me, really can't see why the pixel fold keeps falling when the pixel 7 doesn't. Same hardware (more or less), very similar software build but just a newer device. I'm worried Google has done something and the pixel 8 will be the same way.

Luckily all my bank apps and wallet are working which is all that really matters. I'm just stubborn and want to know what's different/why it keeps falling
[Magisk] pndwal:
Seems it's really to do with DEVICE_INITIAL_SDK_INT... This clue in service.sh for test 4:

# SafetyNet/Play Integrity | STRONG | Hide *first_api_level* in system to open access for *DEVICE_INITIAL_SDK_INT*

The connection/workings are beyond me ATM however... 🙃 PW
[Magisk] Displax:
MOD updated to v.2.0 !

Fix KernelSU support. You still need "ZygiskOnKernelSU".

Fix WiFi calling on some devices (and maybe other related issues) by moving changing *ro.product.first_api_level* from global namespace to GMS only.

Pass *MEETS_STRONG_INTEGRITY*. By default you need device that launched with Android 13+ or custom ROM that manipulate with *ro.product.first_api_level* (>= 33 / or `null` / or not present). If you want to play with it more complex - use separate "-STRONG" build. NOTE: Various system issues are possible on "-STRONG" build!

Source code also published.

Related commit for STRONG: https://github.com/Displax/safetynet-fix/commit/79f6ef22db5eeb717c57a9bd00ee90b8d7cd2201
[Magisk] zgfg:
Sorry for going OT, but it would be also part of the equation.

If you go to (/data/data = /data/user/0):

/data/data/com.google.android.gms/app_dg_cache

you can check how many versions of Droidguards you have

Each one installs to the new folder, my latest from yesterday was:

B8EB1FE48C64CBE5D3BEBCAA046EBB523EC955C5/the.apk

Last but one (about a week old) was:

CFDFF53D48C7796CD7464DD45B79C5FAC21B74C6/the.apk

Each one is about 485 KB and its folder name like:

B8EB1FE48C64CBE5D3BEBCAA046EBB523EC955C5

corresponds to the SHA1 hash of the the.apk file

You have also copies of Droidguards at (more or less same versions - compare their file sizes or better SHA1 hashes, ie subfolder names) at:

/data/data/com.android.vending/app_dg_cache

And if you're using dual apps (or Second or Work space), DroidGuard copies are also at:

/data/user/999/com.google.android.gms/app_dg_cache

/data/user/999/com.android.vending/app_dg_cache
[Magisk] IgorEisberg:
Igor here, Xiaomi.eu Lead Dev. We already know about this, and like the user above me commented, there are serious side-effects, and he only mentioned the issues you can actually see. That prop is a standard mandatory AOSP-defined prop that is checked in many places, like a ton of native libs. This workaround is useless unless access to that prop is only restricted in Play Integrity attestation context, not removed altogether, which isn't that easy to achieve.

And yes, to at least avoid breaking the fingerprint sensor, the prop had to be removed on boot_completed, not on boot.
[Magisk] rushiranpise:
Seems like both version fails on A50 :(

All 3 checks red
[Magisk] sawdoctor:
Ok this is weird but hopefully it might help figure out whats going on. I just opened Androidacy Module Manager and it gave me a message to reset my api keys which I did and now I pass strong on Play integrity API checker.

This is on the pixel fold btw which kept failing strong

Edit @Stillhard this is with your test build
[Magisk] ibbu_37:
Thank you so much because of u i could get this hardware backed..! On one plus 10 pro

Using kernel su i will try netflix and other ott to check whether they work or not coz earlier it was to fail show error coz one plus bl unlocked get detected but surprise to see this
[Magisk] badabing2003:
On Pixel XL

Removing the first API level prop value fails the strong integrity test, setting it to 33 passes.
[Magisk] roirraW "edor" ehT:
Oh, wow. It even passes Strong on my rooted Samsung Galaxy Tab S8 Ultra. (Test 3 did not)

Spoiler content hidden.
[Magisk] LinhBT:
I used LSposed module
[Magisk] LinhBT:
Im using ksu here. And having Alioth, Thyme, Venus are ready to test!
[Magisk] zgfg:
I had it for 10 hours:

resetprop --delete ro.product.first_api_level

postponed 5 seconds after the boot was completed and I didn't observe any side-effect (except for 'enjoying' in the green Strong Integrity)

Particularlly, I successfully unlocked the screen by fingerprint dozens of time

Until now in the evening, suddenly I was unable to unlock the screen by fingerprint and there was shortly a note at the bottom of the locked screen, something that fingerprint cannot unlock

I cleaned my finger and power button (fingerprint scanner is aside), but it didn't help. I unlocked by pin, relocked the screen and tried again, no avail

I had a call and I forgot to check in the Settings before I rebooted

After reboot fingerprint now works fine again but I will see for how long - seems that at some point the fingerprint lib will re-read the (spoofed) ro.product.first_api_level and will stop working again

It shouldt be really implemented into the native code of the Zygisk module (not in the sh scripts where the prop changes affect all apps globally), to target only the process com.google.android.gms.unstable

Xiaomi(eu), A13
[Magisk] LegendaryCheerio:
You little beauty.
[Magisk] problemathic:
everything works for me. enabled zygisk, hides magisk and flashed this module. passed the cts and safetynet. thank you
[Magisk] matfcb:
Xiaomi Mi 9 Pro 5G, latest Miui 13.01., Android 11. Failed in YASNAC cts, Safety Net, device not certified in Play Store. I tried to disable LSposed but phone still doesn't pass Safety Net. I need it to run McDonald's app. Basic Integrity, CTS fail. Nothing of fixes seems working. I tried to put Google Play Services in Deny List, delete data of it, reboot etc It doesn't work. I doubt it will pass on my device. I won't return to old Magisk on Riru to pass Safety Net.
[Magisk] zgfg:
Please first study and follow from yesterday/the previous page
[Magisk] matfcb:
I read everything. Sadly those fixes don't work on my device.
[Magisk] pndwal:
Stock MIUI (not custom EU)? Zygisk=Yes on Magisk App home screen?

Try with NOTHING in denylist and only this USNF module (disable all others and reboot)...

If no dice, do you have TWRP or any TWRP flashable mods? Switched selinux? Had any such mods previously even if reverted?

Did you disable verity/verification or encryption?

Do you have Magisk in boot (ie. not recovery mode / in recovery ramdisk)? PW
[Magisk] matfcb:
Custom EU mod. I have Zygisk as Yes. I will try with nothing but USNF module on. I have selinux permissive. Will try with enforced and only USNF mod. I didn't disable vbmeta verification, it wasn't necessary. I don't have Magisk in Ramdisk.

EDIT. It passed Safety Net check when everything is disabled but USNF and selinux enforcing.
[Magisk] pndwal:
Selinux is probably part/all of your problem... I believe we can't pass deviceIntegrity with permissive set, but there should be no need these days... Why do it?...

Latest @Displax mod should play nicely with ROM integrated SNF now, but there still may be issues with some custom solutions...

You do have Magisk in ramdisk; it can't install anywhere else... But guess you mean ramdisk=no in Magisk, so it's installed in recovery ramdisk ... Nb. Xiaomi bootloaders support ramdisk in boot even though Xiaomi didn't supply one... So if you patched/flashed recovery image, flash unpatched image from ROM back, then patch and flash boot.img w/ recovery mode unselected... Magisk will add a basic ramdisk in boot for magiskinit use... Magisk will still report ramdisk=no for 'no OEM supplied ramdisk in boot partition'.

Edit: disregard all that... Checked device launched with A10, so will be Magisk in boot ramdisk... PW
[Magisk] matfcb:
Thank You for Your help, McDonald's app is finally working with all Magisk mods enabled but SElinux enforcing. I have Selinux permissive for Viper4android. McD app is working without even adding it to Shamiko Deny List. I will just switch from permissive to enforcing when in need.

EDIT. I changed it back Selinux to permissive, McDonalds app works somehow even though Safety Net is not passed. I will keep it that way for now, but will change to enforcing if it stops working.
[Magisk] zgfg:
V4A V2 7.2.1 (several years old) does not require Permissive mode

In case of troubles with installation, try v2.7.2.1 Repackaged or Beta 64-bit v0.2.0 Reverse Engineered - please find more in the V4A thread

The second or third if necessary, must really work for all MIUI versions (up to 13 and 14 - I have two Xiaomi phones, one with A11 and the other with A12 and I've seen ppl confirming for A13)

Ie, Permissive mode is really not recommend, and also not needed
[Magisk] pndwal:
As I said, no need to break Linux security enhancements, especially when you've already broken so much security to root!...I put something about it here:

https://xdaforums.com/t/discussion-magisk-the-age-of-zygisk.4393877/post-88047111

and:

https://xdaforums.com/t/discussion-magisk-the-age-of-zygisk.4393877/post-88052621

and:

https://xdaforums.com/t/discussion-magisk-the-age-of-zygisk.4393877/post-88056483

and:

https://xdaforums.com/t/discussion-magisk-the-age-of-zygisk.4393877/post-88061031

Re. Viper4AndroidFX, even w/ original (older) version you just need to reset Neon driver when selecting legacy mode (ie. when Status=Abnormal.)

In future when you reinstall or have abnormal status, just set legacy mode, disable the module, reboot, re-enable module and reboot again; driver should reset and status should now be Normal... You'll only have issues with Neon driver when installing/changing mode...

I'm using this fork currently:

https://github.com/programminghoch10/ViPER4AndroidRepackaged

🤠 PW
[Magisk] matfcb:
I set SElinux Enforcing, rebooted, Turn on Legacy Mode in V4A and it seems to be working. I can feel it works on YT, Tidal, Spotify. Safety Net passed, Viper4Android working, McDonald's working.
[Magisk] zgfg:
Yes, that's the point. V4A 2.7.2.1 (and newer forks) works with Legacy mode and with no need for SELinux Permissive mode

Btw, I never understood what's wrong (why people are afraid of) with Legacy mode - besides its name😁

To the other side, Permissive mode is first of all not recommended (insecure) and as that a showstopper for SafetyNet/Play Integrity API and hence for the number of 'banking' apos that seek for root - Permissive mode is easily detectible
[Magisk] xdMatthewbx:
Given there's been an update to original UNSF that claims to give what this mod originally delivered over the official module, what exactly does this mod do that the original doesn't? (I haven't tried either yet)
[Magisk] V0latyle:
The original USNF (2.3.1) did not incorporate any fixes for Play Integrity, so @Displax forked it into this branch because he's had the time and energy to keep up with the changes to PI. @kdrag0n has been focused on other projects so while he eventually committed many of Displax's changes into 2.4.0, there have been several changes to PI since then.

So, for now, this fork is the most "up to date" regarding Play Integrity fixes, while Google continues to fiddle with things. Should there come a point when they finally stop messing with stuff we will probably see a lot of the changes committed to the original USNF
[Magisk] Bad Bimr:
Pixel 7 on December Build

Magisk 25.2 (25200) Renamed

Advanced Charging Controller (ACC) v2022.7.30-dev by VR25

Systemless Hosts v1.0 by Magisk

MagiskHide Props Config v6.12-v137 by Dudgeridoohan DISABLED

Shamiko v0.6 by LSPosed

USNF v2.31-Mod_3.0 modded by @Displax

Deny List (NOT ENFORCED)

Chase

Citi Mobile

Discover

Local Bank App

Netflix

Was working good since the 2.31 MOD3 but yesterday it failed. Today I tried to use wallet (used password) and got the error about the device not meeting requirements. exited out, ran Integrity Checker, it passed. I opened wallet back (no password needed) up and it worked. I am a bit confused if I need to add more to the DENY LIST. I used to have Google Play Services, Google Play Services for VR, Google Play Store, Google Wallet, GPay and com,android...wallet enabled but have since disabled them per suggestion from the UNST Thread.

Do I need to enable any of these again?

Would upgrading to USNF 2.4 v1.2 fix any of my issue or introduce more?

Should I update to the January or February build?

I also use the MacroDroid app to run a macro that auto enables NFC when I open wallet and disables it when I close wallet. Could this be causing any issues?

Thanks in advance!

BB
[Magisk] pndwal:
I'd add back G Pay/Wallet only... I understand some have found they don't need to hide root from it but others do...

No need for other Google stuff since USNF hides root from gsm attestation process itself... Nb. Denying modifications in gsm breaks USNF, but proper root hiding (eg. Shamiko which repurposes denylist as hidelist) doesn't so root can be hidden this way from gsm attestation/ droidguard process without conflicts, but there is no real need for double-hiding...

I've updated to latest on Xiaomi RN8T w/ A10 MIUI and haven't had problems with G Pay/Wallet since despite seeing failed deviceIntegrity in Play Integrity API Checker app on one occasion...

Not sure, but it's probably ok if it's not a root app and doesn't detect root...

Welcome... 🙂 PW
[Magisk] Bad Bimr:
MacroDroid is a root app and does require superuser access. I use it to turn NFC on/off when I open and close wallet. It also turns my Wi-Fi on/off based on geolocation. Seems to save some battery with Wi-Fi and peace of mind with regards to NFC.

As far as GPay and Wallet. There are two services for wallet, just the standard or both?

Should I update to a more current build or stay on Dec 22 build?

Thanks Again

BB
[Magisk] V0latyle:
I haven't needed to use DenyList at all for Google processes, but YMMV

I'm not sure the issue is apps that use root as much as apps that manage root.
[Magisk] pndwal:
Interesting... There's a possibility apps detect such root apps... They can usually be hidden from selected apps using HMA LSPosed module...

Seems more likely your issue was due to late start or spasmodic failure in USNF however... 2.4.0 modded builds may be better... 🤔

For most apps incl. G Pay/Wallet hiding root from default processes selected works fine... MS Company Portal (Intune) is one exception where extra processes must be selected...

I'm always using latest Wallet... PW
[Magisk] IgorEisberg:
Your anecdote doesn't disprove anything I said. There are clear side-effects I can easily reproduce. As for the hidden side-effects, well, you can search the whole ROM files and you'll see how many references there are for this prop. Just because you can't identify a side-effect, doesn't mean there isn't any.