yashsingh1/xdaforums huggingface dataset:
[Magisk] pndwal:
But blaming Google doesn't make sense... Whenever changes occur, lately only new props added for hardware based verdict enforcement, @kdrag0n / @Displax / @anirudhgupta109 etc have found prop combinations to bypass it...

Mostly these fixes have given consistent results, but @kdrag0n's attempts at part-time (gms runtime only) spoofing are broken (giving sparodic passing), and @Displax has applied a few fixes but this spoofing may still not be perfect for all devices... Issues like these seem far more likely to account for inconsistent any results a few may face, and adding extra prop manipulation etc is also a likely source of issues (pls let us know after testing)...

Just don't state "Google is quickly patching safetynet fixes as well as the lsposed play integrity fix module" with no basis or evidence... PW
[Magisk] immortalwon:
Yes, you are correct. I am getting consistent passing after removing old, unsupported magiskhidepropsconfig 6.1.2. Maybe this was the source of the problem. I will continue to monitor and see if failures occur, but for now it seems ok.
[Magisk] intel_core_i7:
Reading all of these above and I think I'm thankful enough when in my country, Vietnam, almost every app that an average person has to use doesn't require Safetynet/Play Integrity at all (at any level).
[Magisk] Tomek0000:
Except banks I found 3 other types of apps with this scanning:

- games like pokemon

- app of local parcel delivery company for manage sending parcels using parcel's machines located on the streets, InPost Mobile

- medical app FreeStyle LibreLink

We will see more different type applications with this limitation in the future , I afraid.
[Magisk] zgfg:
There are also e-citizen apps and (pretty stupid) reward apps like (McDonnalds, IKEA), travelling agent apps, etc

Nevertheless, we usually call them all here as 'banking' apps
[Magisk] aboda7m:
Can someone tell me what does this module do?

Play Integrity bypass

Make your device pass Play Integrity check. Shamiko is required.

modules.lsposed.org
[Magisk] HippoMan:
Nothing intrinsically wrong with calling them "banking" apps, as long as we remember that more and more apps, even those which are not specifically dealing with banking, are utilizing these security checks, and this is making the use of root more and more of a liability to normal Android use as time goes on.
[Magisk] immortalwon:
Exactly as the name suggests. Works similar to UNSF magisk module.
[Magisk] pndwal:
And among the first was the game Fate Grand Order (along with a handful of banking apps)... Pokemon and more followed... PW
[Magisk] Tomek0000:
Maybe the future will be not to use root manager, but only activate root for a moment when selected app will be moved to system partition for future work with root without root manager working ?
[Magisk] aboda7m:
I mean is it safe? have anyone else tried it? Why is no one mentioning it?
[Magisk] Tomek0000:
Maybe because it is newer solution for use with shamiko only, instead of UNSF, which will not be able to help next year. Please read first post.

" It has replaced SafetyNet for the most part, with a deadline of June 2024, when Google's SafetyNet servers will go offline."
[Magisk] zgfg:
USNF module also addresses Google Play API, not (only) the old and deprecated SafetyNet API. Actually, that was the reason for its updates and the latest fork and it's update

And you don't need to wait for June - many apps, particularly the Wallet, switched to PI API already in the Q4 of 2022 - also, Google Play Services update from that time installed the new PI API (otherwise, apps like their Wallet would not be able to start using it)

Hence safetynet-fix-v2.4.0-MOD_1.2 was released when the 'future' with PI API replacing SN already started, to let you pass BASIC_INTEGRITY and DEVICE_INTEGRITY from the Play Integrity API checking

That's also why this thread is named Play Integrity API and not SafetyNet API

However, the Magisk module cannot change its old:

id=safetynet-fix

to like:

id=playintegrity-fix

since in that case Magisk would not recognize that the new version of the module comes as an update for the previous one. Most users would then have a mess with both modules/versions installed in parallel, with race-conditions between their spoofs, etc
[Magisk] aboda7m:
So if USNF+shamiko addresses the play integrity... what does the other xposed module do?
[Magisk] zgfg:
Install, test and report here (if you are really interested in)👍
[Magisk] pndwal:
Guess other 'module' is Play Integrity bypass XPosed module?... I think that's been answered; it's a XPosed based alternative to USNF... Should fix any device integrity verdict that normally uses hardware-backed attestation but doesn't require it for passing... I've never tested the XPosed solution however.

