Is grapheheOS actually harder to hack or does cellebrite just not put a lot of effort into supporting it because the very low odds of LEs running into one in the wild?
Why can't the stock ROMs use these features and be more secure also?
I had to get my friend to buy them for me when I was on Graphene
Some of the features may hurt user experience in some way and people made different trade-off.
For example, GrapheneOS disables USB before unlock so that there's no chance that some driver codes in Linux kernel run in response to a device being plugged in, for attack surface reduction. Then, say, if you have a cracked screen, the touchscreen no longer works and you don't want to fix it, if not for this mitigation, you can use an USB-C OTG cable to connect a mouse / keyboard to the phone, unlock it and export all your data. With this mitigation the keyboard won't work so you are forced to fix the screen first just to get your data out.
Some of these features are backported to mainline android, others may be deemed too advanced or just the incentives don't match (e.g. being able to disable networking by the user could cut into Google's earnings, e.g. limited ads in apps).
I guess one reason you'd want to avoid that is that makes it harder to e.g spoof your location or falsely tell the app that screenshotting is disabled.
If you want to dive deeper you can checkout droidguard/play integrity.
It also runs on Lineage with Mind The Gapps.
1. Such as via slower 0-day responses, for instance. This is a thought experiment, I'm nor alleging that this is what it is.
What bothers me is that when phones are stolen, they end up in other countries. Maybe you are a nobody, but if it is trivial to extract the information on a phone then there is more than an identity theft issue. Generative AI makes all of this shit way worse than it was even a year ago.
Not having the source of the patch adds some friction to all attackers, but reversing vulnerabilities from binary patches has a long history.
Anyway, GrapheneOS ships security patches very quickly, often bumps kernel versions quicker than the stock OS etc. Security isnt only reactive, also proactive. Some features like MTE even outrule entire classes of vulnerabilities.
GrapheneOS has much faster patching than the stock OS. It's many months ahead on Linux kernel LTS patches. It ships the latest GKI LTS revisions from Greg KH which don't lag far behind the kernel.org LTS releases. It also updates other software such as SQLite to newer LTS versions earlier. GrapheneOS also develops downstream patches for many serious Android vulnerabilities before those get fixed upstream.
There are currently a bunch of downstream fixes for Android vulnerabilities in GrapheneOS including fixes for a severe tapjacking vulnerability (https://taptrap.click/), 5 outbound VPN leaks, a leak of contacts data to Bluetooth devices and more serious issues which may be remotely exploitable.
GrapheneOS already provides the November 2025, December 2025 and January 2026 Android Security Bulletin patches for AOSP in the security preview releases:
https://discuss.grapheneos.org/d/27068-grapheneos-security-p...
Galaxy and Pixel devices ship a small subset of these patches early, but not most of them. Shipping them early is permitted. There's 1 to 3 month gap between Google disclosing patches to OEMs and those patches getting shipped as part of the Android security patch level. Shipping the patches early is allowed, but is a lot of extra ongoing work requiring a much faster release cycle to do it well.
GrapheneOS mainly focuses on systemic protections for vulnerability classes either wiping those out or making them much harder to exploit. The systemic protections are what makes it stand up much better to Cellebrite rather than patching known vulnerabilities earlier. Patching known vulnerabilities earlier does help in the real world, but the systemic protections help much more due to severe vulnerabilities being quite common in the current era of widespread use of memory unsafe code and to a lesser extent (for Android, definitely not the web platform) dynamic code loading, both of which are heavily addressed by GrapheneOS. I posted about several of the systemic protections relevant to this in my reply at https://news.ycombinator.com/item?id=45779157.
GrapheneOS has reproducible builds which will eventually be usable to enforce that updates are signed off by other parties as matching the code where they can define their own system for approving releases. Delayed patches are a serious security issue and this needs to be approached carefully with groups which can be depended on to have the necessary resources and skills to manage approving releases properly.
The honeypot theories don't make sense, since GrapheneOS is fully open source, and very transparent about developers, funding, infrastructure, and other internal stuff.
Releasing binary patches is allowed, this is why GOS have added the security preview channel.
Not really. There is a bunch of proprietary firmware running on those phones, which can be exploited with or without the help of the manufacturer.
Your machine is a distributed system. The firmware is what runs a specific node.
Yes they usually have DMA, shared busses, etc. That's an implementation detail.
A working IOMMU will stop both free- and non-feee firmware from rooting your device.
These concepts are orthogonal.
Not sure about smartphones though - they mostly struggle with a fact there are no truly open source baseband.
Let's be realistic if some 3 letters agency really want some data about me, there's not much I can do to counter that unless I'm ready to go to extreme lengths.
Even Mr Assange in his embassy could have added fitness trackers to add metrics that were hard and spotty to estimate from video surveillance.
I once thought like you. You do not need to go to extreme lengths to make things difficult and that is what is important. The fact is that the 3 letter agencies are increasingly fucking with normal people in a race to the bottom. Do not be defeatist - that only hurts everyone. The more people protecting themselves the safer everyone is from these people. If people just give up on privacy it puts a spotlight on normal people protecting themselves. The current state of which is so bad I have trouble putting it into words.
See https://news.ycombinator.com/item?id=45779241 which explains this.
See https://news.ycombinator.com/item?id=45779241 which explains this.
Modern Android on modern devices does support disabling software USB support for USB peripherals and USB gadgets while locked via Android 16 Advanced Protection feature. It also has a device admin API for disabling USB at a software level through device admin apps, which could implement disable it while locked but cannot provide support for still using a USB device connected while unlocked to make it much more usable. None of that provides comparable protection to the GrapheneOS USB protection feature, which is one small part of the overall GrapheneOS exploit protections.
By default, GrapheneOS blocks new USB connections at a software AND hardware level when the device is locked and then disabling USB data once existing connections end. You can get similar software level functionality via the Android 16 Advanced Protection feature but not the hardware-level protection or the many other exploit protections in GrapheneOS.
https://grapheneos.org/features#exploit-protection explains what's improved compared to standard Android 16. It's not documentation on Android + GrapheneOS features but rather only what GrapheneOS improves.
Edit: last released leak showed they had broken the then most recent iOS release (17.5.1) in AFU state on all but the most recent hardware which was marked "available in CAS"
https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju...
The good news is neither pixel nor iOS seems to show full file system extract under BFU state in the recent tables I can find.
Apps are installed so that their packages are available before first unlock and can explicitly opt-in to supporting a specific subset of their components and data before available before first unlock. An app can implement push notifications before first unlock if the developers want to do it, and they could do that in a way where no message data, etc. is available before first unlock. The OS leaves it up to apps to decide what to do, and nearly all apps stick with the default of all their functionality and data available After First Unlock instead of either making it available Before First Unlock or having it go back at rest while locked again.
Apple and Google do not appear to have a regular source for finding out which vulnerabilities are currently being exploited. Both appear to be refraining from actively seeking our these devices to patch all the exploits they use. It's often external researchers including at Citizen Lab and Amnesty International determining which vulnerabilities are being exploited by these tools and reporting it to both Apple and Google. Long periods of time often pass with no loss of capabilities for new Android and iOS versions. The main reason Cellebrite loses access is likely tied to the deployment of new exploit protections requiring working around those and using new vulnerabilities. Code churn also likely impacts them.
You seem to be mixing up what they're referring to as a BFU exploit with a BF exploit. Pixel 2, Pixel 6+ and iPhone 12+ have withstood Cellebrite's efforts to do brute force attacks against a BFU device. BFU exploit means they can extract data such as saved Wi-Fi networks and installed apps, but without a BF exploit they cannot bypass the secure element throttling. It may become impractical for them to have BF exploits anymore, but it doesn't make their BFU exploits worthless.
GrapheneOS has access to the latest Cellebrite Premium documentation since we have a contact able to share it with us. In April 2024 and then July 2024, we posted screenshots of specific capability tables from the documentation but then stopped doing it because it could result in losing access to it. The contact sharing it with us was still fine with us doing it but later came to the same conclusion we did that it's best not to post anything from it. Cellebrite doesn't like it being posted publicly even though it's essentially marketing their products, probably because it results in pressure on Android and iOS to stop it happening.
And even if the USB mitigations were hard to write (thanks for all your work, by the way!), they are surely significantly easier to backport from an open source project.
Google shipped the Pixel 8 with production quality MTE support at a hardware level in October 2023 but still isn't using it by default and their Advanced Protection mode only uses it for a tiny subset of the OS and nearly no user installed apps. Enabling it would involve a whole lot of work fixing the bugs it finds, but we're already doing that work in GrapheneOS. They'd also need to fix several issues with their MTE integration in Chromium and elsewhere. It wouldn't be as good as our better implementation in hardened_malloc, etc. but they could be using it. They could start using it in full async mode for near zero performance and cost and then enable sync or asym mode for more components over time where the performance cost is irrelevant, which applies to most of the base OS. They might not want to use sync mode in the kernel for performance reasons, but other than that it mostly has no noticeable performance cost outside of apps.
Performance is likely a major factor Apple is not enabling it by default for apps and is instead discouraging app developers from opting into it by scaring them away with compatibility and performance concerns along with implying apps need to be written with it in mind which is really not the case. It finds memory corruption bugs and doesn't have false positives. Apps should not have memory corruption bugs in regular use and it's more than just an MTE compatibility issue if they do. Android made the smart decision to start tagging points with Top Byte Ignore in the system allocators many years ago which paved the way for HWASan support used by Android to nearly fully replace ASan and then later MTE support. HWASan is similar to MTE but with 8 bit instead of 4 bit tags using Top Byte Ignore but all accesses need to be instrumented to be checked since it's not a hardware feature. HWASan is much slower than MTE but Google has heavily used it for many years which means most of the OS was prepared for MTE other than hardware specific parts not well tested by automated testing.
I experimented with one hour, but missed an alarm.
Its good security practice to reboot your phone before going to bed, this puts it in the much harder to break in to BFU state.
GrapheneOS nearly entirely eliminates the attack vector used by Cellebrite Premium by default via software and hardware blocking of new USB connections while locked along with hardware-level disabling of USB data if there are no existing USB connections. Cellebrite's recent documentation shows they can't currently exploit an unlocked GrapheneOS device when the password is obtain from the user which shows that it's not all about the USB protection at all. They were unable to exploit GrapheneOS prior to the replacement of software blocking of new USB peripherals with the much more complete current implementation of USB attack surface reduction blocking USB peripherals, USB gadgets and USB-C alternate modes at both the software and hardware level along with disabling USB data at a hardware level. They were last able to exploit locked GrapheneOS devices in 2022, possibly because of a USB gadget driver vulnerability exposed without needing to enable a non-default mode such as file transfer or a fastboot firmware vulnerability.
Since April 2024, Pixels zero memory in fastboot mode prior to enabling USB in order to prevent a hard reset followed by booting fastboot mode to perform an exploit of the device through the firmware while still partially in the AFU state. GrapheneOS takes care of zeroing memory when booting the OS and zeroes freed memory in both the kernel and userspace. The zeroing of freed pages in the kernel results in properly restoring the BFU state for a clean reboot/shutdown and zeroing at boot deals with unclean resets. Fully encrypted RAM with a per-boot key would be nicer and what we plan to have on future GrapheneOS devices once an SoC such as Snapdragon supports it.
Since July 2021, GrapheneOS implements locked device auto-reboot. It was enabled with a 72 hour timer by default and then reduced to a default 18 hour timer. Users can set it in the range of 10 minutes through 72 hours. This restores devices to BFU from AFU automatically. Both iOS 18.1 (72 hour default) and Android 16 Advanced Protection mode (72 hour opt-in) implemented a similar feature later on. Android implemented it after we proposed it in January 2024 at the same time we proposed several other improvements including the fastboot memory zeroing which we actually wanted to be for all boot modes, but they only did the firmware boot mode and we have to take care of the OS boot modes ourselves in the kernel since they don't do it.
GrapheneOS adds many other relevant features including 2-factor fingerprint unlock (adding a PIN to fingerprint unlock), PIN scrambling, support for much longer passphrases and an optional duress PIN/password.
Duress PIN/password near instantly prevents recovering any data from the device in multiple ways (wipes hardware keystores, secure element and disk encryption headers) in any place the PIN/password for any profile is requested. It also works with the optional 2nd factor PIN for fingerprint unlock, but not currently with a SIM PIN which we're considering implementing.
A basic secure can use a random 6 digit PIN with security based on the Pixel's high quality secure element performing throttling for decryption attempts, which Cellebrite has been unable to bypass for the Pixel 6 and later. A highly secure setup can use a random 6-8 diceware word passphrase not depending on hardware security combined with a fingerprint+PIN with a random 4-6 PIN as a secondary unlock method. GrapheneOS permits 5 attempts for fingerprint unlock rather than 4 batches of 5 attempts with 2nd factor PIN failures counting towards that so a 4 digit PIN works fine for that. Either setup can take advantage of PIN scrambling.
There's a third party article about the userspace memory allocator hardening in GrapheneOS at https://www.synacktiv.com/en/publications/exploring-graphene... with only one minor error (the comparison between out-of-line metadata + random canaries in hardened_malloc vs. 16-bit checksums for inline metadata in Scudo) and one minor omission (write-after-free check for non-MTE hardware). That's just one aspect of how GrapheneOS hardens against memory corruption. It uses MTE in the kernel too. Android 16 only uses MTE for a tiny subset of the OS not including the kernel when Android 16's Advanced Protection mode is enabled. It can't use it for most user installed apps either while GrapheneOS supports enabling it for all user installed apps.