#GrapheneOS version 2025012600 released. This update adds workarounds for various apps banning aftermarket operating systems using techniques outside of the Play Integrity API. Revolut is the most common app known to do this. There is now a menu to access a list of apps using the Play Integrity API from sandboxed Google Play. You can also choose to block the Play Integrity API for apps entirely, which could potentially help with some apps. Messaging app was ported to Android 15 APIs as a beginning for overhauling all the default / system apps. Changes since the 2025011500 release: • disable standard Android feature holding a 10 minute screen wake lock after the screen brightness is raised at least 2 times within 5 minutes since this is confusing for users and it's far better if keep awake is done explicitly • always show KASAN kernel crash notifications instead of only when system crash reporting is enabled by users • Messaging: begin under the hood overhaul including fully porting to target API 35 (Android 15) • recovery: remove spurious warning after update installation fails on A/B update devices • change build username to build-user and build hostname to build-host instead of setting both to grapheneos due to bad actors using it to ban using GrapheneOS • return green as the value of ro.boot.verifiedbootstate outside of specific parts of the base OS due to bad actors using it to ban using GrapheneOS • SettingsIntelligence: don't show preference summaries in search results since it doesn't work properly for ones depending on dynamic string formatting and isn't done by SettingsIntelligenceGoogle on the stock Pixel OS • Contact Scopes: fix spoofing of OP_GET_CONTACTS for apps not requesting WRITE_CONTACTS • Sandboxed Google Play compatibility layer: improve infrastructure • Sandboxed Google Play compatibility layer: allow blocking the Sandboxed Google Play is running notification • Sandboxed Google Play compatibility layer: add per-app Play Integrity menu in the per-app Settings configuration that's shown after an app uses the Play Integrity API • Sandboxed Google Play compatibility layer: add per-app toggle for blocking using the Play Integrity API via the per-app Play Integrity menu as a workaround for apps which ban devices based on it but don't require providing it to their service yet • Sandboxed Google Play compatibility layer: add shortcut to the per-app Play Integrity API menu for contacting the app developer by leaving a review through the Play Store page • Sandboxed Google Play compatibility layer: add menu for viewing all apps which have used the Play Integrity API with a shortcut in the per-app Play Integrity API menu • Sandboxed Google Play compatibility layer: show optional notification upon detection of Play Integrity usage providing a shortcut to the per-app Play Integrity API menu and another for hiding further notifications for the app which is also available as a toggle in the per-menu • hardened_malloc: update libdivide to 5.2.0 • TalkBack (screen reader): update dependencies • TalkBack (screen reader): make builds fully reproducible by removing the use of __DATE__ and __TIME__ by brltty along with making the liblouis translation table zip use deterministic file order and timestamps • kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.124 • kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.68 • Vanadium: update to version 132.0.6834.122.0

Releases | GrapheneOS

Good news for #GrapheneOS and Cryptomator users

Cryptomator

Cryptomator for Android Now on Accrescent

Cryptomator for Android is now available on Accrescent, offering enhanced security and distribution benefits.

Revolut is specifically banning #GrapheneOS by checking for the build machine hostname and username being set to 'grapheneos'. We've changed these to build-host and build-user. Combined with another change, this allow our users to log in to it again until they roll out Play Integrity API enforcement. There's no legitimate excuse for banning using a much more private and secure operating system while permitting devices with no security patches for a decade. Meanwhile, Revolut's shoddily made app tells users they're banning GrapheneOS because they're "serious about keeping your data secure". Revolut's app will stop working against once they start enforcing having a Play Integrity API result showing it's a Google certified device. This is not a security feature but rather anti-competitive behavior from Google deployed by apps like Revolut wanting to pretend they care about security. Revolut uses a bunch of shady closed source third party libraries in their app and it's one of these libraries banning GrapheneOS. These libraries are a major security risk and put user data at risk of being compromised. Revolut is not taking user security seriously at all and is cutting corners.

