yashsingh1/xdaforums huggingface dataset:
[Magisk] makeyourself:
No it's because after you get Play Integrity passing again you have to clear Google Play Services data if you want Google Wallet to work again straight away. But if you just wait, then after some time (up to 24 hours?) it will just start working again anyway. Obviously what is happening is that Play Services and/or Wallet does a periodic check of PI status, and the result of that status remains until the next check. Running a PI test in Play Store developer options doesn't update the status that Play Services / Wallet holds.
[Magisk] Nergal di Cuthah:
Integrity checker has an update today, wonder what is different

"clarify api throttling error" interesting
[Magisk] osm0sis:
Play Integrity API Checker - Apps on Google Play

Get info about your Device Integrity through the Play Intergrity API

play.google.com

What's new

Last updated Dec 3, 2023

- Clarify API throttling error

- Update dependencies

So we'll see how that looks this evening. 😛
[Magisk] shajman:
I had cleared google play services, google play store and wallet data/cache multiple times and restarted multiple times. The error wouldn't go away.

This is what I've done with every update of the magisk module. This was the first time I had faced such an issue.

In case you hadn't read my post from last night, the wallet app wasn't giving me any errors at all. As in the pop up security errors that you normally get.
[Magisk] UberNorse:
Updated to the new QPR1 update on the P7P and still passing device and basic with @osm0sis' fork and custom fp just fine.
[Magisk] chrisch91:
Today i payed with wallet, first with success and last second got an error. I pass device and basic integrity. Oneplus 9 pro, pure android 13 rom.
[Magisk] Nodens:
It does not matter if you took it from a private device at all. The fp is inside the OEM's firmware package hence it is available and x number of people may be using it, it may be present in y pre-mined lists or could be used in any z number of "auto-updating" solutions.
[Magisk] sawdoctor:
I wonder if your android dishwasher could be used for contactless payments? Allegedly there's android TVs being used as we speak at contactless payment points 😏
[Magisk] wfred:
That's just it. You own and have full control over your device (the plastic, metal, glass, etc), but you only license the software that makes it function; that is owned (or licensed) by Google and the device manufacturer.

There are some software modifications and bypasses Google is required to allow and some modifications they choose to ignore.

They've decided to no longer completely ignore the most common way to bypass Integrity. At least they haven't decided to no longer ignore unlocked bootloaders and make that the Device fail point.

Two watches and something called the Oral_B_View (android toothbrush?) from Braun passed Basic 😁
[Magisk] HippoMan:
I agree. This is the wallet that contains the contactless payment cards that I have always been using ...

View attachment 6041033
[Magisk] wfred:
The first few Pixels had an incentive of unlimited photo backup for the life of the phone. Supposedly there is a way to spoof Google Photos servers into thinking you're using one of those early models.
[Magisk] djcsurf:
Glad you found one in the end.
[Magisk] majorfigjam:
QPR1 is good on my P6P, with osm0sis fork, and my original custom fp.
[Magisk] wfred:
Might want to also try the Brave browser. Their kinda, sorta crowd sourced search returns different results than Google/Bing
[Magisk] Nergal di Cuthah:
Duckduckgo gets (i think still) it's results from bing, which fed me the edit build.prop results. so maybe i will try brave thanks.
[Magisk] titomax82:
I have to surrender abount finding my custom fingerprint. After 4 hours of testing and several pif.json that gave me only basic as best result, I have to give up and go back to normal PIF 14.2

For the ones to fear about going empty of fingerprints, chiteroman can stop doing is work, but who can stop xiaomi.eu that injects fingerprints using the same method, or, to be more precise, the same result?
[Magisk] wfred:
It looks like you're passing Device.

If the message is coming from wallet/gpay you can either wait 12-24 hours for it to reset or clear wallet's cache & data and reboot. You will need to reenter your cards if you do this
[Magisk] Depressed T.Bear:
OnePlus, neither an obscure nor historical phone ;)

