yashsingh1/xdaforums huggingface dataset:
[Magisk] ezdiy:
It's not a protocol level replay attack to begin with, though the capture/replay process may naively hint it being one. The approach is more similar that of how you run bootroms in qemu - you record a trace of IOMMU access and retrieved values on the real hardware, and then use it to simulate what the firmware expects so that it can even run in the sandbox.

For droidguard - with sufficiently low level sandbox - this works because you fundamentally exploit lack of hardware attestation on the device (that you're spoofing) it uses for its inputs, the trace as such is static. As you correctly note there's not much point with bothering anything higher level that droidguard outputs, as that protocol level has an ad-hoc and obfuscated encapsulation.
[Magisk] Aregtheeditor:
I am using magisk btw and I don't want to do a whole apatch thing because my main phone is rooted
[Magisk] zseawqqq:
Worked for me too (Pixel 6 with stock 13 rom). But if I install ZygiskNext, RCS broken again.

what I've tested so far:

1. stock 13 rom without root (unlocked BL), RCS works

2. stock 13 rom + Magisk + no modules, RCS broken

3. stock 13 rom + Magisk + PIF, RCS broken

4. stock 13 rom + KSU + no modules, RCS broken

5. stock 13 rom + Apatch + no modules, RCS works

6. stock 13 rom + Apatch + ZygiskNext , RCS broken

7. stock 13 rom + Apatch + ZygiskNext + PIF, RCS broken
[Magisk] jacobchins:
If you still have Wallet installed, it doesn't usually pop anything up until you attempt to use it (conveniently frustrating), but if you select your profile icon in the top right, then "Payment setup", one of the five options will say "Your phone meets security requirements" or something about it not passing requirements above the rest in a "not finished" section.
[Magisk] LLStarks:
Apatch by itself seems promising. My RCS works for the moment. Wallet adds seem ok.

Waiting for caches to clear.
[Magisk] David B.:
So, the tradeoff is either working RCS with broken device integrity or device integrity with broken RCS. 😕
[Magisk] HippoMan:
There appear to be some exceptions to that generalization. You should go back a few days in this thread and start reading.
[Magisk] generalculprit:
Something is going on.

After latest updates (pixel 8, los21, todays Google update, DEVICE with PIF 15.9.9…) I don't have carrier services anymore, but carrier settings and carrier setup (also carrier OMADM and com.android.carrierconfig).

I cleared all caches, rebooted and activated RCS. It shows as connected and I got a message from JibeRCS with a messenger verification code.

Former RCS chats are actually only as SMS available, where it previously still showed as RCS with vanishing messages.
[Magisk] David B.:
I've been following along with this thread for several days, but there's so much chatter that I have a hard time keeping it straight, and at the rate that this thread is growing, going back a few days means going back about 10 to 20 pages. If you can narrow down where specifically I should be looking, I would appreciate it!
[Magisk] hackthis02:
This is interesting I've been running

stock 13 rom + KSU + ZygisNext, RCS works

for over 12 hours.
[Magisk] CZ.Kostra:
It makes sense Google performs different tests for different devices. That's why it doesn't seem to make sense. 🤔
[Magisk] mwzdalne:
yeah, my other device, which is a redmi 5 plus with one sus android 14 port, RCS works on it perfectly

Sent from SM-S711B using ReLabs
[Magisk] mwzdalne:
by sus, i mean weird with some weird preloaded apps and things, BUT IT WORKS, SO DON'T TOUCH IT

Sent from SM-S711B using ReLabs
[Magisk] Chris_caron25:
I've been keeping up with this thread since the night rcs broke and after seeing people have luck with apatch I wanted to see if anyone else had a similar experience as me. The day rcs broke did anyone else have magisk unhide itself on its own? It could have been just coincidence but when rcs broke I went to make sure pif and playcurl were updated. My homescreen shortcut had disappeared and magisk was in my app drawer and was no longer hidden.
[Magisk] D€INOS:
Out of curiosity I switched from Magisk to Apatch for my test phone Oneplus 8T, and I got NO rcs indication on the 3 chats I had. All of the are work related so I cant send some "test" messages.

Dont have any more contacts that uses RCS, so a more, for science thing.

No rcs indication, with or w/out zygisk-next and/or Osm0sis pif.

Signed Evo X A14, that passes PIF.
[Magisk] mwzdalne:
Idk i have new magisk without magiskhide
[Magisk] badabing2003:
Curious to know if you add Messaging to Magisk denylist and enable it does it work?

It looks like RCS is looking for root more than anything else.
[Magisk] David B.:
I use KernelSU and added Messages to the denylist equivalent several days ago, but it has not fixed it.
[Magisk] majorfigjam:
I can confirm that updating Pixel to today's A14 QPR has no significant impact. I still have wallet, RCS shows connection but doesn't send or receive other than as sms. Device is Play Protect certified, and has Device Integrity..

Using magisk 27001 canary (still as 27002 won't hide itself), Osm0sis fork 9, and sailfish, but otherwise stock.

Messaging is in denylist.
[Magisk] zgfg:
2) I told you to look into the /vendor/build prop instead of to /system/build.prop. Search there for props with device, model, product, fibgerprint

1) Google/Play Integrity does not care how did you unlock BL. That's your business, not theirs. They simply look (among others) if the BL is unlocked

Btw, I also have Xiaomi, also unlocked with the blessing from Xiaomi, but it doesn't matter for Play Integrity. Simple as that your BL is unlocked.

And I also studied my stock Xiaomi prints on two devices, through the Android versions 9-13. Moreover, I had tested while searching for private prints good (some still work now, many have been banned) from the few hundred of Xiaomi ROMs (from various models), by trying my luck with prints extracted both from system and vendor (and in some cases those from /vendor did work while those from /system did not - unfortunately many interesting examples have been banned last month - Ie, they no more pass)

If you are interested into the technical details how PI works, start from the FAQ post, then look for other most liked posts, etc

I can give my hand, it's been many, many times described here in this thread why you cannot get better than Basic Integrity with your stock but on the unlocked BL (eg, I know that I also did answer things like that several times, and by attaching official and unofficial docs and specs about Security and/or including links to them, so sorry if being rude but I'm too tired or lazy to repeat again now😞)
[Magisk] zgfg:
Generally yes, back at the time when G introduced PI as a replacement and successor to SN, SN CTS Basic Profile practically matched the PI Device Integrity.

And that's how it was presented in the official PI specs, in the table how to compare the three tiers of PI (Basic, Device and Strong) against the SN Basic Integrity, CTS Profile Basic and Hardware

However, SN is soon going to be turned off and G did a lot to push developers to upgrade to PI over the last two years. You have two DGs on the phone, one for SN, the other for PI. And they communicate to different juries on the G server side. G did a lot to harden PI and they care less and less to keep SN in pair with PI

Particularly, I've seen many times when testing for private prints the cases where SN passes CTS with Basic profile but Device Integrity for PI fails. It's the case with many 'banned' prints - they didn't care to ban them also for SN (or they intentionally did not want to?)
[Magisk] zgfg:
Yes, search for "the.apk" name in this thread. The path has been mentioned many, many times. And how and why you will see several DG versions there, what happens when you remove...

Go to

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

In every subfolder you will find a little the.apk.

Check the dates to see how often they usually change (it depends also how often you/the apps test SN and PI to pull the latest versions - one for SN, the other for PI)
[Magisk] zgfg:
With RCS, G departed from their own doctrine that 'Play Integrity' is everything what developers need to check against the unsecure modded phones

Btw, you could adapt your native PIF part to check does Google Messages, under its own package name, checks for the FP and other props

I just wonder why they do so - do they use RCS as a pre-production test field for future improvements in PI. Or RCS is really more important to them, or they are pushed harder by Apple or operators than eg by financial industry
[Magisk] HippoMan:
I still vote for the explanation being that the RCS people and Play Integrity people work in two separate groups, and that those groups don't always communicate effectively between each other, even though they need to do so ... and therefore, RCS and PI don't always function together in a consistent manner.
[Magisk] mattburga1984:
Does Play Integrity Fix break Find My Device? Mine doesn't seem to be working.
[Magisk] majorfigjam:
No, and at least for me FMD shows my real device.

Totally unrelated, my Google weather widget is broken now, but that is likely due to some other issue.

Edit: definitely unrelated - weather widget now working.
[Magisk] mattburga1984:
Very strange. Just noticed this today.

FMD tells me to turn it on but it is on.

Can't locate my Pixel 7 Pro which is listed as Motorola Moto Z.
[Magisk] majorfigjam:
Google gets confused sometimes. Moto Z was the "real" device behind the long lasting Griffin print, and at some point you will have updated your Google account or FMD settings with that print in place.

I had a similar issue with my P6 reporting as a Pixel mk1.

To fix it, you likely need to "un-PIF" your phone , and log back into your Google account settings from that phone, and manage your devices. It should then recognise your Pixel 7.

You can then reinstall the PIF module, and so long as you don't update your account details, it should still recognise the P7.
[Magisk] bakaekze:
Your first login to Google was with pif enabled. You need to disable it, remove account and all data of all the related Google apps, reboot and login again
[Magisk] Victor27587:
It works with a test keys signed ROM?!?
[Magisk] BarackMitzvah:
How tough is this to set up? I hesitate jumping through a ton of hoops for a potentially temporary fix

I would rather fail PI if that meant I could use RCS unimpeded, but yeah

Does apatch need its own modules, or can it use magisk modules?
[Magisk] osm0sis:
Ah but here's the thing, with a private working print (i.e. not the current public sailfish one) it works with any root solution. So, I guess it's more that APatch might be the only one NOT triggering whatever extra checks that they've added to RCS to ban the public print.

Messages, Phone and Duo (now Meet) have already been known to hide/neuter some features on rooted devices (reported by Mishaal at various times IIRC), so it's good practice to have them in your DenyList anyway I think, though it doesn't appear to make any difference for the current RCS issue.

Adding Messages AND Carrier Services to DenyList could be worth a try though, then either Enforce DenyList disabled with Shamiko, or enabled without Shamiko.
[Magisk] Hugh9190:
Interesting for what? Hope that more people, besides saying "interesting," can provide more substantial help. For example, listing more clues such as your device model, whether you're using PIF, whether you're using a public fingerprint, etc. Instead of confusing the results of more comprehensive experiment posts and just "mine works".
[Magisk] black.horse:
If anyone find a solution for me.

I have rooted s22 ultra with PI fix module, with basic integrity.

I can't Use Yes Bank Iris app, and Bob world app.

Beside these two app I can Use other banking app with shamiko hide.

App link:

1. YesBank

https://play.google.com/store/apps/details?id=in.irisbyyes.app

2. BobWorld

bob World - Apps on Google Play

The official Mobile Banking app of Bank of Baroda for Android.

