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.
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
#GrapheneOS: We're planning on phasing out support for 32-bit apps on 5th/6th generation Pixels where they're still supported. They were already phased out by Android for 7th generation Pixels and later, and by ARM for 2nd generation ARMv9 Cortex cores onwards. Since 7th/8th generation Pixel users are doing fine without them, we want to bring the improved security to users on 6th generation Pixels which still have a lot of support ahead of them. It will also save a significant amount of build time and bandwidth, particularly when we can move to 64-bit-only builds of Vanadium. The main benefit is dropping all the 32-bit ABI support from the kernel including a bunch of awful legacy cruft for emulating legacy ARM features no longer supported by hardware. The next release will add a clear warning to each launch of 32-bit-only apps. In nearly all cases, people just need to switch to proper builds of apps which aren't 32-bit-only such as the ones distributed by certain 3rd party mirror sites where users accidentally ended up on 32-bit-only builds. It hasn't been possible to install 32-bit-only apps from the Play Store on 64-bit-capable devices since August 2021 and they blocked uploading either new apps or app updates without 64-bit support since August 2019.
Project Announcement: Unplugged are a recent entry in the crowded space of selling insecure hardware with significantly worse privacy and security than an iPhone as highly private and secure. Bottom of the barrel MediaTek device with outdated AOSP is worse than status quo. All marketing, no substance. As part of marketing their products, Unplugged are spreading unsubstantiated spin and misinformation about GrapheneOS and the much more secure hardware we target. We've been aware of it for a while but chose not to respond to it until they began doing it in direct response to us. #GrapheneOS is a hardened OS built on the latest release of the Android Open Source Project rather than older releases with inferior privacy/security and incomplete privacy/security patches. We substantially improve privacy/security with our changes rather than making it worse. The work we do in GrapheneOS is highly regarded by privacy and security researchers. We've made major upstream contributions to the Android Open Source Project, Linux kernel and other projects, both through submitting privacy/security improvements and reporting vulnerabilities. We've also reported numerous vulnerabilities in hardware/firmware along with making multiple suggestions for new features which were implemented for Pixels. They're the only devices meeting our security requirements ( ). We target them because of security. Pixels have first class alternate OS support, which does not come at the expense of security. Support for installing an alternate OS is implemented securely as part of best in class boot chain and secure element security for Android devices. Supporting it has benefited security. Unplugged has claimed open source and support for alternate operating systems reduces security. Pixel security has benefited from many external security researchers along with contributions from GrapheneOS because of it. They'll benefit more as they publish more firmware sources. GrapheneOS not only leverages the same hardware-based security features as the OS but implements major hardware-based features unavailable elsewhere. Hardware memory tagging for production hardening is an exclusive GrapheneOS feature with a best-in-class implementation. Our USB-C port and pogo pins control feature does hardware-level attack surface reduction with code written for the drivers on each device: Our Auditor app leverages the pinning-based hardware attestation available on Pixels based on our proposal for it. Many of our other features are hardware-based, and some of these exist because of features we proposals or helped to secure against weaknesses. In April, Pixels shipped reset attack protection for firmware based on our proposal, which is not available on other Android devices. That reset attack protection blocks real world attacks by forensic data extraction companies, which we reported to Android. In April, Pixels also shipped a mitigation against interrupted factory resets used by those companies based on our report, not yet available on non-Pixels. In June, Android 14 QPR3 was released with a hardware-based OS feature fully blocking interrupting factory resets. This was based on our initial proposal we made as part of our reports of active exploits in January, similar to the reset attack protection shipped in April. Unplugged uses an older Android release. They do not have this AOSP patch. Their hardware is missing many standard security features including these recent 2 improvements shipped on Pixels. Their hardware doesn't even close to meeting our list of security standards even on paper. Unplugged has tried to misrepresent these improvements and falsely claimed they're uniquely relevant to Pixels due to alternate OS support. That's not true. Their device is missing these and many other security features, and is not more secure due to lacking alternate OS support. Unplugged was founded by Erik Prince, the same person who founded Blackwater. Erik Prince, it's founder, and others involved in UP are deeply tied to human rights abuses and surveillance around the world. Best case scenario is they're simply grifting like the Freedom Phone. Worst case is much worse. Unplugged are also infringing on the open source licensing multiple projects including DivestOS where they ripped off their AV from without attribution. They even still use DivestOS servers without permission. SkewedZeppelin is lead developer of DivestOS. image
Vanadium version 126.0.6478.122.1 released: Users will need to enable JavaScript JIT compilation for sites requiring WebAssembly again via the permission menu next to the URL due to us reverting the upstream security regression which resulted in this working by default. Unfortunately, Chromium still doesn't have a WebAssembly interpreter like Edge and got this working by rolling back the security of the API used to disable JIT compilation for their desktop V8 Optimizer toggle. Support for language-specific content filters was added which is automatically enabled when the language is selected (EasyList Germany has been added to the configuration app for testing the implementation). #grapheneos
Chromium's V8 Optimizer toggle for disabling JavaScript JIT compilation was changed to only disable the 2 higher tiers of JIT compilation while still leaving the baseline JIT compiler enabled. This also caused the device management policy for JIT predating this to change meaning. They did this because they decided having a toggle which breaks WebAssembly support is unacceptable. We had to revert these changes. Microsoft Edge implemented a WebAssembly interpreter instead, but it's not open source and there's nothing like it for Chrome yet. Vanadium disables JS JIT by default and provides a convenient per-site toggle available in the drop down menu next to the URL. We've restored the previous meaning of disabling the JIT so you'll need to add exceptions for sites requiring WebAssembly again. In theory, we could add 4 choices instead of 2: Disabled, Baseline JIT, Baseline JIT + Tier 2 and Full JIT. However, it's likely far too complicated and we're likely going to stick with having it either enabled or disabled. Chromium will hopefully add a WASM interpreter soon... #grapheneos
↑