yashsingh1/xdaforums huggingface dataset:
[Magisk] rodken:
Point taken considering that PI improvements are likely driven by general product enhancement rather than specific exploits. Of course, any action to improve security makes it harder for anyone, including those using tools for unintended purposes, to bypass those safeguards.

All of the talk in the past about the constant cat-and-mouse game: developers find vulnerabilities, implement protections, attackers adapt to their methods, and the cycle continues.

At the end of the day, Google's just doing its thing, making its stuff better, like any company would. PI isn't some personal vendetta against one's mad skills, it's just them keeping their castle walls strong - I suppose.
[Magisk] V0latyle:
I prefer l33t $k!11z

(if you get the reference you're an old bastard like me)

But yeah. I have a lot of issues with Google/Alpahbet, not limited just to their corporate greed or their elitist perspective on social/political/environmental affairs...but I still don't really believe anyone over there is out to screw us.
[Magisk] mike.s:
Don't confuse currency with money.
[Magisk] pndwal:
Sure, it's still Android... Should have said ' many key ROM applications '...

Actually HyperOS does close that gap: Apparently there are no system feature differences between HyperOS Global and HyperOS China like there are between MIUI China and Global; the primary difference between HyperOS Global and HyperOS China is the alternate use of Chinese or Google services and system apps.

Yeah, but it's still principally to satisfy licensing and government requirements...

Apparently Play Store shipped on high end China MIUI devices but was hidden and many other China devices had basic GMS services and framework but others didn't... Now HyperOS China Ships with basic or no Google services due to Chinese government restrictions and alternative services developed by local companies fill the void... So it seems that China region devices don't need to pass CTS/VTS (Google certification) although many do...

If it weren't for hardware enforced regions, devices destined for both China and global markets would all need to pass Google CTS/VTS compliance (incl. having valid/passing fingerprint props assigned) since shipped China ROMs could then be changed to Global (with all Google services/apps) for use within China, but Chinese government requirements preclude the ability to do that with locked stock (ie. un-modded) China market devices...

With hardware enforced regions however, OEMs have the option to have devices Google certified (licensed for Play Services) or not, and government requirements are met since Global ROMs are necessarily incompatible with China region devices (regardless of compatibility or vendor test suite status). PW
[Magisk] majorfigjam:
For Pixel users, I can confirm the Osm0sis v5 fork with one month old print has survived the latest January update intact (I'm using Magisk Canary 26404).
[Magisk] intel_core_i7:
HyperOS devices except very low end ones are still equipped with basic GMS like MIUI. The scheme is unchanged, except to unlock Chinese devices legitimately these days you have to have a Chinese government issued ID. Still they sell unlocking accounts (tokens) for $30 per unlock, the instant unlock accounts scheme is also unchanged, though more popular these days
[Magisk] HippoMan:
Actually, I don't think they give us too much thought, one way or the other. IMO they're not out to get us, but they aren't out to encourage, train, nor help us, either.

It's up to us to work around their integrity checks.
[Magisk] dmenezes:
Thanks for the links, and sorry for not explaining myself better, but with all due respect, I don't think the work-around I'm proposing depends on the specifics of hardware attestation:

1) You said it was possible to exploit a bug in Android to work around the atestation;

2) You also said that Google fixed the bug that allowed 1);

3) Therefore, if eg a Magisk module like yours, running as root, reverts the Google fix (eg, by overwriting the fixed code in memory with the old buggy code), then the bug would still be present and the exploit would still work, and work around the attestation would still be possible, regardless of Google having patched the bug or not.

Or am I missing something?
[Magisk] chiteroman:
DroidGuard collects all data of your device and send it to Google servers, all checks are done in a secure Google server. Unless you manage to hack the servers or find another exploit you can't pass STRONG again. Also if you revert back the code or patch something in the lib, you will fail BASIC verdict.
[Magisk] pndwal:
The 'bug' was entirely server end...

Google was allowing some Pixel 2 devices to get fake strongIntegrity pass (these were presumably only producing good basic attestation measurements) on the basis of shipping level prop combined with fingerprint prop... Nb. Pixel 2 spanned 3 shipping API levels and seems the only earliest models had broken keymaster implementation and couldn't pass strongIntegrity (locked)... So Google gave/has been giving the strongIntegrity pass (deceitfully?) for years to cover their bad keymaster and have Pixel 2 devices all pass consistently...

