[DISCUSSION] Play Integrity API

[zgfg]

Also I'm not sure but setting SElinux to permissive at least from my experience might make cts profile match or device integrity fail.

Yes, if I recall the specs correctly, permissive mode is one of the checks for cts-profile attestation

 

[10Maximus10]

Ok, but I argue that the fact that I have Zygisk-LSposed installed, does not attribute to any of my Momo detections

Neither for Ruru, TB-Checker nor SCheck - all those three fully pass in green not finding anything

NB:
TB-Checker extensively looks for XPosed artefacts but it fully passes in green

And actually HMA module for LSPosed helps to pass things for TB-Checker, SCheck and Ruru

I thought that lsposed can be detected because when I recently reflashed the stock firmware for some reason no matter what I did PI api always detected device modifications and failed so I thought that lsposed can also be always detected by some specific app.

 

[10Maximus10]

If I knew about this before I almost hard bricked my phone 2 weeks ago because of the stupid permissive mode.
And I couldn't pass PI API no matter what after that.

Yes, if I recall the specs correctly, permissive mode is one of the checks for cts-profile attestation

 

[zgfg]

I thought that lsposed can be detected because when I recently reflashed the stock firmware for some reason no matter what I did PI api always detected device modifications and failed so I thought that lsposed can also be always detected by some specific app.

My SN and PI pass (of course, cannot pass Strong Integrity - cannot trick TEE) with no problem with LSPosed installed

 

[10Maximus10]

My SN and PI pass (of course, cannot pass Strong Integrity - cannot trick TEE) with no problem with LSPosed installed

Now it works turned out I had to just leave it for a few days and it fixed itself.
Gremlins

 

[pndwal]

FWIW, some tech stuff on Momo detection methods was made public not long ago with the depreciation of MagiskDetector:
https://github.com/vvb2060/MagiskDetector/blob/master/README_ZH.md

A rough transition here:
https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-87262317

PW

 

[linus207]

Hi. I have a riddle that I can't solve. I have two devices: Pixel 6 Pro (raven) and Pixel 7 Pro (cheetah). Both with unlocked bootloader. On Pixel 6 Pro I installed the RiceDroid rom.

[ROM][13][raven][oriole] riceDroid 8.0[AOSP][PIXEL][UNOFFICIAL]

riceDroid for the Google Pixel 6/6 Pro [raven][oriole] What is riceDroid? * Ricedroid is an operating system based on lineage/crdroid, that aims to provide necessary "ricing" for android while being fast and stable. Terminology * The rice in...

forum.xda-developers.com

It is very functional, does not really require root to give satisfaction from daily use. It runs banking applications, gpay (wallet) and has the accepted status of MEETS_DEVICE_INTEGRITY and MEETS_BASIC_INTEGRITY.

Pixel 7 Pro, on the other hand, is quite a challenge. I installed Paranoid Android Topaz beta 1 on it

Paranoid Android Topaz Beta 1 - Google Pixel 7 Pro

We are very excited to announce the beta of Paranoid Android Topaz, based on Android 13. On the first launch, you’ll notice a clean setup with beautiful wallpapers from Hampus Olsson, who teamed up with us again to create several beautiful...

forum.xda-developers.com

Due to limited usability, I rooted and installed Displax mod 2.0 USNF. I couldn't get MEETS_DEVICE_INTEGRITY despite combos with other Magisk modules (Shamiko, Husky, old USNF etc.) So I went back to absolute stock via the online android flash tool. Strangely, on absolute stock, without root, Pixel 7 Pro still shows only MEETS_BASIC_INTEGRITY and no wallet or Netflix or anything "requiring" internal payments accually works. This is a really incomprehensible situation for me considering how the predecessor (Pixel 6 Pro) behaves. I kindly ask for advice and tips.

Cheers

 

[10Maximus10]

Try displax modded usnf. Also does safety net ctsprofilematch pass?

 

[pndwal]

