yashsingh1/xdaforums huggingface dataset:
[Android Software Development] TraderJack:
Mostly. Because I think you are saying exactly what I am saying, but trying to make it more complicated (?).

I think it mostly comes down to how we want to interpret the documentation here which you are already quoting partially.

That's it. That field is either empty or MEETS_DEVICE_INTEGRITY. The other two integrities BASIC/STRONG are additional LABELS (not values), according to the documentation.

To me, that means that you can have the following return values (LABELS):

(null/empty)

MEETS_DEVICE_INTEGRITY

MEETS_DEVICE_INTEGRITY, (MEETS_BASIC_INTEGRITY)

MEETS_DEVICE_INTEGRITY, (MEETS_BASIC_INTEGRITY,MEETS_STRONG_INTEGRITY)

I don't believe you can be returned MEETS_BASIC_INTEGRITY without MEETS_DEVICE_INTEGRITY.

I don't believe you can be returned MEETS_STRONG_INTEGRITY without MEETS_BASIC and MEETS_STRONG

Otherwise I think they would have been clear in calling all of these VALUES instead of clearly stating there were only two values and then additional labels. I could be wrong, but if I am the documentation is just bad.

Therefore, when you say say:

You are basically repeating exactly what I stated.

I just didn't write out all the "sub" integrity values which would have to be assumed. Again, after all if we have been passed MEETS_STRONG_INTEGRITY wouldn't it make sense that we would have had to pass MEETS_BASIC_INTEGRITY as well?

So I believe you are saying the same thing - at least in as far as the quote directly above is concerned.

Similarly, the doc you quote:

I believe is also just paraphrasing that a device that MEETS_BASIC_INTEGRITY is less trustworthy than a device that MEETS_STRONG_INTEGRITY (inferring the two other factors that are obviously included). I think the better way to phrase it would have been:

I don't totally understand your last statement, probably because it is directly related to the chart .

What I mean is the way this chart is structured appears to contradict what is specifically stated in the "Work with Integrity Verdicts" which I link and quote above. Specifically that MEETS_DEVICE_INTEGRITY is the only one of two values (the other being null), while the other 2 are just labels.

The chart is unclear (or maybe wrong. or maybe all the other documentation is?) where it shows that:

MEETS_BASIC_INTEGRITY can be returned without also returning MEETS_DEVICE_INTEGRITY.

Further proof (for my interpretation) that this chart is a bit wonky is that it shows that MEETS_BASIC_INTEGRITY is returned if ctsProfileMatch=False and basicIntegrity=True. However it does not give an evaluationType listed.

AFAIK, you *must* have an evaluation type with determining basicIntegrity with SafetyNet. It is either evaluationType=basic or evaluationType=HARDWARE_BACKED. This is stated in the documentation here.

I think more or less we are on the same page...or at least 90% on the same page. I think the only open discrepancy is if the 3 different MEET_X_INTEGRITY are completely disparate or stack with each other.

Even if they are completely disparate, I still don't think you can have MEETS_STRONG without inferring MEETS_BASIC and neither one without MEETS_DEVICE.

What say you now?
[Android Software Development] TraderJack:
I also want to call back to something referenced before (although maybe it wasn't here but in this github issue).

@1nikolas posted this screenshot which shows the PI options in the Play Console.

With the 3 options there it doesn't appear that *any* of them support MEETS_STRONG_INTEGRITY.

Don't exclude ANY

Exclude devices that don't meet "basic integrity"

Exclude devices that don't meet "device integrity"

Where is the option to say "Exclude devices that don't meet strong integrity"? To me, these only make sense if they go increasingly higher. Don't exclude any, exclude devices that don't meet basic, exclude devices that don't meet strong.

Therefore I have to conclude that here they mean "device integrity" = MEETS_STRONG_INTEGRITY and not MEETS_DEVICE_INTEGRITY.

This is a bit of a leap, and I concede I may be wrong here. But once again refer to the chart.

Do you see an option on that chart under PI where *only* MEETS_DEVICE_INTEGRITY is returned?

I sure don't. If that's the case then how can option #3 be used.

In short, I think that while that chart gives us some good information (especially in the last 2 rows), I don't think it was properly proofread and cross-referenced with how every other piece of documentation and console options are worded.
[Android Software Development] radical68:
This link actually fixed my issue. Woohoo. Thank you guys. Love your work. You made my day. :)
[Android Software Development] 73sydney:
i was just waiting for someone, like the king of fingerprint submissions, and owner of a brain far better than my own, to turn up with a twist on how to handle the nonsense.....thats diabolically clever
[Android Software Development] TraderJack:
Thanks for this. I believe the same idea is used in @kdrag0n's ProtonAOSP setting the fingerprint only to GMS.

