yashsingh1/xdaforums huggingface dataset:
[Magisk] majorfigjam:
Probably TLDR

I only got into rooting** to avoid intrusive ads on my first LG Optimus One, but have stuck with it through various phones and changes to Android and security requirements over the years. I've had to weigh up the dislike of ads over the security of corporate banking apps for many years, and so far there have been developers who have let me manage to have the best of both worlds.

But in the long run, this will come down to the balance between user convenience, and the commercial requirements of the app developers (eg banks, McDonalds, Netflix) or wallet service providers (eg banks, airlines, state-sponsored football clubs). They want to have security for their services, and certainty that their users are who they say they are.

There's a fundamental difference in security between accessing those services in a web browser (where security is server side) and from an app (where security is user side). It doesn't matter to them if you have root or Admin user rights on your computer or phone when you use a browser, because all the security happens at their side; it matters a lot when the security control is user side.

Commercial interests require that the user is who the user claims to be - so only YOU can rock up to the Etihad and use YOUR ticket, and no one else can spoof YOUR identiy in a banking app; only YOU should access YOUR bank accounts. You would be rightly p'd off if they didn't try to ensure that.

And lets face it, this whole thread is about making your phone seem to be something that it is not. So long as root users can pretend to be something they are not, then Google will try to prevent people pretending, and developers and users will try to find a way to continue.

How will it end? I guess it comes down to human nature, there will always those who will challenge "authority," so I don't expect the contest to end any time soon.

If you want absolute certainty, revert to stock and relock your bootloader, or buy a smart watch for wallet only.

Edited: ** I apologise to any Australians who are offended or amused by this statement.
[Magisk] Garry050:
I'm so confusing about recently failed DEVICE_INTEGRITY with Pixel 7(crDroid 10.1).

kernel already spoof /proc/config.gz but still failed DEVICE_INTEGRITY with own FP. so I thought my fp has been banned but other device still pass it with same fp.

disable PIfork and let intrust about playintegrity to crDroid(PixelPropUtils), and it pass.

then i try to use PixelPropUtils fp for PIfork, and pass. hm, so seems my fp banned but why other device pass it. so weird.
[Magisk] Nergal di Cuthah:
Finally a good explanation why the "it doesn't matter on web, why should it matter in app" arguement. Thank you.
[Magisk] CityKev:
Great post (I'll ignore the dig at City 😉)

My phone has locked bootloader and stock MIUI as I have been happy to just debloat it with ADB as I've waited until it has stopped being supported before considering whether to unlock it or not (I'm glad I did). My feeling currently is to play around with my tablets to satisfy my need to customise 'something' but not to take any risks with my primary device.
[Magisk] Nergal di Cuthah:
Wait are you saying your kernel is spoofing and you're using the module. If so the double spoof is likely going to cause problems.
[Magisk] dcarvil:
If ad avoidance is your only reason for rooting, simply set your Private DNS to dns.adguard.com. That does not require root.
[Magisk] Garry050:
not touching about props, only /proc/config.gz.

and crDroid still using PixelPropUtils for spoofing, not like EvoX and Xiaomi.eu so it should be blocked by modules.
[Magisk] CityKev:
I use the following on my phone but the principle is the same:

x-oisd.freedns.controld.com
[Magisk] majorfigjam:
It's certainly not the ONLY reason, I guess I'm one of those who will always challenge "authority".

I've had regular discussions with corporate banking relationship managers over the years about them blocking their authentication apps from running on rooted devices, but I understand why they do it. If someone else pretends to be me, and can prove it with a rooted phone and compromised authenticator app, then they can approve payments fraudulently.

The challenge for me is to work round their restrictions, given that I know I don't have malicious intent in doing so.
[Magisk] zgfg:
Months ago I've been experimenting (and posting) about those the.apk (DroidGuard) apps.

Each subfolder in app-dg-cache contains one version. Whenever you start PI or SN test, Google checks do you have the latest DroidGuard and if not, it will download and install a new subfolder there with the latest actual the.apk

- By inspecting dates of those subfolders you will find that it usually installs one in a week or ten days, but sometimes even as frequently as few versions the same week

- When the latest is installed, it doesn't delete the older ones - hence you usually find a dozen of older version in parallel. But at some point it deletes automatically the very old ones, hence you never end with the months old versions still sitting there

