Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

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?

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.

It physically disables USB ports when locked which significantly reduces the attack surface + can be configured to automatically reboot.

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.

Two fixes that would be trivial to backport to mainline Android.

You can configure USB port for charging only in the developer options.

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.

On Lineage this is the default behaviour: charging only until I tap on a notification to change it.

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”.

I think that's at the OS level. I think there are things that could be done through the firmware level.

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.

Anyone can build GrapheneOS from source code, which I doubt is true of any law-enforcement honeypot.

Exactly what someone who sets up a honeypot targeting nerds would want you to think.

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.

See my footnote in original comment.

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.

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.

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.

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.

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.

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.

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.

That only turns it of on the OS level. GrapheneOS also turns it off on the level of the USB controller.

All of the listed features significantly raise the bar for exploitation ;

https://grapheneos.org/features

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.

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.

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.

iOS lacks configurabiluty for both. USB protection is also less thorough technically.

Often faster than weekly around security releases. And that’s on stable.

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.

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.

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.

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.

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.

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.

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.

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.

Thanks, I was confusing it with the Advanced Protection feature.

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.

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.

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.

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.

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

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.

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.

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.

They generally patch much faster than Google.

Citation needed.

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.

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?

> 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.

My banking apps run on it, but my concert ticket app doesn't, so I have a separate phone just for that one app.

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.

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?

> 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.

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.

Most American banking apps run on Graphene https://privsec.dev/posts/android/banking-applications-compa...

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).

Show me any device on earth that can run a browser that has no proprietary code whatsoever (including hardware) on it?

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.

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.

With Grapheneos no need for developer options however. It's in the usual menu in the exploit protections submenus.

Sorry, I had the wrong terminology.

I had the wrong terminology. Your sibling comment explains it better.

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)

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.

Wells Fargo runs on my Grapheme device.

It also runs on Lineage with Mind The Gapps.

Can concert tickets not be bought in a web browser?

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.

No they can’t. It’s very frustrating.

I had to get my friend to buy them for me when I was on Graphene

There is no smartphone fully powered by open firmware. Also keep in mind that the hardware itself is proprietary too.

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.

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.

>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.

Would this not defeat the purpose of responsible disclosure? As a bad actor I could learn of secret vulnerabilities from this channel.

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.

Obligatory https://www.usenix.org/system/files/1401_08-12_mickens.pdf

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

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

That also sounds like a nonstarter for a lot of kiosk and embedded use cases

What about people who do not have a smartphone?

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?

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?

Because these apps use google play integrity which only google certified devices pass

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.

They do it to prevent botting . They use play integrity ( i think ex safety net ).

Okay? Then switch that off? :)

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.

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

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).

Got it, that makes sense! Thanks for explaining :)

They don't get to go to concerts in Japan.

An implementation detail where TLAs could theoretically get root remotely? Seems like a bit more than a detail to be glossed over.

It works properly again after post on HN. :-/