I think ideally there would be a solution that merged USNF with MHPC so that you could actually inject a different set of fingerprint info to any individual process. In the meantime, this is a good start.

I'm curious now..looking at ProtonAOSP, I think in addition to fingerprint they force in device and model information.

On my Pixel 3XL, when I use MHPC to set it to a Pixel 6 Pro, my output still looks like this:

shell@crosshatch:/ $ getprop | grep -i fingerprint
[init.svc.init-fingerprint-sh]: [stopped]
[ro.bootimage.build.fingerprint]: [google/raven/raven:12/SD1A.210817.015.A4/7697517:user/release-keys]
[ro.build.fingerprint]: [google/raven/raven:12/SD1A.210817.015.A4/7697517:user/release-keys]
[ro.build.version.preview_sdk_fingerprint]: [REL]
[ro.odm.build.fingerprint]: [google/raven/raven:12/SD1A.210817.015.A4/7697517:user/release-keys]
[ro.product.build.fingerprint]: [google/raven/raven:12/SD1A.210817.015.A4/7697517:user/release-keys]
[ro.system.build.fingerprint]: [google/raven/raven:12/SD1A.210817.015.A4/7697517:user/release-keys]
[ro.system_ext.build.fingerprint]: [google/raven/raven:12/SD1A.210817.015.A4/7697517:user/release-keys]
[ro.vendor.build.fingerprint]: [google/raven/raven:12/SD1A.210817.015.A4/7697517:user/release-keys]
[ro.vendor_dlkm.build.fingerprint]: [google/crosshatch/crosshatch:12/SP1A.210812.016.C2/8618562:user/release-keys]

shell@crosshatch:/ $ getprop | grep -i product.device
[ro.product.device]: [crosshatch]
[ro.product.product.device]: [crosshatch]

shell@crosshatch:/ $ getprop | grep -i model
[ro.product.bootimage.model]: [Pixel 3 XL]
[ro.product.model]: [Pixel 3 XL]
[ro.product.odm.model]: [Pixel 3 XL]
[ro.product.product.model]: [Pixel 3 XL]
[ro.product.system.model]: [mainline]
[ro.product.system_ext.model]: [Pixel 3 XL]
[ro.product.vendor.model]: [Pixel 3 XL]
[ro.product.vendor_dlkm.model]: [Pixel 3 XL]
[ro.soc.model]: [SDM845]

I guess previously none of these other things needed to be modified to pass any of the SN checks? But I know that they do set some for ProtonAOSP. You can even see that one of my fingerprint values didn't even get fully updated.

Is there a drawback to spoofing these values? At least to GMS? It seems like low hanging fruit for any API to use these to try and verify the device.
[Android Software Development] dr4go:
Would you be so kind to release a "final" Riru version as well? 😊
[Android Software Development] pulpf:
Hi great thread. I installed the new safetynet version on top of it on my oneplus 7t.

google wallet no longer shows me a problem but I haven't made a payment yet.

Thanks
[Android Software Development] Parideboy:
For some reason this doesn't work for me on a POCO F3 rooted (MIUI)
[Android Software Development] Displax:
Send safetynet test, integrity test, magisk settings.
[Android Software Development] bipindr123:
Thanks Man, Finally a working fix!

Setup: OnePlus Nord

this module

shamiko

hide my app list
[Android Software Development] ezdiy:
Thanks. Feature request: Make the print configurable. Pixel XL has TEE, so matter of time before google nukes its print.
[Android Software Development] Displax:
This print from 7.1.2, without TEE. And if google want to force use TEE (STRONG_INTEGRITY) some day, nothing will save you.
[Android Software Development] mrjuniork:
OP and thread title have been updated in order to reflect current development.

Future releases will also be posted in the OP, including the changelog.

Cheers
[Android Software Development] ezdiy:
Thats limitation of android, not the HW (which can run Oreo). Assumption is that Google will force-update devices that can be updated.

>STRONG_INTEGRITY

Sure, so you might as well give up now like topjohnwu? :)
[Android Software Development] zgfg:
According to Play Integrity API documentation, MEETS_STRONG_INTEGRITY requires to pass SN basicIntegrity + ctsProfileMatch with HARDWARE_BACKED evaluation type (that means TEE = Trusted Execution Environment - built into the chip) - see Device Integrity Verdict mapping table:

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

developer.android.com

