final [GrapheneOS] πŸ“±πŸ‘οΈβ€πŸ—¨οΈ's avatar
final [GrapheneOS] πŸ“±πŸ‘οΈβ€πŸ—¨οΈ
npub1c9d9...sqfm
Keeping the fight. Community Moderator for #GrapheneOS https://discuss.grapheneos.org/u/final This is a personal account. I do not speak on behalf of GrapheneOS developers as a whole (nor am I) and suggestions shall not be endorsements.
The most recent release of #GrapheneOS (2024052100) adds the first piece of our ongoing work on duress/panic features. It makes standard factory resets including by device admin APIs wipe the device near instantly before it reboots to recovery to wipe and format it. We made our own wipe-without-reboot but we're backporting the Android 15 implementation instead of using ours. They made it in response to our vulnerability report about this (CVE-2024-29748, reported by GrapheneOS). The April release added 2 Pixel specific protections against the 2 vulnerabilities we reported, but both vulnerabilities essentially impact all Android devices and were only addressed for Pixels. The factory reset interruption also isn't fully addressed until they ship this part. A wipe without reboot is important as cutting device power during a restart can interrupt the wipe process. GrapheneOS now wipes without a reboot.
#GrapheneOS uncovers leaked documentation for smartphone exploits by Cellebrite. XRY and Cellebrite say they can do consent-based full filesystem extraction with iOS, Android and #GrapheneOS. It means they can extract data from the device once the user provides the lock method, which should always be expected. They unlock, enable developer options and use ADB. Cellebrite's list of capabilities provided to customers in April 2024 shows they can successfully exploit every non-GrapheneOS Android device brand both BFU and AFU, but not GrapheneOS if patch level is past late 2022. It shows only Pixels stop brute force via the secure element. Cellebrite has similar capabilities for iOS devices. This is also from April 2024. We can get the same information from newer months. In the future, we'll avoid sharing screenshots and will simply communicate it via text since to prevent easily tracking down the ongoing leaks. Pixel 6 and later or the latest iPhones are the only devices where a random 6 digit PIN can't be brute forced in practice due to the secure element. Use a strong passphrase such as 6-8 diceware words for a user profile with data you need secured forever regardless of exploits. Pixels are doing a bit better on the secure element front and iPhones are doing a bit better against OS exploitation, but not by much. As always, this shows the importance of our auto-reboot feature which gets the data back at rest after a timer since the device was locked. Our focus in this area is defending against exploitation long enough for auto-reboot to work. It's set to 18 hours since the device was locked by default, but users can set it as low as 10 minutes. Since around January, we massively improved security against these attacks. By default, our recently added USB-C port control feature disallows new USB connections in AFU mode after the device is locked and fully disables USB data at a hardware level once there aren't active USB connections. Users can set it to also do this in BFU or even when unlocked. Users with a high threat model can fully disable USB including USB-PD/charging while the OS is booted to only allow charging while powered off or booted into the fastboot/fastbootd/recovery/charging modes. GrapheneOS on 8th gen Pixels is ideal due to hardware memory tagging. Consent-based data extraction (FFS) is not in the scope of what we're trying to defend against beyond shipping our secure duress PIN/password implementation to replace insecure approaches via apps. Data users can backup is inherently obtainable with consent, which is nearly all. Within the past 24 hours, there has been an attack on GrapheneOS across social media platforms misrepresenting consent-based data extraction as GrapheneOS being compromised/penetrated. The person doing it is pretending to be multiple people and falsely claiming we covered it up. GrapheneOS is the only OS having success defending against these attacks. We could do more with a successful hardware partnership such as having encrypted memory with a per-boot key instead of relying on our kernel memory zeroing combined with auto-reboot and fastbootd zeroing. New versions of iOS and Pixel OS often invalidate their existing exploits, but devices in AFU are stuck in AFU mode waiting for new exploits. Random 6 digit PIN is only secure on a Pixel/iPhone and only due to secure element throttling. Use a strong passphrase to avoid this. If you wonder why duress PIN/password is taking so long, it's because we aren't doing it for show like existing implementations. It needs to work properly and guarantee data will be unrecoverable with no way to interrupt it. Slowly rebooting to recovery to wipe isn't acceptable. See for our thread covering the firmware improvements we helped get implemented in the April 2024 release for Pixels. It doesn't currently really help the stock Pixel OS because they haven't blocked the OS exploits that are being used yet but it helps us. Our hope is that our upcoming 2-factor fingerprint unlock feature combined with a UI for random passphrase and PIN generation will encourage most users to use a 6-8 diceware word passphrase for primary unlock and fingerprint + random 6-digit PIN for convenient secondary unlock. Cellebrite documentation and has stated they'll upload future versions of it if you want to look at the rest of it: We have info on XRY, Graykey and others but not the same level of reliable details as this.
An experimental prerelease of #GrapheneOS for the Pixel 8a is now available, including web installer support. Pixel 8a currently uses Android 14 QPR1 instead of Android 14 QPR2, meaning it's missing many improvements from the 2nd quarterly release including important privacy and security enhancements. It's likely Android 14 QPR3 will be released in June which should resolve this problem. Android 14 QPR2 is the largest ever quarterly release of Android, because it's the first trunk-based development release. It brought a lot of what Android 15 is going to ship, largely under the hood with new user-facing features largely disabled but present in the code. Android 14 QPR2 was released on March 4th but had a delay in publishing to AOSP due to issues with pushing the code which was finished by March 5th. GrapheneOS had a release based on it within a day of that, but it took a couple days to reach staging due to regressions we found. One of those regressions was the High severity Bluetooth vulnerability we found which was introduced in Android 14 QPR2. This issue slipped into our Stable channel release due to only coming up with rare configurations but we got it fixed on March 9th. Since the Pixel 8a is still using Android 14 QPR1, our initial release is based on porting our changes from our 2024030300 release which was the last one based on QPR1 ( It has a current May security patch level, but this doesn't meet our usual standards. It's missing improvements to GrapheneOS from March, April and May in addition to Android 14 QPR2 changes. We backported our change enabling PAC/BTI for userspace and are using a current GrapheneOS 5.15 LTS common kernel source tree. SHOULD be fixed with June update, QPR3 or not. Pixel 8a switched to Samsung GNSS (GPS, etc.) from Broadcom so we need to add Samsung PSDS support to our network services for PSDS to work.
Pixel 8a with the latest May 2024 update is running Android 14 QPR1 with backported security patches instead of Android 14 QPR2. Android 14 QPR2 was released in March 2024 and is by far the largest quarterly release so far due to being the first trunk-based quarterly release. We're definitely not going to backport all the changes we've made since March to Android 14 QPR1. That means we can't simply make the usual device support branch to support it. It's going to need to start out being treated as if it's an end-of-life device in extended support. The Pixel 8a doesn't currently meet our expectations. We haven't decided if we want to move development resources from working on new features to providing experimental support for a device with a botched launch. It would be a lot more efficient to wait for it to be fixed first. It might get fixed in the June release. We could put in a bunch of effort to get experimental support for it in the next 24 hours but that will come at a big cost and it won't be anywhere close to something we can consider a production release due to what they released, not us.
Our #Vanadium browser ( is based on the stable releases of Chromium. We port to the new releases when they're still in Beta/Dev/Canary but we wait until it's Stable to upgrade, particularly since Stable is the only branch with proper security support. Within release channels, Chromium uses staged rollouts where initially only a random subset of users get the new release. Recently, the initial Stable channel release started being done 1 week early and only rolled out to a tiny number of users: Current release status for Android is at There are 2 variants of a regular Stable release and 2 of an early one, since they enjoy A/B testing changes so much. We've been following the early Stable, but this month they failed to support it properly... After the pair of early Stable releases based on v125 for Android, there were 2 pairs of releases based on v124 with 2 rounds of security patches for issues being exploited in the wild. They failed to update the early Stable release as they have before, so we had to deal with it. Strangely, it appears that the early Stable channel release was only rolled out for Android and the Safari-based iOS app. The 0.2% of Android users receiving the early Stable release aren't getting patches for those 2 vulnerabilities being exploited in the wild. That's not great. These are the 2 patches missing for Android users who get updated to 125.0.6422.34 or 125.0.6422.35: Both are marked as having an exploit in the wild. They should really simply make 1 tag and stop making things overly complex. #GrapheneOS
#GrapheneOS version 2024050700 released: While it appears the patch level is older, this is due to Google not releasing the full SPL until later. - full 2024-05-05 security patch level rebased onto AP1A.240505.005 Android Open Source Project release - update our backports of mainline APEX Health Fitness patches - kernel (5.10): update to latest GKI LTS branch revision including update to 5.10.213 - kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.151 - TalkBack (screen reader): update dependencies - Vanadium: update to version 124.0.6367.159.0 - PDF Viewer: update to version 18
We've pre-ordered a Pixel 8a for our official device testing farm. They push the Android Open Source Project tags and stock OS factory images on the official release day. Should take us a couple hours to add support for it. We'll build, test and make an official release quickly. #GrapheneOS
#GrapheneOS receives third Android Security Acknowledgement from Google this year. This time for a high-severity Bluetooth vulnerability: Google has listed the CVE-2024-23694 vulnerability we reported in the security acknowledgements for May 2024: This is the Bluetooth issue we found with memory tagging which they assigned a High severity. We fixed this on March 9th. This vulnerability isn't listed in the baseline Android Security Bulletin despite being an Android Open Source Project issue. It will likely be listed in the Pixel Update Bulletin which should be today with the monthly update of AOSP and the Pixel OS. This vulnerability only impacts Android 14 QPR2 and later. It's possible they only list issues impacting the initial release of Android 14 in Android Security Bulletins and put the rest in Pixel bulletins. It's odd how Pixel bulletins are mostly issues impacting other devices. Last month, Pixels fixed 2 vulnerabilities we reported which were both classified as High severity and were both exploited in the wild by forensic companies to extract data on smartphones. Both also impact non-Pixels but were only fixed for Pixels and listed in the Pixel bulletin. We understand why they didn't list those firmware patches in the Android Security Bulletin (ASB) since other devices with the same issues need their own unique firmware patches for them. The AOSP 14 QPR2 Bluetooth big not being listed means ASB is less complete than we thought though.
Android monthly security backports were released this Monday. We expect the full monthly release to be released much later today (Tuesday). It's what happened last month, but last time we expected the monthly release to be delayed a week so we did an early release with backports. Monthly/quarterly/yearly releases include Low/Moderate severity patches not backported to older releases and are needed for Pixel firmware/driver patches. Those aren't published/disclosed for May yet. We'll do an early release with the ASB backports if it's not released today. We've reviewed the backports and can easily ship them if needed. We've included the next set of Linux kernel GKI LTS updates too. We'll have mitigations for the 3rd party VPN app DNS leaks discovered by our community soon, but likely not today's release.
↑