App compatibility with GrapheneOS

akc3n

Possible workaround solutions

For some problematic apps, including some banking apps.

Purpose: Utilize as a reference permalink for consistent citing on duplicates across platforms. e.g.

Important announcements
Banking app compatibility with GrapheneOS
Possible workaround solutions
Next steps
- Problematic applications
- Not compatible

Important announcements

December 1, 2023 – Compatibility of Banking Apps with GrapheneOS

If you receive a warning from your banking app indicating that your device may be insecure, jailbroken, or rooted, this is usually due to the SafetyNet/Play Integrity API. Specifically, your device fails to pass MEETS_DEVICE_INTEGRITY or MEETS_STRONG_INTEGRITY.

As of now, there are no direct solutions available to users. However, you can help by contacting your bank. Inform them of this issue and suggest they refer to the GrapheneOS Attestation Compatibility Guide for their developers, available here: Attestation Compatibility Guide.

Banking app compatibility with GrapheneOS

To submit, view, and/or track international banking apps compatibility with GrapheneOS, please use this issue-tracker.

A 3rd party community-sourced effort containing banking app compatibility information is maintained by PrivSec.dev. GrapheneOS does not make any guarantees regarding the list's validity.

Possible workaround solutions

1. Native code debugging

Allow the app to make use of native code debugging. Launch app.
If unsuccessful, proceed to step 2.

Settings ➔ Apps ➔ App in question ➔ Exploit protection ➔ Native code debugging

2. Exploit protection compatibility mode

Enable the per-app exploit protection compatibility mode. Launch app.
If unsuccessful, proceed to step 3 for testing only.

Settings ➔ Apps ➔ App in question ➔ Exploit protection ➔ Exploit protection compatibility mode

Turning on the exploit protection compatibility toggle reduces system security but may allow the application to run without crashing. The app crashed because GrapheneOS detected a memory corruption bug that may be exploitable by an attacker.

3. Secure app spawning

3.1 - Temporarily disable secure app spawning.

Settings ➔ Security & privacy ➔ Exploit protection ➔ Secure app spawning

3.2 - Disable the exploit protection compatibility mode as described in step 2.

3.3 - Restart device. Launch app to see if this GrapheneOS feature caused the compatibility issue. The app may be refusing to run if it detects a different spawning mechanism.

Significant security loss and directly affecting some privacy using Zygote

Disabling exec-based spawning reverts to using the traditional Zygote spawning model AOSP's app processes
Spawned as a clone of the Zygote
Each app process has the same random secrets for ASLR, SSP, memory tagging, pointer authentication, setjmp canaries, and heap randomization
Half of the userspace is made of app processes
Applies across all profiles
App in profile A and profile B have same random values, which they can see

3.4 - Revert to secure spawning by enabling it again and restart device.
See step 3.1 above.

4. Alternative frontend clients

Potential use of an unofficial/alternative Google Play Store frontend client may be problematic for misguided apps:

They can check if they were installed from the Play Store and can choose to refuse to work if they were not installed from the Play Store.
Some forbid usage on non-stock OS (most OSes are insecure)
May cause your Google Account to be disabled/blocked/blacklisted by Google.
Anonymous account usage may have negative consequences and have a less secure connection to the Play Store servers.

General recommendation: Install Sandboxed Google Play. Optionally use a throwaway account.

5. Search the existing issues

Search the forum, os-issue-tracker, and/or within the community for keyword(s) specific to the app name.
If unsuccessful with finding a solution, only than proceed to step 6.

6. Capture a bug report

6.1 - To view the specific app's logs, go to Settings ➔ Apps ➔ All apps ➔ APP ➔ View logs.

Note: With the release of 2024011300, GrapheneOS developers have introduced a log viewer, accessible via Settings ➔ System ➔ View logs. This LogViewer avoids the need for developer options to create useful bug reports and inspect the device for issues.

6.2 - Attempt to reproduce the issue by capturing a 'Bug report' using the feature in Developer options if you still run into the app aborting at launch.

Enable Developer option by tapping the 'Build number' 7 times.
Settings ➔ About phone ➔ Device identifiers ➔ Build number
Capture a bug report.
Settings ➔ System ➔ Developer options ➔ Bug Report ➔ Interactive report ➔ REPORT

Note: If you are doing a bug report, the .zip file can contain sensitive info.

6.3 - Alternatively, using logcat.

Example:

Prepare for reproduction
adb logcat -c to clear previous logs
Reproduce the issue
In a timely manner to avoid unecessary logs:
- adb logcat -d > issue.log to dump the logs in a file named issue.log

6.4 - Disable the developer options.

Settings ➔ System ➔ Developer options ➔ Use developer options

We recommend disabling developer options as a whole for a device that's not being used for app or OS development.

7. Submit a bug report