AFAIK, there was a bond for 1M $ to break TEE, don't know is it still relevant if you're interested in 😁
[Android Software Development] Dredead:
Thanks for this! Though I still can't find Netflix in the play store after clearing data for both play store and play services and rebooting. Is there anything we can do about this?
[Android Software Development] 73sydney:
Theres always sideload:

Download Netflix, Inc. apps for Android - APKMirror

Download Netflix, Inc. apps for Android - APKMirror Free and safe Android APK downloads

www.apkmirror.com
[Android Software Development] Dredead:
Of course! But is it normal for everyone else using this right now? Or is it just me. That's what I'm trying to figure out
[Android Software Development] 73sydney:
As you may have seen over the past few days, some people get G Pay working & SafetyNet/Integrity pass and can see Netflix, and some cant. Sometimes a clear of play store/Services fixes this, sometimes it doesnt. There is a bit of variance about across different devices. Be nice if there wasnt

So sideload is always a backup for some people.
[Android Software Development] shoey63:
Give it some time. Can take hours after play store is certified before it shows up.
[Android Software Development] Dredead:
Funnily enough, I had an update for Netflix and it updated successfully, though the app page had the good old no longer compatible error and it's not appearing in search. I'll leave it until tomorrow and see what happens then.

Small price to pay for having wallet working though 😁

Edit: within the minute of me checking, posting this and checking again, it has reappeared haha. Back to full power with no draw backs
[Android Software Development] decayed.cell:
Thanks a lot! This is working with ZA Bank 2.3.6 without having to install MagiskHide Props Config. Play Integrity API Checker says MEETS_DEVICE_INTEGRITY, YASNAC passes Basic integrity. But they have done something in 2.3.8 and the app complains about root with this version. I also have Shamiko and the Magisk app hidden (otherwise the app also complains about root).
[Android Software Development] BootloopedMillennials:
Is this mostly a better option for those on stock roms compared to custom roms? If you change your device fingerprint (using one for your same device and android version) on a custom rom, there could still be side effects/issues? Thank you.
[Android Software Development] pndwal:
Pre Android 8 Devices launched without Hardware-backed Keystore... Why do you assume it can be added after an update to Oreo+?... And how can Google add it to a TEE OS that doesn't exist in the SOC?...

Maybe they've invented the downloadable virtual transistor that can be superimposed on a real silicon substrate and made to materialise as arrayed memory simply by signalling a reversing of electron reduction to produce the metal-oxide needed for large-scale MOS transistor integration... Wow! Hope so; I've dreamed of teleportable hardware! 😜 PW
[Android Software Development] ipdev:
I agree that we are on the same page.

Broken and ever changing as Google's documentation is.🙃

What caught me off guard was the end of your previous post.

Maybe that was a typo but, it is wrong.

MEETS_BASIC_INTEGRITY is returned when what was basicIntegrity is true.

This value (label) does not guarantee anything about the state of what was ctsProfile.

MEETS_DEVICE_INTEGRITY is returned only if all of what was ctsProfile and basicIntegrity are true.

I think this is where we diverged 10% from each other. 🙂

---

As far as the three different MEET_X_INTEGRITY..

They are separate but also compounded.

When deviceIntegrity is called.

By default, the only value returned is MEETS_DEVICE_INTEGRITY if everything that made up ctsProfile and basicIntegrity pass.

If something does not pass, it will return empty.

The other two values are optional and you have to enable them in Play Console.

If you enable them, then you will also get those values returned but, only if the requirements pass.

You are correct about STRONG.

You can not have STRONG without BASIC and DEVICE being true (and stong integrity).

MEETS_STRONG_INTEGRITY will only be returned if all of what was basicIntegrity and ctsProfile pass along with the device supporting a strong (hardware-backed) integrity.

But...

You can have BASIC even if DEVICE is false.

MEETS_BASIC_INTEGRITY will be returned if what was basicIntegrity passes.

Recap note:

You can get BASIC returned even if STRONG and DEVICE fail as long as what was basicIntegrity is true.

You can get DEVICE returned even if STRONG is false, as long what was both ctsProfile and basicIntegrity is true.

You can only get STRONG returned if all of what was ctsProfile and basicIntegrity along with the device supports strong (hardware-backed) integrity.​

Cheers. :cowboy:

PS.

I tried to edit my previous post down before I posted it. 🙃

Think my final post was draft number 6?

It was a long day and I see I decided to (for some reason?) remove the links to the Play Console stuff.

With all the cross Google site(s) I do not remember what I had originally linked to.

Might have been this?

(Optional) Configure Integrity API responses
[Android Software Development] pulpf:
I confirm.

After installing safety net v.2.3.2 g pay (g wallet) works on my oneplus 7t.