Hi. I have a riddle that I can't solve. I have two devices: Pixel 6 Pro (raven) and Pixel 7 Pro (cheetah). Both with unlocked bootloader. On Pixel 6 Pro I installed the RiceDroid rom.

[ROM][13][raven][oriole] riceDroid 8.0[AOSP][PIXEL][UNOFFICIAL]

riceDroid for the Google Pixel 6/6 Pro [raven][oriole] What is riceDroid? * Ricedroid is an operating system based on lineage/crdroid, that aims to provide necessary "ricing" for android while being fast and stable. Terminology * The rice in...

forum.xda-developers.com

It is very functional, does not really require root to give satisfaction from daily use. It runs banking applications, gpay (wallet) and has the accepted status of MEETS_DEVICE_INTEGRITY and MEETS_BASIC_INTEGRITY.

Pixel 7 Pro, on the other hand, is quite a challenge. I installed Paranoid Android Topaz beta 1 on it

Paranoid Android Topaz Beta 1 - Google Pixel 7 Pro

We are very excited to announce the beta of Paranoid Android Topaz, based on Android 13. On the first launch, you’ll notice a clean setup with beautiful wallpapers from Hampus Olsson, who teamed up with us again to create several beautiful...

forum.xda-developers.com

Seems Ricedroid is based on lineage/crdroid... You'll see here that crdroid pulls SafetyNet Fix w/ Displax mod from here:
https://github.com/kdrag0n/safetynet-fix/pull/207
(Latest is this commit: c5ed4b1)

I don't see Paranoid Android on that page although that doesn't mean that they don't integrate a fix...

Personally I prefer to use clean ROMs (eg official LOS) that don't integrate spoofing and add these using Magisk as there are less issues with conflicting Magisk modules and when changes (eg Google server end) are made...

Due to limited usability, I rooted and installed Displax mod 2.0 USNF. I couldn't get MEETS_DEVICE_INTEGRITY despite combos with other Magisk modules (Shamiko, Husky, old USNF etc.)

Nb. Displax mod 2.0 USNF is enough for this; USNF settings will often interfere with that fix and your other solutions may be confusing you/the issue...

It is possible there is also an underlying custom ROM issue (as mentioned above or other) that prevents success...

So I went back to absolute stock via the online android flash tool. Strangely, on absolute stock, without root, Pixel 7 Pro still shows only MEETS_BASIC_INTEGRITY and no wallet or Netflix or anything "requiring" internal payments accually works. This is a really incomprehensible situation for me considering how the predecessor (Pixel 6 Pro) behaves. I kindly ask for advice and tips.

Device is not 'absolute stock' if bootloader is unlocked... AVB is reporting that so you don't have deviceIntegrity! - you need the @Displax modded USNF to spoof this by forcing the fallback (based on an exception error mod causes) to basic attestation as well as several prop mismatches needed to bypass hardware evaluation type enforcement... With old Basic attestation (as used in pre A8 devices) you can spoof deviceIntegrity as AVB signals are not backed by HKA.

I recommend that you check this thread, especially the first 8 posts:
https://forum.xda-developers.com/t/unlock-bootloader-root-pixel-7-pro-cheetah-safetynet.4502805/
as there are really not issues getting deviceIntegrity on stock ROM.

Cheers

Welcome... PW

 

[linus207]

So I was able to get DEVICE_INTEGRITY on rooted stock. Displax mod turned out to be the perfect and simplest solution.

For more customization I used lsposed+ and the aosp mods module.

Wallet works great, added cards and looks like it will function as it should.

I must admit that there is a lot of confusion on the forums and "online guides", probably due to the high volatility of the situation over time. Sometimes the simplest solutions turn out to be the best.

Thank you for the explanation about spoofing in custom roms based on crdroid/linage, it really explains a lot and finally sorted my mind.

 

[V0latyle]

@shoey63 and/or anyone else familiar with the Asus ROG situation, can you explain how the keystore is broken and how this allows Play Integrity to return STRONG verdict?

 

[pndwal]