As far as I know, I'm not allowed to talk about how it's done in detail. So maybe just a vague hint: It's not about installing a custom rom (/and magisk) on a locked bootloader, it's about how you re-lock the bootloader and apply updates of the rom (/and magisk) afterwards ...

There are not many devices which allow doing that anymore, and support for it is also dying with android 14.

Nevertheless, my point is that a locked bootloader is unfortunately not a solution for the FPs getting not banned.
[Magisk] TKruzze:
I can't help but continue to believe that $$ is the primary motivation for the continuation of this. If the money dries up, maybe common sense could prevail.
[Magisk] Nodens:
Not exactly. The problem is not that you can modify images, it is that you can accidentally flash original *stock* images after you have installed your custom key. This is what will cause a brick because after you install avb_custom_key stock signatures are invalid. So obviously this is not an issue for custom roms but only for devices pulling stock OTA updates (which you should block in such a configuration).

And the problem stems from the implementation being entirely half-baked (and also not implemented by 99% of OEMs, PIxels are the only devices guaranteed to support it -- but that's another story). In a proper implementation, you would be able to configure additional keys instead of just replacing a single key and this would be a non-issue. Much like on Secure Boot you can have keys that allow Windows images, Fedora images, Ubuntu images and your own private keys used to sign kernel modules (eg nvidia proprietary driver, vmware workstation drivers etc etc) which otherwise you can't load with Secure Boot enabled. In a perfect implementation, your authenticated OTA updater would be configurable to resign your OTAs automatically with your private key (so you don't have to keep third party keys if you don't want to/don't trust them) and you'd be able to select custom in-house CA for verifying root of trust, which would make the feature enterprise level as well and completely secure.
[Magisk] Nergal di Cuthah:
This confused me, who is doing what for money? If google then duh. If chitroman he's only getting donations for his work. If xia, i didn't know that they took money but if they do they're a business so again, of course it's about $
[Magisk] TKruzze:
As long as the donations continue, the prints will will fly... Once that dries up, common sense might return.
[Magisk] Fishawy:
We have no control over what Xiaomi does unfortunately, but here, we can discuss and maybe even appeal to the dev to - at least - stop accelerating the process.

I sincerely hope this is not the case.
[Magisk] sawdoctor:
Have you ever been a dev or released anything on xda? I've released several roms and kernels back in the note 2 and 4 days and I assure you the ££ from donations is squat

Edit

Some people do do it for the fame and being adored though
[Magisk] mike.s:
You have that backwards. You intentionally broke its security so it wasn't working properly, then Google fixed it so it works as intended.
[Magisk] TKruzze:
Yes, I have... My projects were downloaded over 15 million times on XDA from 2012-2015. And, no, I never even accepted donations!
[Magisk] V0latyle:
Let me clarify: the key corresponds to the image that it's signed with, so ANY modification to that image, or if a different image is flashed to that partition, results in AVB unable to verify that partition.

For example: you want to use the stock ROM but with root, so you generate key with avbroot, sign those images with said key, and install key for AVB to use.

If thereafter any of the protected images are modified via root - such as flashing a different boot image or modifying /system - device will fail to boot. If OEM Unlocking was disabled, it will not be possible to unlock bootloader to reflash everything.

Seems like a fair assessment and I will absolutely agree that many OEMs don't follow the AOSP model. At the very least on Nexus/Pixels, it is possible. I don't know if there is an analogue in the PC industry to Android verified boot state, BUT at the very least, Android is intended - again, I agree that most OEMs don't follow this - to allow custom keys.

When it comes to Google's Play suite, it's enitrely up to them what platform/environment they want their software to run on, just as most major game publishers only support Windows with TPM enabled. Google doesn't officially support alternative Android builds/stock ROMs, and although this isn't a direct analogy, game developers don't support MacOS or Linux.

We can go round and round on this but I suppose we can agree to disagree on who's screwing up what because why. I want to be able to use banking apps and Google Pay on my rooted device, but I understand why they don't want me to be able to, and I don't hold it against them.
[Magisk] __init__:
Taking control of your own device shouldn't "intentionally break its security". I'm really surprised to find this much boot licking on the XDA forums of all places. Not exactly the place I remember it being

My bank doesn't block me from logging in on my laptop because I have an administrator account on Windows
[Magisk] Nergal di Cuthah:
This has been refuted a number of times. You don't use a nfc chip on your computer or pay with it at the corner book store's square reader.

You don't leave your computer at the bar, or get it pickpocketed from your purse.
[Magisk] bigknowz:
I had device and basic yesterday, Wallet was saying not secure, pay worked. Today showing all good.
[Magisk] zgfg:
Generally when we say like "you can get strong integrity only with locked BL..." It means:

- with locked BL you are not allowed to flash, hence you cannot mod your phone

- on the other side, if you unlocked BL and flashed a mod, then you cannot relock BCS you will brick the phone

Hence, with "locked BL" you are supposed to have a not-modded phone, hence both conditions: locked BL and not-modded phone are fulfilled and you will pass Strong Integrity

---

So back to the point - your phone is probably not ancient but as you admit, it allows something that is not normal - and what they are going to fix with the upgrade to A14

And there are exceptions like your OnePlus where it was a flaw in design, or as somebody mentioned the Google's own Pixel - where they made it possible for different reasons

I've also heard about the method with MTK

But all they are not 'norma'l/mainstream cases - only in those exceptional cases you can have locked BL and modded phone and no brick

Nevertheless, since the phone is modded, it cannot pass Strong integrity (again, if there was not abother flaw in design, but that was again another exceptional case)
[Magisk] zgfg:
Plus, there is also another reason - feeling about what you have developed as your baby and not letting it to die and taking for that even the irrational moves

Also like Xiaomi.eu - however, they have much bigger base, history and scope of their 'product'
[Magisk] __init__:
And if I did, what would be the issue? Were there any real-world attacks taking place for which this was the only solution? Genuinely curious
[Magisk] pndwal:
Been answered, but green (Verified, locked) boot state is required for both DEVICE_INTEGRITY and STRONG_INTEGRITY, the difference being that the former can be spoofed with custom mods (for 'illegitimate' pass)...

Neither Yellow (SelfSigned, locked) nor Orange (Unverified, unlocked) will cut it for STRONG_INTEGRITY, but BASIC_INTEGRITY can legitimately pass with either as long as selinux enforcing, unrooted etc, or (for illegitimate pass) these are hidden (with root solutions etc).

... All boot state configurations are "able to provide hardware backed attestation" which is precisely why we can never have STRONG_INTEGRITY with custom mods... For spoofing DEVICE_INTEGRITY we must have non hardware keystore capable devices or bypass capability by triggering on-device fallback to basic-only attestation... Nb. This has

NOTHING

to do with bypassing server end HARDWARE-BACKED evaluationType enforcements by spoofing props, but that will be required in addition for many hardware keystore capable devices...

Guess you really meant "... whether such a configuration would be able to provide MEETS_STRONG_INTEGRITY attestation" however.

🤠 PW
[Magisk] Nergal di Cuthah:
Attacks? I don't understand. This was a solution? Also unclear.

Google is attempting to make a device that mimics a card. When you use a card the clerk is supposed to check your id (i know they don't but businees look at ideal situations)

A malware can gain root, logs and diagnostics don't differentiate between us rooting and malware rooting. Malware with root can man in the middle nfc payments. Android without root can guarantee security of nfc.

I root to a) block ads and b) sync with a ntp server instead of my carrier who at times pushes the wrong timezone. I understand by doing this i have made myself a modicum of less secure and unable to replace my card with a device (why i'd want to idk but it's available).
[Magisk] mike.s:
Pffft. You have full control over your device. Full stop. Run AOSP all you want. Modify it all you want. But, Google and some other developers have decided that they want control over the software they own, and won't let it run on a device which doesn't pass a security check.

See? It works both ways. You do what you want with your device, they'll do what they want with their apps. Don't like it? Don't run their apps.
[Magisk] HippoMan:
To me, the thoughts, motives, and goals of the parties involved are irrelevant.

All that matters to me is that many years ago, I chose Android over iOS because Android was much more configurable and moddable, and I could relatively easily make my devices work in the ways that *I* want them to work.

That is getting more and more difficult to accomplish as time goes on, and that's what I don't like about what's happening with Android these days.

I'm not a mind-reader, and I'm not going to try to second-guess *why* the Googlefrinchians are deciding to make these Android changes that I dislike so much. All that matters to me is that Android's usability and desirability are deteriorating more and more for me as time goes on, irrespective of whatever reasons the Googlefrinchians might have for doing what they're doing.

Luckily, I never wanted to start using my mobile device for contactless payments nor for performing banking and financial functions, and therefore, the Googlefrinchians' current integrity-related policy changes don't directly affect my day-to-day use of the deteriorating Android OS. Those changes still make make me upset, but it's because of how they affect so many others who also chose Android.

But it's not going to be too much more time before the Googlefrinchians start more strictly enforcing STRONG integrity. Once that happens, this will indeed affect me, given how I want to use my devices.

For this reason, I am now starting to explore non-Android/non-iOS alternatives. There are some linux-based devices which, although they don't offer a wide variety of apps, might provide me with a platform which delivers enough of the features that I do want to use, while at the same time, allowing much more unrestricted customization than the deteriorating Android OS even currently offers today.
[Magisk] Nodens:
The feature is essentially based on the Secure Boot UEFI specification but half baked because there is no interest in actual security. See here: https://uefi.org/specs/UEFI/2.10/32_Secure_Boot_and_Driver_Signing.html?highlight=secure boot

It is entirely up to them what environment they want their software to run on. Agreed. What is not up to them though is:

1) Locking device owners out of admin access of their own device.