Several payments yesterday.

Thanks
[Android Software Development] swieder711:
Upgraded USNF to 2.3.2 on my P6P. My corporate sanctioned Microsoft apps (Outlook, Teams, etc) have stopped complaining about my non-compliant device.

Running Magisk stable 25.2

EDIT: Spoke too soon. Got the non-compliant message. Just installed Shamiko. Hopefully that will help.

Thanks!
[Android Software Development] c3k:
Same here. Samsung S21, stock latest rom, magisk 25.2.

Tried with MHPC (simulating android 11, reported working for an S21+ user) before (removing it and) trying your mod.

Cleared Play Store and GPay data after each test but no success until now...
[Android Software Development] ezdiy:
Interesting, do you have a link? What counts as a "break" TEE? mtkclient, as well as a lot of EDL loaders for firehose can run root with HARDWARE_BACKED.
[Android Software Development] ezdiy:
See the original post about CTS fingerprints, https://xdaforums.com/t/discussion-...cussion-thread.3906703/page-128#post-87181171
[Android Software Development] zgfg:
TEE was discussed in the Magisk thread, don't know exactly when (during the last year or half a year)

It is known that TEE are not correctly implemented to some devices (even to the names like One Plus or so) and that was the reason that Google still accepts SN ctsMatchProfile testing with Basic type of evaluation (as forced by USNF module), allowing you to bypass TEE
[Android Software Development] ezdiy:
No I don't care about that, I'm asking about the bounty lol. Since secureboot is routinely bypassed by fairly public exploits (both qcom and mtek, covering majority of devices). With no sboot, TEE becomes moot (for the purposes of magisk).
[Android Software Development] zgfg:
Answered by:

https://xdaforums.com/t/magisk-module-universal-safetynet-fix-2-3-1.4217823/post-87206193
[Android Software Development] Strephon Alkhalikoi:
I thought the updated USNF didn't work, until I cleared data on both Google Play Store and Google Play Services, uninstalled GPay, ran SDMaid (optional), rebooted, reinstalled GPay AND installed Google Wallet. Note I am NOT running MHPC at all.

I had to insert all my cards again, but it was worth it. As of right now contactless payments are working again on my Pixel 6.
[Android Software Development] zgfg:
Very simple.

Google immediately found two articles (maybe good for your beginning to research):

Google offers 50% higher bounties for bugs in Android 13 Beta - Help Net Security

Google has released Android 13 Beta 1 and has sent out a call for bug hunters: Find bugs in it, and you'll get a 50% bonus reward payout.

www.helpnetsecurity.com

Android and Google Devices Security Reward Program Rules | Google Bug Hunters

The Android and Google Devices Security Reward program recognizes the contributions of security researchers who invest their time and effort in helping us secure our devices and platforms. Through this program, we provide monetary rewards and public...

bughunters.google.com

(Ok, less than 1M and limited to Titan)
[Android Software Development] Displax:
https://xdaforums.com/t/magisk-module-universal-safetynet-fix-2-3-1.4217823/post-87198517

Little update:

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

And renamed module version to original one to avoid misunderstandings with original project.
[Android Software Development] MatMew:
Where can we find 2.3.2?
[Android Software Development] Fishawy:
It is now 2.3.1-MOD (name changed for consistency), from the post right above yours.
[Android Software Development] MatMew:
Thanks a lot, this fix worked. We're back in business boys. The community is alive and well.
[Android Software Development] pndwal:
Thanks for attention to a better fix! 😛

Please can you explain how

Drop fingerprint to lowest possible …

5a40632

To ensure that no one use same Android version...

benefits us?

... I'm guessing a mismatch with running Android fingerprint is needed/ (causing some attestation element to fall back and use BASIC evaluation like pre-Oreo devices despite hardware existing) to pass device_Integrity in some devices...

Seems these devices are mainly running Android 11+. My stock MIUI Android 10 Xiaomi RN8T returns MEETS_DEVICE_INTEGRITY with no fingerprint modification, and apparently most devices with pre Android 11 do too.

👍 PW
[Android Software Development] zgfg:
You pass SN (Bassic attestation type) and accordingly MEETS_DEVICE_INTEGRITY with no need for any USNF (and MHPC)?

Don't you have Xiaomi.eu ROM (they build-in USNF to fall back to Basic attestation) or it really does for you bcs of (stock) A10?

Edit: I see, you wrote STOCK

---

I have on Mi 9T, Xiaomi.eu A11 from Nov 2021 and I pass SN (Bassic attestation) and MEETS_DEVICE_INTEGRITY with only MagiskHide (Delta) - no need for USNF