Android uses Clang type-based forward edge Control Flow Integrity (CFI) for the kernel and a subset of userspace. It isn't a high impact security feature. We used to have changes expanding userspace coverage but Android is already doing it and we moved this effort to higher impact work. Unlike Chrome, we enable type-based forward edge CFI for our Vanadium browser to cover the default browser and WebView. Other than that, the usage of Clang CFI has the same scope as the stock Pixel OS and our focus is on higher impact areas. Expanding it causes regressions we have to address. Unlike the stock Pixel OS, we enable branch target identification (BTI) to address holes in Clang CFI coverage in the kernel and the lack of full deployment in userspace. BTI is coarse grained CFI and is an extremely weak security feature but it's easy to enable and doesn't cause regressions. Unlike the stock Pixel OS, we enable pointer authentication (PAC) return protection for userspace instead of only the kernel. Similar to BTI, this is easy to enable and doesn't cause regressions. Unlike the stock Pixel OS, we use Shadow Call Stack as an extra layer on top of PAC in the kernel. Instead of working on expanding CFI coverage, our focus is on higher impact features including hardware memory tagging (MTE). We have a best-in-class implementation of MTE for heap protection in hardened_malloc and we deploy MTE for all but a single userspace process (camera HAL). Our most recent release enabled MTE for the Linux kernel allocators too:

Releases | GrapheneOS

We need to improve the kernel implementation to enforce deterministic guarantees with it as hardened_malloc does. We're also planning to deploy stack allocation MTE for both the kernel and userspace. MTE directly uncovers memory corruption bugs which are often security bugs. Type-based CFI uncovers type mismatches which block deploying it but rarely have any direct security impact. These are major ongoing areas of work as software changes, not only for the initial deployment. The recently published paper "Twenty years later: Evaluating the Adoption of Control Flow Integrity" has major inaccuracies due to flaws in their tools and methodology. They inaccurately claim we don't expand coverage of CFI and wrongly claim we reduce it on end-of-life 4th/5th gen Pixels. 4th/5th gen Pixels are end-of-life. We make it clear that our releases for them are unofficial extended support releases for harm reduction. Regardless, we do not reduce CFI coverage on them. We also don't increase the number of executable code as they claim but rather greatly reduce it. They didn't look into what was actually happening and resulting in their tools reporting what they are. Their claims are likely based on the way we handle device support ending up placing the same executables and libraries in more locations. They also miss a whole lot including Chromium. The paper also wrongly portrays largely ending up with the same end result for compiled code on devices where there aren't major differences such as PAC and BTI as us reusing the code from the stock OS. No, that's not what is happening. Android builds are reproducible. That's not reuse. The paper describes Android 13 is the most recent release of Android and lists releases from April 2023 as what they analyzed, so there's also the issue of it being very outdated. This does not explain the inaccuracies, but does partially explain why it doesn't cover PAC and BTI. There are other inaccuracies including about #GrapheneOS but we don't need to go through all of it point by point. We'll be contacting the authors asking for corrections but our expectations are low based on past experience. Posting this is our main way to address it. Similar to ASLR, forward-edge type-based CFI exists to make exploiting memory corruption vulnerabilities harder in the general case. It protects specific data (function pointers and virtual function tables) from attacks and only outright blocks attacks in a small subset of cases. Clang CFI is least powerful in the Linux kernel and browser engine due to major holes in what it protects and many alternatives to function pointers for taking over control. Unfortunately, those are 2 of the places in the most need of much better exploit protections. Android initially deployed CFI in the media stack and that's still where they focus on it. It was then added for the whole kernel. They're gradually expanding it in userspace starting in higher impact areas. We don't see much value in us focusing on gradually bringing it to lower impact areas. Turning CFI from a weak or mediocre protection largely acting as an annoyance for attackers into a strong protection would require additional compiler features and a massive overhaul to software. There are too many holes in these protections and other exploit targets. It's ultimately a dead end. Rather than making enormous changes to protect or remove exploit targets bit by bit, we need a strong general purpose protection. Memory tagging provides that, with the major caveat that MTE is only 4 bits. A future version can be given the bits from PAC. A far future one can use fat pointers. Memory tagging with fat pointers will be usable to bolt on low overhead memory safety to massive legacy software stacks and to protect against remaining holes in memory safe languages. It's too bad there's so much focus on piling on more and more weak mitigations instead of building solutions.