Open a new issue, provide a description and make contact via the appropriate channels with a similar message like "Bug report capture for issue #104". in order to submit the bug report capture zip privately. (Replace the issue # number).

Contacting the project
Reporting issues
Friendly reminder: instructions for getting support via chat and when to avoid using the os-issue-tracker: ask questions + request support

Next steps

Problematic applications

It's plausible that this is app-related, rather than a compatibility issue with GrapheneOS - acknowledging this factor must be considered. (Ref. 2568#issuecomment-1766887298)

Not compatible

Due to the deprecation of SafetyNet attestations, there is increasing changes among some apps on the Play Store to switch over to the new Play Integrity API. Consequently, some of these apps are known to set themselves as unavailable for devices that do not pass Play Integrity checks at various levels.

See View and restrict your app's compatible devices and Store listing visibility

Turn on integrity checks for your store listing so that Google Play can check that devices pass integrity checks before making your store listing visible to users.

This feature is primarily intended for use only by apps using the Play Integrity API. It aims to prevent users from encountering a poor experience by installing these apps, only to find they do not function properly on their devices.

Please see the Attestation compatibility guide on using remote attestation in a way that's compatible with GrapheneOS and how you can help.

GrapheneOS users are strongly encouraged to share this documentation with app developers enforcing only being able to use the stock OS. Send an email to the developers and leave a review of the app with a link to this information. Share it with other users and create pressure to support GrapheneOS rather than locking users into the stock OS without a valid security reason. GrapheneOS not only upholds the app security model but substantially reinforces it, so it cannot be justified with reasoning based on security, anti-fraud, etc.

[deleted]

akc3n 12 — Please see the Attestation compatibility guide on using remote attestation in a way that's compatible with GrapheneOS and how you can help.

Hello, Is there an API that somehow pings a list of approved Operating systems (to which OS developers can submit a request for their OS too) for apps like Banking apps, Premium apps, Health apps, etc. and uses Hardware attestation / server side checks to prevent tampering? Allowing only Operating systems approved by Google and just One third-party OS isn't Ideal.

hemlockiv

akc3n 3.1 - Temporarily disable secure app spawning.

Setting ➔ Security ➔ Enable secure app spawning

3.2 - Restart device. Launch app to see if this GrapheneOS feature caused the compatibility issue. The app may be refusing to run if it detects a different spawning mechanism.

Significant security loss and directly affecting some privacy using Zygote
Disabling exec-based spawning reverts to using the traditional Zygote spawning model AOSP's app processes
Spawned as a clone of the Zygote
Each app process has the same random secrets for ASLR, SSP, memory tagging, pointer authentication, setjmp canaries, and heap randomization
Half of the userspace is made of app processes
Applies across all profiles
App in profile A and profile B have same random values, which they can see

3.3 - Revert to secure spawning by enabling it again and restart device.
See step 3.1 above.

I suspect I wouldn't be the first person to suggest this, and I also wouldn't be surprised if the devs have already rejected the idea, but does anyone know if there's any consideration of adding, in the future, Per-app Secure Spawning?

I imagine this would work by following the normal Secure Spawning process for most apps, but somehow caching whatever's the default (insecure) Zygote spawn process. Then if an app does misbehave, the user can disable Secure Spawning for that app only, in which case that app will use the cached insecure process. No idea if this would work in practice, but it would be a real nice compatibility feature. I currently have Secure Spawning disabled because a single app (that I can't live without) crashes when it's enabled. It's a waste, and a big security hole.

N1b

Great guide, please leave it pinned for new people to always see.

Also big thanks to all the mods here who spend a lot of time to share their knowledge, be available and organize the threads. This is my go-to tech forum because of the combined expertise and organization, thank you so much for this!

Hanma1963

Hi, I get a message "An operating system modification (bootloader unlocking and/or rooting) has been detected on your device. Therefore, for security reasons, logging in cannot be performed.)". Any workaround in this case? I followed GrapheneOS installation instructions, so bootloader is locked, but it seems like this app detects modification (https://www.oesterreich.gv.at/app-digitales-amt/faq/app_digitales_amt.html#fehler).

akc3n

Hanma1963 An operating system modification (bootloader unlocking and/or rooting)

The error you're experiencing is not uncommon. It signifies that the app detects a non-stock operating system.

Any workaround in this case? I followed GrapheneOS installation instructions, so bootloader is locked, but it seems like this app detects modification

Could you kindly confirm that you've followed the steps in this guide too? If so, this app is likely not compatible. It is recommended that you contact the developers of the app with the instructions from last step titled Next steps.

decadentist

Hanma1963

You can follow this guide (you'll need revanced manager), but on the newest version (3.0.3) they don't care anymore that your OS is modified.

Revanced Manager can also "fix" aome other apps.

Hanma1963

akc3n Thanks for the answer. I followed the steps in your guide, i hope correctly. Will contact the app's developers.

other8026

[deleted] I admit I don't really know how this all works very well, but there's a very detailed article on the GrapheneOS website that covers this topic: https://grapheneos.org/articles/attestation-compatibility-guide

DaRon

Hanma1963 hi, i did contact the "Bürgerservice" back in June already and this is what i got back (in July).
"Wir analysieren aktuell, wie die App „Digitales Amt“ unter Einhaltung der rechtlichen und technischen Vorgaben auch auf Geräten mit anderen Systemen nutzbar werden kann. Wir berücksichtigen dabei gerne Ihre Inputs und bitten noch um etwas Geduld. "

In short: authorities/app devs will check if there is any possibility (legal and tech wise) to allow it on alternative OS as well.

Yee, i did send them the link to the attestation-compatibility-guide...

Hope that helps

DaRon

Hanma1963

FYI: the App "Digitales Amt" (ID-Austria) and "eAusweise" are working now with GrapheneOS :)
After installing and fireing up the app for the first time, you get a warning, and it'll ask you if you know what you are doing, but other than this, it works like a charm

[deleted]

other8026 Yes but just allowing one Third-party OS (GrapheneOS) is not great at all. There should be an list of approved operating systems that can be used by sensitive applications.

[deleted]

other8026 Its good and detailed but not related to my query.

Rhinos

Can these settings only be used for "normal" programs or for multiplayer players ? Or are there other settings recommended or necessary ?

[deleted]

Rhinos These sttings can be used to troubleshoot any application.

Rhinos

Thanks for the info, because I get the game CSR 2 on my Google Pixel Tablet in multiplayer just not run and do not know what it is, I get no error message, nothing, it turns a wheel when I start this and endlessly, that's it !

flgx

@akc3n FWIW there's a typo in step 2, "Turning off the exploit protection compatibility toggle reduces system security" should be turning on

akc3n

flgx thank you :-)

other8026

[deleted] I guess I misunderstood then. And now that I see my response again, I linked the same link you quoted so my reply was kind of useless. But as far as I know, the APIs listed in the linked article (Play Integrity and SafetyNet) are the most common ones that apps use. It would be nice if there were a non-Google alternate that apps could use as well, but until one is available app devs would have to add OSes individually.

WhoTheFuckisAlice

Wonderful...

ok I have here two Apps, where I should can do this BUT

This is only practical when the Apps are installed in the owner Profil BECAUSE
if not and you have two Passwords with each 128 characters (This little bug that nobody can solve but god mother google herself, who doesn't think it's important to solve the problem) , do you know how many time it will cost to creat a little bug report no one will be solved, because the app dev doesn't give a shit if his app runs on a fringe product like GrapheneOS?

Should I give a try?

Sorry, but this is the reality...

other8026

WhoTheFuckisAlice two Passwords with each 128 characters

Obviously you can do whatever you'd like with your phone, but it's not really necessary considering the secure element forces delays between password guesses if being brute forced. I've read project members say that a 6 digit PIN is enough. The only reason you'd be using such a long password is if you don't trust the secure element.

WhoTheFuckisAlice This little bug that nobody can solve but god mother google herself, who doesn't think it's important to solve the problem

what little bug?

WhoTheFuckisAlice

other8026 Obviously you can do whatever you'd like with your phone, but it's not really necessary considering the secure element forces delays between password guesses if being brute forced. I've read project members say that a 6 digit PIN is enough. The only reason you'd be using such a long password is if you don't trust the secure element.

This password is not the key for the encryption of the user data partition in every profile?
Why do I still assign passwords when you can solve this so elegantly... every electronic device should have such a secure element. God bless your security management !

other8026 what little bug?

https://discuss.grapheneos.org/d/5731-bug-fingerprint-unlock-disabled-after-profile-change
https://github.com/GrapheneOS/os-issue-tracker/issues/1611

other8026

WhoTheFuckisAlice This password is not the key for the encryption of the user data partition in every profile?

You'll want to read this section of the website about how all that works: https://grapheneos.org/faq#encryption. Here's a relevant quote:

Sensitive data is stored in user profiles. User profiles each have their own unique, randomly generated disk encryption key and their own unique key encryption key is used to encrypt it.

And another:

Using a secondary profile for regular usage allows you to make use of the device without decrypting the data in your regular usage profile. It also allows putting it at rest without rebooting the device. Even if you use the same passphrase for multiple profiles, each of those profiles still ends up with a unique key encryption key and a compromise of the OS while one of them is active won't leak the passphrase. The advantage to using separate passphrases is in case an attacker records you entering it.

https://discuss.grapheneos.org/d/5731-bug-fingerprint-unlock-disabled-after-profile-change
https://github.com/GrapheneOS/os-issue-tracker/issues/1611

I didn't realize that this was still a problem that people were experiencing. I used to have this issue from time to time, but not anymore. I can understand that this is very annoying, especially when using really long passwords.