yashsingh1/xdaforums huggingface dataset:
[Android Software Development] profetia:
Thank You!

Works great on my rooted:

Pixel 5 January 2021 Update

Magisk 21305

Manager 4831 (15)

Safetynet fix 1.1.1
[Android Software Development] xp99:
Confirmed as working on Pixel 3a on android 11 January 2021 release. Used v1.1.1.

magisk: 21.3 (21300)

magisk manager: 8.0.6 (4826) (15)
[Android Software Development] eustachy:
FInally I got that working as well :). I hid MManager, updated magisk to 21.4, added MagiskHide Props COnfig and installed safetynet fix from Magisk console (instead of TWRP) and ... it works !!!
[Android Software Development] Kurt Krummbein:
I'm on Xioami Mi 10T Lite (gauguin), running AndyYan LOS 18.1-20210111-GSI

Used: v1.1.1

magisk: 21.3 (21300)

magisk manager: 8.0.6 (4826) (15)

Guess i also need MagiskHide Props Config ... tried that using Vendor-fingerprint (proposed for GSI), but that leads to a bootloop (saw in the logs some messages with camera3 HAL crashing) ... have a nice graveyard with many tombstones now :-).

Will wait for a device-specifiy fingerprint :-).

Greetz

Kurt
[Android Software Development] AndDiSa:
@73sydney hmm ... but for me I had to enable the wallet within my deny list, shouldn't that remain enabled, when only the package name changed
[Android Software Development] Nova_Max:
Switching to Delta unfortunately didn't fix the issue for me.

I set Magisk Hide to whitelist.

SafetyNet and Play Certificate pass.

Oprek doesn't find anything.

With zygisk disabled

Momo finds su

With zygisk enabled and without shamiko

Momo finds zygote

With zygisk enabled and shamiko

Momo detects nothing

Universal SafetyNet is necessary if zygisk is enabled. Maybe. Doesn't seem to be responding now. Maybe I reached some sort of API limit.

None of these combinations worked with Wallet
[Android Software Development] rodken:
Surprisingly, I was able to update to Wallet > Pass all requirements > No need to have Wallet selected in the denylist.

-- Alpha Magisk [25102]
-- Wallet v.22.26.15

-- Shamiko v.0.51
-- USNF v.2.2.0

-- MHPC v.6.12

-- Hide UserDebug v.1.0

-- LSPosed v.1.8.3 (6587) - Zygisk
++ Core Patch v.3.8
++ DevOptsHide v.2.1
[Android Software Development] zgfg:
I would suggest to rather enable in MagiskHide those apps you need, instead of Whitelisting (there was a discussion in Magisk or Delta thread that MagiskHide whitelising takes resources)
[Android Software Development] 73sydney:
I literally did the update in bed last night (i manually update everything, so i know whats going on) and after the update the name had changed to Wallet in my Deny List...but it was still ticked as the package name hadnt changed

Perhaps you removed Pay and installed Wallet?, in which case, yes, you would need to tick it (again)

Its been unnecessary for me for about 1.5-2 years to have Pay in the Deny List/MagiskHide, but its force of habit (just in case). Its always ticked as its saved in my MagiskHideDenyBackup backup and installed again when i restore it. My GPay module still has it automatically hidden during install too....god i keep waiting for the day people stop using that, but for some people (had one today who PM'd me) it for some reasons sometimes is the only thing that works...i wish it would die..BostonDan and my abject laziness to do things manually have a lot to answer for :)

Update:

it got me, finally :)

the wallet issue is realsies, but also weird and random:

https://xdaforums.com/t/working-mag...s-of-gms-17-1-22-on-pie.3929950/post-87180731
[Android Software Development] Makishima:
I have Zygisk enabled and Google Wallet added to the denylist and the denylist is enforced, as I said. Why should I have denylist not enforced? I do not have Shamiko, though, it worked just fine without it before.
[Android Software Development] zgfg:
Not enforced only if you have Shamiko.
[Android Software Development] Makishima:
Yep, I looked it up afterwards. But I don't have it... I'll try it, but I'm seeing lots of people in the other thread too that did not get it to work with Shamiko either. I tried clearing Play Store/Services and app data in flight mode, reinstalling the app etc. Device still shows Certified in Play Store and Netflix is showing up in the results.
[Android Software Development] ai024:
I've managed to get it working thanks to this comment in another thread. Changed device CTS/fingerprint in Magiskhideprosconf to Android 10 version, cleaned up Google Play Services and Store data/caches, rebooted and voila. Seems Android version is critical, with Android 12 fingerprint it wasn't working.
[Android Software Development] Makishima:
Does this not mess up anything else?
[Android Software Development] ai024:
No, everything is working. I had to add cards again to the Wallet though.

