yashsingh1/xdaforums huggingface dataset:
[Magisk] Zaxx32:
I have my old Moto G5+ (US) that is still on A8 but is rooted and not been powered up for ~2 years...any clue if it's one of the 70 club? Even if it is, dunno wth I'm doing tbh except for rooting and adb...:rolleyes:
[Magisk] ThatOneGuyOverThere:
Anyone actually able to send RCS chats yet?
[Magisk] osm0sis:
Again, please go read the FAQ. This has nothing to do with physical devices.
[Magisk] pndwal:
They've clearly made changes...

In HMA best practice is to use templates to hide anything even loosely associated with modding including Magisk itself (and use inbuilt Hide the Magisk app stub obfuscation also), LSPosed modules including HMA, all root apps and even detectors like Momo etc... You could also try whitelist hiding... Sparingly...

If that fails, it's likely Zygisk... Use Alpha or wait for next TJW Magisk build which will have the same (native bridge loading) advantages... Won't be long... 😜

I think you'll crack if you persist... Or possibly just wait for next TJW Magisk... BTW, do you have Shamiko? 🙃 PW

Edit: sorry for the OT folks...
[Magisk] TheRomRooster:
Works fine on cheetah after the displax one started to fail
[Magisk] bobby8921:
I also tried HMA, but I can't add my credit card to Wallet.

Not sure if it's related to PIF though.
[Magisk] BrimoFan123:
Magisk Canary 26401, Shamiko v0.7.4(188), Systemless Hosts, Universal SafetyNet Fix v2.4.0-MOD_2.0 by Displax, Zygisk - LSPosed v1.9.2 (7024)

- YASNAC: Basic integrity Pass; CTS profile match PASS

- Integrity Checker Made by Nikolas Spiridakis v 1.1 (11) - MEETS_DEVICE_INTEGRITY - red

- Wallet - Device doesn't meet security requirements

Installed Play Integrity Fix v12.1 without disabling nor removing other Magisk's modules. In installation log information: "USNF will be removed" After reboot indeed USNF is not present in Magisks modules and MEETS_DEVICE_INTEGRITY - green but Wallet still says: Device doesn't meet security requirements, so I have cleared data for Wallet and rebooted phone. Now Wallet works.

And AdAway 6.1.1 is running - there is no need to disable.

Thanks for developer for Installed Play Integrity Fix.
[Magisk] SymtaxError:
for real, cannot be more grateful to displax for making the mod (otherwise wallet didnt work) and kdrag0n for making the source
[Magisk] dekefake:
Thank you for your well detailed post. I have tried to reproduce your setup on my OnePlus 11 running LineageOS 20, but no luck. Magisk 26401 + Shamiko 0.7.4 (with disabled denylist) + LSPosed 1.9.2 + Play Integrity Fix 12.1 gets me to the same state as you (device integrity green) but Wallet is still not working after data wipes and reboots.

Edit : clearing data of Google play services, wallet and rebooting fixed the problem. Wiping data of the Google Pay app only isn't enough in my case.
[Magisk] ripereira01:
It doesn't work on all miui 14, I used on a custom miui 14 a12 and it worked, and another miui 14 a13 didn't work, I think it has some compatibility error
[Magisk] chiteroman:
If the ROM is a fork of Xiaomi.eu it won't work.
[Magisk] xflowy:
If u dont mind me asking: Do you have anything beside the module here installed? Do I need shamiko, too? Are you on Delta or Official Magisk? Canary? Thanks!
[Magisk] panosdim:
In Pixel Experience Plus 13 also not working. Even if I clear data of wallet and reboot phone
[Magisk] BrimoFan123:
To clarify: does the Wallet still gives you the massage "Device doesn't meet security requirements" or you can't make a payment even if that message is not produced? This need to be clarified because my report that Wallet works states for the situation that the message is not generated but I did not checked possibility to make a real payment yet.
[Magisk] Pheggas:
Thank you so much! Worked like a charm! I just deleted cache & data from wallet, google play store, and google play services and flashed the latest version from github. Then rebooted and ready to pay!
[Magisk] HRSE:
Xiaomi Redmi Note 9 Pro Global (joyeuse)

