yashsingh1/xdaforums huggingface dataset:
[Android Software Development] ipdev:
I do not use gPay or any of that but, one difference between stock oos and LineageOS would be the build type.

Stock (and some custom) rom will be user.

Most custom roms (including official Lineage) are userdebug.

Example:

Pixel 3a. Official LineageOS.

Adjusting the secure props.

Sensitive and/or Secure properties.

[ Safe ] ro.adb.secure is set to 1
[ Safe ] ro.boot.flash.locked is set to 1
[ Safe ] ro.boot.verifiedbootstate is set to green
[ Safe ] ro.bootmode is set to unknown
[ Safe ] ro.build.tags is set to release-keys
[ Safe ] ro.build.type is set to user
[ Safe ] ro.crypto.state is set to encrypted
[ Safe ] ro.debuggable is set to 0
[ Safe ] ro.odm.build.tags is set to release-keys
[ Safe ] ro.odm.build.type is set to user
[ Safe ] ro.product.build.tags is set to release-keys
[ Safe ] ro.product.build.type is set to user
[ Safe ] ro.secure is set to 1
[ Safe ] ro.system.build.tags is set to release-keys
[ Safe ] ro.system.build.type is set to user
[ Safe ] ro.vendor.build.tags is set to release-keys
[ Safe ] ro.vendor.build.type is set to user
[ Safe ] sys.oem_unlock_allowed is set to 0

Properties of interest.

[ Note ] ro.oem.key1 is set to G020C
[ Note ] ro.oem_unlock_supported is set to 1

Not adjusting the secure props.

Sensitive and/or Secure properties.

[ Safe ] ro.adb.secure is set to 1
[ Danger ] ro.boot.flash.locked is set to 0
Safe value is 1
[ Danger ] ro.boot.verifiedbootstate is set to orange
Safe value is green
[ Safe ] ro.bootmode is set to unknown
[ Safe ] ro.build.tags is set to release-keys
[ Danger ] ro.build.type is set to userdebug
Safe value is user
[ Safe ] ro.crypto.state is set to encrypted
[ Danger ] ro.debuggable is set to 1
Safe value is 0
[ Safe ] ro.odm.build.tags is set to release-keys
[ Danger ] ro.odm.build.type is set to userdebug
Safe value is user
[ Safe ] ro.product.build.tags is set to release-keys
[ Danger ] ro.product.build.type is set to userdebug
Safe value is user
[ Safe ] ro.secure is set to 1
[ Safe ] ro.system.build.tags is set to release-keys
[ Danger ] ro.system.build.type is set to userdebug
Safe value is user
[ Safe ] ro.vendor.build.tags is set to release-keys
[ Danger ] ro.vendor.build.type is set to userdebug
Safe value is user
[ Warning ] sys.oem_unlock_allowed is set to 1
Safe value is 0

Properties of interest.

[ Note ] ro.oem.key1 is set to G020C
[ Note ] ro.oem_unlock_supported is set to 1

I am not sure if gPay is looking at build type or not. 🙃

Cheers. :cowboy:
[Android Software Development] pndwal:
Many are using GPay/Wallet w/ LOS and other custom ROMs, some reported in Google Pay Magisk Discussion Thread... As far as I'm aware, no-one has reported the need for anything other than S/N and now PI deviceIntegrity verdicts passing since the change from needing to block gms database attest values w/ SQLite fix...

I doubt Google want to be seen promoting or will be using checks other than their device integrity API's. 🙂 PW
[Android Software Development] ezdiy:
Not sure if conspiracy. We *are* breaking google's stuff. Once the CTS 6.0 basic attest is gone, we'll be straight out malware bad guys - lurking in dark alleys, molesting sboot trust chain (yes, that involves far more than "just" unlocking BL, though chinese vendors don't make it particularly hard). All for the sake of having working banking on rooted devices.

Topjohnwu and many others have seen that one coming for a long while now, hence the silence.
[Android Software Development] pndwal:
Please say what makes you think it'll be gone anytime soon.

It's needed for PI deviceIntegrity verdict, and that's all pre Android 8/keymaster 3 devices can have!... Or do you mean 'when banks begin implementing required strongIntegrity verdict?...

So 'Black hat' in Google's eyes?

Well that's a matter of perspective, but actually goes against what Google leaders have said.

Such leaders have said they don't view this community nefarious, and that Magisk enabling people to bypass Android security just "shows that we have work to do" and "helps us to identify where we need to do that work" Also, "it's better for everyone if there's a healthy "white hat" community focused on finding problems and reporting or publishing them."

The Android Hardware-backed security team leader said all this just a year ago, and continued "I see the Magisk community as part of that white hat community"

www.reddit.com/r/Magisk/comments/ofrbqh/comment/h4y62f3/

Notable parts:

Well, yes (assuming you mean banks requiring properly enforced hardware key based attestation, ie. current strongIntegrity), but it's shape has morphed somewhat, and actually into something that has forced banks into holding off on adopting...

Seeing it coming is one thing, but seeing it implemented by relevant parties has taken much longer and is quite another thing!

FWIW, when strongIntegrity is taken up by banks, I'm fairly sure modders won't simply give up... They'll be keenly looking at vulns however impossible they appear to exploit "all for the sake of having working banking on rooted devices", and Google will continue to view these as 'White hat" because they know that simply "having working banking on rooted devices" isn't a nefarious end in itself...

For instance I'm sure there'll be interest in hacking OEM Droidguard implementations and reversers will no doubt look at the Asus ROG Phone 3's "the.app" code to understand how this passes hardware attested green bootloader state to gms when the bootloader is actually unlocked... even if Google has already given gms the smarts needed to detect broken droidguard by that point...

I'm equally sure Google will stop up the holes, but they'll be thankful that a White hat community identified them first... 😜

Personally, I'll just look out for a used Rog Phone 3! 😝 PW
[Android Software Development] Snuuuuupy:
Figured it out. Understanding that `ndk-build` is an executable makes all the difference :)
[Android Software Development] V0latyle:
So this has brought up a question: we've talked about how Play Integrity affects pre Android 8/Keymaster 3 devices because they aren't capable of the SN HARDWARE_BACKED / PI STRONG_INTEGRITY attestation. I must have misunderstood because I was under the impression that even bone stock pre-A8 devices would fail all 3 results of PI; is it more correct to state that the major difference is that they are only capable of basic evaluationType, therefore they CAN still pass BASIC_INTEGRITY and DEVICE_INTEGRITY? After all, this is what the USNF mod does, isn't it - downgrades the fingerprint to force basic evaluation instead of hardware backed?
[Android Software Development] pndwal:
To be clear however, we're not speaking about the traditional passing fingerprint / security patch prop change combo achieved for CTS Profile match using MHPC module...

We're speaking specifically about the second of several prop mismatches needed to bypass hardware based evaluation type enforcement for PI API where an expected (passing) fingerprint prop value also flags a device as being on Google's PI whitelist for enforcement of hardware based evaluation type attestations...

This could be achieved by using MHPC module, but users needed to experiment to find passing prints that were from lower Android API levels or at least earlier ROM builds...

Aside from achieving the necessary mismatch with devices whitelisted by Google for hardware attestation enforcement on the basis of fingerprint prop value, this does make USNF a more universal/complete solution in that it automatically fixes any CTS Profile Match issue even for users of custom, China region, beta and development ROMs etc... But really this was not principal reason for its adoption...

@kdrag0n has said in his GitHub till now:

Of course this will change/has changed with 2.4.0+ as the newly required fingerprint prop value inclusion must not only be mismatched (with expected stock ROM value), but also "pass basic CTS profile attestation" which now negates any need for MHPC to 'spoof a certified device profile' since it's done here... So passing CTS natively w/ USNF is a value-added benefit for uncertified ROM users, but it's also an unexpected/unplanned bonus borne from the need for a fingerprint prop mismatch based hardware evaluation type enforcement bypass... It actually comes as more of a welcome fluke and a happy coincidence than as a planned function... 😋

Nb. Those actually needing this prop adjustment for PI hardware evaluation type enforcement bypass purposes invariably can no longer use up-to-date CTS Profile Match passing MHPC listed prints for PI verdicts...

Well that's not so. (sorry!)... 😬

See next comment.

This commit is not intended for A12 LV devices and does nothing for them. 😉 ... Shipping level must be API 33+ have an effect...

... That commit affects the third set of devices slated for prop based flaging as whitelisted by Google for HKA enforcement, those being API level 33+ LV devices. Further, as with the other props used for whitelist flaging, changing it does actually bypass hardware based checking in A13 LV devices... 😜 🙃

Nb. That fix should work as is for A14+ devices in future also (hence "for devices >=33"), but who knows what other flaging / mechanisms Google will introduce...

Please see my last comments in post above regarding this prop change also...

Yup, of course... 🙂 PW
[Android Software Development] V0latyle:
Thank you for the explanation, @pndwal
[Android Software Development] osm0sis:
Anybody know if this has been addressed for 2.4.0 public release which came out today?
[Android Software Development] Fishawy:
Where did you get that?

Nothing on here, Github still says on Patreon, and FoxMMM detects 2.4.0 but fails to download it.
[Android Software Development] osm0sis:
Ah, I was just going by what Fox's MMM reported. Didn't try to install since I was worried about that issue, so false alarm then I guess! Hopefully someone's reported the issue internally to kdrag0n. 🤞
[Android Software Development] Nergal di Cuthah:
If you hit update in magisk (from 2.3.1 mod 2.1) it shows you can download 2.4.0 but it doesn't seem to do anything

Edit: it does start the download process but i was impatient and didn't see the alert from magisk (because it's silent). Can't tell how much is left to download from the two that didn't error out
[Android Software Development] Fishawy:
Same, it just fails.

We should wait for the public release.
[Android Software Development] Nergal di Cuthah:
Finally killed magisk to end the two remaining. I've got 1200+Mb/s internet speed so it was obvious they stalled. I'll give it a few day and try again if we don't learn anything through this thread.
[Android Software Development] pndwal:
Seems to be WIP ATM... JSON not properly configured yet?...

Not sure about previous issue, but @Displax just submitted his patch-set that was seperated from his original commit for PI deviceIntegrity fix... Might fix a number of issues in next update... Actually, @kdrag0n may be holding back this update for a 2.4.1 release w/ these fixes... PW
[Android Software Development] zgfg:
If you open the module.prop file you can see:

updateJson=

https://raw.githubusercontent.com/kdrag0n/safetynet-fix/master/update.json

Hence this is where it looks for the update info.

You can open that JSON in browser, it will show:

"zipUrl": "

https://github.com/kdrag0n/safetynet-fix/releases/download/v2.4.0/safetynet-fix-v2.4.0.zip

"

"changelog": "

https://raw.githubusercontent.com/kdrag0n/safetynet-fix/master/CHANGELOG.md

"

Changelog URL is valid (you can open in browser and read) but the zipUrl to download from returns: 404 Not Found

Indeed, on the GitHub:

https://github.com/kdrag0n/safetynet-fix

v2.4.0 is still on Early Access and if you go to Assets there is no module installation file to download yet:

safetynet-fix-v2.4.0.zip

Ie, everything is prepared for now but the download is not published yet - once published, the Update/Install mechanism would start working
[Android Software Development] Displax:
While we still waiting official public release of 2.4.0, i am compiled this version myself from latest source.

So if you can't wait to try - you are welcome :)

Public release is up. Use it instead.
[Android Software Development] 73sydney:
Great what are the people who like to feel FOMO and rage about it going to do now? :)
[Android Software Development] pndwal:
Yup... You can use MHPC for any of the current 3 prop-mismatch based hardware evaluation type enforcement bypasses that are/may be needed per device...

As I mentioned re 2nd prop-mismatch (ie. fingerprint), "users needed to experiment to find passing prints that were from lower Android API levels or at least earlier ROM builds" and many did that, reporting in [Discussion] Google Pay Magisk Discussion Thread... Some apparently still use MHPC for this w/ official 2.3.1 USNF...

In [Discussion] Google Pay Magisk Discussion Thread also perhaps?...

😂 ... Still a Deadhead then?...

🙂 PW
[Android Software Development] m0han:
deadheads trying to create ripples, i guess
[Android Software Development] pndwal:
So 2.4.x needs further work; May be for the best that public release is reverted / never got completed... Latest commits:

Revert Magisk update metadata …

Next public release(s) will be published after robustness improvements

to fingerprint spoofing are done. In the meantime, revert this to avoid

linking to a 404 release.

kdrag0n committed 4 hours ago

[NEXT RELEASE] Separate patchset …

* Move safetynet props to boot completed to fix fingerprint not working on OOS12 (Thaks to @HuskyDG)

Displax authored and kdrag0n

👀 PW
[Android Software Development] pndwal:
U2? 🤪 ...

FWIW, I'm simply trying to achieve some disambiguation between 1) forcing the fallback to use of basic attestations from droidguard and 2) allowing gms to accept/pass verdicts with the same by bypassing the different hardware evaluation type enforcement criteria defined per integrity attestation API (ie. SafetyNet and Play Integrity)...

I'm not trying to create ripples (and I'm not a particular fan of The Grateful Dead either), but even the best of us keep muddying the river / confusing others, and I'd love to contribute to better understanding of how USNF works especially among XDA patrons... Ripples or no ripples I want a Clear Water Revival... PW
[Android Software Development] bleh815:
This is misleading as it does not contain the new and improved implementation that makes the acutal 2.4.0. The code has simply not been published yet. The 2.4.0 Tag in GitHub is merely just for the Changelog pointing to Patreon.

See https://github.com/kdrag0n/safetynet-fix/pull/207#issuecomment-1369194909
[Android Software Development] bleh815:
Oh, okay. It's pushed now 😇

Dynamically patch build fingerprint in GMS process · kdrag0n/safetynet-fix@73c8587

"AndroidCAStore" always seems to be used early in the attestation process, before the fingerprint is checked. Dynamic patching avoids problems with device detection and functionality tha...

github.com
[Android Software Development] pndwal:
Well it has...

mmm... Commits pushed 12 hrs ago, just before this:

version: 2.4.0

kdrag0n committed 12 hours ago

which has now been reverted. See my post above.

... So anyone can build (buggy) 2.4.0... but probably better to wait for the fixes @kdrag0n's now working on... 😜 PW
[Android Software Development] FireRattus:
They released it days ago, if you look at the releases page you can see the Pre-Release https://github.com/kdrag0n/safetynet-fix/releases

it links to the patreon but "Pledge at least $5.00 per month to get access."
[Android Software Development] zgfg:
That prerelease on Patreon was already discussed here when it appeared

But the posts yesterday (and the one you quoted) were about Magisk showing that USNF module had v2.4.0 update but update/download from Magisk was failing

Now update.json is reverted and Magisk doesn't notify USNF update anymore, neither the USNF Changelog shows v2.4.0 anymore
[Android Software Development] pndwal:
Well we know that of course; I announced that here:

https://xdaforums.com/t/magisk-module-universal-safetynet-fix-2-3-1.4217823/post-87935327

... We're talking about the public release that that went up today albeit w/ broken download link, then was reverted with reasons given by @kdrag0n linked here:

https://xdaforums.com/t/magisk-module-universal-safetynet-fix-2-3-1.4217823/post-87960043

😜 PW
[Android Software Development] FireRattus:
I mean my comment was specifically on the part where you say "... So anyone can build (buggy) 2.4.0... but probably better to wait for the fixes @kdrag0n's now working on... 😜 PW"

I was just pointing out that there was no need to build it yourself if anyone didn't want to, I wasn't disagreeing or arguing about the rest and didn't see you had already posted that announcement
[Android Software Development] m0han:
Spoiler content hidden.

;)
[Android Software Development] pndwal:
Ah, ok... But the statement about ability to compile it was a direct response to this convo:

The code had actually been up on GitHub tree a full 12 hrs (and was also published as .zip archive when pre-release was announced anyway of course) so @Displax could of course build full 2.4.0 w/ "new and improved implementation"... Pays to check context! 😉 PW
[Android Software Development] ipdev:
<REMOVED>
[Android Software Development] pndwal:
Ok doc, it's getting warmer, but you still seem to be missing what I'm saying...

Trying to get you to digest this, but maybe you've worked out what you think USNF does from some code analysis rather than digesting @kdrag0ns 'How does Universal SafetyNet Fix work?' doc. 🤔

Yup... Same page here as discussed earlier...

Assuming USNF is running, devices released with Android 13 (API 33) are NOT forced to use the hardware check!!!

- 'Hardware check'/checking CANNOT even be used!... The hardware keystore registered is FAKE!... An exception has been thrown... This has ALREADY forced gms to collect (only) basic attestations from droidguard!... USNF ALWAYS does this (main) part of its job!

Anyway, as I already said, I'm pretty sure you didn't actually mean "Devices released with Android 13 (API 33) are forced to use the hardware check" as you're still muddling triggering attestation type fallback with bypassing prop-based checking (and subsequent enforcement of exclusively hardware-based verdicts) for devices known by Google to support hardware-backed attestation as are so many others here... The former means only basic attestations are available while the latter means only hardware verdicts will pass (despite the fact that none are available)...

So I assume you mean "for devices released with Android 13 (API 33), the Play Integrity API uses a different/additional(?) Prop-based check for devices known by Google to support hardware-backed attestation and subsequently enforce exclusively hardware-based verdicts [or simply substitute 'invalidate basic attestation-based verdicts' here]"...

All

devices known by Google to support hardware-backed attestation can still both

1) be forced to use basic attestation and

2) have exclusive hardware-based verdict enforcement for devices known by Google to support hardware-backed attestation bypassed!!!