@shoey63 and/or anyone else familiar with the Asus ROG situation, can you explain how the keystore is broken and how this allows Play Integrity to return STRONG verdict?

You may have missed the exchange here, but I recently analysed & made (educated) guesses w/ @shoey63's help. See here:
https://forum.xda-developers.com/t/discussion-play-integrity-api.4479337/post-87684705
and here:
https://forum.xda-developers.com/t/discussion-play-integrity-api.4479337/post-87684959

Basically It seems droidguard is erroneously sending basic attestation data flagged as hardware backed and this is the basic breakage in keymaster implementation...

Further, gms is not smart enough to challenge this (it would be very unusual after all) but the PI API has the smarts to recognise that some included data is not hardware backed and thus requires (the initial fingerprint) mismatched prop trigger for PI hardware enforcement bypass before accepting the attestation data...

PW

 

[V0latyle]

What's the deal with so many people jumping through hoops with Shamiko and lsposed to try to hide root? It would seem that the Play Integrity workaround should work for most people, the exception being apps that use specific root detection methods? In other words, hiding root shouldn't be necessary for most people; passing BASIC and DEVICE integrity should be the main concern, no?

 

[zgfg]

What's the deal with so many people jumping through hoops with Shamiko and lsposed to try to hide root? It would seem that the Play Integrity workaround should work for most people, the exception being apps that use specific root detection methods? In other words, hiding root shouldn't be necessary for most people; passing BASIC and DEVICE integrity should be the main concern, no?

Hiding root is necessary for many users because otherwise they cannot use various banking apps, e-citizen apps, mobile device management, etc

