yashsingh1/xdaforums huggingface dataset:
[Magisk] osm0sis:
It's possible the ROM is built with "release-keys" in the build props, but the key used to sign was still the testkey so PI will fail. They need to do a release-keys build and sign with a private key.

I'm in a similar conversation trying to explain things to a dev over in the Unofficial Lineage 20 flo thread: https://xdaforums.com/t/rom-flo-deb-unofficial-lineageos-20-0.3569067/page-217#post-89527859

You still need to follow the instructions in my module's installer to remove any user apps for the injectors; it's been tested and working on all the supported ROMs I mentioned: https://github.com/osm0sis/PlayIntegrityFork/blob/main/module/common_setup.sh#L56
[Magisk] pndwal:
PIF wouldn't work if DroidGuard was in Play Store cos PIF spoofs target the Droidguard process (com.google.android.gms.unstable) in GMS... That process is not actually DroidGuard either; it's just the Droidguard/GMS interface... The real implementation of DroidGuard is actually a virtual machine located in 'the.apk', stored at /data/data/com.google.android.gms/app_dg_cache/<hash>/the.apk and dynamically loaded by DroidGuardService...

DroidGuard location doesn't differ whether attestation data is called by S/N or PI APIs and is not in Play Store... However I don't know mich about microG's implementation; DriodGuard may be in what's called FakeStore (if that's not really the Play Store equivalent)...

It's would be interesting to discover why some microG implementations work with PIF as you indicate; perhaps there are special settings or changes users must make that you could outline?

The comment I made about microG/GMS core/FakeStore the member you responded to picked up on was:

Also, with a normal GApps (GMS suite) setup, GMS Core process is com.google.android.gms and DroidGuard interface is com.google.android.gms.unstable in Google Play Services while Google Play Store main process is com.android.vending in Google Play Store.

I assumed that with the minimal microG setup, GMS Core and DroidGuard processes would be in microG Services Core, but maybe a DroidGuard (non-core) implementation is separate??... And that Play Store equivalent may be FakeStore...

@Displax made a special USNF build for microG... I haven't looked at the code... May do so later, maybe someone else can take a look, but I'm guessing it would just have changed the DroidGuard target process for spoofing from Google Play Services com.google.android.gms.unstable to microG Services Core (or wherever the DroidGuard interface is located in microG), and also changed the processes needing root hiding from GMS Core (A11+ only?) and DroidGuard in Google Play Services to to microG Services Core (and wherever else the DroidGuard interface may be located in microG; maybe you meant that's in FakeStore 🤔, but my guess was that FakeStore is minimal Play Store)...

This understanding (of microG unique locations for GMS components) may be all that's needed for @chiteroman (or someone forking) to make a PIF build that accommodates various microG implementations, or to make master PIF compatible... 😃

microG users, please chime in and say what configuration is needed to make e PIF work with microG... 👍 PW
[Magisk] zgfg:
AFAIK, no KSU for Lisa (gki kernel not supported), unless for some AOSP ROMs

That was the case last year when I checked (and tested, was able to boot but wasn't able to unlock PIN)

I doubt it would be better now if you upgraded to HyperOS
[Magisk] zgfg:
Documents were shared here with the detailed architecture

Yes, everything is signed back and forth.

Verdict is returned from G server signed by their private key, signature includes package name of the original app requesting PI from gms.unstable, timestemp of that request and the nonce from that request.

And everything from TEE (Strong Integrity) is also signed by the vendor's private key

You cannot proxy DG blob with TEE result neither the final verdit from another device
[Magisk] Bio69:
Hi 😉

Thank you for your good work.

Google Wallet work fine (Poco X3 Pro stock rom with lasted Magisk Canary build), but ItsMe app detect immediately that my phone is rooted (no need to have a account to test that).

itsme - Apps on Google Play

itsme will change the way you identify yourself during digital interactions

play.google.com

It worked fine, but the problem appeared after an app update.

Could you help me?

Cordially 😊
[Magisk] majorfigjam:
This Is not a Play Integrity issue.

If Shamiko can not hide root** from the Belgian government, then nothing will. Maybe they've switched to Strong Integrity - after all they don't want someone to steal or spoof your identity, and you probably don't want that either.

** Edit: it can't.
[Magisk] DylanAkp:
Is it just me or Google Wallet lowered Play Integrity requirements ?

It works just fine with BASIC for me

(And I don't pass anything more than BASIC since setup)
[Magisk] amexH:
One more confirmation, that building signed LOS (21) with my own keys brought back 'Device Integrity'. No 'Reset to factory' necessary.

I followed instructions at https://wiki.lineageos.org/signing_builds to the letter. Got signed-ota_update.zip

extracted recovery.img from signed-ota_update.zip and flashed to both slots

adapted migration.sh script to my keys (extract_keys.sh helped)

executed on device and booted to recovery

installed (sideload) signed-ota_update.zip

PIF fork by osm0sis

Thanks for all the help here.
[Magisk] TestaMic:
I get this error when i try to sign crdroid? Do you think what maybe the error? I used generate.sh and compile.sh from chiteroman...
[Magisk] zgfg:
Your Wallet is probably running on Cache and you did not try to add a card.

(I used to pay similarly on the cached verdicts for a day - and others, and on the other side I was not able to pay for days although passing Device Integrity untill I wiped the Wallet Cache)

Btw, Settings, Method payment - does it show you're Ready?
[Magisk] DylanAkp:
I have a card, I paid with, it shows ready, I don't pass anything else than BASIC since I cleanflashed
[Magisk] markdewet:
You must be lucky, I am still getting " Your device doesn't meet security standards to make contactless payments. It may be rooted or running uncertified software." For the record, I am running LOS 20 on SM-G955F, Magisk 27.0, hidden, enforce denylist on, Wallet added to deny list, with MagiskHide Props Config v6.1.2v137 and Universal Safteynet Fix v2.4.0 by kdragon. May I ask, are you using the Magisk module referenced in this thread?
[Magisk] zgfg:
If you're on A13, why do you stick with MHPC and USNF - did try uninstalling them and using PIF from Chiteroman or PI Fork from Osmosis (you must also use his autopif.sh to grab the prints)

Zygisk must be enabled, Shamiko, gms.unstable in DenyList (not enforced( - instructions/FAQ can be found in this thread:

- PC browser (or mobile browser with Desktop site enabled - clumsy to read)

- Most liked posts (right, choose All time, second one is the FAQ)

Check also is your Kernel name and the last days discussion about (re)signing the LOS
[Magisk] DylanAkp:
No I'm not using the referenced module (I tested with it too), I have my own updater for props
[Magisk] markdewet:
@zgfg, Thank you for your reply. I will answer what I can and I have a few questions as a noob (as mentioned in another thread) so please bear with me:

1: What is the A13 you are referring to, please? The reason I am on MHPC and USNf is that I tried to follow another thread: https://xdaforums.com/t/guide-tutorial-howto-samsung-galaxy-s8-or-s8-stock-to-android-13.4599235/ in order to get Wallet working.

2: Apologies, Zygisk is enabled, forgot to mention that.

3: So Shamiko MUSt be installd?? Bit confused there, I was told NOT to install it previoulsy.

4: There is no "gms.unstable" on my phone, I did tick the "show system apps" and "show OS apps" in Magisk.

5: Ok, I will uncheck "enforce denylist" in Magisk.

6: I have read this thread from start to finish, I did do a "search" but did not find any FAQ as such, which is why I am asking questions here.

7: Apologies, I do not understand this part : "Check also is your Kernel name and the last days discussion about (re)signing the LOS". Could you please explain, if possible?

I would like to add here that Magisk in not at all an easy app to use and as this is my first time attempting, I have tried to do as much research as possible, however, most posts and threads tend to "assume" one already has experience with Magisk so detailed explanations of installation and usage are somewhat lacking, at least in my experience.
[Magisk] markdewet:
Oh I see, thank you.
[Magisk] zgfg:
A13 means Android 13 (isn't that your LOS 20)

You're following outdated instructions (they may still work for A8 and below, IDK) but as already instructed in the other thread, carefully read the FAQ post and find the details (I didn't check but I'm pretty sure that must be in) about Shamiko, DenyList, etc)

All that covered by FAQ should be for the BEGINNING, then if you still don't pass Device Integrity check about the banned Kernel names and recent discussions about signing LOS. But with that old MHPC and USNF (that were tailored for the now deprecated SafeteyNet) you have no chances to pass Device Integrity (from Play Integrity)
[Magisk] Koeties:
Maybe try Zygisk Assist. Shamiko didn't work for some apps on my tablet and I tried Zygisk Assist and now the apps can't detect root.
[Magisk] austinjklim:
Current on Magisk with Zygisk/Enable Denylist with latest PIF, Poco F3 Alioth Xiaomi.Eu HyperOS 1.0.3.0

Been installing/uninstalling, clearing cache of GMS, Gwallet, Clear app data etc.. But since unable to pass payment since 5 days ago. Gwallet reports everything good, security requirements are met. I've taken quite some effort into troubleshooting it but I just could not make it work.

Gonna try to see osm0sis's fork would work for my case. I'm not entirely sure what's going on, but I do see some users on Xiaomi.Eu started to report this issue whether play integrity was passed but payment could not be made. Or my NFC chip just fried itself.
[Magisk] DylanAkp:
Mystery resolved

My Play Integrity fix wasn't working fine (and didn't noticed since dirtyflash allowed PIH to use old overlays)

And ofc it was overriding PlayIntegrityFix module

TLDR; I messed up everything XD, few revert and will be fixed

Sorry for this, I thought I've found something about PlayIntegrity changes, but it was just my code

Nothing to do with EDL as @chiteroman said previously
[Magisk] markdewet:
@zgfg, thank you for your reply. Answers as follows:

1: Ah OK, silly me, yes, LOS 20 is Android 13.

2: The link I provided is for Android 13 LOS 20, so I am not sure why you would say it is outdated. Also, again you refer to "FAQ" however, I cannot find this "FAQ" so either I am extremely stupid, or I am missing something really obvious.

3: I have read the WHOLE thread about LOS 20 and again, cannot find anything about "signed" LOS or banned kernels. Again, either I am stupid or missing something obvious.

3: OK, I will remove the MHPC and USNF modules and try the module referenced in this thread.
[Magisk] zgfg:
I don't use LOS, I don't know about your guide

However, here there are users with LOS, hence see here why they use PI Fork/Fix mudule(s), not the old MHPC and USNF.

Btw, you don't pass Device Integrity and your Wallet doesn't work - so you see that the Guide you're using is not useful. Either stick with what you have (with the Wallet not working), or start moving on

In the post #15931 I have attached screenshot showing how to open FAQ post (and a note how to use the browser)
[Magisk] pndwal:
Here's some of the nitty gritty since this question seems to be asked every week:

Your app's server-side backend generates and sends a unique value to the client-side logic, aka "app"... App creates a

nonce

from the unique value also

containing device, app, and account details

... It then calls the Play Integrity API, passing in the nonce... App receives a

signed and encrypted verdict

from the Play Integrity API... App passes the verdict to your app's backend. App's backend sends the verdict to a Google Play server. The Google Play server

decrypts and verifies

the verdict, returning the results to your app's backend... App's backend decides how to proceed, based on the signals contained in the token payload and sends the decision outcomes to your app.

Dev's should "leverage the nonce field to mitigate certain types of attacks, such as

person-in-the-middle*

(PITM)

tampering attacks and replay attacks

" by 1) Including a request hash to protect against tampering (Compute a digest of all critical request parameters (e.g. SHA256 of a stable request serialization)... Decode and verify the integrity token, and obtain the digest from the nonce field... Compare the app-side and server-side digests. If they do not match, the request is not trustworthy)... "

verify

both the device and app integrity signals

to ensure that the results

of the high-value action

were created by your untampered app on an untampered device

" and by 2) Including unique values to protect against replay attacks. (For example, a cryptographically-secure random number generated on the server side can be such a value, or a pre-existing ID, such as a session or a transaction ID, used to uniquely identify each message to prevent malicious users from reusing previous responses from the Play Integrity API.) Google recommends Devs combine both of these protections...

Ref (and much more):

https://developer.android.com/google/play/integrity/classic

Google now offers 2 types of Play Integrity API request... The above mainly applies to Classic requests, but there are basic recommendations for securing both Classic and Standard (new) requests for app Devs (These examples may be relevant):

https://developer.android.com/google/play/integrity/overview

So I'd say it won't be easy! 😜 PW

*FWIW, love that Google is so progressive and PC!... When did PITM become a thing?

No ManHoles any more (we now have the Maintenance hole/Personnel hatch), and all sorts of stuff in California is now human-made (since 2019), so why not Person-in-the-middle attacks?... Seems that the best Android hackers (associated with XPosed and Magisk root) aren't men so I'll give an inch...

I've got in trouble on XDA before for mentioning an acting American president, but can I mention a presidents First Partner?... And what about Chairperson Mao?... Oh yes, love the Chinese 'Teach a person to fish and you'll feed it them... make a fisherperson!'... And the Chinapersons hat!... They're preparing for the first personed missions to the moon you know (cos America only did the first Manned ones!)...
[Magisk] EAZY BLACK:
microG has a option for dg and it uses embedded droidguard runtime but the thing is how does this get updated because google blocks some stuff etc
[Magisk] markdewet:
So, after removing MPHC and USNF and installing Play Integrity Fix from this thread and Shimiko v1.0.1, unchecking enfoce denylist and adding Wallet to denylist, I STILL get "" Your device doesn't meet security standards to make contactless payments. It may be rooted or running uncertified software.""
[Magisk] markdewet:
@zgfg Thank you for your reply.

Yes, I do understand now why that Guide is no loner useful, as explained many times, I am new and seeing as I was accused of wanting to be "spoonfed" I tried my own research. (Look where THAT got me).

As regards your screenshot, thank you and I apologize for not seeing that in the beginning. My bad.
[Magisk] zgfg:
Now, following what I already listed in the other thread was checking if your custom Kernel name is banned. Again Most liked posts, All time, one of the top posts from Osm0sis...If the Kernel name is banned, no Play Integrity

And then what was discussed here all the last days about signing LOS (you will need to read the posts backwards and ask quote/ask those that did discuss about)

Btw, check what does PIC (play Integrity Checker) or SPIC (Simple PIC) display, only Basic Integrity.

In some cases it may show Device Integrity but Wallet still complaining
[Magisk] Koeties:
I assume you also added all the Google Play apps (like play store, play services etc) to the deny list?
[Magisk] markdewet:
@Koeties, yes, sir, also cleared cache and data on all four items (play store, play services, framework, wallet), after installing the Magisk Modules.
[Magisk] markdewet:
@zgfg, thank you, I found the banned kernel list (link osm0si' github page) and looks like LineageOS in among them, so I guess I am not going to get Google Wallet to work at all.

SPIC gives Basic Integrity only.
[Magisk] Vision:
Xiaomi Poco X3 NFC A11 MIUI 12,5.

I figured out when make a dummy file for boot-framework.art via magisk module, and have enable PIF Fork v8 by @osm0sis or PIF latest by @chiteroman , the internet refresh and request is very very slow (the strange is Netflix is normal not slow), but disable all normal.

How these 2 are related?

Anyone else, can confirm that?
[Magisk] twu2:
try this method.
[Magisk] zgfg:
I NEVER put anything else than GMS and Wallet from GApps to DenyList (not even Playstore, etc). And I never have problems.

Btw, not really sure if Wallet needs to be in DenyList (if it doesn't check anything else than through PI API, then it also does not need to be)

As long as apps do not look for 'root' themselves, they don't need to be in DenyList. Google's intention was to provide Play Integrity API instead of seeking for 'root' by the apps themselves. However, 3rd party apps like banking and similar apps do extra checks themselves, hence they don't rely on Play Integrity API only and therefore they need to be in DenyList; additionally HMA must be used for some (depending how a particular app looks for the 'root'), and some need more complicated tricks (Kitsune or Alpha instead of standard Magisk, even KSU, and so)

'Root' (here) covers any 'unsafe' mods. - however, the next question would be, what is 'unsafe' for them :cool:

Generally, anything custom whose flashing requires unlocked Bootloader. They look also for Zygisk - that's why Shamiko is needed (or ZygiskNext instead).

Then (not knowing better) some look for the hints like seeing TWRP folder (indicating that there 'should' be TWRP flashed and therefore unlocked BL, otherwise why would one have TWRP folder), or Magisk app (indicating that there 'should' be Magisk, otherwise why an ordinary Joe would have Magisk app installed - although Magisk app is not the Magisk/root itself, anybody can just download Magisk app and ) and so

Chrome, Maps, etc by no means look for the 'root' (not even through Play Integrity)
[Magisk] TestaMic:
what method? please specify
[Magisk] D€INOS:
FYI I've never have or needed anything Google related in the DenyList
[Magisk] twu2:
sorry, forget url.

Signing LineageOS builds with your own dev-keys

Signing LineageOS builds with your own dev-keys. GitHub Gist: instantly share code, notes, and snippets.

gist.github.com
[Magisk] zoisa:
Hi, i have Crdroid 9, Android 13, how you signed that?
[Magisk] samhhmobil:
Sorry for being a bit offtopic.

Google seems to provide new checks to app developers, against custom ROMs.

My Device Mi 10T lite (gauguin)

LineageOS 20 (A13)

Magisk 27

Shamiko

PIF 15.9.9

Device is certified (Play Store)

Device Integrity and Basic Integrity are green

But since today the German Magenta App (not a banking app) refuses to work and requests an update. And PlayStore shows: incompatible device and refuses the install. (I got it from alternative sources, --- and the app itself works, if one could install it. Of course the app is in denylist.)

The show must go on, not only in PlayIntegrity...

samhhmobil
[Magisk] Yeedatoy:
Ive always assumed that's because the device fingerprint that is being picked up by the servers is a device/android version/architecture that indeed is not supported by that app
[Magisk] generalculprit:
Playstore knows your real device, as you can see if you use its own play integrity checker. The fingerprint is spoofed for droidguard.
[Magisk] rogerty:
I want to ask the developer of crDroid for mi mix 2 (chiron) if he can update the rom with a new one signed with a PRODUCTION KEY, instead of the current test key.

Is it complex to do ?

If not, can a final user do it with some work using the existing install package for this rom ? If so, please explain how-to...

thanks
[Magisk] wilsonhlacerda:
For the ROM dev/maintainer it is not difficult, just a few/low effort adjustments that they for sure know how to do/can easy learn for instance reading the last pages of this thread here.

For a regular user, when having the source code, it is harder. The knowledge itself and also the need of a good PC, being it a hardware one or a virtual machine (can rent a VPS for that). Have to do the adjustments and then compile ROM by own (source code => flashible zip to put on device), every time an update is available.

Not having the source code or starting from a ROM zip already in hands only is impossible currently. This, if ever, will be possible only if someone find a way to spoof Google checks.

Alternative is always to abandon the banned custom ROM in favor of a working custom/stock ROM.
[Magisk] SoyDPR:
I imagine there still isn’t an easy way to do all this to use Google services by installing just a couple of modules or something like that, right? Signing ROMs is too much for me already, haha. 😄
[Magisk] pndwal:
My (primary) question is 'where exactly is the GMS DroidGuard process (com.google.android.gms.unstable) in microG'?... In microG Services Core?... In FakeStore?... Other?... 🤔 PW
[Magisk] martinsegura84:
DG is embedded in microG services (screenshot for proof). I remember in the past, it wasn't like that, I had to download DG from the microg repo after flashing, it was separate. But since 2 years ago or so, microg team decided to include it with core.

Fakestore (or "microG Companion" nowadays) is just a placeholder, it is not a cutdown-playstore, or patched playstore, it is nothing, it has no functions other than being a proxy. Basically any request that is sent to com.android.vending is redirected to core by the placeholder. When you flash microg with fakestore, you don't have a playstore at all, you need fdroid and aurora store, but it is still able to trick apps to think they are 'talking' to playstore.

But from what I've been reading, not a single person that has fakestore has achieved getting rid of the CANNOT_BIND_TO_SERVICE error (2nd screenshot) when using the PI test apps like SPIC. Basically fakestore is useless now, at least for PI, still useful for SN. People have been flashing microg with modded playstore or normal playstore to get rid of that error and being able to test for integrity, etc. But personally, not even doing that is working, it throws a different error saying playstore is not official or not installed (3rd screenshot).