BTW, Shamiko does not address PI; it's a root hiding module (hides Magisk modifications incl. Zygisk hooking and more)... There is some overlap between-hardware backed attestation bypass mods and root hiding mods however, eg. both will set sensitive props to non-alarming values to conceal B/L state etc...

👀 PW
[Magisk] aboda7m:
Im intersted but i have no knowledge or experince in testing... i would install it but not know what its doing so no point in me testing and reporting it

I might use it wrong and give false reports... or it could even be malware and i wouldnt even know... thats why i asked here where there are experts on the matter

What do you mean by "uses hardware-backed attestation but doesn't require it for passing"?

Also thanks for your reply
[Magisk] pndwal:
Attestations like S/N ctsProfileMatch and PI deviceIntegrity use hardware-backed attestation on devices that have the hardware for this/are capable (keymaster 3+ / Android 8+ required) by default, and such attestation cannot be spoofed/bypassed.

In order to achieve passing verdicts we can simply cause an exception to be thrown (error) by registering a fake keystore with gms which will cause A8+ devices to fall back to basic attestation however. Then it's just a matter of spoofing the necessary props (device properties) and hiding root from Google Play Service's attestation (droidguard) process etc to pass...

For many, perhaps most, hardware-backed attestation capable devices Google further enforces hardware-backed attestation use for verdicts by disallowing verdicts reached using basic attestation that would otherwise pass. Bypassing this enforcement is also a simple matter of discovering and spoofing the props used by Google to identity devices slated for hardware-backed attestation based verdict enforcement. So spoofing these props is required in addition to those needed for passing basic attestation based verdicts...

This works because S/N ctsProfileMatch and PI deviceIntegrity are device integrity verdicts that normally use hardware-backed attestation but don't require this. Therefore we can use a 'fix' like USNF to achieve passing verdicts.

A strongIntegrity verdict is a device integrity verdict that both uses hardware-backed attestation and requires this for passing. Therefore we cannot use a 'fix' like USNF to achieve a passing verdict since the the fallback to basic attestation and the basic attestation based verdict are disallowed at Google's back (server) end...

👀 PW
[Magisk] immortalwon:
Can someone help me bypass this root detection of my credit card app?

https://play.google.com/store/apps/details?id=io.ionic.access&hl=en_US&gl=US - Card access app

It recently started crashing, means they are detecting something from magisk and/or modules.

Magisk Alpha 26.1

List of modules:
[Magisk] zgfg:
@V0latyle sorry but I think that the paragraph on the screenshot needs clarification

To pass Basic and Device Integrity those two modules are needed, but in the first place it means that Magisk must be installed - more info in the OP posts:

https://xdaforums.com/t/discussion-magisk-the-age-of-zygisk.4393877/

Or something like that 😁
[Magisk] V0latyle:
I'm not sure I understand the problem. I could specify that Magisk must be installed (and have root) but I thought this was implied with the use of any Magisk module.

MHPC is not necessary on stock ROMs, only to spoof valid CTS profile such as one might need to do with a custom ROM. The only module that's been necessary for me is the USNF Displax MOD. Pixel 5 running stock system and kernel...although I'm currently running the UPB1 14 Beta, still don't have to use MHPC

Spoiler content hidden.
[Magisk] zgfg:
Yeah, I know that it should be implicitly understood that Magisk is required.

But all other things you did repeat if it was necessary