play.google.com
[Magisk] pndwal:
Are you sure? (I feel a bit like a patient taking to a surgeon here, but I'm trying to understand this as much as most here are.)

Maybe I'm still not understanding it fully , but I thought that what you describe is what already happened up to 2.3.1 USNF builds incl. @Displax builds that spoofed fingerprint full time (although targeted) to the DroidGuard process...

2.4.0 introduced builds that 'dynamically' patch, then 'revert the fingerprint change'... I think @kdrag0n was looking for a suitable end hook for that for some time, but came up with use of "AndroidCAStore" (as it always seems to be used early in the attestation process before the fingerprint is checked) for 'only spoofing the fingerprint transiently':

https://github.com/kdrag0n/safetynet-fix/pull/207#issuecomment-1340460803

and we got something like his original concept:

https://github.com/kdrag0n/safetynet-fix/pull/207#issuecomment-1200437447

with Dynamically patch build fingerprint in GMS process, setting 'patched' print when 'AndroidCAStore' is detected for a set PATCH_DURATION before "unpatch" (field.set to val orig = Build.FINGERPRINT again).

Since @chiteroman's PIF originally forked @Displax 2.4.0_mod-2.0, I'm assuming we still have 'dynamic' ('transient') patching... [EDIT: turns out we didn't because @Displax reverted 'unpatch' before @chiteroman forked his USNF modded version for PIF. ☹️] With that, it seems to me we already have DroidGuard (on device) seeing proper device props/fields except at runtime for app attestation calls. (Maybe your verboseLogs only see results after attestation?... I dunno tho.)... However, if G servers are catching last DriodGuard measurements (which I only suspect) for RCS/other uses, these will be the spoofed (dynamically patched) props/fields unless another attestation call is made after "unpatch"...

That's what I'm thinking may be worth a shot to see if server-end RCS can get proper original (expected) device signals with PIF still functioning. 🙃 PW
[Magisk] pndwal:
But per the list from @zseawqqq, RCS is broken with APatch + PIF (assume public print)... Only working with APatch + no modules... Seems same reported by @freeza ... 😉 PW
[Magisk] Zaxx32:
Seems RCS started acting up around the same time Apple said they'd use it. Apple prolly pressuring goog on different aspects and they're basically giving them a reach-around of sorts...no telling 4 sure but timing is sorta suspicious. :unsure:
[Magisk] David B.:
The stupidity never ends. Did Mishaal write an article about this? I can't seem to find one, but if he did, I'd love to read about what exactly Google has been keeping from me since I am rooted.
[Magisk] hackthis02:
What was interesting was that the post before mine which I quoted had stock 13 + KSU + ZygiskNext + no PIF and his RCS didn't work.

I'm on a Red Magic 7 stock 13 rom, unlocked boot, KSU, ZygiskNext, no PIF.
[Magisk] ripereira01:
o ****, would there be any way to use it in .EU? in future update?
[Magisk] chiteroman:
No, that ROMs are closed source and I don't know how them works.
[Magisk] chiteroman:
Provide logs.

Are you using A14 ?
[Magisk] anthonnyb98:
Yes, a14! Can you tell me how to get the logs through termux?
[Magisk] chiteroman:
First run command "su" and grant root perms to Termux.

Then run logcat | grep 'PIF' > /sdcard/log.txt and upload the file "log.txt"
[Magisk] anthonnyb98:
The only thing that appears is that. Does not generate txt file
[Magisk] HippoMan:
After using PIF for a while on my Nothing 2 OS 2.0.3 (A13) with Magisk Delta 26301, I noticed some strange behaviors. Even though it successfully gave me DEVICE and BASIC integrity and I could successfully use GPay/Wallet, I noticed that any app that tried to connect to a remote web server using my device's Google login ID could not make the web connection (all web accesses with other login ID's worked fine).

This affected AdAway, Pushbullet, MightyText Pulse SMS, and a few other apps.

I uninstalled each of those apps and reinstalled, and this didn't fix the problem. Then, I removed PIF and rebooted, and the problem remained. I then did a full restore from the latest OrangeFox nandroid backup which I took right before installing PIF, and all but one of those apps started working again with regard to making remote web connections. AdAway was the exception.

I then did an uninstall of AdAway via F-Droid (the previous uninstalls were all done simply via Android's normal facilities), and then a reinstall of AdAway via F-Droid, and then it started working again.

I'm guessing that the F-Droid uninstall must have cleared some data somewhere that a normal Android uninstall doesn't touch.

Anyway, I am not into using my device for banking, and so I can live without that capability, like I have been doing for years.

PIF seems to work well regarding the banking apps, and I still think it's a very worthwhile module. I'm pretty sure that my particular problem must have been due to one or more other apps or modules that I normally use and how they might interact with PIF. Since device-resident banking is not important to me and I don't have a lot of spare time to try to diagnose which apps/modules might be responsible for my problem, I decided to not use PIF and just stick with BASIC integrity.

But I still think PIF would be quite useful for lots of people.
[Magisk] kenkaneki07:
Basically did the exact same thing. Galaxy S22 Ultra, even though I pass integrity check, have the same modules and deleted the caches I still can't pay with Google

UPDATE:

12.2 fixed it for me
[Magisk] osm0sis:
Wallet data doesn't matter, only Play Services and a Play Store do.
[Magisk] osm0sis:
Working fine for me on latest official Magisk canary, so must be something with KernelSU or ZygiskNext?
[Magisk] anthonnyb98:
YYes, the problem is with zygisknext, you have problems loading the module and it even causes an error with the rest of the modules, none of them work. Install alpha for now.
[Magisk] chiteroman:
New prerelease build! -> https://github.com/chiteroman/PlayIntegrityFix/releases/tag/v12.2
[Magisk] zgfg:
Which device and ROM exactly, with Android version
[Magisk] zgfg:
I don't know is its about AdAway

Supposedly, all Google logins go through GSM = Google Play Services.

And this module spoofs your device for GSM, to be Asus ZenFone

So when you try to login eg to YT, Google maybe immediately refuses, not accepting that you now use a different phone

Just a possible explanation
[Magisk] chiteroman:
Poco x3 pro (vayu), global stock 14.0.3 Android 13
[Magisk] SpiderAang:
I put version 12.2 and yet it keeps crashing.

Spoiler content hidden.
[Magisk] chiteroman:
Logcat shows any module log ?
[Magisk] zgfg:
Thanks, so it's only a problem for custom Xiaomi.eu MUI 14/A13, not for official MUI 14/A13
[Magisk] stathis95194:
Attached a log file from Xiaomi 13 Pro (nuwa) A13 if it helps. IC and SN fail
[Magisk] SpiderAang:
How do I do that?
[Magisk] tom1807:
Wrong topic

Correct topic: https://xdaforums.com/t/magisk-general-support-discussion.3432382/

Cheers

Tom
[Magisk] zgfg:
With PIF, you should get Device Integrity, not only Basic

If you don't get Device with PIF, then you can uninstall PIF, most likely you would still have Basic Integrity - or start reading from the FAQ post to find what prevents you from getting Device Integrity, how to fix it or how to know if your custom kernel or ROM may be the issues

Maybe passing Device Int would also help to your apps or maybe not if they use other detection methods, but then it would be out-of-topic for here
[Magisk] markdewet:
Seems to be, so far, yes
[Magisk] zgfg:
Wallet probably runs on ache. It could be different if you try to add a cardl. In the Wallet settings there is also a check if your device is secure - but maybe also running on cache

However, do you pass Device Integrity with that test keys?

RCS is different...
[Magisk] markdewet:
According to TB Checker, yes I do pass Device Integrity.
[Magisk] 에어 론 리:
Well, mine device now do not pass even DEVICE test in Play Store.

Just installed Rom and made test.

A12 stock, LG v50, play integrity fix + play integrity next modules.

Fixed after several device reboots, but device still non-certified, while test became normal (all except strong)

Sombody meet this issue?
[Magisk] 에어 론 리:
After device reboot it became this.

UPD: after a 5-10 minutes, I've reset gms and playstore data, updated PIF and it became normal. Dunno what was it.
[Magisk] mrgbuzz:
If your ROM is not signed by the developer, it wont pass.
[Magisk] 에어 론 리:
my rom is stock-based. it don't need to be signed by dev.

I made it based on stock.
[Magisk] mrgbuzz:
Even if its based on stock, its no longer stock. So it still needs to be signed by the dev/maintainer.
[Magisk] 에어 론 리:
Nope, you're not right. It work normally. Tried to update pif several times - now working normally.

You don't know how I've modified Rom, so you can't say. that it's NOT stock rom in terms of Google certification /fingerprints/etc.
[Magisk] osm0sis:
There's nothing transient about the way it works now as far as I've seen, and IIRC kdrag0n's was a failed attempt at the idea and was reverted as well. Check your verboseLogs at 100 and see all the (unchanged) fields and props.

I seem to recall him mentioning it on his Twitter multiple times.
[Magisk] 에어 론 리:
FYI: I'm not the only one who received this error.

And you're totally not right about stocks and stock-based roms.

If dev/modder didn't changed fprints, it doesnot need to be signed.

Especially while my Rom made with additional deep modding.
[Magisk] osm0sis:
That screenshot shows NO integrity.
[Magisk] 에어 론 리:
mine too. but after reboot it appears.

The same for user on that SS
[Magisk] manjaroid:
Dang, I've been holding out with the public print figuring my private ONE stood a better chance. Bit myself on the ass with that logic.

Believable if Visual Voicemail is an indicator. It's always been stubborn but this time around is like kicking a dead horse.

Did your Pixel 8 Pro come with Carrier Services installed? My 7 Pro didn't, or it went away after updating 13 to 14. It still shows up in the uninstalled list in Play Store app management but I left it alone after looking into it. Mainly just wondering if it's worth experimenting with DenyList and the public print and whatever it was that took over for Carrier Services.
[Magisk] s1dest3pnate:
Using apatch with zygisknext and PIF only made RCS work temporarily. RCS is again broken for me. Damnit!!!!!!
[Magisk] pndwal:
The point is S/N was only an API for device integrity and as such it had already evolved and been strengthening out of sight and over many years. Eg S/N was originally based solely on user-space signals and TJW integrated S/N hiding w/ Magisk 8 at the beginning of 2017... Years later, S/N was updated for hardware based key attestation in March 2020, "evalType" was added to Magisk's integrated 'Check SafetyNet' feature in 21.x builds and passing S/N became a whole new science involving breaking key attestation to trigger fallback to spoofable basic (user-space) signal based attestations...

As a device integrity API, S/N could well have continued to evolve with all the changes we've seen for PI deviceIntegrity attestations except that Google wanted to move to a Multi-faceted attestation API capable of a range of Integrity verdicts in addition to the singular S/N deviceIntegrity attestation ("to protect your apps and games from harmful abuse and attacks"), and capable of being extended and added to further... Thats the reason the Play Integrity API was born, ie. to accommodate appIntegrity and accountDetails main fields in addition to deviceIntegrity... There was no other need to retire S/N...

Since then, not only has the deviceIntegrity attestation been hardened (in the best tradition of S/N), but so have the new integrity attestation fields... Further, Google have also since added new environmentDetails attestations to the Play Integrity lineup including appAccessRiskVerdict, appsDetected and playProtectVerdict responses.

🤠 PW