Those apps use various other methods to detect root - eg, although you pass Play Integrity (SN), those apps still seek themselves (not through Google's PII/SN) for su, initrc, LSPosed module and/or even for the presence of Magisk app, etc

If they detect, they complain that device is unsecure and user cannot open them to eg configure his banking logging account, etc

More or less, that's all because stakeholders for those apps know that PI/SN attestation is not full-proof, ie, that many users successfully spoof CTS attestation although their Bootloaders are unlocked, custom ROMs installed, boot partition patched with Magisk and so.
Hence they look for other detection methods that are harder (specially for newbies) to spoof

And the tricky part is that you cannot know what they detected and how (obviously, they don't tell you to help you to 'fix') hence the only way is to experiment by various methods

Some method that work for one device/ROM may not work for the other, and of course a method that works for one app ma not work for the other.
But still, most of that is common but unfortunately many users are lazy to follow discussions, read/learn in time and then they ask for help although they didn't even try basic things

 

[V0latyle]

Hiding root is necessary for many users because otherwise they cannot use various banking apps, e-citizen apps, mobile device management, etc

Those apps use various other methods to detect root - eg, although you pass Play Integrity (SN), those apps still seek themselves (not through Google's PII/SN) for su, initrc, LSPosed module and/or even for the presence of Magisk app, etc

If they detect, they complain that device is unsecure and user cannot open them to eg configure his banking logging account, etc

More or less, that's all because stakeholders for those apps know that PI/SN attestation is not full-proof, ie, that many users successfully spoof CTS attestation although their Bootloaders are unlocked, custom ROMs installed, boot partition patched with Magisk and so.
Hence they look for other detection methods that are harder (specially for newbies) to spoof

Makes sense

I guess what is bugging me is when someone recommends using Shamiko + lsposed as a fix for PI dependent apps not working. Google Wallet doesn't work? Here, install three modules and configure a bunch of confusing DenyList crap, instead of just installing one module and calling it a day

Occam's razor.

 

[zgfg]

Makes sense

I guess what is bugging me is when someone recommends using Shamiko + lsposed as a fix for PI dependent apps not working. Google Wallet doesn't work? Here, install three modules and configure a bunch of confusing DenyList crap, instead of just installing one module and calling it a day

Occam's razor.

That's again the lack of knowledge and understanding

Eg, some user needs to hide root from his banking app. To pass he does not only need USNF but also eg Shamiko, LSPosed + Hide My Apps, etc

Then he tests Wallet and it works for him (bcs, among other things, he did install USNF)

Then another user asks only for Wallet and the first user tells him, you need all those (USNF, hide Magisk app, Shamiko, blue shirt, white socks, umbrella, sunglasses, who knows) bcs he had all that, he passed Wallet but he doesn't really know what of all that was really necessary just for Wallet

And then that 'guide' spreads around like conspiracy theories do (they are sometimes more catchy than the simple truth)

 

[pndwal]

Makes sense

I guess what is bugging me is when someone recommends using Shamiko + lsposed as a fix for PI dependent apps not working. Google Wallet doesn't work? Here, install three modules and configure a bunch of confusing DenyList crap, instead of just installing one module and calling it a day

Occam's razor.

Google knows S/N / PI are easy to bypass, but don't seem to regard the 'white hat' modding community as high risk, and aren't in a big hurry to preempt enforced use of hardware based attestation verdicts either... In this sense they don't seem to be working against this community (contrary to what some Google haters keep asserting) at all, but they do need to be seen to be providing reliable means for developers of security dependant apps to determine if runtime environment has been tampered, so they've provided evaluationType and strongIntegrity attestations capable of doing this...

The issue for banks is that there there is no inclusion of hardware-backed device model labels with these attestations (at best they can poll props for such information which can be spoofed) which means that there is no assurance that deploying evaluationType or (current) strongIntegrity attestations in their apps on a per-device basis won't be bypassed any more than the likes of deviceIntegrity verdict...

This means that Google have effectively ensured that strongIntegrity verdict needs to be deployed access the board (if at all) to be totally reliable, and that users of any devices launched with Android 7 or less (incl. those now running up to date A12, 13 etc) as well as so many modern OnePlus and other devices (all launched with broken keymaster implementations at least until very recently) would be collateral damage in this event.

... So banks have understandably held off from using the foolproof strongIntegrity (and previous evaluationType) verdict... I believe Google intend to leave things this way and not preempt its use, ie they'll let the banks choose the time (when they deem there is sufficient market saturation of A8+ devices etc) to migrate apps to strongIntegrity verdict use... (New meaning to 'Google is your friend '?)

This also means (as I see it) that Google won't ever use root detection methods other than PI deviceIntegrity for Google Pay (they simply don't want to be seen to lack confidence in their own API for code execution environment security) at least until strongIntegrity is adopted by banks as the necessary new level of gatekeeping required for environment security... At that point I predict that Google will also follow suit...

Banks, on the other hand, have no such qualms using as many extra means to detect device/execution environment tampering as are available, and will often spend money/resources to develop new ones... These generally use PI deviceIntegrity API, but already augment this with a substantial (and. growing) list of root/modified environment detection means, many of which can be bypassed but tools like Skamiko, HMA etc...

So while Google Pay and many banks need nothing more than PI deviceIntegrity passing, other banks, increasingly concerned about (and affected by?) nefarious use of integrity API bypass mods to commit fraud, require methods equal to their integrated security engines (eg Promon) and their customised detections to fool apps into running on modded devices...

I believe this game (both of developing new tactics to coner the mouse, and of developing new methods to outsmart the cat) will only (finally) end with strongIntegrity deployment by banks...

The cat will win and have supper then... but we can have some fun meanwhile... PW

 

[HippoMan]

[ ... etc. ... ] Banks, on the other hand, have no such qualms using as many extra means to detect device/execution environment tampering as are available, and will often spend money/resources to develop new ones...

[ ... etc. ... ]

And yet, these same banks gladly issue debit cards to their customers, and these cards are just as easy to steal as mobile devices, and they have many fewer "security" measures associated with them than most of these banks try to implement within mobile devices.

Lots of these cards are set up with credit-card-like clearing mechanisms and can be used without PINs for purchases. Therefore, it is easier to commit fraud via stolen debit cards than via stolen or hacked Android devices.

Furthermore, these banks allow their customers full web-based access to their finances via desktop computers which can be hacked with keystroke-capturing malware that can then be used to determine the victims' login ID's and passwords that are utilized to access these banks' web sites.

And all these desktop computers are rooted, and the banks do nothing to cripple any software on these desktop computers, nor do they even try to force their users to install anti-virus software before allowing web access to their banking sites.

And there are many more desktop computers and debit cards in use in the world than there are rooted Android devices, and much more fraud is committed via compromised home computers and via stolen debit cards than could possibly ever be committed via hacked or stolen rooted Android devices.

I believe that the monetary value of all the fraud that has been prevented by Android-device-crippling "security" software is lower than the amount of money spent by banks to develop and maintain the anti-rooting and anti-modding facilities that they utilize.

I'm not talking about Google themselves here; rather, I'm referring to the stupidity of the management of these banks.

But there's no law against being stupid, and therefore, we mice will be increasingly at the mercy of these cretinous cats.

 

[pndwal]

And yet, these same banks gladly issue debit cards to their customers, and these cards are just as easy to steal as mobile devices, and they have many fewer "security" measures associated with them than most of these banks try to implement within mobile devices.

Lots of these cards are set up with credit-card-like clearing mechanisms and can be used without PINs for purchases. Therefore, it is easier to commit fraud via stolen debit cards than via stolen or hacked Android devices.

Furthermore, these banks allow their customers full web-based access to their finances via desktop computers which can be hacked with keystroke-capturing malware that can then be used to determine the victims' login ID's and passwords that are utilized to access these banks' web sites.

And all these desktop computers are rooted, and the banks do nothing to cripple any software on these desktop computers, nor do they even try to force their users to install anti-virus software before allowing web access to their banking sites.

And there are many more desktop computers and debit cards in use in the world than there are rooted Android devices, and much more fraud is committed via compromised home computers and via stolen debit cards than could possibly ever be committed via hacked or stolen rooted Android devices.

I believe that the monetary value of all the fraud that has been prevented by Android-device-crippling "security" software is lower than the amount of money spent by banks to develop and maintain the anti-rooting and anti-modding facilities that they utilize.

I'm not talking about Google themselves here; rather, I'm referring to the stupidity of the management of these banks.

But there's no law against being stupid, and therefore, we mice will be increasingly at the mercy of these cretinous cats.

Just realised I replied to the wrong member above... Corrected now...

Anyway, I was simply elaborating on why banks need more detection bypasses than Google's G Pay/Wallet (which goes to the issue of users confusing what bypasses are actually required)... Just stating how things are / developed / are developing...

Did I say anything wrong?... PW

 

[V0latyle]

Just realised I replied to the wrong member above... Corrected now...

Anyway, I was simply elaborating on why banks need more detection bypasses than Google's G Pay/Wallet (which goes to the issue of users confusing what bypasses are actually required)... Just stating how things are / developed / are developing...

Did I say anything wrong?... PW

No, he's just being a little obstinate and ignoring the fact that it's much less "risky" to attempt to exploit vulnerabilities on devices and obtain financial information that way...carrying a stolen card can get you caught, and installing a card skimmer is risky, too. I think it's pretty pointless to rail against the big bad banks when they try to take (necessary) steps to protect their customers, simply because it means that using their apps may not be possible a few white hats. As pndwal said, we are collateral damage.

Google certainly isn't trying to screw us, and if you really want to find issue with banks, I could tell you all about ESG divestments, asset management firms like BlackRock buying up entire subdivisions of single family homes, and companies like PayPal who refuse to let their customers use their services to purchase perfectly legal things such as firearms. Bank Australia will no longer issue loans for new gasoline or diesel cars in as little as 2 years, despite the lack of necessary infrastructure to support EVs.

And if you want to talk about the evils of Google...Look at their arbitrary ranking of search results, to the point of suppressing vital information, as well as their daughter company YouTube which exercises heavy handed censorship against anyone with views to the right of center, while permitting sexually suggestive and disturbing material for children.

But that's another story...