Everything else works smooth (other banking apps, Play Store, etc), but back again they were working fine, only Wallet was complaining.
[Android Software Development] zgfg:
Sad that thread title still names USNF v1.1.0 (v2.1 was long ago released on GitHub, discussed here and in use)
[Android Software Development] mrjuniork:
OP has been last seen on XDA in August 2021, so it's safe to assume that his interest is more towards GitHub activity.

I'll try to reach out to the Dev in order to get the OP updated accordingly.

Cheers
[Android Software Development] Makishima:
Update... Device is still showing up as certified in Play Store but Netflix and other apps are no longer showing up... Spoofing the fingerprint to A10 did not help either.
[Android Software Development] pndwal:
Folks, the SafetyNet API was depreciated last Month with 'full turndown' slated for June 2024 and the introduction of the new Play Integrity API. It has also become clear that Google apps are simply the first to adopt the long foretold Play Integrity API; all responsible banks are bound to follow suit in short order, and at least before the June 2023 migration deadline.

This means (assuming fully deployed Hardware Key Attestation doesn't come first 😬) that the need for a 'Universal Play Integrity Fix' has become quite urgent.

We currently have workarounds involving using older fingerprint props by means of MHPC module (similar to fix needed for uncertified ROMs), but success/mileage varies per device and users of regular bank apps / gamers etc on stock devices will all soon be forced to experiment with MHPC prints also... This is hardly ideal.

So I've made an issue report/request on USNF GitHub as follows. This information may be insightful to users here also...

Please let me know here if I have missed anything important, or add any technically relevant details there...

PLEASE DON'T spam that issue with unimportant details or queries... (The previous issue is already burgeoning w/ OT.) That's what this thread is for... 😛 :

Here's hoping... 🙃 PW
[Android Software Development] V0latyle:
Are you talking about Play Protect certification? My Pixel 5 passes both SafetyNet and Play Protect, yet somehow GPay still detects root.
[Android Software Development] zgfg:
Don't you see in the quoted post the dates in future?

It's an announcement about the changes to come - btw, to push the new API, Google will need to update Google Play Services...
[Android Software Development] plepew:
@pndwal

Thank you so much for the clear & detailed explanation in both posts (here & the other thread, where you shared this post).

As I was reading through many the previous posts over the last week, I got more confused on what is happening on the immediate situation with GPay/Wallet & the longterm goals & changes Google has planned.

I was successful in using Props for the Fingerprint workaround yesterday, despite still not clearly understanding what is going on, until now.

Cheers!! ✌️

** The following comment is not directed @pndwal at all!! **

There are some that make comments to read, read, read...which is what ppl should do in general...but not everyone is as knowledgeable, savvy, or experienced in doing any of these workarounds & stuff.

I found some of the posts in recent pages to me disrespectful, condescending & agressive toward ppl that are simply trying to understand & looking for help. These forums are to share, inform, assist and help ppl when they need it the most!! It should always be positive. If you are angry towards what Google is doing, take it up with them, not the members of any level in XDA community.

✌️
[Android Software Development] V0latyle:
I did see the posts, I'm asking if Play Integrity and Play Protect certification are the same thing.

And @plepew is exactly right. Seniority and expertise does not give anyone license to be rude or condescending. If you find yourself unable to respond in a patient, helpful manner, you should avoid posting at all. Remember that disrespect is absolutely not tolerated on XDA. Compliance with the Forum Rules is mandatory, and no one gets a free pass.
[Android Software Development] zgfg:
From the post and the linked article it should be understandable (if reading carefully before asking) that Google is going to replace SafetyNet API with the new API, and in the foreseeable future - as they say, old API will be removed by June '24, but they ask banking apps to adapt to the incoming API till Jun '23. We are now in Jul '22

Somebody asked how come the SN still works - of course it does since it is still the old SN API, not full-proof (that's one of the main reasons Google will replace) where we can still use the old known holes to bypass
[Android Software Development] V0latyle:
Right, and I understand that SafetyNet and Play Protect are not the same thing. What I'm asking is if Play Integrity is an evolution or extension of Play Protect, or if it's going to replace both Play Protect and SafetyNet?
[Android Software Development] ipdev:
Play Integrity is a new (improved) way to check the same things.

It replaces Play Protect and SafetyNet.

There is a short video introduction on Google's website.

Play Integrity API - [developer.android] - Link

Along with a link to the documentation.

Quick links.

Introducing Play Integrity API - [YouTube] - Link

Overview of the Play Integrity API - [developer.android] - Link​

Hope it helps more than confuse. 🙃

Cheers. :cowboy:
[Android Software Development] V0latyle:
That's the answer I was looking for, thank you!
[Android Software Development] 73sydney:
@ipdev and @pndwal did a much better job than my earlier hit and run posting of an androidpolice article from just last month, which gives a roadmap of nearly 2 years...i guess it makes sense if theyve gone hard and early for their core apps...

Like most i only discovered this new paradigm shift by coming across the linked article when the smelly stuff hit the fan or from links from ipdev and pndwal
[Android Software Development] 1nikolas:
That is true but I was talking about the 3 flags of the "Genuine Android device" thing. The "old" (aka current) app only checks for MEETS_DEVICE_INTEGRITY but there are 2 extra flags, MEETS_BASIC_INTEGRITY and MEETS_STRONG_INTEGRITY which are (as far as I know) one to one with the SafetyNet Basic and CTS profile (but of course more strict). The latter 2 are available only for apps through the Play Store that's why I made a new better app for and uploaded it on Play Store. The only problem is that Google tells me they need to "Verify my ID" and this takes 2 business days (so that is tomorrow). In the meantime you can check the source code which is available on Github (frontend and backend)

Note: I havent actually tested the functionallity of the 2 extra flags because, well, I can't until the app is published on Google Play
[Android Software Development] pndwal:
No... Play Protect status (at least currently) relies on SafetyNet API which was deprecated last month.

This concerns the SafetyNet replacement called Play Integrity. 😛 PW
[Android Software Development] TraderJack:
Would be good to know exactly what they mean how they are determined!

This is what is out there:

Integrity verdicts | Google Play | Android Developers

developer.android.com

So what is interesting is my device (and I'm sure others) according to your app is simply showing MEETS_DEVICE_INTEGRITY.

At this point, they must not be opting in for the "additional labels" as mentioned above. If they are they certainly would not be delivering the MEETS_STRONG_INTEGRITY label. If they were it would mean that hardware-backed attestation was either not really necessary, or still being fooled by USNF.
[Android Software Development] 1nikolas:
Also this is interesting:

It checks for bootloader too (unless SafetyNet did that too)
[Android Software Development] TraderJack:
Yes I also read that and found it interesting, but assumed anyone who wanted would read the full page (as you did!).

I believe, SafetyNet would have certainly checked for bootloader for HA.

But with USNF, we only were ever reporting Basic (saying we couldn't perform HA), so they would not have known if it was locked or not.

Now, according to my theory above, we have to prove our Hardware Attestation status through the new API in order to be given a STRONG rating.
[Android Software Development] Orphee:
Hi !

Samsung Galaxy S20 5G with Android 12.

as everybody there, new Google check killed Pay features.

My bootloader is unlocked

Magisk 25.2

Safetynet fix module

I used Props config to fake S20 ultra Android 10 from certified list.

Wiped Play services and GPay. rebooted.

It did the trick, for now.

GPay/Wallet is working again.
[Android Software Development] desvariando:
I am on Magisk on a custom ROM on Android 12 which mimics a Pixel 5 with Android 12 fingerprint. It only passes Basic integrity.

Play Integrity fails.

However, when removing Magisk, despite being on Android 12 and with Basic Integrity, "Play Integrity" passes.

So, there is something else behond hardware attestation, as otherwise I wouldn't be able to run the "Stock ROM" passing Play Integrity.
[Android Software Development] TraderJack:
I don't think that is definitive.

Also. Define what you mean by "Basic integrity"? Are you speaking about SafetyNet?
[Android Software Development] desvariando:
Yes. Basic SafetyNet attestation.
[Android Software Development] pndwal:
But if MEETS_BASIC_INTEGRITY and MEETS_STRONG_INTEGRITY are one for one with original Basic Integrity and Compatibility Test Suite Profile match (I'm not sure they are 'one for one', but seems likely they are very similar at this point, and can still be made to fall back to a basic attestation/evaluation type), then these are likely opted for by the apps and passing (by using USNF)...

My conclusion is that GPay, Play Store etc are calling STRONG_INTEGRITY verdict in fact, but the basic DEVICE_INTEGRITY verdict is using fingerprint prop in a way that's not yet clear to me... It seems likely that this is actually bypassing hardware attestation for this verdict (a fallback to basic?) per some Google server end white or black-list of fingerprints currently...

It is clear that USNF is working currently for PI API as for S/N once a passing fingerprint is selected (at least for A11+ devices generally; A10- seem to pass PI's DEVICE_INTEGRITY verdict as is); this attestation will fail where the selected fingerprint fails old CTS Profile match or if USNF is simply disabled, indicating that a STRONG_INTEGRITY verdict is probably being effectively bypassed by USNF... PW
[Android Software Development] TraderJack:
I don't think I agree with much of that (FWIW).

To start. SafetyNet check is made up of several components, but the two most important are ctsProfileMatch and basicIntegrity. See here.

It would appear based on verbiage in the PI-API that MEETS_STRONG_INTEGRITY requires Hardware Attestation.

I'll concede that the documentation isn't 100% clear. It clearly says has a "strong guarantee" but it also say "SUCH AS harware-backed proof of boot integrity" (i.e. HA). I think it is not unreasonable to assume that MEETS_STRONG_INTEGRITY requires a successful HA, which USNF will not produce.

I think MEETS_BASIC_INTEGRITY is on par with SafetyNet passing with basicIntegrity=True, whereas MEETS_STRONG_INTEGRITY would be SafetyNet passing with Hardware Attestation.

I'm also curious to how you believe that USNF is definitively working for PI API? We can assume that USNF is functioning as it did before. Meaning that when HA is requested, USNF causes it to failback to basic. This would therefore make the device pass SN with a qualification of basic which would therefore allow the device to meet the PI API requirement of MEETS_BASIC_INTEGRITY assuming that the CTS Profile is being matched to a device which currently does not require HA to meet it.

Again, these are my thoughts just looking at the available documentation and data we have so far. I'm interested in further discussion.

EDIT: AHA - I found I think part of what we are looking for:

Migrating from the SafetyNet Attestation API | Google Play | Android Developers

developer.android.com

I believe it is backing up my statements. It shows that the original SN checks of basicIntegrity and CTSProfileMatch only contribute to the decisions and are not a one-to-one match.

What is very interesting about this chart (and although it does reinforce what I was saying, it also muddles it with misinformation from other posts). Previously the documentation stated that MEETS_DEVICE_INTEGRITY is the standard response to device_recognition_verdict. It also says the additional data labels of BASIC_OR_STRONG can be delivered if requested.

However this chart seems to indicate that MEETS_BASIC_INTEGRITY can be returned independently of MEETS_DEVICE_INTEGRITY, which to me would be completely contradictory to what was being stated in the previously linked section.

Regardless, it shows that:

MEETS_BASIC_INTEGRITY is equivalent to a SafetyNet pass of ctsProfileMatch = True and basicIntegrity/Basic Evaluation. This is what USNF provides.

MEETS_STRONG_INTEGRITY is equivalent to a SafetyNet pass of ctsProfileMatch = True and basicIntegrity/HA Evaluation. This is not going to be achievable on almost any rooted/unlocked device.
[Android Software Development] zgfg:
More exactly, per Play Integrity API documentation, Device Integrity Verdict mapping table:

Migrating from the SafetyNet Attestation API | Google Play | Android Developers

developer.android.com

SafetyNet basicIntegrety = Play Integrity MEETS_BASIC_INTEGRITY

SafetyNet basicIntegrety + ctsProfileMatch with Basic attestation = Play Integrity MEETS_DEVICE_INTEGRITY

SafetyNet basicIntegrety + ctsProfileMatch with Hardware_backed attestation = Play Integrity MEETS_STRONG_INTEGRITY

Screenshot from the API doc attached

Edit: I see now that @TraderJack has already quoted that mapping table😁
[Android Software Development] Displax:
So, here is my modification of USNF with Play Integrity API bypass.

It changes fingerprint to old 7.1.2 6.0 (LOL) and apply it only for GMS SafetyNet process (by Zygisk injection), so your original prints/security path level does not change. This avoids many side effects/problems with global props changing.

Updated 3.0:

No words needed, you understand everything yourself 😜

Updated 2.1:

Hide "Enable OEM Unlock" setting

Updated 2.0:

Bypassing DEVICE_INTEGRITY for devices that shipped with Android 13+ (Pixel`s 7 )

Updated:

Drop fingerprint to lowest possible (6.0) to ensure that no one use same Android version

Usage:

1. Delete/disable/reset MagiskHidePropsConfig (if installed).

2. Just install it over old Universal SafetyNet Fix and reboot device.

3. You may be needed to wipe GMS data (not cache) if there is no result immediately.

Many thanks to @1nikolas for integrity checker.

Source code: https://github.com/Displax/safetynet-fix/tree/integrity
[Android Software Development] wyt18:
thanks - this seemed to work for me on Samsung S20 A12 stock. Gpay does not report errors, but Play Integrity Checker app does. have not tried making a payment yet though

what device fingerprint does this point to, if I may ask?
[Android Software Development] ipdev:
I know enough to follow along (normally).

No way I could sit down and write any of this into a working code. 🙃

I think you are correct in the first part.

Not the last part.

I am not sure but from the documentation, it seems this would be more likely.

MEETS_DEVICE_INTEGRITY | MEETS_BASIC_INTEGRITY would be equivalent to a SafetyNet pass of ctsProfileMatch = True and basicIntegrity = True using Basic Evaluation.

MEETS_STRONG_INTEGRITY | MEETS_DEVICE_INTEGRITY | MEETS_BASIC_INTEGRITY would be equivalent to a SafetyNet pass of ctsProfileMatch = True and basicIntegrity = True using Hardware Evaluation.

---

My take away from it is..

From the Device integrity field section.

MEETS_DEVICE_INTEGRITY

The app is running on an Android device powered by Google Play services. The device passes system integrity checks and meets Android compatibility requirements.​

This is replacing SafetyNet's ctsProfile.

If you opt in to receive additional labels in the integrity verdict, device_recognition_verdict can have the following additional labels:​

Note: The above line makes a little more sense to me now that I have written this all out.

MEETS_BASIC_INTEGRITY

The app is running on a device that passes basic system integrity checks. The device may not meet Android compatibility requirements and may not be approved to run Google Play services. For example, the device may be running an unrecognized version of Android, may have an unlocked bootloader, or may not have been certified by the manufacturer.​

This is replacing SafetyNet's basicIntegraty.

MEETS_STRONG_INTEGRITY

The app is running on an Android device powered by Google Play services and has a strong guarantee of system integrity such as a hardware-backed proof of boot integrity. The device passes system integrity checks and meets Android compatibility requirements.​

This is replacing SafetyNet's Hardware Attestation.

From the overview.

For example, a device that returns MEETS_BASIC_INTEGRITY, MEETS_DEVICE_INTEGRITY, and MEETS_STRONG_INTEGRITY could be trusted more than a device that returns only MEETS_BASIC_INTEGRITY. You can configure your server's response accordingly. This can be combined with different actions on whether the user account is LICENSED or UNLICENSED.​

From the Device integrity verdict mapping (chart).

It appears that MEETS_DEVICE_INTEGRITY does not return a value if MEETS_BASIC_INTEGRITY is false.

Where as (I thought) with SafetyNet cts returned a value even if basic returned false.

Note: Now that I typed this all out it makes sense that deviceIntegrity would return empty if basic fails even if what was cts passed.

This way you can stop there if you wish or continue on checking the additional values returned.

---

Does any of this make sense or am I way off track. :unsure:

Cheers. :cowboy: