Hacker News Reader

Comment by ls612 | Hacker News Reader

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

View on HN

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.

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.

I think the biggest deal with phone security is extracting E2E messages & data or local files on the phone, since most other things the government can subpoena from the service providers if they can't hack the phone. Does doing that require FFS, BF, or AFU capability?

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.

Thanks! So you will indeed get a small amount of data, but nearly nothing tied to a specific user profile.

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.

Reply on news.ycombinator.com