yashsingh1/xdaforums huggingface dataset:
[Magisk] Yuri_Rosas:
Well, I was just using magisk in an attempt to hide Uber's bootloader. Without magisk it didn't work and with it would be complex.

As I don't need the magisk /root. The easiest would be to block bootloader.

With miui did not pass in cts safetynet, even without magisk.

Removing the magisk would perhaps allow you to use that Bank in that room, But I'd still be without Uber.

Tomorrow I will install the last miui to my device and lock the bootloader. A silver bullet maybe.

If it doesn't work I'll unlock and try every kind of hidden magisk offers
[Magisk] pndwal:
So with basic GSF, how do/did you get a complete GMS setup?... Have to download playstore, play services etc? Only installed as user apps, not system I guess as B/L locked?

Saw here:

https://xdaforums.com/t/chinese-ver...t-key-attestation-fails.4612677/post-88832759

TGY is called "Global"... Where is this claimed?... Only on Ali Express? In ROM? Other specs?...

Also, is current TGY the one preloaded at purchase?...

Of course, PI API is part of Google play services, which is why it's concerning if complete GMS isn't supplied in ROM or installed in /system... Curious to ascertain if play services are in ROM for certain... PW
[Magisk] pndwal:
"... attempt to hide Uber's bootloader unlocked bootloader from Uber"?

May or may not be possible...

"... block lock the bootloader"?

"... In that room ROM"?

If XiaomiEU inbuilt SNF isn't working to give deviceIntegrity, even your bank apps will likely fail...

👍 PW
[Magisk] Yuri_Rosas:
My translator didn't work well and I didn't revise the text. And I confused room with rom.

I tried to flash the last miui to my device and lock the bootloader. It did not work because the Mi Flash tool did not recognize my phone. By adb and cmd, my cell phone was identified normally, by Mi Flash tool, no 🤡
[Magisk] pndwal:
Oh... Hope you get that sorted...

On the rooted device front, I just responded to another Uber Driver app user and tried the app myself...

Strangely I didn't even add app to denylist or use HMA, so guessing detections may still occur later per in-app options selected, but I'm signed into app fine (not signed up with Uber)...

If you wish to persue rooted options/solutions you may want to comment there:

https://xdaforums.com/t/need-help-uber-driver-app-not-go-online.4614295/post-88851283

especially whether you can or cannot get this far (rooted) after a clean Uber Driver app install (or identity later trigger for app detecting modified device)... 👍 PW
[Magisk] mrspeccy:
GSF and Play Services were already available - probably as system apps. I just installed Play Store as user app, which worked fine. However, I also tried sideloading the Play Integrity Checker app after a reboot, which did not make a difference. Exactly one passed DeviceIntegrity was possible but DeviceIntegrity failed in all subsequent calls to the PlayIntegrity API.

Sorry for the confusion. The device was delivered with TGY software, which is called "Global" on AliExpress. With that software, it passed DeviceIntegrity exactly once after installation. The sales agent at AliExpress confirmed to me that they had replaced the CSC (mainland China) software with TGY using Odin to obtain immediate Google services support. I tried flashing back the CSC version (with locked bootloader) and again arrived at the strange result mentioned above with DeviceIntegrity passing once.

I think the services are in /system even in the mainland China rom. However, I did not check that and am back to the TGY version anyway.
[Magisk] pndwal:
Yes, seems strange that device comes with GMS basics which means is should be CTS/VTS certified (ie have passing fingerprint prop) AGAICS... But I really don't know enough about OEM regional variants or China/Google policy to comment further...

One though, since it passes initially, can you test in Play Integrity API Checker, then click <> symbol at top and screenshot full raw JSON output?... 👍 PW
[Magisk] sunny928:
Hello bro how yo use this in Samsung galaxy s21 ultra
[Magisk] chiteroman:
Spoiler: it doesn't work XD
[Magisk] sunny928:
You mentioned code for pass strong integrity. I have to pass strong intrigrity in my Samsung galaxy s21 ultra.
[Magisk] pndwal:
Loophole closed...