I also pass both if I boot with the original Xiaomi.eu boot img (ie, no Magisk)
[Android Software Development] pndwal:
No... I need USNF* for both API bypasses, but not MHPC.

*Note: This does not (yet) alter fingerprint props, although it formerly changed ro.build.version.security_patch to a matching date before v1.1.1

What I said was I don't need to alter fingerprint prop on my device to pass new device_Integrity. 😜

To clarify:

Many A11+ users have S/N pass (of course w/ USNF), but not new PI Device Integrity without an older print so have recently (before @Displax's modded USNF) been using MHPC to spoof older prints even on stock ROMs.

USNF causes more than one hardware attestation mechanism issue (failed keystore access and server end supported model check not finding a match) to break opportunistic use of HARDWARE attestation and trigger a fall back to BASIC evaluation type already. Also, either one fallback produces a BASIC evaluation type result which can mask the fact that another hardware mechanism may still be functioning / causing a failed result.

@kdragon originally referred to

but really it seems that there are simply multiple mechanisms needing to be bypassed.

I was wondering if / seeking confirmation that the need for differing fingerprint props to obtain a passing PI device_Integrity verdict in many Android 11+ devices could be another fallback trigger required for bypassing new MEETS_DEVICE_INTEGRITY failure, especially since @Displax made PR to Drop fingerprint to lowest possible (6.0) stating this is

🤠 PW
[Android Software Development] ezdiy:
I see, you are talking Google devices in particular (nobody has managed to break anything above Pixel 5, coz google generally know their stuff and don't depend on shoddy vendor crap in the boot chain anymore).
[Android Software Development] pershoot:
Hi.

I used USNF 2.3.2 from Displax and this took place:

1. Took about 24-48 hours for the security warning in 'Wallet' to come off.

2. Tried to pay today, check mark ok on phone, but the connected card was declined at the vendor (the card was fine; used it directly thereafter in the machine to pay).

Later on today:

I have now changed to USNF 2.3.1-MOD (Displax)

Tap to Pay: Success!

Bramble (latest update), latest Magisk + Zygisk.

@Displax Thank you.
[Android Software Development] cantenna:
Not working here with the mod.

Continue to get "Bad card type" at post.

This is on a One Plus 7 Pro unofficial LOS build and nick gasps (with Google launcher disabled)

No xposed and shamiko module, configure Deny list but not enforced, no GPay sqlite fix module
[Android Software Development] V0latyle:
If you aren't using stock firmware, you'll need to spoof a fingerprint using MHPC.
[Android Software Development] cantenna:
Thank you, I've tried that as well.

Do you have a recommend fingerprint/ device to try, I've tried 3 already
[Android Software Development] c3k:
Same setup, my Wallet app still alert "phone is not secure" but nfc payment works. Same behaviour in the past, I think the alert will disappear in next day.
[Android Software Development] jnss98b:
Hi, I'm not op but it didn't work for me either on a pixel 5. I can send everything you asked but first, how do I perform a PI API test? Is there an app I can use?
[Android Software Development] zgfg:
The app "Play Integrity API checker" was posted by 1nikolas in GPay thread around last Friday
[Android Software Development] jnss98b:
Yep I just found it, thank you
[Android Software Development] 73sydney:
Found some time about 12 hours ago and decided to give the Displax method a go

On my Stock S20+ 5G (A12), i disabled MPHC (which id used to spoof a Pixel 6 (A12)), installed Displax's USNF over the top of existing USNF, (renabled my magisk module to spoof 2 props to keep Samsung Health going) and rebooted

Seamless....that was all

Paid for stuff about 2 hours ago
[Android Software Development] jnss98b:
Ok lmk if I missed anything @Displax
[Android Software Development] jnss98b:
Oh and this is why I think the module didn't work
[Android Software Development] Lada333:
I'm far from being a developer, so excuse me if my question is silly.

I'm on a A12 Pixel 4a, using Magisk props to spoof my device fingerprint to A11 P4a. My understanding is that using this modified SafetyNet fix module by Displax gets rid of the need to use props.

My question is that if fingerprint spoofing works for me (as of now), is there any reason to move to this updated SafetyNet fix instead? Is it less likely to break at some point, like the fingerprint spoofing method? Any other advantages?
[Android Software Development] _mysiak_:
On my phone it took about 2 days for the fix to reflect in Play store (to show Netflix) and Wallet to stop complaining about unsecure device. Data cleanup of Play store or Wallet didn't speed it up. I don't delete Play services data as it used to cause "partial factory reset" with side effects like delayed messages delivery, missing notifications etc.