Both these things work in A13 LV and A12 etc alike, so it CANNOT be said that "Devices released with Android 12 (API 31 and 32) can still be forced back to basic" while "Devices released with Android 13 (API 33) are forced to use the hardware check even if you try to force it back to basic"!!!

Repeat: Cannot be said... Is not so!!!

With A12 LV (and lower) devices Google uses model and/or fingerprint props to identify 'devices known by Google to support hardware-backed attestation' so we just change these to bypass the invalidation of basic attestation-based verdicts (ie. bypass hardware-based enforcement). With A13 LV devices Google uses model, fingerprint and/or shipping level props to identify such devices, so we must change these... Simple... 🥴 🙃 PW
[Android Software Development] ipdev:
I concede.

Apparently I can not explain it correctly so I removed my prior post(s) as not to confuse the matter. 🙃

Cheers. :cowboy:
[Android Software Development] pndwal:
@m0han:

Don't know what happened to your last post, but I'm not trying to 'win' mate, or to simply prove a point... And don't feel like I have anyway... (Just a Dead end...)

FWIW, I believe my understanding of USNF functions (especially re. what exactly 'forces' basic attestation usage) is correct, but it's a more complex subject than many realise... And each modder has aspects he/she understands better than others...

Actually, I hope everyone here can be right/on the right track... that's all... PW

Edit: @73sydney has informed me that I've taken out the 2023 pedant of the year award for this little exchange... Already... (Not bad only 7 days in)...

Guess that makes me a winner... Hope the prize is worth it...
[Android Software Development] m0han:
A mod let me know politely that they were deleting the post saying the thread has had enough of music and laughs. Maybe the powers that be thought my post was a blot on the XDA landscape.

BTW, my post was made in jest, ofc; I remember there was just a ;). The 'OT' was 'spoiled'.
[Android Software Development] aliantonio:
Tried installing this and Wallet just crashes on me at startup on Pixel 7. Seems to happen on 2.3.1 as well. Not sure what the issue is but tried uninstalling and reinstalling and still no luck.
[Android Software Development] Lughnasadh:
Public release of v.2.4.0 now available.

Release v2.4.0 · kdrag0n/safetynet-fix

Highlights Play Integrity bypass without breaking device checks or causing other issues Disabled use of hardware attestation on Pixel 7 and newer (@anirudhgupta109) Other changes Updated instruc...

github.com
[Android Software Development] mrjuniork:
OP and thread title have been updated in order to reflect the latest changes.

Cheers
[Android Software Development] aliantonio:
Is anyone else experiencing crashes when opening Google Wallet? I'm on Magisk 25.2 and latest 2.4.0 safetynet-fix on Pixel 7.
[Android Software Development] Displax:
Logcat from crash please
[Android Software Development] aliantonio:
Here you go. Hopefully I did this right.

Edit: removing logcat file since it's been resolved. Thanks @Displax !
[Android Software Development] Displax:
Disable all font/overlay modules.
[Android Software Development] osm0sis:
@Displax Would something like QuickSwitch overlay trigger this as well? Or was it only fonts or specific kinds of overlay modules at fault?
[Android Software Development] iakoboss7:
@Displax hello.

Should we still use your mod from here https://xdaforums.com/t/magisk-module-universal-safetynet-fix-2-4-0.4217823/page-91#post-87198517

Or the new 2.4.0 update includes your fixes and should be the only option from now on?
[Android Software Development] 73sydney:
Perhaps i shouldnt need to explain deductive reasonsing (top down logic), but ill have a crack :)

Read the last few posts and decide if you think the issues reported so far (font/overlay modules) affect you

If Yes, use 2.3.1 Mod 2.1 for now

If Not, use latest
[Android Software Development] Jon8RFC:
Just checking...

Have you hidden magisk and set to something other than the auto-filled suggestion or "magisk" part of it?

Do you have "enforce deny list" enabled, and the cred.ai app added to that list?

Then wipe data for the cred.ai app, then give it a reboot for grins?

It works for me through the registration process where I'd have to enter my social security number, so I stopped there, but I don't know if it checks at some point after an account is logged in or not.
[Android Software Development] m0han:
Just to get this cleared: Is v2.4.0 only for Zygisk users? Anything yet for Riru folks?
[Android Software Development] roberto_1986:
HI!!!

Im installed last SafetyNet 2.4.0 and if i put google services in deny list i get "HARDWARE_BACKED" but if i reboot my phone google services gone from deny list and then my SafetyNet pass...how i can fix pls???