#GrapheneOS version 2025011500 released. This update provides currently exclusive and early fixes for security bugs regarding the lock screen originating from the upstream stock Android. They do not affect contemporary users as they would not use such a unique accessibility configuration to allow this. These vulnerabilities also didn't allow bypassing the lock screen, rather certain restrictions on fingerprint unlocks. Early fixes like these help GrapheneOS stand out. MTE has been extended to the kernel allocators, which significantly increases kernel security. We're also pushing kernel security patches earlier than anyone including the patch for CVE-2024-56556 (a High severity vulnerability). Changes: • fix upstream Android lockscreen triggered by the combination of fully disabling animations (via Settings > Accessibility > Color and motion > Remove animations) and enabling always-on display (Settings > Display > Lock screen > Always show time and info) which results in the locking process getting stuck and not considering the device locked until it wakes again due to not skipping animations as intended (this did not create a lockscreen bypass but did result in valid biometric unlock credentials skipping restrictions) • add protection against upstream lockscreen bugs bypassing restrictions on biometric unlocking while the device is asleep including the standard restrictions and our recently added 2-factor fingerprint unlock feature • kernel (Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold): enable hardware memory tagging for the main kernel allocators via the upstream Hardware Tag-Based KASAN implementation (which is intended for production usage, unlike the other KASAN modes) • kernel (Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold): switch KASAN fault handling from report to panic to use it as a hardening feature instead of only a bug finding tool • kernel (Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold): switch KASAN hardware memory tagging mode from synchronous to asymmetric for the initial deployment to reduce the performance cost and match our existing hardware memory tagging usage in userspace (synchronous mode is potentially more useful in the kernel than it is for userspace which is something we can investigate and potentially offer as an option) • kernel (Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold): disable our slab canary feature since it's incompatible with the kernel's hardware memory tagging and will be obsolete after we've made basic improvements to the upstream hardware memory tagging implementation • Updater: require TLSv1.3 instead of either TLSv1.2 or TLSv1.3 • kernel (5.10): update to latest GKI LTS branch revision including update to 5.10.233 • kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.176 • kernel (5.15): merge latest GKI tag to incorporate important security and other patches including the patch for CVE-2024-56556 which are not included in the latest kernel.org release (5.15.176) or the latest GKI LTS branch revision • kernel (6.6): update to latest GKI LTS branch revision • Seedvault: update to a newer revision (will be replaced with a better backup implementation in the future) • System UI Tuner: opt-out of Android 15 edge-to-edge since it's not properly supported yet (upstream bug) • make eng builds more consistent with user/userdebug builds by extending the GrapheneOS additions of the ro.control_privapp_permissions=enforce, net.tethering.noprovisioning=true and ro.sys.time_detector_update_diff=50 system properties to all build variants • show a system error notification for privileged permission allowlist violations in development builds (userdebug and eng builds) instead of breaking booting the device to make developing device support and porting to new OS versions easier

Releases | GrapheneOS

DNSNet (Continued DNS66 fork - a ad/content blocker DNS) app on Accrescent now.

For alpha testers, a preview update of the AOSP Messaging app is out in #GrapheneOS. It is mostly bug fixes and to be updated to a newer target API. This is part of future work to replace all the default apps with new, better apps or to fork them and make them more useable. App developers have been hired to help for this task. Changes won't be immediate but app improvements should be made in the near future.

Stacker News is now noncustodial (after some delays) so final@stacker.news goes to final@minibits.cash from now on. Smaller, separate zaps preferred as sometimes I don't see them.