So I used to play by deleting them (I made a private module/script to clean the old versions)

- You can safely delete the older subfolders (ie, the older DroidGuards versions)

- You can also delete the latest/newest as well but on the first subsequent PI/SN test it will immediately download and reinstall the latest the.apk (DroidGuard) again

- If you delete the latest but leave an older like the one but last, and if you set the whole folder read-only (to prevent PI/SN to reinstall the latest DroidGuard) the PI/SN attestation will fail with an error (similarly like when you put the phone to airplane mode before testing)

All together, you cannot prevent the G to install and use the latest DroidGuard and you cannot force it to use an older version instead

(That's what I used to answer/comment that G does not need to update Google Play Services, etc - they silently update the DroidGuard, ie the.apk every couple of days and most users are not even aware of all that stuff in the app-dg-cache folder)

And few more observations (from that time/several months ago - I didn't retest things now):

- I used to check with my two phones (with different Android versions and different ROMs) and if I eg deleted all those subfolders on both phones and then retested PI on both, then I was pushed the same latest the.apk (DroidGuard) on both phones

- If I deleted and tested both with PI and SN, then I was sometimes pushed two different subfolders (ie, two different the.apk versions), meaning that PI and SN (sometimes but not always) install and use different DroidGuard versions

Also, if you use Dual apps or Second space, then you will find the same things (parallel installations) both for the main user:

/data/user/0/com.google.android.gms/app_dg_cache

(/data/user/0 = /data/data)

and for the second user:

/data/user/999/com.google.android.gms/app_dg_cache

----

Btw, I use all the time PI Fork v4 with pif json (simple/old format with the eight fields as from that time/version) that I mined before XMas, and so far I never observed any problem - it always passes Basic and Device and Wallet constantly works with no issues
[Magisk] majorfigjam:
If you're going to try this - which I did - make sure you reboot or wait a while before rechecking!

I deleted the folders with root explorer, then retested - scoring 0/3 on the integrity scale.

A reboot fixed that, and now I'm back to passing 2/3. Interesting that I now have 3 new sub folders.
[Magisk] badabing2003:
Then you didn't test the way I suggested.

If you run YASNAC, then you can pass PI again, it triggers the apk download (let's call this apk1), however if you run PI test, it fails and doesn't get the apk.

If you reboot or wait long enough, you get another apk (the second one that @zgfg is talking about, let's call this apk2). If you have the apk2 and run PI test, it downloads apk1 and then passes PI (of course when I say passes, that's assuming that you have a good print)

It is not the case that apk1 is for safetynet and apk2 for PI, apk1 alone will work with both Safetynet and PI

So how do you get apk1?

Run Yasnac or

If you have apk2 (ie reboot)
[Magisk] majorfigjam:
I wasn't following your suggestion - I only was playing after reading zgfg's post, I don't recall yours.

In any event, it all works now - do you have any idea what the third sub folder is?
[Magisk] Nergal di Cuthah:
So does the # of subfolder get updated every pi check (likely with a cool down period)
[Magisk] zgfg:
Not for every your test but every time when G pushes the new the.apk (DroudGuard)

Btw, you will never find the.apk under the installed apps. And for the matter of facts, all other apps install to /data/app, never to /data/data
[Magisk] Nergal di Cuthah:
I guess my question was more does a pi check trigger an update (check) and dowload newest if exist or are they pushed as they release.
[Magisk] majorfigjam:
Apparently not, based on my experience of checking PI. There were no new subfolders after I checked PI only - there were 3 after I then rebooted.
[Magisk] Umgak:
The former should still be possible with Wallet, even while failing PI. All that failing PI removes is tap to pay. The latter depends on the bank in question. My bank doesn't appear to check for root or play integrity at all, but YMMV. There's also the option of the web interface for your bank, which can't detect root at all.
[Magisk] zgfg:
Just check the dates of your subfolders You can test PI every day/hour but you will find the new subfolder (with the new creation date) only when they push the new DroidGuard version

If you don't delete subfolders, the latest can remain there for days with the sane folder creation/update date/time

That's what I said, the new will be installed only when you test and G finds that you didn't have the latest
[Magisk] zgfg:
And accordingly to the manifest when you unzip the.apk, it's package name should be:

com.google.ccc.abuse.droidguard

but pm list packages will not find such a package
[Magisk] bakaekze:
There are plenty of AOSP based ROMs for 3t with different kernels that you can try:

Android 11.0

1. ArrowOS

2. Bliss OS

3. ColtOS

4. DerpFest

5. dotOS

6. Havoc-OS

7. Jaguar

8. MSM-Xtended

9. Octavi-OS

10. Pixel Experience

11. PixelPlusUI

12. Project Sakura

Also this kernel seem to support lineage os that you can try: https://xdaforums.com/f/oneplus-3-3t-cross-device-development.6157/
[Magisk] HippoMan:
Just out of curiosity, have any of these banking managers explained why their banks allow and even encourage their customers to use plastic debit and credit cards which have no authentication associated with them whatsoever, and which would permit anyone who steals these cards to fraudulently impersonate the original card-owners when making purchases with those cards?

Even on a rooted/modded device which therefore fails integrity checks, but which is being is being spoofed with fake DEVICE integrity, the cards loaded into the wallet are protected better than these plastic cards, because some sort of screen locking is necessary to use the wallet, even when DEVICE integrity is being spoofed.
[Magisk] CityKev:
I've never had it fail so I don't know but I have seen posters say they've had issues with Wallet and not just Google Pay. I would still want all my banking apps to work so the current situation wouldn't be acceptable to me.
[Magisk] simplepinoi177:
So another user believes

As such, one other user (credit to him @brentlauert) stated

If your set up isn't working no matter what you do simply being because on LOS, maybe doing this might work -- especially when it's been reported that it worked already once for this user...

And if you do try this and can come back here and confirm if it did work for you, it would be great because then I could suggest the same for others on that custom ROM having issues...
[Magisk] weilunt0219:
Yeah, I agree that the first time it stopped working was probably that the one that shipped with PIF was restricted.

As response to the Wallet thing though, I think we had a misunderstanding, I had used the script to find a new working fingerprint that allowed me to use Wallet again. I had indeed cleared my cache and what not to get it working again (which did not remove my cards), but other than that, it worked for maybe a week before it stopped working again, despite BASIC and DEVICE passing. I had swapped the fingerprint again and got Wallet working again, it might have just been that second restriction-wave. Who knows, hopefully it doesn't just cut out again.
[Magisk] simplepinoi177:
I was under the impression that Wallet's only function (other than to display cards digitally) was for Tap to Pay -- everything else from holding payment info to paying online (banks, services, stores, goods) to sending/receiving money (like Venmo, Zelle) was done in GPay (Google Pay). To the point that on my Pixel 7 Pro (A13 at the time) and Pixel Watch 2, just having an unlocked bootloader wouldn't allow Wallet to add cards (or even to launch) without PIF. In the example scenario, wouldn't trying to add a pass stop like it would as if it were trying to add a payment option/method?
[Magisk] simplepinoi177:
sometimes clearing

data

may be the only way to keep it falling back to failing, even on DEVICE.....maybe....?

It does suck to re-add & have to re-verify all the cards as it will remove them, but maybe something still gets stored even if one clears the cache (as in it gets stored in the data) and/or that something stored finds an incompatibility that affects its own integrity check confirmation that matches to and is only cleared temporarily in the cache
[Magisk] majorfigjam:
No, it's not something I discussed with them. But it's a different question entirely, compared to one of proving identity to authorise million dollar payments in the corporate world. The difference is retail vs commercial - ACH or Fedwire, if you get the US comparison in values.

Low value retail payments by individuals have some level of control. Amounts over a limit on a card need a pin, cards not present need a CVV. Using Wallet needs a pin or pattern, but then there's no transaction limit beyond the account limit or balance. Retail bank fraud checking was impressive, even before AI came into wider use.

I know it maybe illogical, but seriously, their commercial interest is in ensuring that the person using the app, or wallet, is the person entitled to do so. If the device is compromised (ie rooted) they can't be sure the person using it is genuine, unless they can force them to log into a server side security controlled environment which requires identification independent of the device. Edit: for completeness, banks used to use things like SecureID tokens and Digipasses to confirm ID, but are moving to phone apps instead. Unfortunately that brings them into conflict with device integrity when checking IDs.

Similar considerations apply to other apps - are McDonalds charging the right person for their meal? Is your Uber driver really an Uber driver, or someone more dangerous? They need to be sure, for the good of their business, and they would argue to protect your interests too.

And the reason why we're discussing this is because we're following a thread about making our devices appear to be what they're not!
[Magisk] trevtdogg:
off topic but just an FYI - this is not true.

I process credit card payments made over the phone at work, and while it's encouraged and ideal to get the CVV it's not a necessary step for the transaction to go through successfully.
[Magisk] simplepinoi177:
Also, for those on Sultan custom kernel...

(credit to Teri on Telegram)
[Magisk] majorfigjam:
Definitely OT, but yes, me too. Some merchant gateways allow it for manually entered transactions by the seller. But if you don't get it and use it, typically your merchant agreement will pass the fraud risk to your company.
[Magisk] purgy:
I wonder how different difficult it is for a non dev type person to edit that string? Seems any update he pushes would just get added to the list
[Magisk] osm0sis:
Kernel developers could just, you know, stop adding their vanity strings to the kernel build name... 😛
[Magisk] purgy:
Assuming that it's still droidguard doing all the "work", is kernel build name a thing that can be potentially spoofed by pi fork?
[Magisk] osm0sis:
People are still working out how it's checked, but one way or the other likely yes.

However, before everyone starts saying this is "a new low" for Google or whatever, let me just point out this is a readily accessible bit of information about your running device, so it was actually low-hanging fruit for them to block since the custom kernel/ROM community has gotten pretty cocky with putting their names all over everything. I'm surprised other apps don't check for this more.

Once again this just feels more like an invitation to be more discreet, and more clever about things, not an attempt to shut us down.
[Magisk] Umgak:
It is interesting though that some devices/kernels seem OK while others aren't. My LineageOS based OP9Pro works, but other users on Lineage for other devices report issues. My boot image has "The LineageOS Project" plastered all over it, and yet I'm still passing.

Is this some kind of A/B rollout system, maybe? I didn't think DroidGuard ever did that. Hashes are all the same too.
[Magisk] osm0sis:
I'm guessing it's a rollout or A-B testing, yeah. I've suspected DroidGuard of that for awhile where we've often seen prints that work on one device but not another.
[Magisk] osm0sis:
New PIF FAQ I threw together this afternoon:

PIF FAQ

PIF FAQ Abbreviations DG = DroidGuard (SafetyNet/Play Integrity) GMS = Google Mobile Services (Google Play Services) PIF = Play Integrity Fix Frequently Asked Questions Q: What is a fingerprint and where does it come from? A: A fingerprint...

xdaforums.com
[Magisk] HippoMan:
And it's just as easy for a plastic bank card thief to read and supply the CVV when making purchases with the stolen card as it is for the card's bona fide owner.
[Magisk] HippoMan:
When a bank card thiefs make tap-and-pay transactions with the srolen cards, they are also making themselves appear as someone they're not.

And banks have not instituted the same level of tap-and-pay security for plastic-based transactions as what they institute for tap-and-pay transactions via Android devices.
[Magisk] Emmes:
thanks fo the explanation! it worked yesterday also with SPIC and Play Store Check vice versa (though i ddn't know why it worked, now i know, thanks @badabing)
[Magisk] majorfigjam:
Again TLDR from me.

Or clone a card in a restaurant, or set up a fake pay site to steal details. That cat is out of the bag long ago. Which is why they have strong retail fraud controls over cards, and it still costs them (ie all of us through fees etc) millions.

And that's also why they now want to ensure that their new software offerings are not susceptible to similar compromise. If they could make everyone use a secure app with verified identity, I'm sure they would, but there is a high proportion of people who like cash, and others who just love their plastic, so its got to be a gradual process.

Yes, you and I (dare I say early adopters) may be willing to take the risk on our rooted device, and I'll freely admit I've avoided controls over corporate apps in the past, and still do for some other apps now. That's why I'm here in this thread, after all.

But if a 'bad actor' might compromise their app and assume multiple identities, with malicious intent, then why wouldn't they want to try to limit that risk from the outset.

It's annoying to us, but that's the way it is, and I don't expect banks, McDonalds, Netflix, Uber etc aided and abetted by Google or Apple to change anytime soon.

So I hope that our skilled developers will allow us to stay one step ahead.
[Magisk] Utini:
Thank you! But could you also add a list of all available PIF modules/forks and shortly explain their differences?

And maybe also a link to the currently available tools/methods for getting FPs?

I am loosing the overview ATM and what to use. But I am also still on @chiteroman v13 module.
[Magisk] meiser:
I could indeed fix the attestation by removing "-lineageos" from the LOCALVERSION string on my OP3.

diff --git a/arch/arm64/configs/lineageos_oneplus3_defconfig b/arch/arm64/configs/lineageos_oneplus3_defconfig
index 70fa6ce94969..1e419cdf3ef6 100644
--- a/arch/arm64/configs/lineageos_oneplus3_defconfig
+++ b/arch/arm64/configs/lineageos_oneplus3_defconfig
@@ -1,4 +1,4 @@
-CONFIG_LOCALVERSION="-lineageos"
+CONFIG_LOCALVERSION=""
CONFIG_SYSVIPC=y
# CONFIG_USELIB is not set
CONFIG_AUDIT=y
[Magisk] 666biker:
Please explain more how to make it, if it is not very complex, i would try it as well on my OP3T
[Magisk] chiteroman:
v15.4 released !

Release v15.4 · chiteroman/PlayIntegrityFix

Spoof Kernel release name! (uname hook) Xiaomi.eu spoofing apps are now replaced correctly! Fixed BUILD_ID / ID spoof code. Added DEVICE_INITIAL_SDK_INT spoof support from @osm0sis fork! New way to...

github.com
[Magisk] Lurxs:
I've just got a new device, and it is apparently EROFS (something to do with being read only?). how would I edit files in root now? when using MiXplorer I can browse root but it shows as 0Bytes free and I can't edit or add files so can't add a custom PIF
[Magisk] bakaekze:
It looks like kernel spoof doesn't seem to do anything for those with banned kernels unfortunately.
[Magisk] rumia2802:
will this fix secure environment problem on eu
[Magisk] bakaekze:
elaborate please what exactly are you referring to?
[Magisk] rumia2802:
ohh sorry i mean the new pif by @chiteroman can it fix the problem cant pass secure environment for some banking app on eu
[Magisk] bakaekze:
what is "secure environment on eu"?
[Magisk] rumia2802:
like this View attachment 6061003
[Magisk] xcl1pse:
Seem kernel spoofing works for me lol

Edit: nah, it doesn't

View attachment 6061005
[Magisk] bakaekze:
If this app checks for "MEETS_DEVICE_INTEGRITY" then yes. If it checks for other stuff, then no.
[Magisk] bakaekze:
It works in log, but in fact it doesn't.
[Magisk] xcl1pse:
Yeah just check it
[Magisk] EuK_V:
Can confirm, unfortunately still need to flash another kernel to pass device.
[Magisk] Ubimo:
I get this error on my S23 ultra when trying to install latest version. Stock Samsung ROM.
[Magisk] bakaekze:
no errors here. it's just a note.
[Magisk] rumia2802:
w

well ig that because eu inject,even i dont root my devices and using eu inject for fixing play integrity still cant pass that app, and i tried using magisk on eu uninstalling update eu inject, installing module pif and shamiko still cant pass too
[Magisk] xcl1pse:
Well I'm still passing device integrity with my custom kernel but not passing just because kernel string name its kinda unnecessary lol
[Magisk] :
Works as designed. You need to find a valid fingerprint. Easy way would be https://github.com/TheFreeman193/PIFS
[Magisk] zgfg:
Of course, how else nowadays

Systemless rooting. All modules do that. Google about
[Magisk] Emmes:
you have to delete inject -> pm uninstall -k --user 0 eu.xiaomi.module.inject
[Magisk] HippoMan:
Because of screen locking being required for tap-and-pay, storing a bank card in a rooted, PI-spoofed (stealable) Android device is actually *safer* and offers *less* *risk* than storing that same bank card in plastic form in a leather (stealable) wallet.

And I certainly agree that banks and pseudo-banks like McDonald's and Uber aren't going to change their Android-device-tap-and-pay policies, despite this lower risk of using tap-and-pay from a spoofed and rooted Android device instead of directly via plastic.
[Magisk] bakaekze:
No more script ig
[Magisk] mike.s:
And a non-PI-spoofed (i.e. stock firmware, unrooted, bootloader locked) device is actually *safer* and offers *less* *risk* than either. So, that's what Google wants to enforce.