yashsingh1/xdaforums huggingface dataset:
[Magisk] V0latyle:
Unfortunately without a way of knowing exactly what these apps are looking for, it's hard to say.

I think I should probably retract one of my statements: We don't really know which apps may require STRONG integrity. Right @pndwal ? Or is there something I'm missing in being able to determine what responses an app needs?
[Magisk] sawdoctor:
If you think of the main reasons people root thier phones perhaps if Google helped a little more we may not root. It would be nice to remove some bloat, block adds, have sound modifications, theme your phone etc without root. Yes I know a lot of these things can be done without root but it's harder.

Ive just switched from Samsung to pixel, with Samsung theme park and goodlock I could achieve a lot of things 8 need root for on pixel which really is a shame. But at least we're not locked down like apple and cam choose the phone brand that suits our needs best
[Magisk] V0latyle:
No ads definitely won't happen from Google - they ban apps from the appstore that block ads, and the overwhelming majority of Google's revenue comes from Doubleclick

I have used HTC, Samsung, and Google. I've always liked the AOSP feel, so the Pixels stand out to me in that regard...plus they have no added bloat beyond the Google Play stuff.

The difference between OneUI and what is running on the Pixels is that OneUI has Samsung's own theming framework on top of Android, so since they already have something that changes the appearance of the UI it's pretty simple to implement themes. Pixels on the other hand are basically running AOSP which doesn't have any theme at all beyond colors, so to do more than is built in you obviously have to use modules with root.