If / when you really need to pass you'll need to restore stock images and lock bootloader... Don't wait for/depend on another loophole/vuln, they're like unicorns... 😜 PW
[Magisk] Jackychans:
Hello @pndwal

I've tried many different lineageOS 18.1,19,20 for samsung starlte but none of them passing all in Play Integrity API Checker app.

they can pass only 2nd option, MEETS_BASIC_INTEGRITY. is there a custom rom by default meets all of those 3 conditions ?

Maybe it's because of bootloader unlocked, right ?

I actually dont need MEETS_STRONG_INTEGRITY, just wonder which properties required to meet MEET_DEVICE_INTEGRITY (first option)
[Magisk] westruk:
You're absolutely right.
[Magisk] sunny928:
Any custom rom can fullfeel all 3 condition
[Magisk] zgfg:
Not. With Bootloader unlocked, you cannot spoof Strong Integrity
[Magisk] sunny928:
Not any option because uber app not working show unable to authenicate device
[Magisk] zgfg:
Flash stock firmware and relock Bootloader. Currently no other solution (and hardly to be and to stay for a period of time)
[Magisk] borisSweden:
How do I test Integrity if I have a "older" Play service version?
[Magisk] pndwal:
Doesn't Play Integrity API Checker (per OP here) work?... PW
[Magisk] zgfg:
Google Play Services, its GMS process is just a man-in-the-middle or 'messenger'

It downloads the.apk (so called droidGuard), you will find (not just the latest but also the whole bunch of their older versions) at:

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

Open each subfolder there, it will contain one version of the apk

And that the.apk (droidGuard) performs SaferyNet/PlayIntegrity attestation

Attached is a hacker's pdf study that was already discussed and circulated here on XDA in this or similar theeads

That's how it works since 2019 or so (already at the time of SafetyNet, prior to Play Integrity), hence if your Google Play Services supports attestation, it should already work that way

This makes possible for Google that they don't depend on the new/old GMS. Instead they can always (without user's consent) update:

- the.apk (droidGuard)

- bytecode that droidGuard always calls from Google server (and that bytecode actually collects data for attestation)

- SafetyNet/PlayIntegrity verdict logic that Google server sends at the end (telling you what you pass or not)

That's the way how they eg two months ago closed their flaw with Strong Integrity - they didn't need at all to update ours Google Play Services - and they didn't

They oftenly, once or twice a week update the.apk (droidGuard) and nobody could know how often and when they update the verdict logic on their server and even the bytecode that the.apk pulls on every attestation
[Magisk] Arcline:
In case it's helpful, some banking apps rely on local bootloader attestations instead of Play Integrity, as it was in my case. The lsposed module "BootloaderSpoofer" fixed this problem. Took me half a year to figure this out.
[Magisk] V0latyle:
I believe the Play Integrity fix is supposed to do this as well.
[Magisk] pndwal:
Glad you got to the bottom of that... Baffles me why they bother to do local validation and stop short of Googles model gift-horse... It must have a nice mouth... 🤪
[Magisk] pndwal:
Nah... Key Attestation (Verifying hardware-backed key pairs) is an independent approach... PW
[Magisk] Arcline:
Well I'm glad they don't, haha
[Magisk] eclipsek20:
One of the first apps to use it seems to be starling huge bummer
[Magisk] chiteroman:
Starling doesn't check Play Integrity neither SafetyNet...
[Magisk] V0latyle:
As we've discussed ad nauseum, there are many developers out there who for whatever reason choose to disregard the free "one size fits all" solution that is Play Integrity, and instead go with third party security solutions that cost money and don't always work properly across the Android ecosystem.
[Magisk] intel_core_i7:
An app requiring android 5 and up implementing PI hardware? I think you should check the app's OS requirement before jumping to conlusions. PI software (basic/device) is just too easily to be bypassed, so custom methods must come to play.