MIUI Global 14.0.3 Stable (Android 12)

GPay 200.1.1

Magisk 26.4 (hidden + frozen)

Zygisk

Shamiko 0.7.3

Play Integrity Fix 12.1

LSposed (Zygisk) 1.9.2

MagiskHide Props Config 6.1.2-v137

Debloater 17.3.1

Systemless Hosts 1.0

Wipe data of:

Google Play Store (is it needed?)

Google Play Services

GPay

Reboot

GPay doesn't show "not meet security requirements" anymore

Not tried actual payment yet.
[Magisk] dekefake:
In my situation, the message about security requirements is still there, and I haven't tried to make a payment.

Edit : clearing data of Google play services, wallet and rebooting fixed the problem. Wiping data of the wallet app only isn't enough in my case.
[Magisk] MetallicGR:
Works. Magisk Canary 26401 with Play Integrity Fix v12.1 modules, Zygisk, Systemless Hosts from Magisk settings and a clear data on Wallet + Google Play Services -> then restart.

As far as i see, you don't have to have strong integrity green-checked. It works with only Device and Basic integrity too.

Mi 10 Lite with current PixelExperience 13
[Magisk] g1b50n:
I can confirm, that is work:

Magisk 26.4

Zygisk

Play Integrity Fix 12.1

Deleted CACHE & DATA in:

Google Play Store

Google Play Services

Google Walker

View attachment 6031137

Thanks to @chiteroman !!!
[Magisk] IAMAB:
Need some help with my setup. Not sure what I'm doing wrong. Couple of Indian banking apps are detecting root no matter what I do.

For e.g. Hdfc bank, kotak bank app.

My setup.

Magisk 26.4

PIF 12.1

Apps configured in denylist

Enforce denylist enabled

Tried installing shamiko and disabled enforce denylist, but still same result.

All the required caches are cleared. Banking apps were un-installed and installed again.

Any advise.?
[Magisk] HRSE:
Magisk Delta / Magisk Alpha

Kernel SU
[Magisk] anthonnyb98:
Hello @chiteroman, I have the pixel 8 pro with the November update and it still hasn't passed the cts profile.

I am using the latest version of Github, 12.1, kernelsu and zygisk next View attachment 6031150
[Magisk] ho0o0o11111:
Hi,

I wanna try but don't want to register all credit cards again in G Wallet (I will lose all if I clear data in G wallet)

Should I change from USNF to PIF 12.1 first, before I flash Nov update?

current setting: Pixel 6 pro and Pixel 7 pro, A14, Oct update, Magisk 26.3, USNF 2.4.0-1.3 ver

Thanks a lot.
[Magisk] Nergal di Cuthah:
As many people have posted that it's working and others who say it's not. Some say it's connected but not sending/receiving some say it isn't connected. All these answers you can get by reading the last few days posts...just sayin
[Magisk] ThatOneGuyOverThere:
I did and its just been a mess.
[Magisk] osm0sis:
Just read this: https://xdaforums.com/t/module-play-integrity-fix-safetynet-fix.4607985/post-89433239
[Magisk] passionicon:
Folks with private prints
[Magisk] pndwal:
Sorry I missed this... Just saw it... 🙁

The method of Zygisk loading only matters if apps actively detect Zygisk.

Since Google apps aside from GMS/DroidGuard (in connection with S/N or PI APIs) seem to rely on PI verdicts to detect root traces (incl. Zygisk) and don't use internal detection methods like most banks do (don't even need G Pay/Wallet in deny/hide-lists for that reason), I'd be very surprised if Zygisk loading method has any bearing on changed RCS security requirements.