But yes...Android phones are built on the principle of openness, despite the efforts of Samsung to lock theirs down. You can (usually) install any OS you want, you just have to port it to the device. You can install any app you want, whether from official or unofficial sources. You can use it with Google services, or you can use it without. You can play with the code all you want because (beyond Samsung's firmware) it's open source. And as far as I know Android doesn't incorporate any intentional forced obsolescence.

Conttrast that with iPhones. You can only run iOS without some serious modification and jailbreaking. You can only install apps from the app store. You can only use it with Apple's services. Their code is completely closed source, and they'll sue you into oblivion if you try to modify it. And they have built in forced obsolescence that reduces the performance and stability of older devices.
[Magisk] pndwal:
Well member did say

- This is key; this app clearly doesn't require PI strongIntegrity, at least implemented in a standard way.

Apps could theoretically use a hybrid method to call strongIntegrity on a per device basis, but since PI doesn't provide any hardware backed device/hardware identifiers this would really defeat the purpose; Prop based device/hardware identification etc can always be spoofed, so users could still bypass such a hybrid strongntegrity implementation anyway, ie. it would really be no stronger than deviceIntegrity that way.

On the other hand, it seems we'll need a reasonable amount of anecdotal evidence to determine if apps start using the unrelated "documented method for Hardware Key Attestation" I discussed and you linked above.. That does in fact include all device/hardware identifiers (eg devices keymaster version) from verified boot keys needed to selectively require a hardware key backed attestation.

I know some checks can be easily identified from logs, sometimes the apps own, and also by monitoring/deciphering network traffic/calls, but besides reversing code I can't think of other ways off top of head... There may be other ways, but probably no more easy ones. 🙃 PW
[Magisk] intel_core_i7:
I guess this app has its own root detection method, which is quite strong these days, probably zygisk detection since it's widespread implemented in my country, you kinda have to wait for hiding methods/magisk/shamiko/etc. to update right now

No, it's not bootloader related, by any way. I downloaded it, and the app opened fine. Device is running android 11, no hardware TEE by any means (unsupported), unlocked bootloader - only basic integrity passes. Connection keeps failing though, probably because it would not accept internet connections from outside of Brazil
[Magisk] chiteroman:
Working with latest Magisk Alpha with Zygisk enabled. It doesn't check bootloader status.
[Magisk] pndwal:
I have a problem...

With Alpha NB-Zygisk POC, previously vv's Momo saw only Unlocked Bootloader and Nullptr's Native Detector saw nothing too...

However I've installed several Magisk versions since first trying Alpha 26102 (private group test version) and having put it back w/ no changes AFAIK... only Huskys (proc string?) Memory Detector still sees nothing; Mono now sees Zygisk and Magisk, and Native Detector sees Injection and Abnormal Environment... Bank apps like Livin by Mandiri are detecting again too... 🙁

Perhaps you could give me clues re. whats changed in my system because NB-Zygisk was working beautifully (for most detecting banks) before... 🙂 PW
[Magisk] chiteroman:
Try to completely uninstall Magisk, then go to TWRP and remove dalvik and cache. From TWRP remove all content in /data/adb (don't remove the folder).

Reboot system, remove all data and cache of target apps.

Flash latest Magisk Alpha from "private" group and check again if it's working. If not, maybe you should reinstall the rom :(
[Magisk] wilsonhlacerda:
Nice find! Yes, if app shows any screen then it is working, could not detect that system is rooted/modified.

I'll keep an eye on newest Alpha. (Older used not to help.)
[Magisk] pndwal:
Can you say if this: NativeDetector gives 'Normal' result (nothing detected) with your Alpha setup?... Thanks, PW
[Magisk] chiteroman:
Mine crash XD
[Magisk] wilsonhlacerda:
May I ask you a favor to test 2 other banks on your Magisk Alpha? I believe both are also detecting zygisk, just like the previous one (no success here with Magisk Delta). Thanks!:

1- (this one crash) https://play.google.com/store/apps/details?id=com.btg.pactual.digital.mobile

2- (this one only shows a warning screen with an OK button) https://play.google.com/store/apps/details?id=com.picpay
[Magisk] chiteroman:
I was using LineageOS and has a problem (a lot of problems) in build.prop, I will try it in MIUI
[Magisk] intel_core_i7:
Some people are really braindead, they still think that Google is going to force safetynet hardware attestation down into every single app...

I just don't understand why they keep thinking like that, despite many speculations (from professionals to amateurs) that this is almost impossible to happen

I guess google is always the "bad guy" in their eyes, hence why this happens
[Magisk] chiteroman:
They never force nothing to any developer, it's the developer decision to use hardware attestation or not. Also, this can be done without Play Integrity / Safetynet like Key Attestation Demo or CIB do.
[Magisk] intel_core_i7:
I decided to give Google's AI a try about Google enforcing the Play Integrity API and has it been mandatory or plans to be mandatory for all new apps, really? I asked for more information but the bot will refuse to answer, because it's outside of its capabilities. Can anyone verify this information, or does this only applies for old apps that use Safetynet only? I made a quick search on google.com and couldn't find any answer to this

Still, it didn't say which level of attestation would be required, so safe to say only BASIC is enforced
[Magisk] chiteroman:
That's fake. Never trust the words of an AI.

Google never force devs to use Safetynet.
[Magisk] intel_core_i7:
Yeah I tried searching and of course nothing appeared that has this info in it. Already believed that it's made up, but chance of being true is always there. Thanks for clarifying
[Magisk] intel_core_i7:
Also, I present to you guys another app that its root check will immediately trip when a custom ROM using a different device fingerprint than the device's own one:

Ví VNPAY – Ví của Gia đình - Ứng dụng trên Google Play

Cho cuộc sống đơn giản hơn

play.google.com

I can guarantee that it doesn't use Play Integrity API, since using OEM's ROM with unlocked bootloader (only BASIC passes) and it doesn't complain. It also checks for zygisk, too. Very strong of an app.
[Magisk] chiteroman:
I can open it using KernelSU and Zygisk
[Magisk] intel_core_i7:
Hmm weird, because it will trip on some non rooted custom ROM, in some cases, some users have been reporting this. And also this app only gives a rooted notification, it will not force close.
[Magisk] mido4ever2000:
I've tried to bypass play integrity in all possible ways but I couldn't

Even play store says that device is not certified 🙄
[Magisk] chiteroman:
Yeah, it showed me an alert of root, maybe it's just a Zygisk detection.
[Magisk] HippoMan:
Yes, it's the developers who are responsible for making rooted Android devices increasingly less usable.
[Magisk] chiteroman:
Evolution X (Official) in Evolution X

Safetynet now fully passes by default after the latest source changes. Tell your maintainers to release a new update and to check for themselves. This will fix lots of apps crashing and that magisk is no longer needed to pass safetynet. EDIT: Looks like this only applies to a few devices. It's...

t.me
[Magisk] V0latyle:
Is this a custom ROM?

How in the world did they manage this?
[Magisk] chiteroman:
Same as Xiaomi.eu did, it's just a Google bug in their servers.

You can check it yourself: https://github.com/Evolution-X/fram...rnal/util/evolution/PixelPropsUtils.java#L358
[Magisk] intel_core_i7:
I can imagine Google patching this in a hearbeat, if they decide that this bug was exploited at a widespread level
[Magisk] HippoMan:
To all of you Google employees who are reading here: this "Safetynet passes" comment is just a joke! Ha ha ha ha! What a knee-slapper! Of course there's no need to take that comment seriously. Really! (Please don't!!!)

:)
[Magisk] intel_core_i7:
Hey, at least it only happens on a very few devices, for example POCO F4 doesn't pass.
[Magisk] ipdev:
That is an old trick for safetynet. 😉