2) Having themselves unauthorized admin access on devices and doubly so when they are also doing 1, effectively creating the black box paradigm (complete control with zero accountability/ability to be monitored by the owner)

3) Creating APIs that grant a level of control and invasion of privacy, against the device owner, to third parties and having the audacity to market it as a security solution on top of it.

I have zero objections to not running any of their software (personally). I do object though if they make it so that the majority of developers require their software to be running on my device otherwise it refuses to execute. Specially when their software is also used to dictate what I can and cannot do on my computer while they also have free reign on my computer. This is essentially what PI adoption by developers translates to and why we must do everything possible to prevent it.

Also I'm not sure why you think that all major game publishers only support Windows with TPM enabled? There is only a single game publisher (Riot Games) that requires TPM in their anticheat solution (Vanguard) and that is only for a single title of their games (Valorant) with zero adoption by the industry and abysmally bad reception (and rightfully so..not only it is completely intrusive but it also opens a very dangerous attack vector security-wise).

The top anti cheat solution is Epic's EAC (Easy Anti Cheat) and EAC_EOS (Epic Onlne Services version) followed by BattlEye Innovations's BattleEye, followed by Wellbia's Xigncode3 (Extensively used in Asian origin games mostly). None of these solutions have such a requirement (although they are still intrusive to various extents with Xigncode3 being the worse offender).