Looks like print (prop/field) set and SIM setup are likely to affect users mileage however... Also, it seems Google may be wanting to enforce a higher level of security than PI MEETS_DEVICE_INTEGRITY (to satisfy Apple, or simply to head of RCS spamming root abusers themselves?) without preempting use of MEETS_STRONG_INTEGRITY to me. (If they wanted an easy fix, they could just pull the STRONG_INTEGRITY pin and throw modders the grenade!)... Might be avoiding doing that because of collateral damage to old device users and users of OnePlus and other broken-OEM-implementation devices (just like banks are), but maybe they just love the modding community enough not to take our bone away themselves... 🙃

Re. RCS Take-up:

People should keep in mind that RCS is still an emerging technology now largely led by Google, and while the RCS concept (ie. the GSM Association's proposal for the next generation of messaging technology) emerged back in 2007 and Google finally announced it would 'lead a charge into an RCS future' in early 2016, it's adoption by Apple (who have really dragged the chain) by the end of 2024 (this will likely arrive as part of iOS18 w/ the public rollout expected around September) was only recently announced, so it seems Google is currently hurrying to make security changes to meet Apple's required standards (for cross-platform security and anti-abuse protections) by that time... These changes may also be bigger (of more importance) than many modders here realise...

Further, even after that goal is reached, cross platform RCS will still be relatively immature with Apple only supporting the baseline RCS Universal Standard meaning end-to-end encryption (E2EE) won't be implemented at least until the GSMA adopts E2EE as standard instead of it being a proprietary Google extension to RCS, so changes/tests/disruptions for these and other reasons may still continue to affect RCS adopters for years yet before RCS matures as the messaging protocol envisaged by the GSMA 17 years ago.

To get a better grasp on RCS history and to understand Google's investment in this thing, please click the Spoiler (WOT) embedded in this post:

https://xdaforums.com/t/module-play-integrity-fix-safetynet-fix.4607985/post-89432711

👀 PW
[Magisk] jobsense:
I installed 3 different Roms linageos20 Cdroid and infinity on my redmi note 4 , to my surprise all custom roms i am trying are CTS profile match failed even using Pif+playcurl. Looks like google punished all the custom roms & nothing is working to get it pass.
[Magisk] pndwal:
So microG minimal GMS app (gmscore?) and microG framework instead of Google's in 'minMicroG', but full Play Store... I think lacking signal caches in microG's minimal GMS app will be you issue as I mentioned already... Play Store is part of the GMS suite of apps, and Play Protect (incl. device certification) is integrated with Google's Play Services (GMS) app as well as a separate Play Protect Service app where that exists (late Pixels only?)...

My guess it that your minMicroG iteration Devs were only concerned with passing PI MEETS_DEVICE_INTEGRITY (which you apparently have), and not with making Play Protect integration with Play Store work (still not clear if you installed full Play Store yourself or if minMicroG originally came with FakeStore or the newer fake Companion app however), otherwise they'd have included full Play Services and G Services Framework... And then there's not much reason to bother with microG. 😜

I'd say be happy with MEETS_DEVICE_INTEGRITY and bank apps working even if you must sideload many apps in minMicroG... Or use a ROM with proper GApps support! 😃 PW
[Magisk] mwzdalne:
what about SMessages and it's rcs?

Sent from SM-S711B using ReLabs
[Magisk] pndwal:
Is LineageOS unofficial?... Because official will be properly signed and PIF should still work. 🤠 PW
[Magisk] CZ.Kostra:
Read attached posts.

🔧 [MODULE] Play Integrity Fix (SafetyNet fix)

PLAY INTEGRITY FIX This module tries to fix Play Integrity and SafetyNet verdicts to get a valid attestation. BEFORE YOU START: - Your ROM must be signed with a private key from maintainer, you can check with this command: unzip -l...

xdaforums.com

🔧 [MODULE] Play Integrity Fix (SafetyNet fix)

PLAY INTEGRITY FIX This module tries to fix Play Integrity and SafetyNet verdicts to get a valid attestation. BEFORE YOU START: - Your ROM must be signed with a private key from maintainer, you can check with this command: unzip -l...

xdaforums.com

If you're using latest PIFix, you don't need 'playcurl'.

If the file '/data/adb/pif.json' exists, delete it.
[Magisk] pndwal:
Ah yes... I can't remember if official LOS used 'vanity' string(?)... But even if official build @jobsense can check by running `uname -r`. 👍 PW
[Magisk] mwzdalne:
maybe mod GMessgages so that it doesnt do the check?

Sent from SM-S711B using ReLabs
[Magisk] mwzdalne:
*GMessages

Sent from SM-S711B using ReLabs
[Magisk] jobsense:
Yes i checked uname - r on all 3 roms and no one was in ban list but still google punished those custom rom's
[Magisk] sawdoctor:
We have some really talented Devs regularly posting in this thread, you only need to look at osmosis threads to see what he's contributed over the last 10 years. If there was an easy fix for any of theses issues then it would have been released
[Magisk] mwzdalne:
okay, i will look 🙂

Sent from SM-S711B using ReLabs
[Magisk] osm0sis:
Depends on the device maintainer.
[Magisk] pndwal:
So most likely none are properly signed (still use testkeys)... You still didn't say if LOS is official, but I checked LineageOS site and seems RN4 is no longer maintained so think your LOS20 must be unofficial...

If you drop to official LineageOS 16.0 (Pie), PIF would probably work for you (at least if had no 'vanity' string in 16.0 too). 😆 PW
[Magisk] osm0sis:
Pie would probably predate Lineage official using their own keys. I forget when they started.
[Magisk] CZ.Kostra:
-fixed minor bugs

-added useful functions
[Magisk] Kopasz999:
Its worked only on Xiaomi phones?
[Magisk] CZ.Kostra:
No. App should work on any Android+root device.
[Magisk] Zaxx32:
My bad. Looked for a FAQ link in op...don't see it. Would the build # from the A8 phone be useful?
[Magisk] pndwal:
Official LineageOS has always been signed (private keys, announced in 3rd blog), so ever since CyanogenMod was forked in Dec 2016 and builds began flowing early 2017. Last official for Xiaomi Mido seems to be lineage-16.0-20200407-nightly-mido-signed.zip. 🤠 PW
[Magisk] shoey63:
Dont forget the easy check for test keys people

unzip -l /system/etc/security/otacerts.zip

Edit: Having "signed" in the name of the zip does NOT mean the rom is necessarily singed with release keys.
[Magisk] casouzaj:
Official LineageOS 21 signing keys:
[Magisk] osm0sis:
Statistically probably not, but you can always try.

FAQ is pretty easily seen in the OP:
[Magisk] Magik_Malfici:
Hello @zgfg.

Thanks for your reply about my comment.

1) Yeah, in practice, it shouldn't fail, but since I've unlocked the BL & the root... it's bound to fail.