You also need to use the security date that matches the fingerprint used.

It would do no nothing to spoof "Hardware Backed" attestation.

Cheers. :cowboy:

PS.

When you build a custom rom, you set the fingerprint to the current (or last) official fingerprint.

android_device_google_bonito/lineage_bonito.mk at 5146eda3e9c3d42adf22b565235364ba70b0eba9 · LineageOS/android_device_google_bonito

Contribute to LineageOS/android_device_google_bonito development by creating an account on GitHub.

github.com

PPS.

ezio84 included kdrag0n's SafetyNet "FIXES" in his (now dead) abc rom.

Commits · ezio84/abc_build

Contribute to ezio84/abc_build development by creating an account on GitHub.

github.com
[Magisk] pndwal:
Sorry doc, can you explain the trick?... I'd never heard of shouldBypassTaskPermission etc... 🤔 PW
[Magisk] ipdev:
Confused me for a minute. 🙃

There was a commit (8 hours ago as I write this replay).

The original post(s).

543 and 545

Linked to:

setPropValue("FINGERPRINT", "google/walleye/walleye:8.1.0/OPM1.171019.011/4448085:user/release-keys");

Which is currently Line #260.

---

I am not familiar with evolution-x.

Not sure what patches/hacks they include in their builds.

Since the original post was about SafetyNet/PI passing Hardware.

Newer devices had to spoof an older certified device to use basic attestation.

Just changing the build fingerprint is not enough to pass Hardware attestation.

But...

I know you know all this and can explain it better than I can.

I know because I read you posts though the years about it. 😉​

On the other hand, they (evolution-x) might only be spoofing an older Pixel for Google extras.

I honestly do not remember what if any there are currently.

I think you get some extra apps and something with gDrive (addition storage or exemption from storage limit?).

Cheers. :cowboy:
[Magisk] ManiKanta@123:
Bro help me a little. Please. My CTS profile is failing please help anyone. My device:ASUS ROG PHONE 2
[Magisk] shoey63:
Forget about MHPC module.

Remove it and use USNF module by @Displax .
[Magisk] intel_core_i7:
I don't know if this is the appropriate thread to discuss about banking apps, but since I have discussed here before so can I ask a question, please remove or move to another, more appropriate thread if needed:

Have you ever seen banking apps requiring users to completely disable accessibility apps & services in order to gain access, if yes then what are your thoughts? This is happening in my country, with several banks doing it. I got it that accessibility is one of the most misused parts of Android, and Google itself has been working hard to removing unnecessary rights of those apps requiring it, but this is just too far, leaving out many custom launcher users, and people with actual accessibility needs on their phone (not that many here, and they aren't prioritized that much like developed country)
[Magisk] V0latyle:
That's out of the scope of this thread, but it wouldn't surprise me - a few developers use a "one size fits all" security model developed by third party companies that have rather strict policies for devices. Personally, I think it's wrong - no app developer should be able to tell you what to do with your device, beyond showing a warning that you use the app at your own risk on a rooted device...But accessibility functions? That's pretty extreme.
[Magisk] zgfg:
It reminds me of Ruru checker - that also looks if Accessibility Services are enabled
[Magisk] ManiKanta@123:
What happens if we use both? Can we use both?
[Magisk] zgfg:
Use/test on your own risk. Problem is that MHPC wants to overwrite the same props but it is not up to date with all the SN/PI API changes and with what the USNF does. Hence it will most likely affect what USNF wants to do

You were previously advised to forget MHPC, and for good reasons
[Magisk] ManiKanta@123:
So should I remove the mhpc module once and for all??
[Magisk] zgfg:
I don't use it for years. Development for the original MHPC halted two or three years ago

There is a fork (I don't know which one you use), but developer never updates into the new thread on XDA he opened like a year or two ago,, so you should find and check it's status on his TG channel
[Magisk] ManiKanta@123:
Oh tnx bro. I removed the mhpc module. And CTS profile match is passed tnx very much 😁. Bro I use shamiko also. Should I update shamiko or leave it as it is?

@zgfg
[Magisk] V0latyle:
What are your Play Integrity responses?
[Magisk] ManiKanta@123:
What play integrity bro? Like play store?
[Magisk] roirraW "edor" ehT:
Install from the Play Store:

YASNAC - SafetyNet Checker

Launch it.

Click Run SafetyNet Attestation.

It should say:

Basic integrity: Pass

CTS profile match: Pass

Evaluation type: BASIC

Play Integrity API Checker

Launch it.

Click Check.

It should have the following with a green checkmark:

MEETS_DEVICE_INTEGRITY

MEETS_BASIC_INTEGRITY

It's normal for MEETS_STRONG_INTEGRITY to have a red X.
[Magisk] ManiKanta@123:
Yeah it says as it is. But strong integrity is red x.
[Magisk] ManiKanta@123:
Yeah tnx bro. But banking apps are detecting the Root what to do?
[Magisk] roirraW "edor" ehT:
You've got root hidden from those apps in Magisk's DenyList? If so, then some bank apps just can't be fooled, and there's nothing you can do unless you want to unroot. The alternative is to use their websites in a web browser instead of their apps.
[Magisk] zgfg:
And who says it is exactly because of Strong Integrity

They can detect dozens of other 'root' footprints. Please search around, tons of similar posts, questions, answers, checkers to test, methods to hide have been posted

You never know what exactly certain app looks for and finds - it's not in their internet to tell you. Mouse and cat game
[Magisk] intel_core_i7:
It's really sad to see that banking apps going too far... Scamming here happened to often, via phone calls with people disguising themselves as authorities. Vietnam has a problem when everything in your life demands you to have its apps installed on your phone, most notably banking apps and government issued health and identification app, and the local authorities will abuse you to hell if you don't install it, even though it's "voluntary" (corrupted system, it's just the higher levels pushing internal policies, plans to make lower levels to try to have people have those installed on your phone). Two of that combined and it became disastrous, people are scared of authorities making your life harder, so they installed unknown apps from random websites that were made by those scammers, which were using accessibility services to skim people's passwords and 2FAs. Some individuals lost up to hundreds of thousands USD, and b's probably have gone too sick and tired of people calling and making them work hard to retrieve the money (which fails all the time, btw) so here we are.

I would blame on user error for not having enough knowledge and for not reading everything appears on the phone display, but as I explained above + the elders, this is inevitable. The best outcome is there would be an opt-out system, but that's not something the banking system of a developing country would do, where consumer rights aren't enough. If this happened in the EU/North america, I would expect at least one lawsuit to happen, about this
[Magisk] pndwal:
Prop spoofing is done for many reasons...

S/N and PI related props like fingerprint and model (set in MHPC by 'force basic attestation' setting) should now be properly handled by USNF (and these two in particular target gms rather than being globally set) as well as 'MagiskHide' sensitive props... Nb. The sensitive props are the only ones reset (if exist) by default (no configuration) w/ MHPC enabled... This can also be disabled but shouldn't hurt...

You can still use MHPC for other purposes of course, but leave props above the USNF... 👀 PW
[Magisk] ManiKanta@123:
N

Bro good morning. Bro one more doubt. I'm using hide my applist and xprivacy lua. Should I use both or only hide my applist is enough. Because today I got to know that xprivacy lua project is dead before more than 1 year
[Magisk] zgfg:
There have been posts here and/or in other threads where users had problems with one or another 'banking' app (and 'root' checkers) and it eventually turned out that they had XLua

They fixed the problem when they got rid of XLua. But it's not enough to uninstall XLua since it leaves some files that detectors still find. Please search and read. What/how to delete is also described on XLua GitHub Readme
[Magisk] ManiKanta@123:
Can you send me that process in how to delete?
[Magisk] zgfg:
Sorry, I don't have time to play search machine for the others

As said, google for XPrivacyLua GitHub project, read Readme, and FAQ there , you should find - like everybody else (or as I did when I needed a year and more ago)
[Magisk] ManiKanta@123:
Ok thnx
[Magisk] V0latyle:
@pndwal @zgfg and others, how exactly does this work? Apparently it only works for devices which originally shipped with Android 13....unless you manually change ro.product.first_api_level to 33
[Magisk] zgfg:
For me Strong Integrity works with first Test and with Sweer's module for Xiaomi.eu, hence I don't play with Test3 (originally Strong didn't pass)

Check your props with disabled USNF and MHCP, to see the real ones

I guess that Displax will.implemenr appropriate IF in the next version, hence users would not need to spoof one prop, to make his Test3 module to work

Also, you cannot change ro props on the read-only System by root file mngr (without Magic OverlayFS), only by service sh script in a module (or a script in the service_d folder)
[Magisk] V0latyle:
Technical details on how this works to spoof Strong integrity?
[Magisk] chiteroman:
It's just a Google bug in their servers. The only way to truly spoof Strong integrity is hacking TrustyOS (operating system from Google which is located in TrustZone) and force to sign locked bootloader into certificate chain.

So there are two options, hacking TEE (and StrongBox) or using quantum computer with Shor algorithm to obtain private key from public key of certificates and build our custom certs.
[Magisk] HippoMan:
Yes, we could debate some of my assumptions. However, all in all, you and I are definitely on the same page.

Bye-bye rooting and modding. It's been nice knowing you.
[Magisk] rodken:
Hopefully, there could be some truth in what was discussed here.
[Magisk] HippoMan:
You can go here for my response to that:

https://xdaforums.com/t/discussion-...ding-cat-and-mouse-game.4425939/post-87403751
[Magisk] Namelesswonder:
They already have the timeline, I and anyone else that generated API tokens for SafetyNet got this email beginning of the month. Also details the new response that SafetyNet will have next month.
[Magisk] Namelesswonder:
Email sent out to me and anyone else that generated SafetyNet API tokens at the beginning of the month.

Things aren't looking so good in the coming future.
[Magisk] pndwal:
Still, nothing new here AFAICS... This is just a heads up for Devs who may have missed this:

https://developer.android.com/training/safetynet/deprecation-timeline

🙃 PW
[Magisk] V0latyle:
Huh, I didn't realize there was an actual timeline. So the question is whether Google (and other major developers) will be following this as well and removing SafetyNet API support from their apps. I wonder exactly what's going to change - like is a future Play Services update going to effectively remove SafetyNet? If that's the case we could probably prolong the inevitable by providing a "homebrew" SafetyNet API via a Magisk module or something...but then the question just goes back to "how long until apps don't support SafetyNet at all".
[Magisk] pndwal:
All apps using S/N are encouraged to migrate immediately to PI, or by June 2023 at latest... S/N will continue to work for their old versions till June 2024, but these will also stop working a year earlier if Devs fail to produce PI compliment versions by June 2023...

Why?... A full turndown for S/N will occur in june 2024 as stated...

Not sure what you mean here, but may be answered above(?).

Must be PI versions of any app by June 2023 to keep working... If this is done S/N versions will fail in June 2024. If not, the same apps will fail in June 2023...

Basically this means users get a 1 year grace period from June 2023 to avoid updating to latest versions using PI, but Devs must supply the same before that date...

🤠 PW
[Magisk] V0latyle:
Right, but the question is exactly how the SafetyNet removal will be implemented. I know there is going to be a full turndown; I'm asking exactly how they're going to do it. SafetyNet is strictly device-side, yes? So, I'm wondering if an enterprising dev could potentially supply a replacement API for apps that still support it? Won't do any good for those that remove SafetyNet support, of course...but this is a sort of double edged sword where older apps will no longer be able to run after SafetyNet is removed.
[Magisk] pndwal:
No. The Attestation service runs in device side gms, but signed attestations are generated by Google servers:

https://developer.android.com/training/safetynet/attestation#overview

So Full Turndown simply means Google switch off server side support...

Of course, if this stuff was all done device side, bypassing / spoofing attestation would be easy... It's the cryptographicly (military grade) signed response containing the calling app's original nounce that makes this virtually impossible...

I think it's pretty clear there's no wriggle room in my statements above (and Google's announcement) that

and

June 2024 is the last time S/N will work in any case unless Google changes stance / turndown date...

🙃 PW
[Magisk] V0latyle:
Well crap. Sounds like I'll be using the browser a lot more for security sensitive tasks. I'm not sure I'd be willing to give up root.