DEVICE integrity on Android 13+

[teodly]

Describe the bug
On Android 15 (and probably 13 and 14 too), it is possible to achieve only BASIC integrity. Many apps today require at least DEVICE.

(to be extra clear and not spread false rumors: if an app doesn't work, it is usually more important to hide root than to achieve any integrity)

To Reproduce
Steps to reproduce the behavior: I've already written it in comment to ChatGPT ticket.

In short, enable SafetyNet in microG and try to run an app like ChatGPT, or Simple Play Integrity Checker.

Expected behavior
DEVICE integrity working out-of-the-box on LineageOS microG edition (similar to integrated signature spoofing patch)

A clear tutorial how to achieve DEVICE integrity on other ROMs.

System
Android Version: 15
Custom ROM: LineageOS microG edition 22.2
Google Pixel 4a
Magisk
Doesn't matter whether Zygisk is enabled.

Additional context
@FSaurenbach and @ale5000-git have recently reported that one should get DEVICE integrity with microG. What Android versions have you tested?

Also, there is this tutorial which shows how to achieve DEVICE integrity with microG on Android 15, but it includes installing lots of modules, including now-closed-source Tricky Store (which actually never was FOSS, only source-available for some time).

That's because, as far as I know from reading XDA, /r/androidroot and /r/Magisk, getting DEVICE requires a keybox, just like STRONG. However, using microG instead of Google Play Services is rare in these communities.

The Plan

1. Understand whether keybox is required
2. If so, make a clean room FOSS implementation of Tricky Store or find another FOSS module that works
3. Port required modules to patches for LOS microG edition, to make them work without Magisk modules, like signature spoofing
4. Maybe compile required modules in microG CI/CD infrastructure to have binaries we can trust, for users of other ROMs?

I can help with it, I'm fluent in C & C++ and know Android internals a bit (contributed to signature spoofing patches: Lanchon/haystack#34 https://gitlab.com/teodly/NanoDroid/-/compare/master...patcher-q-fix?from_project_id=5247931)

[FSaurenbach]

Quick disclaimer: I am not a maintainer so don't trust my "answers" right away, I might very well be wrong.

So I have multiple things i want to address.

• First of all for No. 2 there actually is a tricky store fork that is FOSS and actively developed. (It works the same as the normal tricky store)
• For No. 1 I believe the answer is no as you can see in the release notes: "DroidGuard: Disable access to hardware attestation."
• ChatGPT. I really don't think device integrity itself is the issue as it works fine with basic integrity with sandboxed gplay (probably normal gapps too, not tested) Sooo probably the issue lies in MicroGs implementation but again, correct me if I'm wrong.

Now about device integrity. I have recently (in the last month i think) lost device integrity with MicroG on 2 old phone's of mine, one running android 10 and one android 14 (both custom rom). During that time google changed some things up, probably removed legacy checks.

[teodly]

there actually is a tricky store fork that is FOSS and actively developed

This module is advertised as FOSS but actually is still source-available - it lacks license terms. Adding license is not an option because it is a fork of a module that never had one - effectively making it all rights reserved. It was also pointed out in the original repository.

So, still better that closed source because it is auditable and we can learn from it, but legally gray area if we want to incorporate it into other code, compile binaries etc...

For No. 1 I believe the answer is no as you can see in the release notes: "DroidGuard: Disable access to hardware attestation."

It has changed recently, and it affects Android 13 and later:

Starting in December of last year, [...] Google made all integrity verdicts even stricter: the “device” integrity verdict was updated to also use hardware-backed security signals, while the “strong” integrity verdict was revised to require a security patch level from within the last year. Meanwhile, the “basic” integrity verdict was also updated to use hardware-backed signals, though due to its less stringent requirements, it passes even on devices with root enabled or the bootloader unlocked.
[...]
At the time of the announcement, these updated integrity verdicts weren’t immediately enforced. Google made them opt-in for developers but stated that all “[Play Integrity] API integrations would automatically transition to the new verdicts in May 2025.”
[...]
power users who root their phones or install a custom ROM may suddenly find some apps stop working, especially on devices running Android 13 or later

source: https://www.androidauthority.com/google-play-integrity-hardware-attestation-3561592/

ChatGPT. I really don't think device integrity itself is the issue as it works fine with basic integrity with sandboxed gplay

On Android 13 or later?

Actually, I may not have complete BASIC integrity. SPIC says MEETS_BASIC_INTEGRITY but 'Test SafetyNet attestation' in microG Settings gives 'Warning: CTS profile does not match' which means that DroidGuard returned BASIC integrity but with ctsProfileMatch set to false or missing. When using Magisk DenyList instead of Zygisk+Zygisk Assistant, I've had another warning 'Bootloader is not locked'.

[FSaurenbach]

Yes my device with chatGPT is on Android 15 so no legacy checks.

But I personally think legacy and normal checks are bullshit because I can't see ANY difference on a device on A10 and A14. Both passed device integrity a month before with the same basic setup of modules (zygisk assistant and play integrity fix) and denylist and now both of them only pass basic with that CTS error in MicroG.

BTW chatgpt never worked with microg in the first place with or without device integrity

[sewnie]

I would like to comment in that using normal Lineage with GApps and the same module setup, I can get STRONG passing, however, on LineageOS4MicroG, it simply refuses to go past BASIC passing, with the exact same module setup, and even TrickyStore (official) reporting that it was successful.

This leads me to blame microG. What else can i do?

[sewnie]

Also, there is this tutorial which shows how to achieve DEVICE integrity with microG on Android 15, but it includes installing lots of modules, including now-closed-source Tricky Store (which actually never was FOSS, only source-available for some time).

I've done almost nearly the exact same steps in this module, minus a few modules, which i did on regular Lineage, and it had worked for me. Not on LOS4microg.

[teodly]

@sewnie probably this commit breaks DroidGuard: 97b8646

If it was possible to forcefully install package signed by a different developer, I could try to compile GmsCore with this blockade disabled, but couldn't find meaningful info on how to do it (I have root). Maybe I could add my public key to allowed developer keys in some system database?

@mar-v-in (microG developer) suggested to use Zygisk to patch microG. I don't have experience with this, tried to get inspiration from PIFork but failed.

My only device with recent enough Android for this test is my daily driver, so not going to do aggressive things like uninstalling GmsCore with app data wipe, which might not help anyway because LOS microG edition has GmsCore built-in.

---

Regarding security, this source-available fork of TrickyStore has reproducible build verified by GitHub. Zygisk Assistant is build by GH Actions. PIFork and Magisk itself are uploaded by developers and not verified, that should be addressed if it is going to become a method officially endorsed by microG.

[sewnie]

Wow. I understand microG not officially endorsing these methods, but blocking them outright is such an inconvenience when it can very clearly work.

[mar-v-in]

For clarification:

• On a reasonably secure system, microG should pass BASIC integrity out of the box. On systems with user-space root, this might be not the case, except if you do extra effort to hide it from microG
• On many systems, microG can pass DEVICE integrity with small modifications to some system properties. On newer devices, this only works because of 97b8646, which essentially does something similar as popular Xposed modules would do.
• microG as of now has no way to inject keyboxes or override system properties. We might add such feature later. PRs welcome.

[sewnie]

On many systems, microG can pass DEVICE integrity with small modifications to some system properties. On newer devices, this only works because access to the 97b8646, which essentially does something similar as popular Xposed modules would do.

This is false. It doesn't work anymore.
It used to, months ago, but PlayIntegrity has changed. I can only get either BASIC only or all and STRONG, no BASIC & DEVICE. Perhaps if this was disabled, some modules would have better chances.

[mar-v-in]

I just verified that you can still have BASIC+DEVICE without STRONG on latest microG release without requiring a keybox. In this case the SafetyNet attestation check in microG settings will also pass.

Just for clarification:

• BASIC is just some basic checks (like checking for user-space root)
• DEVICE is almost equivalent to CTS check in SafetyNet, so if it gives you the warning of CTS profile not matching in microG's SafetyNet attestation test, you will not pass DEVICE integrity either.
  • On some devices and later Android versions, passing CTS requires hardware attestation. The obvious solution is to use the properties of a device and/or to spoof an SDK version that doesn't require hardware attestation.
• STRONG is for hardware attestation, which requires a keybox to pass on custom ROMs.

Making you pass Play Integrity is not a goal of microG. If you have issues with apps that require Play Integrity, especially if they require more than BASIC attestation, I advice to let its developer know and use a competitor app that doesn't require Play Integrity until they decide to change. The best thing we can do against not passing Play Integrity is to make developers stop using it.

[sewnie]

DEVICE is almost equivalent to CTS check in SafetyNet

If only i could get this working, i wouldn't have to worry about STRONG passing.

On some devices and later Android versions, passing CTS requires hardware attestation. The obvious solution is to use the properties of a device and/or to spoof an SDK version that doesn't require hardware attestation.

Right, okay. If that is an obvious solution, why not do so on microG?

I have managed to make an LSPosed module to hook onto microG and successfully set initialized to true and null the ensureInitialized, however, even with the module simply hooked, its almost as if microG detects its been hooked via LSPosed and it becomes "Failed: integrity check failed; ROM is not clean"

Why is this? I believe my only option then is to revert the commit, which takes a long time since microG takes time to compile.

[ale5000-git]

@mar-v-in
It may be simpler by just making DroidGuard: Block hardware attestation configurable by ROM developers using something like: /system/etc/microg.xml
(possibly using a separate file and not the same)

[FSaurenbach]

@mar-v-in It may be simpler by just making DroidGuard: Block hardware attestation configurable by ROM developers using something like: /system/etc/microg.xml (possibly using a separate file and not the same)

That'd be a good idea! Wont you also be able to achieve strong integrity with an unrevoked keybox too?

[sewnie]

It may be simpler by just making DroidGuard: Block hardware attestation configurable by ROM developers using something like:

Why not expose it as a user option..? Or remove it as it brings benefit to no one. and only serves as a inconvenience to everyone.