How do you go about doing that?

Because the only changes I've made are to unlock the BL via Xiaomi (official), upgrade Android via an official image flash and root via Masgisk through the boot image.

2) What ? If I use vendor-build.prop, my model as a matter of fact is Lime for ARM64 so? I'm not sure I follow you why this is not going well?

Yeah but it's unlocked :p (How else can you flash the root or even upgrade?)

A lot of people say that fingerprints are banned, so I wanted to try and change that, but I'm not sure I understand how it all works...

The Android / Android Security section is very obscure to me! I'm trying so hard to solve the problem by trying some modifications, but nothing changes... some still have RCS, others don't, it's really an incomprehensible mess...
[Magisk] freeza:
Wish there was a way to sync messages from a non-rooted phone to a rooted one like the messages app does for tablets. Using the messages web interface sucks and doesn't give the same options
[Magisk] mwzdalne:
how does it behave when droidguard is entirely removed

Sent from SM-S711B using ReLabs
[Magisk] Magik_Malfici:
Don't install Android. or Don't install anypart of Google maybe...?
[Magisk] Nergal di Cuthah:
I'm going to guess that it fails to test and sends back red on all three. However i don't even believe it's possible to do that
[Magisk] Magik_Malfici:
Remove : Outdate https://i.blackhat.com/Asia-22/Thursday-Materials/asia-22-Thomas-DroidGuard-A-Deep-Dive-Into-Safetynet-slides.pdf
[Magisk] Nergal di Cuthah:
Kinda old and outdated, the parts i read at least before the webpages glitched out. Talks about safetynet (now depreciated) and Magisk Hide (now removed from Magisk)
[Magisk] Magik_Malfici:
Modified. I set it's outdated. Sorry 😐
[Magisk] HippoMan:
There is no way to remove DroidGuard. It is not resident on your phone.