In fact nowadays most major game publishers now even support Linux due to the SteamDeck and Valve's efforts with Proton. Epic's EAC supports it out of the box with the flick of a boolean in the build environment making it extremely easy for developers to get out of the Windows ecosystem. This the exact opposite direction.

In fact Riot Games themselves have not opted in to use Vanguare in their best selling title (League of Legends) because of the extreme backlash with the TPM requirement.

Of course we can agree to disagree. We're just having a debate about related technologies and their intent. Disagreement is part of any discourse :)
[Magisk] V0latyle:
Yeah, wording is everything, sorry.

Pretty much. Sucks for us and I think there's some value to what @HippoMan says about voluntarily accepting risk - after all, Android is the most, shall we say, convienient and consumer ready with the ecosystem of Google services...But at the end of the day, it's up to them what device environments they approve of. If they were actively trying to lock down Android itself, I would have a problem. But we are only talking about GMS here, which is not integral to Android.
[Magisk] sawdoctor:
And it is also probably the banks/credit card companies putting pressure on Google to enforce play integrity/enforce wallet security rather than Google doing it themselves. It matters nothing to Google if your using hooky payments at the local supermarket
[Magisk] HippoMan:
And these same banks and credit-card companies are perfectly happy to issue us payment devices called "debit cards" and "credit cards" which we can use at the local supermarket without any of the nonsense that we need to go through when accessing these same cards via Android.