I just wanted to make sure that somebody who unlocked the Bootloader and changed the ROM or something must be aware that (if he didn't do yet) he must also install Magisk to be able to use the modules and spoof the PI

Otherwise, at the first glance, somebody could eg think of just trying to flash the module zip file(s) through TWRP or something

Ie, people are afraid that Magisk will make it harder to pass PI, and banking apps checking - but once they already made their minds to unlock BL and eg install custom ROMs, they have to proceed also with Magisk if they want to spoof
[Magisk] V0latyle:
Makes sense. I'll do some edits. Thanks for the feedback.
[Magisk] aboda7m:
Do i need MHPC if i am using a custom rom? And which settings do i need to enable? I have USNF and shamiko, but i was told to uninstall MHPC...
[Magisk] V0latyle:
Maybe. MHPC is used to configure device props to reflect a valid CTS profile. If the ROM you are using already incorporates a CTS profile fix, then you shouldn't need MHPC.

The CTS profile is the device + software combo that passed the Compatibility Test Suite for use with Google Play Services. Few, if any, custom ROMs are CTS tested, so while the device itself may be, the hardware + software combo might not be. Some ROM developers "fix" this by having their props reflect a valid CTS profile so the device appears to be on the stock firmware.

I don't know much about Shamiko so I don't know if it can help in this area.
[Magisk] pndwal:
@V0latyle, one OP change that's still needed:

Really this is no longer true...

The first fix for PI deviceIntegrity in @Displax's modded USNF build and all builds following was inbuilt targeted fingerprint prop spoofing in gms...

This had to be both a passing print and also one mismatched with the one expected for any ROM installed to facilitate the HKA bypass.

Of course stock ROMs already had passing fingerprint props, but even these are no longer used for gms (attestation/droidguard process) spoofing; we now use a very early A6 (Nexus 6P, huawei-angler) fingerprint across the board, and this fixes/works for both ctsProfileMatch and deviceIntegrity for stock and custom ROMs alike...

MHPC spoofing is no longer needed for either custom, China region, developer preview, beta or stock ROMs... 🙃 PW
[Magisk] pndwal:
Actually you don't need this with any late USNF build as I've just posted above... 🙃 PW
[Magisk] V0latyle:
Okay, thanks for the update.
[Magisk] pndwal:
@V0latyle, re new OP wording:

... Of course custom ROMs (like @kdragon's Proton builds) w/ inbuilt SNF/spoofing would make the exception to this... 🙃
[Magisk] V0latyle:
Goddamnit, I can't get anything right. Lol.
[Magisk] zgfg:
Also some versions of Xiaomi.eu ROMs

I can pass PI on both my Xiaomi phones Xiaomi.eu MUI 12 5 and 13 but I still use Husky's (instead of USNF) because it provides better additional hiding:

GitHub - Magisk-Modules-Alt-Repo/sensitive_props: Reset sensitive properties to safe state, take from MagiskHide code

Reset sensitive properties to safe state, take from MagiskHide code - Magisk-Modules-Alt-Repo/sensitive_props

github.com
[Magisk] aboda7m:
Do all apps use play integrity api to check for root? Can some apps check hardware attestation directly without using PI?

Does this mean USNF only spoof hardware attestation for GMS? And if other apps used hardware attestation it will not spoof it for them?
[Magisk] V0latyle:
No, some apps have their own root detection methods. Some of these include:

checking for the presence of a SU binary

checking for the presence of a root manager app such as Magisk or SuperSu

checking for traces of Zygisk / Xposed / LSPosed

checking for permissive SELinux

Some may even check to see whether USB debugging or OEM Unlocking are enabled.

Play Integrity is just an Application Programming Interface. It provides a means for apps to check the integrity verdicts, so while each app can request integrity verdicts for itself, the apps cannot "look behind" Play Integrity to do their "own" investigation of hardware/software states

If you're asking whether an app can check to see whether the bootloader is unlocked, I'm not sure if there is a way for apps to directly interface with the hardware to check the "true" bootloader status; there are props that are supposed to reflect whether the bootloader is unlocked:

ro.boot.flash.locked should be 1 when locked, 0 when unlocked. UNSF Displax MOD sets this to 1.

ro.boot.secure_boot shows PRODUCTION on my device

ro.boot.verifiedbootstate should be ORANGE if bootloader is unlocked; USNF Displax Mod sets this to GREEN

ro.boot.veritymode shows ENFORCING on my device

Since I can view these in Termux without su, I assume they're visible to all user apps.

The UNSF mod causes a fallback from hardware backed attestation to basic attestation, so when apps request integrity verdicts, they will always get MEETS_BASIC_INTEGRITY and MEETS_DEVICE_INTEGRITY.

As mentioned above, apps can implement other methods to check for root, but I don't know if they can tell whether the PI attestation method has been tampered with. If you're asking whether apps can bypass Play Integrity, I don't think this is possible due to the fact that PI encrypts its responses, so apps would have to have access to Google encryption.
[Magisk] zgfg:
See the previous response

Just adding/clarifying that Hardware attestation is part of PI API and as that provided by GMS, hence other apps then use the GMS and they cannot implement or call "Hardware attestation" themselves.

Hence yes, USNF spoofs only for GMS

As you were answered by the previous response, the other apps can additionally implement their own methods to check for 'root'

In most cases that can be also spoofed but by additional Magisk modules (eg Shamiko), LSP modules (eg HMA), etc

In some harder cases one cannot spoof those apps with the official Magisk but eg by using Magisk Delta fork - Delta implements MagiskHide instead of DenyList and it can be even used with Riru instead of Zygisk (better oriented for hiding)

However, there are still some rare apps that cannot be spoofed - or it's not publicly known how-to.

Eg, the 'notorious' Momo detector (closed source) that reports "Bootloader unlocked" (probably not on all phones), and AFAIK there is no known way to spoof

For the 'real' apps, in some cases (if they don't know a better way - although maybe, there exists some), users install an older version of that particular app that was weaker in detecting 'root', etc

Hence you can always expect that once you update a particular 'banking' app that previously worked fine with certain spoofs you have made, that it then starts detecting the 'root' again and that you will need to research how additionally to spoof the new version of that app

It's always the game of cat and mice

Strictly speaking, questions how to spoof this or that app are out-of-scope for this thread that is named PI API - because those apps do not detect root by calling PI API but by some additional methods

However, you will find questions (and answers) about spoofing the particular apps also in this thread, and also scattered around in various other threads
[Magisk] V0latyle:
Great point, I'll add this to the OP as well - "My device is passing BASIC and DEVICE attestation, but an app still detects root. What do I do?"

I would assume the Magisk support/discussion thread would be the appropriate place for that?
[Magisk] HippoMan:
I normally would agree, but that discussion contains more than 50,000 messages spanning several years and a number of changed and refactored Magisk versions, and it will be very confusing for a newcomer to figure out where this information can be found in this thread.

Perhaps we need one or more new, more specifically focused threads for this kind of info ... ???

What do you think?
[Magisk] V0latyle:
Well...

On one hand, we generally prefer that topics remain in existing threads, so if there's already a thread that's appropriate, we'd like folks to use that. Otherwise, to reduce clutter, we'd prefer one general support thread.

However, on the other hand, people rarely search before posting like they're supposed to, and they never read the threads anyway. So the most comprehensive way would be for a single thread to be used for the purpose, with someone constantly maintaining and updating the OP to reflect which apps need what. That is a lot of work so obviously we don't expect anyone to do that.

We could do individual threads specific to each app, but with the number of apps out there, this would quickly go out of control and clutter the site even more.
[Magisk] pndwal:
No.

Yes... Good point...

Nb. This documented method is not using attestation data processed by the droidguard VM for gms that evaluates the runtime environment in response to requests from apps using device integrity APIs; it's using keys generated in response to seperate attestation challenges...

It may take some work for banks, but google provides the method here:

https://developer.android.com/training/articles/security-key-attestation

replete with a Key Attestation sample showing use of the ASN.1 parser from Bouncy Castle to extract an attestation certificate's extension data...

Note for deployment:

Further, main Magisk devs RikkaW and vvb2060 have a built POC here:

https://github.com/vvb2060/KeyAttestation

... while

... but try running it: the information extracted from the Android attestation data is enlightening...

Well we can't spoof hardware keystore backed attestation... USNF actually spoofs a non hardware attestation capable device by registering a fake keystore to produce an exception that causes the droidguardVM attestation engine to supply 'basic' attestations... USNF must also spoof props to bypass Google's prop based hardware backed verdict enforcements applied to many (not all) keymaster 3+ capable devices before such a basic attestation can be accepted (pass) for deviceIntegrity purposes...

The fact that we have NOT and can NOT spoof passing hardware keystore backed attestation is the reason a strongIntegrity verdict cannot be achieved with unlocked devices; bypass works for deviceIntegrity only because Google can accept 'basic' attestations where hardware-backed attestation fails...

But yes, the spoofing is targeted at gms only, specifically the droidguard/attestation process.

It's not the app, but the device that determines if hardware-backed or basic attestation is used... Basically a combination of both types are used by Android 8+ devices for droidguard / device integrity API purposes... Android 7+ are capable of hardware attestation also, but below the threshold required for SafetyNet and Play Integrity... We can force a device to provide only 'basic' attestations via the droidguard VM as mentioned however...

Perhaps you meant "if other apps enforced hardware-backed verdicts" however... That's a different story... Really, that's exactly what is ensured by using/enforcing the PI API strongIntegrity verdict... And no, we can't spoof that; it's Game Over at that point...

Or maybe you mean that apps could be fooled by polling USNF's spoofs if we weren't targeting gms?... Well this would do no good as were not actually spoofing passing hardware backed attestations as I said; only signals that cause droidguard attestations to fall back to basic and Google API's server end enforced use of hardware backed verdicts to be bypassed...

😝 PW
[Magisk] zgfg:
This was the thread you opened a year ago "[Discussion] Magisk - The root-hiding and mod-hiding cat-and-mouse game"

- it's still alive:

[Discussion] Magisk - The root-hiding and mod-hiding cat-and-mouse game

We know that Google supports root per se, while at the same time, they are engaged in ongoing efforts to keep enhancing rooting-detection and modding-detection capabilities in order to make it easier for app developers to know when to cripple...

xdaforums.com

Btw, @V0latyle also used to post there😁
[Magisk] V0latyle:
Exactly. The question of whether an app could individually determine hardware proved integrity begs another question: What would be the point of a developer going to the trouble to verify hardware backed attestation when they can simply use the STRONG_INTEGRITY verdict?

There isn't one. It's more work. You won't find many industries where someone will reinvent something that's freely available and easy to use.

i personally find it a little odd that there's many developers who implement their own root detection when they could simply require MEETS_STRONG_INTEGRITY...But, perhaps this is because these same developers aren't ready to give up on legacy (pre 8.0) Android users; Just as SafetyNet had both the BASIC and HARDWARE_BACKED attestation types, not one single developer has ever required hardware backed attestation because only Android 8.0+ supports it, and knowing this, they have had to resort to other methods to try to determine whether the device is compromised. Again, it's up to the individual developer on what they require and why; Google Play Services vis a vis Play Integrity just provides the interface.

Note on this: From a security standpoint, root = rootkit = compromised security = vulnerable environment. It makes no difference to a bank whether or not some of their users might be "power users"; they're only concerned about avoiding lawsuits, so from their perspective, they try to plug every hole they can find. Maybe there's some out there who get some sort of weird sadistic pleasure out of screwing with power users and developers, who knows.
[Magisk] V0latyle:
Ah, good find. I'll direct questions on specific apps to that thread if @HippoMan doesn't mind. However, unless the OP is kept up to date regarding specific app requirements, I would expect a lot of repeated questions...and to be honest, even with an updated OP this will still happen because no one reads the OP...
[Magisk] aboda7m:
Thank you very much, so if an app is detecting root while passing play integrity i can be sure its another method and not hardware attestation right?
[Magisk] V0latyle:
Most likely. The difficult part of this is as far as I know there's no clear way to determine what verdicts an app requires (@pndwal has answered this question before but I don't remember the specific answer) so there's not really any way to tell exactly what is causing the app to fail - whether it's finding root in some external way, or whether it requires the STRONG_INTEGRITY verdict.

I would suggest taking this discussion to this thread. Specify what app you're having trouble with, as well as the other relevant details - device, Android version, Magisk version, modules used, specific error messages or behaviour encountered. It would also help to do a little research and determine what that particular app's minimum Android requirement is, as some apps do not support older versions of Android.
[Magisk] HippoMan:
Yes, but my thread is just a thread for ranting about the cat-and-mouse game, with the guarantee that nothing will be treated as "off topic". It's not a technical thread.

I think some sort of "how to do it'" technical threads which are focused on very specific problems that various people seem to be repeatedly encountering could be helpful.

Because of my aversion to the cat-and-mouse game, I am way, way, WAY behind the 8-ball in terms of keeping up with the latest Magisk and Magisk-related technical issues (I'm sticking with Magisk 23.0 on an Android-11 custom ROM because I don't want to deal with the headaches of moving forward to anything newer).

Therefore, I'm not a good person to start any focused, problem-solving-related threads about the current Magisk-related issues ... but maybe others would like to do so,