yashsingh1/xdaforums huggingface dataset:
[Android Software Development] pndwal:
Rooting enables a user to have administrator-level permissions to the operating system environment, allows normal users to install custom Roms, alternative software kernels, update to the latest version of Android OS on an older phone, run root apps, remove or bypass bloatware, etc etc. It is also a very important tool for development / developers / software/hardware testing / pen-testers etc etc...

Modders have also been enjoying the power-use it makes available and unlike Apple, Google is not inclined to prevent any of these advantages of root; Rootability is good for their business model, a selling point for OEM partners and devices and ultimately good for their bottom line and mobile OS promotion.

Subverting / spoofing security signals however is quite a different matter, and is arguably NOT the purpose of root... It's certainly not an official function in Android...

When it comes to running proprietary software on anything other than the verified-secure system a vendor agreed to provide software for, these are just our 'wants', and off course banks are concerned (understatement?) when AVB (Android Verified Boot) / DM Verity (Device Mapper Verity), SafetyNet, Play Integrity and other security measures are bypassed...

Have we just come to expect these personal conveniences simply because we've been on the pigs back for so long?...

Well when we're unceremoniously ditched, some of us will understand, some will wake up and smell the roses, and others will just continue to hate Google... for taking away our free ride... and just for being big... and successful...

For me It's a no-brainer that Google must / should meet the hightening security demands of institutions supplying the software Android users want before indulging a small modding community... They'd be nothing other than stupid not to...

I don't doubt Google want to indulge us (they are our benefactors as providers of the only moddable mobile OS with any sort of respectable presence after all; not 'evil'!)... And they have for quite a while, and quite knowingly to boot!...

But do the maths!!! - They need to look after corporate partners as well as be seen to be offering a platform that is capable of keeping up with emerging security issues and requirements including a fundamentally infallible system of attestation to a secure operating environment for proprietary code as is expected by both banks and the average bank customer and Android user...

Hope this helps just a few more here to Get Real! ...

However...

When apps do fail to run with root (and they will), both root and development will continue as well as practically all root apps, even if some of us will have to find a new mode of transport...

MagiskHide is dead... RootHide may be dying too,

...but Long Live Root! 😁 PW
[Android Software Development] rafapadilla93:
Thank you so much!! It works for me.
[Android Software Development] ashish1989:
Kindly help, I have tried 2-3 versions, in my samsung device having A7 aosp rom in it.

