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.
For Signal users: Outside of just the security benefits for using Molly we discuss a lot about, you should also use it if you don't use Google Play Services, as the non-FCM push notifications in the original Signal app drains a lot of battery. Molly FOSS has a much more efficient implementation of non-FCM push notifications and doesn't drain battery. You can find Molly FOSS on the Accrescent app store (available in GrapheneOS Apps app) or from the project site.
EXCLUSIVE: Here's the Cellebrite Premium 7.69.5 iOS Support Matrix from July 2024. 404media recently published an article based on the same April 2024 docs we received in April and published in May. Many tech news sites including 9to5Mac made incorrect assumptions treating that as current. Here's the Cellebrite Premium 7.69.5 Android Support Matrix from July 2024 for Pixels. They're still unable to exploit locked #GrapheneOS devices unless they're missing patches from 2022. A locked GrapheneOS device also automatically gets back to BFU from AFU after 18h by default.
We published the Cellebrite Premium documentation from April 2024 in May 2024. Our thread properly explained the info in the tables including their inability to exploit Pixel 6 or later secure element and only partially bypass it on iPhone 12 or later at that current period of time. Cellebrite was a few months behind on supporting the latest iOS versions. It's common for them to fall a few months behind for the latest iOS and quarterly/yearly Android releases. They've had April, May, June and July to advance further. It's wrong to assume capabilities didn't change for the later iPhones. 404media published an article about the leaked documentation this week but it doesn't go into depth analyzing the leaked information as we did, but it didn't make any major errors. Many news publications are now writing highly inaccurate articles about it following that coverage. The detailed Android table showing the same info as iPhones for Pixels wasn't included in the article. Other news publications appear to be ignoring the leaked docs and our thread linked by 404media with more detail. They're only paraphrasing that article and making assumptions. The person who shared it with 404media is one of our community members. We regularly get sent this kind of information. In the case of XRY from MSAB, we were able to report several Android vulnerabilities based on their docs which are now fixed on Pixels but not elsewhere yet. We received Cellebrite's April 2024 Android and iOS support documents in April and from another source in May before publishing it. Someone else shared those and more documents on our forum. It didn't help us improve GrapheneOS, but it's good to know what we're doing is currently working. It would be a lot more helpful if people leaked the current code for Cellebrite, Graykey and XRY to us. We'll report all of the Android vulnerabilities they use whether or not they can be used against GrapheneOS. We can also make suggestions on how to fix vulnerability classes. In April, Pixels added a reset attack mitigation feature based on our proposal ruling out the class of vulnerability being used by XRY. In June, Pixels added support for wipe-without-reboot based on our proposal to prevent device admin app wiping bypass being used by XRY. In Cellebrite's docs, they show they can extract the iOS lock method from memory on an After First Unlock device after exploiting it, so the opt-in data classes for keeping data at rest when locked don't really work. XRY used a similar issue in their now blocked Android exploit. #GrapheneOS zero-on-free features appear to stop that data from being kept around after unlock. However, it would be nice to know what's being kept around. It's not the password since they have to brute force so it must be the initial scrypt-derived key or one of the hashes of it.
The #Accrescent security and privacy focused Android app store is now available in the #GrapheneOS app store. Accrescent is a mobile security and privacy project that closely ties to our values. We hope the Accrescent project can benefit from having more users. Accrescent features: - App signing key pinning: first-time app installs are verified so you don't have to TOFU. - Signed repository metadata: repository contents are protected against malicious tampering. -Automatic, unattended, unprivileged updates (Android 12+): updates are handled seamlessly without relying on privileged OS integration. - Designed for split APKs: downloaded APKs are optimized for your device to save bandwidth. - No remote APK signing: developers are in full control of their app signing keys. - No account required: users don't need an account to install apps, improving privacy. image
Journalist Joseph Cox of 404 Media has made commentary on the leaked Cellebrite documentation we discussed, and additionally verified the authenticity (we know it's genuine, but it's good to see from others). The #GrapheneOS team has provided commentary. We continue to monitor what threats are up to and prioritize GrapheneOS development when threats arise. We have a proven track record of discovering, reporting and fixing vulnerabilities exploited in the wild. This work will continue.
Certain banking apps use a buggy anti-tampering library which was broken by a security improvement in the most recent #GrapheneOS release. It wasn't reported during 2 days of Alpha/Beta testing. We've paused rolling it out to the Stable channel and we're working on resolving it. Compatibility issue is caused by these apps having hand-written 64-bit ARM assembly code that's making system calls with the 32-bit ARM compatibility layer even on devices unable to run 32-bit ARM code at a CPU level. They depend on a quirk of how 32-bit ARM compatibility works. Unfortunately, it means we need to temporarily revert the removal of the kernel's 32-bit compatibility layer on devices without 32-bit support. Banking apps are holding back security with their anti-tampering libraries. They do this to make it harder to audit their insecure apps.
#GrapheneOS version 2025070900 released. - Settings: extend standard fingerprint enrollment stages with proper support for devices with power button fingerprint scanners (Pixel Fold, Pixel Tablet) which is not present in AOSP (Pixel Fold was still usable, but it had become incredibly hard to successfully register new fingerprints on the Pixel Tablet) - improve warning for 32-bit-only apps by explaining why the warning is shown, how to resolve it for apps that are still developed and that we plan to phase out support for it on 5th/6th generation Pixels where it's still available - show warning for 32-bit-only apps on each launch instead of only once - kernel (Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a): disable 32-bit ABI support to substantially decrease kernel size and attack surface and raise mmap_min_addr to the standard 65536 for 64-bit-only ARM - kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.158 - adevtool: update file removal for 8th gen Pixels to skip Family Space related files - GmsCompatConfig: update to version 122 - Vanadium: update to version 126.0.6478.122.3
↑