With each integrity check, the DroidGuard bytecode gets loaded onto your phone from the Googlefrinchian server, and that bytecode gets immediately executed on your phone to perform the integrity check.
[Magisk] mwzdalne:
oh so theres no loader? it just loads itself? ROOT POTENTIAL WITHOUT BOOTLOADER UNLOCKED(just a idea)

Sent from SM-S711B using ReLabs
[Magisk] HippoMan:
The DroidGuard bytecode is digitally signed and is digitally verified before execution. If your Android phone was an advanced quantum computer, you might be able you crack the digital signature, and then send some other bytecode to be executed.

Otherwise ... ... ...
[Magisk] sawdoctor:
This is the closest thing there is but it's extremely risky and can hard brick your device

GitHub - chenxiaolong/avbroot: Sign (and root) Android A/B OTAs with custom keys while preserving Android Verified Boot

Sign (and root) Android A/B OTAs with custom keys while preserving Android Verified Boot - chenxiaolong/avbroot

github.com
[Magisk] intel_core_i7:
Modify the app that requires strong itself to remove the strong requirement or to make it accept a dummy strong verdict seems more plausible, it's just if anyone is skilled enough and if the user has the guts to use those modified banking, government id apks.

No I'm not talking about modding droidguard to make it return a strong verdict.
[Magisk] pndwal:
Except that for official LOS, it does... 🙂 PW
[Magisk] HippoMan:
Agreed. Good luck trying to hack each individual app to stop checking for the "locked bootloader" state or the DEVICE-level integrity state.

There's a utility called "BootloaderSpoofer" which is intended to hide the unlocked bootloader state from specified apps. However, it only works with a small subset of apps which are not written to use the latest official methodology for detecting an unlocked bootloader. Other apps which use the official detection method are not able to be fooled by BootloaderSpoofer.

The only known procedure which might work in a subset of cases is the risky methodology referenced above by @sawdoctor. If you try it, good luck again!
[Magisk] ezdiy:
Re droidguard, if someone is really willing to pursue that approach: Record a strace dump on real working nougat device (eg original Google Pixel being the global fp). Then replay it all on spoofed device, again, on syscall ptrace level.

We're nearing the end game of cts device integrity - Google will have to soon pull the nuclear option on the few devices that are still actually in use, because device based bank fraud is increasingly becoming a problem.