My guess is that the management of these companies are just going after low-hanging fruit w/r/t modded Android device security, and then they can go to their investors and shareholders and say things like, "See! Look at how serious we are about security! We're blocking access to people's funds and credit via modded Android devices. This shows that we are leaders in security! Now, please invest more in our businesses."
[Magisk] xSnowLeopardx:
Update

Four days passed and my first found FP is still working.
[Magisk] mike.s:
Google Wallet/Pay is no doubt subject to PCI compliance, and needs to make a good faith effort at maintaining security.
[Magisk] V0latyle:
They don't. Google does not mandate anything of the sort for AOSP, and they've actually pushed for OEMs to be MORE developer friendly, not less. Say what you want about other OEMS, but they aren't following the AOSP model, or Google's lead. Google for their part has been one of the most developer friendly OEMs with the Nexus/Pixel line.

And, this has nothing to do with Play Integrity.

I'm not sure I follow. GMS doesn't dictate device policy. Sure, there's certain requirements that the device must meet for certain functionality, but Google doesn't have admin rights to your phone, through GMS or anything else.

Here I actually agree with you, I have a huge problem with Google's cavalier attitude towards user privacy. I don't care that user data is one of the biggest markets out there, it's a huge ethical problem. "If you stand for nothing, you'll fall for everything".

Google doesn't "make" it this way. They've just provided the Play Services platform and made it appealing to developers, who chose to use it. Many don't, and Android still allows you to sideload apps.

K, again, I think you're making assumptions here about what power they (rather, their services) have and what they can do to your device, and as pointed out above, Google isn't limiting what you can or can't do on your device...the OEM might but Google doesn't, and Google's own products don't.

You're pissing into the wind there, bud. Google's already attracted a lot of developers with Play Services. They market your app on the Play Store, they protect your app with Play Integrity (yes it does app integrity too) and they provide device security verdicts as well. It's advertising and support, at what is generally very low cost.

Sure, but it's important to be correct, too. A lot of people including yourself are mad at Google over this whole Play Integrity thing. I'm not trying to defend them unnecessarily but I do think it's important that we don't make assumptions or accusations about who's doing what here. Google is reinforcing their own API as part of their own Play Services. App developers can use their APIs...Or not. Google is not restricting users or devices or pressuring OEMs to do the same. I use a Pixel, I left Samsung behind a long time ago. I was drawn to Pixel because 1) builds are closer to AOSP than almost anything else out there and 2) because the devices are literally made to be developer friendly. I'm not a developer, just a power user, but I appreciate having the ability to do whatever I want to this device. I'm at the end of official software updates for my phone, but I can easily flash a GSI and keep this thing fairly up to date until it dies.

Speaking of GSIs, I'm going to have to play with my Pixel 3 running the GSI with GMS and see what the Play Integrity responses are...
[Magisk] mike.s:
Really? You've rooted the chip in your credit cards? I'm not aware of any "nonsense" involved with Android if you have an unmodified phone.
[Magisk] V0latyle:
Not sure this is actually happening, but it's possible, especially if banks know that Play Integrity can be spoofed. They could all require STRONG_INTEGRITY but they won't because this means only users with phones that launched with Android 8 and newer will be able to run their apps, and Android suffers greatly from fragmentation

Well...It matters in the sesne that you're using their payment app so they bear some degree of liability