It was later discovered thay by using the same (walleye) print + various shipping levels not matching the two good Pixel 2 iterations, we could spoof the P2 device with broken keymaster and pass strongIntegrity on most other devices...

There was no bug on any physical device, and none were patched at all... only server end code changed...

So this was a case of Google being found out and having to revert (server based) spoofs themselves (wipe the egg off their faces fast)... Now that Pixel 2 iteration (made by HTC for Google) properly has broken deviceIntegrity like so many OnePlus and other devices... Of course Google'll be a bit like Sergeant Schultz on this:

I know nothing!... I see nothing!.. I hear nothing!

I say nothing!...

😆 PW
[Magisk] dmenezes:
Ah! Ok, now it all makes sense. I was thinking it was a bug in Android (client-side).

Thanks for taking the time to explain it so thoroughly.
[Magisk] zgfg:
Yes, you are missing the answers we gave you earlier

You can fo to the Google servers and revert what they fixed there😁

Or put it more simple - if you have Nandroid backup from the time when Strong Integrity spoof worked - restore the backup and test Strong Integrity now again. And please report your today's results

Don't you think that somebody else could have tried the same?
[Magisk] simpleatom7:
Test banking app called "Yono SBI" since it would crash if root is detected.

There are more apps for which u don't need to login to bank of even create an account. The fact that u can browse the basic login ui, that in itself reflects, u have bypassed the root detection.

Also basic root detector like App List Detector should be all green.

[If done correctly] even rootbeer should say no root

then comes ruru which is the main thing here, if u pass that, u can almost use app apps except apps which detect bootloader which are quite few & have alts called as xyz lite.

If u have followed all of the steps I have mentioned, all 3 apps shall be bypassed as if u never rooted.
[Magisk] simpleatom7:
Ss your modules in magisk.
[Magisk] zgfg:
Thx but I already have Ruru, TBChecker, AppListDetector, SB-Checker, both RootBeer apps, Oprek - all green and passing

On both my phones

Btw, I even run LSPosed app (not the parasitic screenshot), and I successfully hide it from Ruru, Applist, TBChecker

I didn't ask for the help but maybe your post helps to somebody else (long ago I just asked what you meant by She'll in HMA since I thought that it might be a newer HMA version with the additional options in the Settings - so that was my question, not how to pass apps)