Before that happens (it's a liability nightmare), expect droidguard checks to get hyper-specific to the few validating devices, meaning usefulness of said prints will increasingly depend on ability to directly fool droidguard.

Whether it's worth still bothering with cts device integrity is anyone's guess.
[Magisk] intel_core_i7:
View attachment 6111792

It could be done, hence I said it's more plausible. Although it seems like those app uses local attestation. This way can be used for Strong bypass, depending on how the developer decide on what to do with the strong verdict.
[Magisk] XDM inc:
can i sign a rom thats been already installed or do i have to wipe and sign and reinstall?

also how do i about signing my rom?
[Magisk] Nergal di Cuthah:
Either you or the developer of the rom need(s) to sign the rom while compilng it, i don't know if installing the now signed rom requires a wipe but doibt it does as nobody has written they had to wipe
[Magisk] XDM inc:
oh boy Apple... Um GOOGLE is really getting annoying these days with all this unwanted gatekeeping.

im not the dev but think i can reverse engineer the zip and sign it? how would i sign this anyway?
[Magisk] osm0sis:
Either a wipe or the use of that ROM signature migration script is required.
[Magisk] pndwal:
Really, not much has changed in the Device integrity mechanism, components and protocols (although algorithms are always changing) moving from S/N to PI; only some additional checks to those mentioned in Romain Thomas's 'Annex' details and an understanding that SafetyNet (and newer PI) API were actually separate components to the DroidGuard (eg. Romain T, John W and others write of the 'Safetynet process' in GMS and equate DriodGuard with that, but it has now been made clear that a distinction is needed). Actually, Google would probably have simply continued to strengthen S/N except that they wanted to create an API that accommodated Integrity responses in addition to S/N's Device integrity field... In PI we now have responses for Device integrity, Play account details, Application integrity, Recent device activity, App access risk and Play Protect with the ability to add more as needed.

Considering we're only concerned here with the Device integrity verdicts (especially PI MEETS_DEVICE_INTEGRITY which essentially matches old ctsProfileMatch) and it's relationship with DroidGuard hasn't really changed, the Romain Thomas Whitepaper (Deep dive doc) is still very applicable to how this thing works. Several of us here have gained a basic understanding of both S/N and PI Device integrity attestation by reading it (along with the Google developer docs which simply give an overview w/o technical detail). This understanding includes the specific checks the DroidGuard VM performs... Just substitute some references to SafetyNet for DroidGuard and others for Play Integrity API depending on the context...

For a list of the mostly user-space based signals SafetyNet was already polling via GMS and Droidguard as of May 2022 as extrapolated by the reverser (and I included section 8.4.3, Hardware Attestation, for those interested in what was/is polled where HARDWARE_BACKED attestation is used for DEVICE_INTEGRITY or STRONG_INTEGRITY verdicts also), see the first Spoiler/WOT section (latter part) I put here:

https://xdaforums.com/t/module-play-integrity-fix-safetynet-fix.4607985/post-89313530

👀 PW
[Magisk] pndwal:
And for what?... Won't give Verified (green) bootstate in key extension data from AVB chain of trust anyway, only Selfsigned (yellow) instead of Unverified (orange)...

Ie. banks can still still see it's customised OS that may include root, PI still needs spoofing to pass DEVICE_INTEGRITY and STRONG_INTEGRITY will still fail. 😬 PW
[Magisk] ezdiy:
See 8.7 for telemetry data, there's a bit more there now than it used to be back then. Anecdotally, the way CTS profile bans are implemented is via telemetry mismatch, sort of like how you ban cheaters in video games.

It trips a lazy alarm on google side because of sudden influx of weird values (ie partaining to different roms and much higher android versions) compared to old devices that report what's memoized as "usual" for that CTS string. The VM code is still happy, but the server side can simply say no to more than just the profile string.
[Magisk] pndwal:
Google have replay attacks (Devs can/should leverage the nonce field for this) and many other contingencies covered in PI API, and they were also largely covered w/ S/N.

https://xdaforums.com/t/module-play-integrity-fix-safetynet-fix.4607985/post-89532625

🤠 PW
[Magisk] ezdiy:
I'm not talking about replaying the protocol talking to google servers, but having a precise capture of what the VM touches on system and the corresponding values it gets back - and you replay that back on fake host, call by call. With enough traces you can reconstruct plausible environment. It needs to run at this low level (binder IDL/syscalls), so that you can skip all over the VM stuff and its higher level antidebug.