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?
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?
All of the listed features significantly raise the bar for exploitation ;
https://grapheneos.org/features
So Graphene is actually more secure than most stock ROMs, but e.g. banking apps won't run on it "for security"?
Why can't the stock ROMs use these features and be more secure also?
> Why can't the stock ROMs use these features and be more secure also?
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.
That also sounds like a nonstarter for a lot of kiosk and embedded use cases
Okay? Then switch that off? :)
If apps refuse to run on graphene it's not because of graphene's content it's just a question of whether the attestation is recognised. It's not signed by Google.
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.
It's mostly preventing apps to be botted . As each device has its own certificate and can be banned exclusively, if it's google certified. This certificate( also called keybox/keybox.xml) is stored in the secure enclave in the device.
If you want to dive deeper you can checkout droidguard/play integrity.
A good deal of banking apps will run on it just fine.
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).
For what its worth, all of my local banking and e-government apps work flawlessly on GrapheneOS. The only unsupported feature or app I've found so far is Google Pay. (I'm from Italy)
My banking apps run on it, but my concert ticket app doesn't, so I have a separate phone just for that one app.
They do it to prevent botting . They use play integrity ( i think ex safety net ).
Can concert tickets not be bought in a web browser?
No they can’t. It’s very frustrating.
I had to get my friend to buy them for me when I was on Graphene
Nope. This is eplus in Japan, and if you try go through the website it tells you you have to use the app. It's cos a lot of shows these days don't use paper tickets, but smart tickets on your phone. It is what it is.
What about people who do not have a smartphone?
They don't get to go to concerts in Japan.
Because these apps use google play integrity which only google certified devices pass
Most American banking apps run on Graphene https://privsec.dev/posts/android/banking-applications-compa...
Wells Fargo runs on my Grapheme device.
It also runs on Lineage with Mind The Gapps.
I read from an old HN post that three letter agencies hate graphen OS. The author heard it from defcon or some similar conference. I couldn’t find the post anyway :/ I think it is buried under one of the posts that discuss Defcon and Blackhat.
Wouldn't it be a total mindfuck if it turns out that Graphene is less secure[1] than stock Pixel, and this is all part of an ANOM-style honeypot operation that has Feds hyping it up, to trick interesting targets into adopting a less-effective security posture.
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.
GrapheneOS releases patches very quickly, often even faster than OEMs do. But patches are only useful for fixing individual known vulnerabilities. GrapheneOS additionally focuses on defending against whole classes of vulnerabilities. [1] For example, in addition to fixing memory corruption bugs in individual system components, GrapheneOS has deployed memory protections for the entire OS in the form of hardened_malloc [2] and by enabling the ARM memory tagging extension for the kernel, most system processes (with very few exceptions) and all user-installed apps.
The honeypot theories don't make sense, since GrapheneOS is fully open source, and very transparent about developers, funding, infrastructure, and other internal stuff.
[1] https://grapheneos.org/features#exploit-protection
[2] https://github.com/GrapheneOS/hardened_malloc
> GrapheneOS is fully open source
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.
Firmware is not OS.
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.
An implementation detail where TLAs could theoretically get root remotely? Seems like a bit more than a detail to be glossed over.
Show me any device on earth that can run a browser that has no proprietary code whatsoever (including hardware) on it?
AFAIK older Talos Secure Workstation with Power CPUs was it. Everything open including CPU firmware.
Not sure about smartphones though - they mostly struggle with a fact there are no truly open source baseband.
There is no smartphone fully powered by open firmware. Also keep in mind that the hardware itself is proprietary too.
Reminds me of that one case a few weeks back where Graphene wasn't allowed to release a patch because Google wasn't planning on releasing a patch for it for a few more months.
GrapheneOS has a security preview release channel that is opt-in but includes patches from these embargoed vulns already. Again, it's opt-in but for those with a higher threat model use-case it's nice to have.
Would this not defeat the purpose of responsible disclosure? As a bad actor I could learn of secret vulnerabilities from this channel.
These patches are available to all vendors who chose not to protect their users yet.
Releasing binary patches is allowed, this is why GOS have added the security preview channel.
You have google to blame. GrapheneOS tried very hard to make sure they have those security patches as google delays publishing the source tree and it's only available to OEMs
Those honeypot phones clearly use marketing aimed at criminals and make all sort of false promises and clearly aren't technical and transparent projects like GrapheneOS. GrapheneOS community doesn't tolerate discussion of crime or implying you are a criminal on their official community chat rooms and forum. Doesn't make sense for it to be a project aimed at luring in criminals.
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.
The biggest difference is that the honeypot phones come with their own custom apps all claiming to have completely secure communications. That's their selling point, the set of apps, or even a single one, which they claim is unbreakable. The criminals buying these phones aren't interested in just GrapheneOS on its own. Clearly they don't consider something like Signal secure enough, even if run on GrapheneOS.
Well, if you're implying someone is a criminal because they don't want their phone come with the google buttplug and spyware installed....... I think you have a problem :D
I use graphene not for security but because it doesn't come with any Google surveillance stuff.
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.
>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.
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.
I think their comment is rightly pointing out that if a TLA or other state intelligence actor takes an interest in you specifically, they can do quite a bit of classic spycraft that is considerably more expensive i.e. direct surveillance. No alternative handset OS will protect you from an agent who bugs your house, or someone firing a polonium pellet into your leg from a modified umbrella.
[dead]
Realistic is that some data is impractical to protect and too late to protect if your parents chose a somewhat normal life for you but that is hardly all data.
Even Mr Assange in his embassy could have added fitness trackers to add metrics that were hard and spotty to estimate from video surveillance.
Obligatory https://www.usenix.org/system/files/1401_08-12_mickens.pdf
GrapheneOS is an open source project which was started in 2014 by people with an existing history working on open source projects. It has existed for over 11 years. It resisted a takeover attempt by a company sponsoring it. It's entirely funded by donations with no strong ties to any company, no government grants, etc. We don't accept strings attached funding, only donations. The core people working on the project have all been involved for years.
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.
Anyone can build GrapheneOS from source code, which I doubt is true of any law-enforcement honeypot.
See my footnote in original comment.
GrapheneOS updates really fast, like on a weekly basis. The trouble is that you have to trust the developers in general. Even if you did build it yourself, did you read all the code and scripts used to build it? But I think it's still a net benefit for a certain kind of user to have the code, and it raises the minimum complexity of any potential exploit.
Often faster than weekly around security releases. And that’s on stable.
[dead]
Exactly what someone who sets up a honeypot targeting nerds would want you to think.
You can actually build it. But who has time to audit all that stuff? Then you know, there could be firmware hacks that make all the system-level backdoors a moot point.
Now in grapheneosin the updates settings it allows you to apply Google's upstream security patches, but grapheneos is forbidden from releasing the source code for these until a certain time later. You can read more about it on their blog. I have them enabled. At least I can rest easy knowing the Grapheneos Devs are able to inspect the code on users behalf even if they can't yet release it.
Will Graphene release the patches concurrently with Google? If there's a lag, then then Graphene is a tiny bit less safe in terms of one-day/n-day bugs.
Not having the source of the patch adds some friction to all attackers, but reversing vulnerabilities from binary patches has a long history.
For the security preview channel where they have to withhold the code until it's officially released yes that comes out with/days after Google releases them publicly.
They generally patch much faster than Google.
This occurred to me. If I were the feds and broke some secure app like Signal, I’d keep complaining how the encryption is hurt law enforcement and watch people flock to it.
It wouldn't be the first honeypot phone, haha.
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.
Why spread FUD? Why prove to the world how fucking dumb you are? Graphene is non-profit. It doesn't allow criminal activities at all. It was never made for it. They do real security research and used to report lots of CVEs to google. It's the most cutting edge android security you're gonna see
It physically disables USB ports when locked which significantly reduces the attack surface + can be configured to automatically reboot.
The auto reboot is configured by default. Its quite a long window, every 18 hours or so from memory. It can be configured to be shorter than this.
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.
Alarms work after reboot in the default system Clock app configuration. However, it does not work in all configurations since not everything is properly handled for the Clock app's Direct Boot mode. Google's Clock app works better since it diverged from AOSP Clock years ago. The main thing you'll miss are push notifications since the vast majority of apps do not have Direct Boot support for detecting there are notifications available. We aren't actually aware of any non-Google app supporting it.
Two fixes that would be trivial to backport to mainline Android.
That's definitely not trivial and it's a small fraction of the security features GrapheneOS provides. https://news.ycombinator.com/item?id=45779157 explains several of the relevant features. Using hardware memory tagging for the whole base OS is definitely not trivial, and neither is implementing a much more hardened memory allocator. Our USB protection is not a trivial feature and is much more advanced than the USB protection features available in standard Android via the device admin API and Android 16 Advanced Protection mode.
I never wrote that the other Graphene OS features and mitigations are trivial. I agree that there is much more to that.
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.
Convincing people that the exploit protections are valuable and worth providing as even an opt-in feature let alone an enabled by default one is difficult.
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.
You can configure USB port for charging only in the developer options.
No, that only changes the USB gadget mode. It doesn't disable USB peripheral support, USB protocol handling, etc. in the OS and doesn't disable USB at a hardware level. It doesn't protect against the vast majority of Linux kernel driver exploits heavily used by Cellebrite. They mainly exploit bugs in USB peripheral drivers but could also exploit lower level kernel code or firmware if they had to.
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.
With Grapheneos no need for developer options however. It's in the usual menu in the exploit protections submenus.
That only turns it of on the OS level. GrapheneOS also turns it off on the level of the USB controller.
That standard Android toggle doesn't turn off USB support at the OS level but rather controls the default USB gadget mode. USB gadget functionality is one part of the high level USB functionality. That doesn't block USB peripherals, USB-C alternate modes, etc. and leaves nearly all the kernel attack surface being exploited by Cellebrite intact.
See https://news.ycombinator.com/item?id=45779241 which explains this.
Thanks, I was confusing it with the Advanced Protection feature.
I think that's at the OS level. I think there are things that could be done through the firmware level.
That standard Android toggle doesn't turn off USB support at the OS level but rather controls the default USB gadget mode. USB gadget functionality is one part of the high level USB functionality. That doesn't block USB peripherals, USB-C alternate modes, etc. and leaves nearly all the kernel attack surface being exploited by Cellebrite intact.
See https://news.ycombinator.com/item?id=45779241 which explains this.
Sorry, I had the wrong terminology.
Since no phone on the market has open-source firmware, and the firmware likely has all the capabilities of the base system, I think arguing for a firmware lock on that is kind of pointless. Sure, every little bit of security helps, but ultimately you still need to trust a lot of stuff to use a smartphone or most other modern hardware.
I had the wrong terminology. Your sibling comment explains it better.
On Lineage this is the default behaviour: charging only until I tap on a notification to change it.
That's the standard Android behavior for the USB gadget mode, not something specific to LineageOS, and it does not mean USB is in a charging-only mode but rather than no USB gadget functionality such as file transfer (MTP) is active. It does not mean USB peripherals and USB-C alternate mode are disabled, which certainly work in the default charging-only mode for Android's USB gadget setting. It doesn't even mean that USB gadget mode is fully disabled, only that it's in the MTP mode with MTP disabled. There's a slight difference between the regular and and more advanced setting: MTP mode with MTP disabled vs. no active USB gadget. The USB protection feature on GrapheneOS is for blocking new USB connections as a whole at both a software and hardware level and disabling USB data at a hardware level vs. that setting only controlling USB gadget mode. Most of the attack surface is in the USB protocol implementation and especially the USB peripheral drivers which are not disabled in the default mode Android calls charging-only since it's about USB gadget mode, i.e. using the phone itself as a peripheral.
Got it, that makes sense! Thanks for explaining :)
It is not the same feature as present on GrapheneOS. That is done through the OS while GrapheneOS makes kernel changes to physically shut it down.
iOS already does both of this afaik. At least the automatic reboot part, I think the USB data functionality is disabled in some cases while locked too.
iOS 18.1 added a variant of the locked device auto-reboot feature used by GrapheneOS, but it has a hard-wired 72 hour timer instead of a default 18 hour timer that's configurable between 10 minutes and 72 hours. iOS doesn't have an equivalent to the USB protection functionality in GrapheneOS and it doesn't enable what it does have by default.
iOS lacks configurabiluty for both. USB protection is also less thorough technically.
iOS is also compromised according to other cellebrite docs so that makes me think Graphene OS just might not be worth the effort for them.
iOS was hackable in 2024 for certain hardware (in particular the checkm8 era phones) or for iOS versions which had known vulns at that point. Modern hardware with updates was still listed as “in research” which means “we can’t”.
The last leak was in 2024. Hopefully somone nabs the latest iOS release information
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.
February 2025 documentation was posted by someone in that thread and a blog post was written by someone about it which was linked there. The initial link posted with the February 2025 documentation died and the blog post only focuses on Android and GrapheneOS rather than iOS too.
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.
Any info on recent ban of SafeDot by Android and GOS? Any plans to implement SafeDot as an official GOS app?
Isn't that now a native android function?
A little green dot? No, it's a small fraction of SafeDot functionality. I'm interested in audible notification when camera, mic, or gps is accessed. Currently, I cannot make it work on GOS (maybe, may phone is hacked).
It works properly again after post on HN. :-/
Neither have had any known BFU on the latest iOS for years. AFU is occasionally possible but most of the leaks had latest software and hardware as still protected. Powering off the phone is always still a good idea though if you can.
That's not true. Cellebrite has working BFU and AFU exploits for recent iOS and usually catches up to the latest iOS versions and hardware in weeks or a couple months. They do not have working brute force support for the Pixel 2 / Pixel 6 or later / iPhone 12 or later due to the secure elements but can still exploit the devices in BFU mode and extract the data available before unlocking. iPhone 17 may work out better due to hardware memory tagging but previous iOS and iPhone models did not hold out in the way you're claiming at all.
What data _is_ there to extract BFU, really, if you can't break the secure element? I mean, the main storage isn't decrypted yet, right?
Android and iOS both use filesystem-based disk encryption with fine-grained keys, not only a global encryption key. There's a subset of the OS data available before first unlock to have basic functionality available there. Three examples are installed apps, saved Wi-Fi networks including passwords and alarms with the system clock apps being available before first unlock via explicitly storing it in the before first unlock encrypted data. All of the data and metadata blocks are encrypted, but not all of it is encrypted with keys tied to the user's credentials. Android uses per-profile encryption so it gets security benefits from it too, but both operating systems mainly use it for usability benefits needed to make always on disk encryption suitable for their broad audience. They were able to deploy disk encryption to everyone without complaints partly because they did it this way, so in that sense the before first unlock data has a security benefit.
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.
My mental model of this is “Apple releases new iOS with security patches -> time passes before cellebrite develops an AFU exploit -> Eventually Apple patches the exploit -> go to step 1”. By adding auto reboot Apple ensured that since lots of the time is spent in the stage where the latest iOS has no AFU exploit and AFU becomes BFU before that changes, and thus they are stuck with only extracting whatever is unencrypted at boot time at best. The leaked matrices even for September 2024 had no BFU listed for any remotely recent versions.
Cellebrite and other companies can develop exploits using independent sets of bugs. Cellebrite is also not the only company developing exploits. These companies (or governments) don't have to wait until the bugs they use get patched or mitigated before they develop more exploits. They can also develop exploits against Beta releases of Android and iOS rather than waiting for it to be used by a large audience. That makes it possible for them to develop exploits against newer exploit protections prior to launch unless they're specific to newer hardware that's not released yet. Android has a more open development model and much longer longer beta testing for new major releases which gives them a lot of time to prepare for next generation exploit protections in standard Android. iOS doesn't give them as much time to prepare, but they still have time to prepare before new major releases come out. That's also not taking into account that they can have more than public sources to test with new versions.
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.
Citation needed.
It's a statement directly based on the regularly updated Cellebrite Premium documentation from the past 2 years. At a bare minimum, the April 2024, July 2024 and February 2025 documentation was posted publicly and even that subset shows what's said above. Do you think Cellebrite's documentation isn't accurate or that the leaked documentation was tampered? We aren't posting it publicly ourselves, but we do have a source providing it to us and can compare it over time. Only Pixels and iPhones are successfully stopping brute force but neither is successfully stopping exploiting the OS whether they're BFU or AFU.
No, that's wrong. You're basing your claims on outdated leaks of Cellebrite documentation showing they didn't support the most recent iOS version yet, which they did end up support weeks later. You can't simply point to outdated documentation where they were working on catching up to claim they don't support those versions and devices today, which is in fact untrue.
[dead]
Clearly it's harder but just how much harder is anyone's guess? Surely higher value targets would be more likely to use Graphene, so I would think that would make it just as important to invest resources into.
GrapheneOS provides massive security improvements over Android. You should read https://grapheneos.org/features#exploit-protection for an overview. Cellebrite quite clearly puts substantial effort into targeting GrapheneOS, much more than they do into targeting variants of Google Mobile Services Android across devices. Cellebrite provides much more detailed information and comparisons for GrapheneOS than any other variant of Android. One of the biggest security improvements for exploitation is GrapheneOS using hardware memory tagging (ARM MTE) in the main kernel and userspace allocators for all of the base OS.
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.
This is great information, thank you! Do you happen to know to what extent MTE is used on Android 16 when both Advanced Protection is enabled and when the newly-released "Device Protection" feature is enabled?
The stock OS doesn't use it for any of the kernel or most of userspace. It only uses it for specific processes where they're explicitly enabling it in that mode and apps explicitly opting into it. Nearly no apps are explicitly opting into MTE. On GrapheneOS, we dealt with third party apps by always using MTE with apps opting in, apps with no native code of their own and apps in our compatibility database. For the remaining apps with native code and no MTE opt-in, we have a per-app toggle and a global toggle to change it to opt-out instead of opt-in. We have user-facing MTE crash notifications providing a traceback to report to developers. We plan to significantly expand our compatibility database to always enable it for more apps like Signal but we're being cautious about that due to the potential for apps to ship a memory corruption bug occurring in regular use which not prioritizing fixing it. WhatsApp is an example of a widely used app which mostly works with our MTE integration but sometimes crashes in regular use and Facebook hasn't taken the issue seriously despite MTE not having any false positives.