Also I have two my local banking apps working (and I'm not really interesting in bloating my phone with some foreign banking apps), but again, your post may help to others

Btw, I don't have your Shell enabled for hiding from in HMA. Nevertheless, on both my phone's Ruru and others don't detect HMA, etc. Maybe BCS I have Vold isolation enabled - the combination I have works for me and I'm not going to change the winning combo
[Magisk] pershoot:
Trying this on P7A. Was able to add cards but in tap to pay setup shows 'does not meet requirements'. I'll see if it drops off in ~24h.
[Magisk] sawdoctor:
On the pixel 7 series 2.40_1.3 seems to work best
[Magisk] pershoot:
Yup, noticed that from reading around, but wanted to try the latest work. I'll put it in place at some point and observe. Thank you.
[Magisk] pershoot:
I started failing checks w/ Play Integrity Fix. I reverted to Displax's 2.4.0_1.3 and will observe.
[Magisk] simpleatom7:
U can test, Payzapp since I'm pretty sure they are detecting bootloader. Update me if otherwise.
[Magisk] zgfg:
App not available in my region on Playstore and when installed from APKMirror it cannot reach their servers (but no complains about detections till that)
[Magisk] simpleatom7:
Just got to know it detects Bootloader. U can use India VPN & the moment it connects, it won't work. Idk why the heck have they put this bootloader thing.
[Magisk] pershoot:
Wallet (Tap to Pay setup security requirements): It has dropped off. WiFi calling is ok on 7a (Sep. patchset).
[Magisk] pndwal:
Please say what "dropped off" means... You mean now 'meets security requirements'?... PW
[Magisk] pershoot:
Yup.
[Magisk] pndwal:
Interesting...

Hope your issues with PIF fork can be sorted... It should work better than current builds of @Displax's modded fork as I mentioned here:

https://xdaforums.com/t/module-mod-universal-safetynet-fix.4553699/post-89069535

Did you check if you fail to get just DEVICEINTEGRITY or also lack BASICINTEGRITY with that? PW
[Magisk] pershoot:
Initially, it was passing device and basic. Then basic went error some time later on.
[Magisk] Dragon Kumera:
didnt know that was out. I should update my phone!
[Magisk] pndwal:
Ah yes... I see 'Basic Google Services' can be turned on (at least in some devices) in HyperOS settings so perhaps not much has changed from MIUI in that regard... Thanks... Edited post above...

Key difference seems to be that while only MIUI China ran fast and stable, with HyperOS both China and Global variants do as underlying system features are now aligned/identical... My guess is that HyperOS more closely resembles AOSP, whereas 'pure' (China) MIUI was modified to derive Global MIUI and achieve compatibility for key Google system applications, which meant it ran comparatively slow and unstable in practice... PW
[Magisk] SoulsAssassins:
Hi! First of all thank you for all the work you've done, it's so amazing, then I have a problem when TheFreeman193 released his script everything was working fine, in 5-10 tries I was able to find a working pif, but since TheFreeman193 updated his script to V2 the pifs only pass the "Basic Integrity", I've tried about 50 of them, and it's always the same. I must admit I don't understand, I'm on the Osmosis V5 fork, and I haven't activated magisk hide so I don't understand.
[Magisk] osm0sis:
Maybe try again. @TheFreeman193's first V2 update had a missing property entry, but should be working now: https://github.com/TheFreeman193/PIFS/commits/main/
[Magisk] simplepinoi177:
I'm surprised....I guess Google gave PIG a good long holiday vacation....

but it might be worrisome if this is signs that they're abandoning this all because something newer and scarier is coming and is simply just letting this be -- false sense of security/hope or "calm before the storm"....
[Magisk] SoulsAssassins:
I will try so! For now using ur script Xiaomi eu so thanks for that 👍
[Magisk] SteweEliteModder:
Tested right now latest version 15.1 and works great on my Samsung Galaxy S22 Ultra 👍
[Magisk] phone_etix:
STRONG integrity requirement incoming soon? Google has to pull the plug at some point. I wouldn't put it past them to contrive a situation that allows them to steamroll any protests and retain sufficient market share.

Spoiler content hidden.

Okay maybe it doesn't have to be as dastardly as the above, but it's 2024. Why wouldn't this be the year they put their foot down? It's been over 6 years since Android 8.0 was released. At some point they could afford to lose the grandmas, rural villagers and curmudgeonly greenies like me who still want to legitimately use old phones.
[Magisk] intel_core_i7:
Enforce strong on what? Except of Gpay they don't have any control over whether an app must use PI or what level of attestation an app must use. No need to be that paranoid, and there are always alternatives if one software decline to run on your phone
[Magisk] phone_etix:
Enforce strong for google play store to be run at all? Couldn't that be a future possibility? (and apps can be developed to not run unless installed via play store)

Google doesn't need to enforce app developers to depend on their ecosystem and security standards, but they could set the stage for enough of them to start making the shift - much like more and more apps are checking for root nowadays even if it's completely unnecessary.

As has been discussed in this thread Google won't ever _ban_ rooting, but they could make it an extremely crippled experience.
[Magisk] dmenezes:
Hear, hear!

I *strongly* support that. Let's not give the Google PIGs anything more than they already have.

Despite many posts here claiming they're not out to eff us modders, it certainly felt that way when my apps stopped working with the original PIF a month ago and I (and the rest of the community) had to scramble just so we could use our phones again.

I have no desire to go thorough that again!
[Magisk] rogers11:
I'm slowly beginning to understand why some things can happen. 😋
[Magisk] dmenezes:
Good news indeed, haven't heard about it until you mentioned! So, it looks like the banana-ing only lasts for what, weeks?

What else can you tell us about that?
[Magisk] gpvecchi:
A little OT, but there's no official thread, what happened to Play Integrity Next?
[Magisk] sawdoctor:
Monday's and Thursdays tend to be his days unless he's still on an extrnded holiday
[Magisk] intel_core_i7:
Google wants people and android itself to be more and and more dependant on GMS, making play store to only run on locked bootloaders means opening a floodgate of people moving to other OS like iOS or just pure AOSP, or Huawei's HarmonyOS NEXT (?)

And remember GMS's minimal supported version is android 5, they only dropped 4.4.4 last year. If they wanted to do that then it would just hurt themselves more in a long run, no one is crazy enough to cut support 3 popular android versions at the same time in the near future
[Magisk] V0latyle:
You're talking about some serious anti trust liability. There's a reason why GMS is not an integral part of Android. App developers CAN use GMS but they don't have to.

What would the point of this be? I think it's been more than clear that Google isn't interested in doing this. Every Google app works perfectly fine on my Pixel 5 - even Authenticator. I haven't hidden root or used any other root hiding methods; the only module I use is Play Integrity Fork. And yet, everything continues to work fine.

As @intel_core_i7 pointed out, the major point a lot of people seem to be forgetting is that enforcing STRONG would immediately mean that everyone using phones launched before Android 8 would no longer be able to use those apps - even if their phones were completely stock.

Play Integrity is just an indicator of device security state. That's all it is. Google is not interested in preventing root or going after modders, otherwise it would be impossible to install and use Gapps on unlocked and modified devices.

I really wish people would stop it with the paranoid defeatist rhetoric, especially when they don't fully understand how this works and what the implications would be if they did bring the hammer down.
[Magisk] majorfigjam:
I'm aware of some high value corporate banking and expense type apps, where the developers have already made decisions not to support anything older than Pie roms. But then they know that their user base will have newer hardware anyway. One or two may already be enforcing Strong.

Where third party developers perceive a need to enforce Strong, then they will try, and Google simply gives them the tools. The risk to them is that they will lose users with older devices.

For Google, Wallet is a special case, as it's closely integrated into banking systems, and the major payment networks like Visa, MC and Amex. Let's face it, Google would rather not allow the spoofing of account IDs into those networks, and Wallet on insecure bootloaders is one way that might happen.

I don't expect Google to enforce Strong anytime soon, but I do expect they will introduce new checks to make it harder for new devices to masquerade as old ones, particularly for Wallet.

If and when that happens, expect a rush to cheap nfc enabled watches for payment.
[Magisk] Utini:
Except that every random corporate relevant or banking relevant app will the jump on the wagon and require "strong" as well. Because corporate IT departments require it, because banks are paranoid,...
[Magisk] purgy:
I'd be interested in finding out which prints have risen again, and what motivation they could have to reinstate them?

More the latter really, as it seems the bananaing must have had some negative side effect that they couldn't work around.
[Magisk] HippoMan:
It would be interesting to note the date when each of these FP's was banana-ed and the date when it was de-banana-ed.

If the duration of these FP's being unusable is constant, then perhaps banana-ing is temporary and only lasts for a fixed amount of time.
[Magisk] HipKat:
I can confirm the same thing and the fingerprint I've passed with using @osm0sis has been passing for about a week now, even after flashing OTA to both slots
[Magisk] osm0sis:
I'm still on my first fingerprint from November 19. The method works! 😉
[Magisk] uschipower:
Hello,

just some questions for my understanding:

- I had a look which fingerprints are used in the history in the module. There are used fingerprints from android 7 and 8. Is there a reason why no newer prints are used?

I noticed the same in "Magisk Hide Props". But here, i supposed it is because the mod isnt maintained any more.

- when google ban the fingerprints, what does this mean for people who really uses these devices?

- in my thought, would it not better to use fingerprints of new devices which are maintained by manufacture at the moment and which are expensive when buying? Here Google cannot ban the fingerprints because this would lead to many complains of real device users.

EDIT:

Why does Momo still show LOS-Infos?

I do not understand it.

View attachment 6051541
[Magisk] pndwal:
Latest Shamiko-v1.0-290-release

Note:

• 3. Hide some traces introduced by other modules (e.g. PlayIntegrityFix)

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-89255931

👍 PW
[Magisk] osm0sis:
Interesting! It removes all of their service.sh and post-fs-data.sh prop changes. Possibly moves them internal to the code, but can't say for sure since it's not in the changelog and closed source.
[Magisk] pndwal:
Yup... Know any good reversers? 😉 PW
[Magisk] pndwal:
FWIW, that function existed (per changelog) since v0.8.0... PW
[Magisk] shoey63:
Definitely internalized and using a method other than reset-prop, which is being detected by a lot of banks now.

Apart from the obvious ones in service.sh, does pif v5 also use reset-prop to change values?
[Magisk] intel_core_i7:
They have the option to implement it now, no need to wait for Google. Some already require local attestation of bootloader locking, and well the progress on restricted unlocked devices on others hasn't gone anywhere, no new known bank has done it in several months?
[Magisk] osm0sis:
Just service.sh and post-fs-data.sh for the ones that are safe to be changed globally. Though perhaps we should make them all Zygisk side to only DroidGuard and let Shamiko do the Shamiko things.
[Magisk] trevtdogg:
all of these questions have been discussed here often. i know it's a long thread, but the all-time most liked posts do give a lot of info, as well as this thread: https://xdaforums.com/t/how-to-sear...scussion-for-complete-noobs-from-one.4645816/

the fingerprints are only banned from spoofing. the actual locked bootloader stock rom devices that use the same fingerprint by default are not affected by the banning of their fingerprints.

newer devices don't pass as easily or as consistently as older devices, because the whole point of spoofing a different device fingerprint is to force software attestation instead of hardware attestation. phones released with android 8 or later use hardware attestation, only phones released with android 7 or earlier use software attestation.

this is a very general rule of thumb to go by, it's not a hard blanket rule. some users have found working prints from devices launched with android 9, 10, 11, etc. however these seem to be a bit rarer.
[Magisk] beeshyams:
All your Qs have addressed multiple times in this thread. Therefore, I will be very brief :

1. Newer devices force hardware attestation which will fail in Spoofing

2. Nothing, they continue to use their devices. Only spoofed prints are banned.

3. Covered in 1 & 2 (para before edit)

4. Because Spoofing is not for the entire device but an element of OS that checks (Droid Guard)
[Magisk] shoey63:
Sounds like a good idea👍
[Magisk] xcl1pse:
Because theres weird app that false positive detecting shamiko lol
[Magisk] pndwal:
The later the device the more likely Google enforce HARDWARE_BACKED evaluationType verdicts at server end, ant that's done by checking the props we're spoofing...

Nb. No such enforcement is applied to A7 launch version devices and earlier and many A8-A12 LV devices are exempted... All A13+ LV devices have HARDWARE_BACKED evaluationType verdicts enforced... (The window for OEMs to mess up keymaster implementations etc was thus closed with A13, however with A14+ such issues may be fixable on the fly)...

They still work... That's why I initially opposed the use of the word 'banned' but it stuck. 😉

We still haven't figured out the precise 'banning' mechanism used /cross checking done to differentiate between locked/stock and spoofing devices... This is a real priority...

As explained above, 'banning' can simply mean enforcing HARDWARE_BACKED evaluationType verdicts although servers may simply be blocking BASIC-only evaluationType verdicts on spoofed devices using these prints... Of course the prints we use must necessarily not be used for enforcement purposes, so to be sure they won't be enforced later (effectively 'banning' for our purposes) you'd need to choose A8+ devices known to have broken keymaster or other chain of trust issues... I'm actually using one such OnePlus device print/prop set.

I'm running unofficial LOS and had the same + warning about TWRP...

Momo/banks look for and can see certain folders... I renamed TWRP folder in /storage and addon.d folder in /system and now get only:

View attachment 6051559

🤠 PW
[Magisk] xcl1pse:
Move /system/addon.d and /vendor/bin/install-recovery.sh to something else. You need that back if you plan to dirty flash your custom ROM
[Magisk] mesiu84:
What is the key you're talking about?

I have my custom pif.json pulled from an old phone I own but not use anymore, I try the same pif.json with both 14.6 and 15.1 version but it only work (passes tests) on 14.6.

{
"PRODUCT": "XXXXX",
"DEVICE": "XXXXX",
"MANUFACTURER": "XXXXX",
"BRAND": "XXXXX",
"MODEL": "XXXXX",
"FINGERPRINT": "XXXXX",
"SECURITY_PATCH": "XXXXX",
"FIRST_API_LEVEL": "XXXXX"
}

what other keys am I missing so I could pull those from that phone I own.

Why to use always the latest version:

1. I have a rule to always be up to date if possible

2. If there is a new release fixing some changes google did, those changes would be applied probably on version 15.1 and be released as 15.2 or something, so if 15.1 doesn't work for me probably 15.2 would also not work :)

3. Just my curiosity ... 🙃