But no module is working, which version to use in android 7.1.2?
[Android Software Development] MatMew:
Can someone please point to the most latest version of the USNF?
[Android Software Development] m0han:
the one that's hot atm: https://xdaforums.com/t/magisk-module-universal-safetynet-fix-2-3-1.4217823/post-87198517
[Android Software Development] pndwal:
This module is largely for fixing SafetyNet by causing falback from HARDWARE to BASIC evaluation (attestation) type... This is generally only needed w/ Android 8+ w/ Keymaster 3... (Google haven't invoked Hardware Evaluation type using early hardware Keymaster 1 or 2).

Please say what isn't working; do you have have BASIC evaluation type in YASNAC?...

USNF 2.3.1 did restore compatibility w/ A7 however, since it was removed from 2.1.3... This will adjust sensitive props for A7 which may help with S/N, but attestation type fallback using Zygisk is disabled...

If you mean an AOSP custom ROM (stock Samsung is also AOSP), @Displax's unofficial USNF should be a good way to pass CTS Profile match instead of using a fingerprint prop configured in MagiskHide Props Config module... It should also allow new Play Integrity Meets_Device_Integrity verdict...

So this mod may well solve your A7 woes... See here:

https://xdaforums.com/t/magisk-module-universal-safetynet-fix-2-3-1.4217823/post-87198517

🙂 PW
[Android Software Development] ashish1989:
I have flashed this mod and because of this mod I am stuck on boot logo now, I have xposed installed, can that be the reason?
[Android Software Development] anryl:
Nothing works on chime(Poco M3) ppui 4.8

Device not certified on Playstore
[Android Software Development] skr1p7k1dd:
@Displax

@pndwai

Thanks bros! I can confirm that the v2.3.1 mod fixed my situation. Kdragons v2.3.1 version worked until I updated to oxygenos12 c33 then my device would no longer pass basic integrity check. Confirmed using Play Integrity API Checker

Anyways, after flashing I am able to use google pay/wallet again. It doesnt pass strong integrity but I'm pretty sure I dont need that anyway.
[Android Software Development] 73sydney:
Magisk - Installation and troubleshooting:Magisk and MagiskHide Installation and Troubleshooting guide

didgeridoohan.com

everyone should have this bookmarked
[Android Software Development] pndwal:
Haven't heard reports of issues like that w/ this, but thinking about it now there may well be issues for A7 (probably not xposed related however):

Official versions disable Zygisk parts (fallback to BASIC triggers targeting the gms attestation process specifically) to re-enable A7 support...

It could be that @Displax's modded version doesn't properly disable the added fix which adds old A6 fingerprint prop targeting same gms attestation process (using Zygisk), and failure to run this may be causing your issues...

I hadn't thought that part through for your A7 device, and clearly the old fingerprint prop won't be applied in any case, so modded (unofficial) version won't benefit you anyway...

The solution for your custom setup to pass S/N & PI is will most likely be the traditional use of MHPC w/ configured fingerprint... You may need to spoof an older print to allow new PI API's MEETS_DEVICE_INTEGRITY but usually this isn't needed for Android 10 and less AFAIK...

@Displax / others may be able to expand on this observation... PW
[Android Software Development] ashish1989:
I also deleted module from twrp manually, but still device is stuck on boot logo

Well I reflashed the rom now, but still my device is not certified on play store, as you said its not needed on devices below A10, I am not using any safetynet module now. But still thinking, what can be done for my old device now?
[Android Software Development] DocMAX:
In YASNAC i'm stuck with "RESTORE_TO_FACTORY_ROM" advice. I am on latest Magisk with SafeNet Fix. No chance to fix.
[Android Software Development] pndwal:
I didn't say that... And you haven't said exactly what 'wasn't working' after your initial efforts ...

I said modded USNF version is not generally needed for deviceIntegrity verdict in A10 (or less) devices... A7 won't need Fallback to BASIC attestation type... Please read carefully...

However, for custom ROMs you likely need solutions to spoof fingerprint or security patch prop(s) to pass SafetyNets CTS Profile Match as well as to set / reset sensitive props that trip SafetyNet & Play Integrity APIs

If the @Displax modded USNF can be made to work (ie. Zygisk is active), it should also naturally fix this issue as a side benefit as it spoofs a passing A6 print. It will also set / reset sensitive props as needed... Nb. Some custom ROMs will do all this and pass S/N without Magisk by spoofing prints and setting sensitive props (also integrating Proton's SafetyNet Fix for A8+ ROMs) out-of-the-box. Some, eg. official LOS, never will...

If modded USNF cannot work (eg Zygisk cannot activate on your device or mod dis-allows Zygisk-targeted fingerprint prop application in addition to Zygisk-activated evaluation Type fallbacks - you'll only need the former, but I'm not sure whether it's active or not in A7), your best fix for SafetyNet's CTS Profile Match and sensitive props is the traditional MHPC configured passing fingerprint prop applied globally. Nb. MHPC will also also set / reset sensitive props as needed by default (unconfigured) and applies these global also...

Your issue w/ USNF may be with Zygisk. Are you getting Zygisk=Yes on home screen?... Nb. old Samsung devices w/ kernels before 3.19 may not be able to use Zygisk.

https://github.com/topjohnwu/Magisk/issues/5395

🙂 PW
[Android Software Development] Displax:
Set SELinux to enforcing
[Android Software Development] ashish1989:
Yes I am getting zygisk = yes in main home screen. And I have set google play services gms and gms stable to enforce deny list, but whenever I am setting play store in denylist phone is stucking on boot screen
[Android Software Development] ipdev:
During the module install, the Android level is checked.

If it Less than 26 (Android 8) the Zygisk part of the module is removed (deleted).

So no Zygisk parts to load on Android 7.x (25) and below. 🙃

Cheers. :cowboy:
[Android Software Development] ipdev:
You should not need to add PlayStore to the denylist.

You only need to add part of GMS.

com.google.android.gms com.google.android.gms.unstable

If Magisk's path is not /sbin you will also need to add

com.google.android.gms com.google.android.gms

Example.

oriole:/ #
oriole:/ # magisk --denylist add com.google.android.gms com.google.android.gms.unstable
oriole:/ # magisk --path
/dev/dsiXiL0
oriole:/ # magisk --denylist add com.google.android.gms com.google.android.gms
oriole:/ #

If you add more of GMS to the denylist, you will normally fail SafetyNet.

Cheers. :cowboy:

PS.

Make sure to clear cache and/or data of PlayStore after you pass SafetyNet.
[Android Software Development] ashish1989:
I am doing the same, but whenever I am enabling zygisk with deny force list enabled, the phone is stucking on boot logo after reboot. In magisk thread @zgfg brother is saying old xposed is not supported with zygisk
[Android Software Development] ipdev:
Since this is getting OT for this thread.

Lets move into the Age of Zygisk thread.

Post # 2,261

See you in the other thread. 🙃

Cheers. :cowboy:
[Android Software Development] Fishawy:
Quick query - I understand that GMS should be disappearing from the Magisk DenyList after a reboot while using the USNF module, but starting yesterday that is not the case anymore. GMS stays visible after a reboot, and on top of that I have these weird GMS java crashes when trying to open certain apps like Instagram (errors are related to com.google.android.gms.ads.identifier.service and android.app.ContextImpl.bindService).

What I tried was updating GMS, uninstalling updates, clearing data & cache, rebooting, disabling all modules and testing, and dirty-flashing the ROM. Nothing works.

I thought I might reset the advertising ID, and low and behold, when I go to Settings - Google - Ads, the page is completely blank.

Hours of online search led me nowhere. Any idea what that might be?
[Android Software Development] ipdev:
Hi all. 🙂

I am currently at a deadhead on what to do. :unsure:

deadhead as in a hydraulic (pressure) stoped/blocked.

As for being a "Deadhead" ... Since I was seven years old. 😉​

I updated the link in my prior post to point to my current testing branch.

I rewrote the scripts and mixed in parts of a module I started shortly after John restarted Magisk development.

Magisk General Post # 48,174

I shelved mHide SafetyNet once Zygisk USNF was released.​

Since the Zygisk version of USNF..

Devices running Android 8 and newer would pass SafetyNet regardless if they support hardware attestation.

Hence Post # 6 in the Age of Zygisk thread.

---

I have gathered some more secure and sensitive properties from more devices (manufactures).

Added them to my check list.

I originally added them as Danger, then started adding the new props as Warning.

- Need to go back and try to figure out what prop should be Danger [secure] or Warning [sensitive]. 🙃

---

A big Thank You to huskydg for nudging me in the direction to check Zygisk. (y)

A bit cleaner so I switched to sqlite to check the denylist also.

---

Still not sure how to handle or if needed to include.

ro.oem_unlock_supported

and

sys.oem_unlock_allowed

huskydg recommended adding sys.oem_unlock_allowed since some apps look for this prop.

So I added sys.oem_unlock_allowed 0 to late (boot complete) props.

This value is set from the toggle in developer settings.

0 is not enabled, 1 is enabled​

---

Two more suggestions from huskydg. (y)

Use the -n option with resetprop.

When I originally read the resetprop section, I though bypassing property_service was defualt.

resetprop is implemented by distilling out the source code related to system properties from AOSP and patched to allow direct modification to property area, or prop_area, bypassing the need to go through property_service.​

I read it again and see I was wrong?

The default set property behavior of resetprop matches setprop, which WILL trigger events (implemented by first deleting the property then set it via property_service). There is a flag -n to disable it if you need this special behavior.​

Does anyone have a reason not to switch to using the resetprop -n option?

-

Kill Google Services in late (after boot complete)?

I did not see any advantage in killing it and having it restart during late boot.

This might have been due the device(s) I tested on.

All comments, thoughts and suggestions are more than welcome.

Cheers all. :cowboy:
[Android Software Development] pndwal:
Commit from @ipdev changed this to remove gms processes only when denylist is enforced IIRC... So if you're using Shamiko etc, these remain in list on bootup... Just don't put them in I guess... PW
[Android Software Development] Fishawy:
Thanks for that, yes I am using Shamiko.

Any idea about those crashes and the blank ads page though? Apologies in advance if this is not the right place to ask.
[Android Software Development] pndwal:
Sorry, beyond me... But are you saying these services run fine w/o USNF enabled? PW
[Android Software Development] Fishawy:
They did for a while yes, but now crashing again. I'm unable to pinpoint the root cause, hence was the query here in hopes someone more experienced is able to shed some light.

I guess it might not be USNF-related after all.
[Android Software Development] pndwal:
So 'a boring or unenterprising person' or a fan of "Casey Jones"?... You don't need to answer that! 😜

I don't have enough insight to comment on your technical issues here (at least not yet) 😛 ...

Had a quick look at mHide SafetyNet project though...

Just from this:

Magisk Module

Module to help pass SafetyNet on devices that do not support hardware attestation...

This module will

Generate a list of 'sensitive' properties on the device and set the values to the 'safe' setting(s) during boot.

Check and adjust some 'sensitive' properties during boot.

Set Magisk's Denylist to enforcing.

Add part of PlayServices to the DenyList.

Requires Zygisk to be enabled in Magisk.

... I'm wondering:

- Could this be made to be an ideal solution for older devices in the event that Zygisk fix in modded USNF cannot be activated for A7 and lower?

Ie.

• Do adjustments to sensitive props target only com.google.android.gms.unstable?

• Can we not set Denylist to enforcing (for use with Shamiko etc)?

• Can we do targeted hiding of root from com.google.android.gms.unstable process instead of adding this to denylist (like USNF)?

(I'm assuming Magisk path is always in /sbin in legacy ramdisk booting devices; is this correct?)

• Can we do com.google.android.gms.unstable targeted spoofing of the same old A6 fingerprint prop as @Displax's USNF mod uses to fix CTS Profile Match in uncertified ROMs? (Possibly this could be enabled as an option if there's any benefit leaving original fingerprint as is where ROM is stock... I'm not sure there is however...)

Ta! 🙂 PW
[Android Software Development] MatMew:
Hi all, if I remove all banking apps and Google wallet, restart my phone and quickly reinstall my banking app, add contactless card and make a payment, I can pay. However, if I wait a few minutes after the card has been added, my phone reverts to saying device is insecure, etc. etc.

Magisk 25.2

Zygisk: Yes

Ramdisk: Yes

Modules installed:

USNF 2.3.1

Zygisk LSPosed 1.8.3
[Android Software Development] 73sydney:
Are you using this specific USNF?
[Android Software Development] MatMew:
Should I be? I think I am.

Edit: turns out I wasn't, I followed the url in the post but downloaded the original USNF. Thank you, kind stranger.
[Android Software Development] MatMew:
View attachment 5694989

Google wallet still shows this.
[Android Software Development] 73sydney:
ill take the stranger :)

you say a word @pndwal and there will be trouble :P
[Android Software Development] TurricanM3:
Did anyone manage to get the VW weconnect app running without root restrictions? I tried so many things but it always detects root and i cannot open/close my car by phone.
[Android Software Development] bjevers:
I have an Audi which I would think is built on the same software? Anyway, I have it in the Magisk denylist, Enforce deny list disabled, and using Shamiko and it works fine.
[Android Software Development] pndwal:
Did you sort that out?

Check you have MEETS_DEVICE_INTEGRITY using Play Integrity API Checker...

If so, many are reporting that Pay/Wallet security requirement issues fix themselves simply by waiting (maybe 5 days?)...

Otherwise you may need to clear Google Play Services and GPay/Wallet data...

Important note:

REBOOT immediately after clearing GPay/Wallet data! ... Opening app before rebooting may result in issues that won't be resolved until you clear data again, including failure of Activity list to populate...

You don't get much stranger ... kinder than this guy (until you annoy him 😜...)

... but I live for trouble! (Bring it on)...

😋 PW
[Android Software Development] rodken:
Sometimes longer ...... :ROFLMAO:
[Android Software Development] tehrzky:
guys this is new. this app detected shamiko

edit:zygisk denylist fixed this. this is the first time i encounter shamiko will be the culprit

View attachment 5702287
[Android Software Development] edd080:
This is what I needed ! Many many thanks for this; i had upgraded from Miui 12 to 13 (Android 12) and had Netflix not showing up for me; but your module just did the trick Netflix shows up in playstore now .

This was my issue here .

Thanks once again! 👍😁
[Android Software Development] HippoMan:
As the use of Play Integrity (and its likely descendants) continues to spread, more and more apps will cease to function fully (or at all) on a rooted/modded device.

Sure, rooting will still be possible, but rooted devices will become more and more crippled for normal use as time goes on.
[Android Software Development] 73sydney:
Im not super concerned, but if it ever gets that bad, i reckon we start a class action and call it "classroot" or "right to root", which here in Oz would have an entirely different context....
[Android Software Development] Fishawy:
Just imagine the reactions on my mates faces when I said "Oh I root my phone" for the first and last time.

Never again.
[Android Software Development] spysky:
Hi all,

Does anyone know if there is any fix for the "MEETS_STRONG_INTEGRITY" ?

From what I've read, the "MEETS_DEVICE_INTEGRITY" and "MEETS_BASIC_INTEGRITY" are fixable using Displax's fix on the USNF (thank you so much for this).

However, i didn't found anything related the strong integrity.

Is this correct, or have I missed some step?

I'm facing this on a OnePlus 5 and a Nothing 1

Thanks
[Android Software Development] osm0sis:
Strong integrity = hardware attestation, basically, so no, no way to fix AFAIK. OnePlus devices at least up to the OnePlus 9 Pro still shipped stock with broken hardware attestation, so there's no way at all of getting it working on those devices.
[Android Software Development] pndwal:
Yes; purchase an Asus ROG Phone 3!

This is the only device I know of where the OEM has messed up the Keymaster implementation in such a way that it will pass MEETS_STRONG_INTEGRITY verdict w/ unlocked bootloader... Other device's may also...

An app requiring new MEETS_STRONG_INTEGRITY is equivalent to requiring old CTS Profile Match using HARDWARE_BACKED evaluationType. As such, banks have not yet required either (although they could) as doing so would exclude users / customers with

1) Many late devices (many OnePlus and others) with broken keymaster implementations.

2) Devices launched with Android 7 and earlier, even if running late Android.

🤠 PW
[Android Software Development] David B.:
Perhaps a stupid question, but, what kinds of side effects come with doing a global props change? I am currently using MagiskHide Props Config to work around this issue and I haven't noticed any problems.
[Android Software Development] zgfg:
Samsung phones may not connect to Samsung store, GCam may load wrong profile since thinking it is different phone.

In the worst case, some phones may have problems with OTA
[Android Software Development] David B.:
Good to know. Thanks! Perhaps the reason I haven't had any issues is because the fingerprint I am using is from the same device I am actually using. The only difference is that I'm using Android 13 and the fingerprint is from one of the old Android 12 images.
[Android Software Development] pndwal:
I assume you mean you have USNF, but have applied a mismatched but certified fingerprint to achieve deviceIntegrity verdict for Play Integrity API, so your model prop(s) changes will be targeted at attestation process in gms while fingerprint will be applied globally... Please say if other...

Apparently it's confirmed that this type of fingerprint change can affect how Play Store perceives a device, and may mean updates or apps (incl. YouTube) are not available due to fingerprint use for Play Store app filtering.

https://github.com/Magisk-Modules-R...ob/master/README.md#can-i-use-any-fingerprint

Fingerprint may affect other functions but I'm not aware which...

It's worth noting that global application of fingerprints by MHPC was generally limited to custom, China region, developer and beta ROMs (as spoofing a fingerprint this way was never needed for certified stock ROMs) so issues with device-specific functions likely remain largely unknown, especially as custom ROM users often don't have options like special camera modes (due to difficulty reverse engineering/using proprietary hardware blobs for these, etc) or OEM app stores working anyway...

This is certainly a side effect of the original globally applied alterations to model prop(s) for 'forcing BASIC attestation' (simple mismatch of model prop is sufficient to bypass enforcement of hardware-backed attestation) both by @Displax and as found in MHPC...

https://github.com/Magisk-Modules-R.../master/README.md#force-basic-key-attestation

... Device-specific special features (eg high-end or proprietary camera functions) are also affected by model prop global changes...

However, I have no knowledge of similar issues resulting from a fingerprint prop changes... Of course this could occur in theory, and will depend on which props are polled by such OEM specific software...

I believe @Displax is simply avoiding unnecessary surprises (including confirmed Play Store issues) by using proper targeted fingerprint spoofing... His comment, while his mod only adds a fingerprint change, also seems to apply broadly to best practice for necessary prop changes in general...

Others may well know of more confirmed side effects for global fingerprint spoofing... PW
[Android Software Development] zgfg:
When using USNF in Zygisk mode, props alterations are applied only to GMS - therefore, they should not affect Samsung store and other apps