Like you guys have discussed before, the risk of leaving a large proportion of customers behind with a such high android version requirement (5.0 -> 8.0) bump is significant, and then depending on the market (e.g Vietnam) where lots of devices are imported from other markets (mainly China with some Google-related software problems), users are likely to unlock the bootloader and flash a modified stock ROM, or a full fledged custom ROM. Banking is a business after all, and they need customers.
[Magisk] V0latyle:
Read my post again, I'm afraid you're the one jumping to conclusions my friend. My point was, and your statement reinforces this, that an app not working on man unlocked/rooted device might not even be using Play Integrity.

Your point is a good reason as to why that might be the case. STRONG attestation is only available on 8.0+ devices, and since there's so much fragmentation in the Android market, it makes sense for a developer to seek alternatives for security attestation that are friendlier to older devices and Android versions
[Magisk] intel_core_i7:
Probably a misunderstanding then. Reading your statement I felt like you are somewhat asking developers to implement strong, while being a rooted user, very weird?

After all, we have already known that the big banking bois and Google has won the modding game with PI strong.
[Magisk] V0latyle:
Nope, was asking the rhetorical question of "why aren't they using PI" but as you pointed out, if they did, that would affect a significant portion of their user base

Eh...dunno if it's so much a game as it is mousetraps and idiots. Someone always builds a better mousetrap, then eventually someone makes a better idiot
[Magisk] HippoMan:
And also, some of the mousetraps (not the better ones) are made by some of the better idiots.
[Magisk] pndwal:
mmm ... If we're discussing the comment following these:

, ie:

, I assumed member was saying Starling seems to be using key attestation with server side validation and extraction of extension data to detect compromised device, not asking anything... Again (assuming the comment was a continuation of the conversation), this provision for polling AVB etc, is independent of Google's device integrity APIs, whether deviceIntegrity, strongIntegrity or other verdict labels...

Actually, evidently Starling bank is not using either S/N / PI APIs or the Key Attestation method (unless changes are in last week)...

Seems it's been simply detecting these traces:

- Any Zygisk including Magisk Delta and Magisk Alpha, (Shamiko doesn't help ATM)

- Magisk's resetprop; any module using this is detected.

- su binary.

https://xdaforums.com/t/banking-app-starling-detecting-magisk.4576421/post-88866509

🤔 🤷‍♂️ 😆 PW
[Magisk] ocean65:
Hello all,

Nice topic. I was wondering how is the app attestation done. In particular, how is the playintegritytoken generated. It is within the code that is on the app or it "calls" googleplay to generate the token.

This is an example from the app talked on the first post :

token=eyJhbGciOiJBMjU2S1ciLCJlbmMiOiJBMjU2R0NNIn0.RkbBrsVSkWklHO1xM3L_xxBSSdl4zNspSTIIGewF4iGq21Ys7eOJrg.lCdBHKK0RRma6qA0.6DebtQsXvPnYvpTNrLmgheDiwR46aVAIcLuD_Djm1L9I9xLsC4TAuV0wWTRA3w6oZLFhT9wMD2n-NnqUwZBBj8Z3Ohk-wQRvspCT8GQKTsLaIK60VSsAd_YFijX2DDTkAG2RVPkS8uXKKIyOPgmQH1TCVBNm1-cGvLJZ11SsCaVaeBS_HGbyCNr18DSErv13UeNhWQ2CmUJBaxb5vokPmyl28VxfXGZM3IueSpEQTqAEV713-u-znPft7LHa1nVj6lsubGRcYit41kBYVDgh2obR3mJlbXDwwPmNhg1dR64G5gxR-ioeV1z4P8OD1_F9RNAe234xtUbkV5Qr-mDKgQFJuQ_WGmhqzMAdC6yrqUlg9QWCw1QMYbHx5PhMjfYdxhz5vGfUPpLN5A7tNaVaT7XNmM-fsa_GuuD8w9buULtOw6pembC8Eak1gj11uxTxkQsiKDLgh5tLREY8MyT297t13fBgAnEk1EuOrvkiW1nDxshGbdRF2OwHM28-B6jE8dvaoyf2IiazKK0vGN7O1t718Poq045t83wi86qosQ9DtcJLvZbz5mLeLtjgGtN5cWVlmOFhag6X1VYZPsuRMq3X5xqc0aj-EteuJrJozK1eXRmdjmEsEhkpOk3m0rL2uIuPi9PcR7qbLBy0LlJOeajT0tyVm4_z9dgM8vKFoZl9ZN_3n8jAMkSOGLe27DrjsT8Zgkju5n_qHmDU08iRNbe1JMsTBDfEXRdeGJoHxqwJGsAjkxn8SyvWKiH7wsSeD80IjF4CARPgaqh3ft6fQM78kr8TcTEFvqJf1HXMC6nuHzlMyQOmuUGhMPqcOmKQTXYTnaqDyEijSK7BVUbLux-0Riiy5jzyuskYq04SF9mAlf2msO4KqBqWizIvTBkjGxZ-ZYMtqwk_dWJnEP-ZqJxDJioCfH4MC1OGwE330WxP0VxKXJD8K-BD2208w3Wkh1hv7yqyPOirfFv-qH1XXn8YWSD7ZSPneRn5DCxtXJ4hHZNx2R_Pmhpj1z1bU-UMuslCk-z1blsF6cdgtPrAjNppNqMMJtAy5Emzu9xOnspO9oj-DTPpzkXkrLma7z7Ua_1xRZMVazttINYWSeecT8-pCFMVwt6yf9-S8q-shgmJ1LB2Pg7_n1ptGruAKBjsZyu7F26NDFUrsisdbiYPKrUNDfJQl6fXpKPs_RqIcuRATM_RzY3clrDB58bMkCsrdI8SW7MBf62WQ3yh.WlA2RemvVmVuRSCZfwPJNA

You get

{"requestDetails":{"requestPackageName":"gr.nikolasspyr.integritycheck","timestampMillis":"1695496791294","nonce":"ageWOMCbXNyF1YpTsY5bxJezKrjBGlLDRHZxlrBMm0Q7ESmWHg=="},"appIntegrity":{"appRecognitionVerdict":"PLAY_RECOGNIZED","packageName":"gr.nikolasspyr.integritycheck","certificateSha256Digest":["F5UrXPhnBbreh3Q_WjMe_kyYK_tNoNL9XXC_wjXPeeM"],"versionCode":"10"},"deviceIntegrity":{"deviceRecognitionVerdict":["MEETS_BASIC_INTEGRITY","MEETS_DEVICE_INTEGRITY"]},"accountDetails":{"appLicensingVerdict":"LICENSED"}}

Please correct me if I'm wrong and thank you for any info.
[Magisk] V0latyle:
Check out the documentation in the first post of this thread. Play Integrity is an API
[Magisk] zgfg:
Official Google API documentation:

Overview of the Play Integrity API | Google Play | Android Developers

developer.android.com
[Magisk] ocean65:
Hello,

Thank you so much! I still have some doubts. From what I understand the API "asks" google play about (play returns verdicts about) device, app, and account. This information received is encrypted ? I will have to encrypt the information received from the API and send it to the server to validation ? Is this is the case, I will have the encryption key on the app that I developed. Is this correct ?

Once again, thank you!
[Magisk] zgfg:
If you are developing an app that checks Play Integrity API, you don't communicate with Google's servers. You just call PI API and read its JSON result

You can make verdict from the JSON directly in your app or you will send JSON (how, encrypted and/or signed by your keys - your wish) to you server and make the verdict (is the phone safe for your purpose or not) there

Google just recommends that instead of 'hardcoding' how you conclude verdict from JSON in the app, that you put that logic to your server. Then, if you have to update the logic, you don't need to force updating your app (some users will omit to update), you just update your logic on your server

You only call PI API and handle its JSON result. Everything behind the API (gms, droidguard, Google server) is not visible and it's a black box for you

Do you have your server, how your app handles the JSON result (on your server or locally in the app) it's all up to you

And keep in mind that Google themselves do not require Strong Integrity. For Google Wallet (payments with the cards!!! - so most secure purpose), they require only Device and Basic Integrity

Attached is another diagram from the hacker's investigation showing more deeply what goes in the black-box (behind the PI API). Diagram shows SaftyNet, but the architecture is more or less the same for PI. In fact, SN Hardware backed CTS corresponds to PI Strong Integrity, CTS software/basic to the PI Basic Integrity - you have all that in more details in the Google's docs, the link was in my previous answer
[Magisk] amakuramio:
Hackers are able to enter my google accounts through a google prompt, I think these mods are not safe. Happened twice so far
[Magisk] sawdoctor:
All these "unsafe mods" are fully open source and anyone including yourself can inspect the code for anything malicious and even compile themselves. What can happen if you are rooted is giving su privalgies to a malicious app but that would be an app installed by the user
[Magisk] amakuramio:
Not the tool but because of the tool. And no I know what I've installed, am rooted since F05D Fujitsu Android 4 rom till now. I do not know what the cause is but so far two times hackers accessed my google accounts through prompt, maybe the fingerprint is the same (pixel 2) because of this mod
[Magisk] V0latyle:
{Mod edit: Quoted post has been deleted. Oswald Boelcke, Senior Moderator}

What does that have to do with Magisk modules, especially the ones mentioned in this thread?

If someone's been able to gain access to your Google account, it is probably your own fault - you failed to implement sufficient account security.

This is what I do, and my Google account has NEVER been compromised:

Unique password with at least 10 characters, a mix of upper case, lower case, numbers, and special characters

2 factor authentication through authenticator apps via one time keys

Additional security by requiring notification whenever my account is logged into

Password is not saved on any device or browser

Use of a VPN

Additionally, I am very selective about what modules I use, where they come from, and what apps I install.

At the end of the day I find it extremely unlikely that any of the mods I referenced were responsible for unauthorized access to your account, and this thread is not the place to complain about it.
[Magisk] Oswald Boelcke:
Moderator Announcement

On request of OP @V0latyle I've removed the posts that were off-topic to the subject on this thread! The ones who are affected certainly know. If not just ping me privately and I'd tell you.

While we appreciate vivid and interesting discussions that occasionally convert to excursions, the decision if off-topic is accepted in a thread solely remains with the thread owner. The owner is the one who sets the standards - especially if the thread's subject at least in my opinion seems to be of utmost importance to a lot of users like in this case. I suggest to contact the OP privately if you've questions or concerns regarding the standards and conditions. Thanks very much for your understanding and cooperation.

Just in case somebody is wondering: We've an internal policy that a moderator never moderates an own thread in order to ensure maximum fairness and to prove impartiality. This is the reason why I jumped in.

Pending on the timezone where you live, I wish you a great day or an enjoyable nightrest. Latter is the case for me in a few minutes.

Regards

Oswald Boelcke

Senior Moderator
[Magisk] V0latyle:
The conversation was removed from this thread becuase it was off topic; any complaints concerning account breach or infiltration don't belong here.

However, it's important to note that as you described, if the device fingerprint was changed, that device may show up as a "different' device in one's Google account.

Still, both forks (and the original USNF) are open source, so it's easy for anyone to review the code and determine that it's benign.

Further, we get quite a few tinfoil hat themed posts here on XDA with people claiming they've been hacked, with everything from misreading printk logs to weird stores involving an ex girlfriend and a suspicious app. Regardless, that nonsense doesn't belong in this thread.
[Magisk] pndwal:
Sure...

My hope is that some proper detail on basic functions/concept can assure any who may be concerned... I believe it should, that basic understanding is key, and is certainly better than jumping to conclusions..

.. And I agree that this includes the fact that open source code like this is probed by many, some of whom also contribute in PRs... PW
[Magisk] teknixstuff:
Couldn't you just make a custom kernel/boot.img that fakes a TEE? Or even better, launch a TEE just like the bootloader does! Or even just mod the Play Integrity jar/apk/dex/whatever to always act like it would on a normal (bootlocked) device? It's probably going to be an easy cat-and-mouse game once someone gets it going, since it's impossible to truly prove the device hasn't been tampered with as soon as some untrusted code was given full control (like a custom kernel/system). The only time a perfectly accurate tamper check could run would be in the bootloader or on-chip ROM. In theory you could also do it if you had a full chain-of-trust from the on-chip ROM all the way into the kernel and entire system (like iOS/iPadOS does), however that would completely block all custom ROMs and rooting (until an exploit inevitably came out). Also either of these can always be spoofed just by dumping the on-chip ROM or bootloader (or whatever chain-of-trust verified code the secrets are stored in) and just making a reimplementation of whatever APIs Google expects from it. All in all, the only true way to check if a device is tampered with would be checking some bootloader mode (or another read-only boot phase) in-person, which is impossible for anyone but the repair/service team to enforce. And a hardware mod might allow for bypassing even that.

EDIT: Sorry for such a long reply. I never manage to make short messages.
[Magisk] V0latyle:
Excellent question, @pndwal should be able to weigh in on this.

I suppose it could be possible to emulate the hardware authentication in some sort of virtual environment but I don't know enough about the Android hardware-software interface to say.

As far as modifying Play Integrity itself, one has to remember that PI relies on Google servers to verify the responses. If you modified PI on your device, the server responses would expose that pretty quickly.

Again, the issue is that PI isn't contained entirely on the device and relies on external verification. PI doesn't work without an Internet connection; I just ran a check with Play Integrity API Checker with airplane mode turned on, and got an immediate fail:

Same with TB Checker:
[Magisk] zgfg:
AFAIK, TEE must sign with the private vendor's key - how would a custom ROM sign that, that Google server could validate with the trusted public key?

And yes, of course, PI does not happen locally. First, PI API downloads from Google the latest droid-guard (The.apk), then droid-guard sends the bytecode with signed collected results to Google server, Google server responds with the signed verdict

Hence without the Internet connection, there will be no PI API attestation

And the app who asked for the attestation validates the JSON verdict by public Google key - so it must have been signed by the Google private key,, therefore you cannot return your own fake JSON telling that device is passing (Strong🤪).

Hence, Internet and Google servers are a must
[Magisk] V0latyle:
There you have it, @teknixstuff

The only time we were able to spoof STRONG was because of a Google side bug with the Pixel 2's attestation, whihc has since been patched

Play Integrity was designed to prevent local compromise such as intercepting the app request

Fortunately we can still pass BASIC and DEVICE, and for most apps that's sufficient. We don't know which ones require STRONG, if any do, and it seems that most apps that have stronger security requirements use third party security engines anyway
[Magisk] teknixstuff:
Yes, but I'm suggesting to mod the local side of the check.

Here's how that would work:

The integrity API (the local phase implementing requestIntegrityToken()) takes a nonce from the app, and some (unknown) system variables, sends them off to google (not shown in the above image), and outputs a token from google. My thinking is to hack the Integrity API jar/apk/whatever so that it always sends known-good (ie captured from a normal bootlocked device) system parameters to google!

Also with regards to the TEE, the private vendor's key (or whatever secret is required) must be stored in the TEE (or somewhere else that sends the data to the TEE), so why not just dump it from a known-good (ie bootlocked) device?