Leaker Reveals Which Pixels Are Vulnerable to Cellebrite Phone Hacking

Cellebrite is like the Kmart Blue Light Special of Israeli spyware, when you compare it to Greykey and NSO Group offerings. I would not use their capabilities as the be-all end-all.

Lots more devices are safe BFU than just Apple's. It's not that complicated on a technical level - it's basically full-disk encryption.

Apple sells the illusion of security and privacy, but they're not meaningfully more secure or private except from the device's owner. Remember when they made a big deal of blocking Facebook tracking, while simultaneously adding their own intrusive tracking?

“Siri, whose phone is this” doesn’t work on recent iOS versions. You could ask it to reboot, but that requires confirmation

>Last cellebrite leak showed they couldn’t do anything in BFU, and you can tell Siri to put it back in BFU without hands while being arrested.

Source? Note that "disables faceid/fingerprint" isn't the same as "BFU".

BFU = Before First Unlock after power on or reboot.

In this state, a significant portion of the data on the device remains encrypted and inaccessible, unlike the "After First Unlock" (AFU) state, where the necessary encryption keys are available.

I’ll be asking Anwar down at the bodega to start carrying jugs of unhackable from now on! I want to try the new razzle dazzle berry and 4D cool ranch if he can get them…

You mean the same Eric Schmidt who admitted that he used a BlackBerry for years after Android was released?

> the founders and Eric Schmidt

Still have huge influence as demonstrated by them stepping in to lead parts of the AI push. Ezra Klein actually has an interesting perspective that the owner class of Silicon Valley has moved right a lot more and the workers are still the same politically causing companies to behave differently. My experience in Tech largely tracks. I would say the middle management and manager class are largely good people and try to navigate the world as best they can although they will choose to not rock the boat whenever possible. The tolerance for activism has just evaporated so we don't hear as much about it anymore.

I think this is a very negative idea to promote: that laws should can be subverted. Everyone should believe that laws work and when they don't we should work to fix that, not assume that it can never be fixed.

The government certainly objected when Apple designed an implementation of encrypted cloud backups for iDevices.

That didn't stop Apple from eventually rolling out encrypted cloud backups anyway.

Apple also refused to insert a backdoor into iDevices when James Comey ordered them to do so. They took the FBI to court and forced them to back down.

Google is perfectly capable of fighting too, but their business model puts them at a huge disadvantage.

If you make your money spying on users to make ad sales more profitable, then you have no choice but to hand it over to any Federal, State or local agency that can convince a judge to issue a warrant.

>The government does what it wants because it's the government. Mere laws generally don't stand in its way for long.

Sounds an awful lot like terrorists.

Well then why hasn’t the government “discovered” CSAM on apple executives’ computers? We know that at least last year iOS users who had reasonably modern hardware and kept up with software updates were very difficult to hack on par with Graphene, and last fall Apple introduced automatic reboots in iOS 18.1 which closed a lot of “wait for AFU exploit” paths off.

Who is "the government" here? There isn't a single "the government" in the US.

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

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.

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.

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.

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.

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

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.

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.

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.

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

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

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.

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

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

Wells Fargo runs on my Grapheme device.

It also runs on Lineage with Mind The Gapps.

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)

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

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.

That's not the reasoning. The reasoning is lack of proper hardware support on supported devices for secure face unlock.

Coerced unlocking also holds true for fingerprint in some instances and that's worked around by using 2FA (fingerprint + password/PIN).

> stuff that's been removed as a "feature" isn't always stuff that nobody wants.

Graphene isn't made to cater to what everyone wants. Face ID and fingerprint unlocking so clearly have no place in a hardened OS. "Google OS-level integration is absent" should not be suprising.

This said, you ought to be able to have BFU security with stock Android and it's embarrassing Google ships stock vulnerable.

Is it really missing Chromecast? I read that it works if you have Play services (but haven't tried)

I have no idea what you're talking about. Graphene is my daily driver. "Manual configuration" does not ring any bells. Google OS-level integration being "absent" is a core feature, not an annoyance.

The problem with Graphene is that some app publishers are absolute asshats, they think their app is "more secure" when they require the Google verification spiel, when it is the other way around.

That's because the OS integration is priviliged and that's problematic. On GrapheneOS Play runs sandboxed, like any other user-installed app.