Most active commenters
  • ls612(4)
  • int0x29(3)
  • strcat(3)
  • oddmiral(3)

←back to thread

Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

(arstechnica.com)
452 points akyuu | 13 comments | 30 Oct 25 23:12 UTC | HN request time: 0.002s | source | bottom
Show context
derbOac ◴[30 Oct 25 23:39 UTC] No.45766747[source]▶
They couldn't answer the question most on my mind: "We’ve reached out to Google to inquire about why a custom ROM created by volunteers is more resistant to industrial phone hacking than the official Pixel OS. We’ll update this article if Google has anything to say."
replies(10): >>45766778 #>>45777056 #>>45778032 #>>45778056 #>>45779079 #>>45779102 #>>45779404 #>>45780503 #>>45781099 #>>45783125 #
IncreasePosts ◴[31 Oct 25 21:45 UTC] No.45777056[source]▶
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?
replies(5): >>45777082 #>>45777144 #>>45777155 #>>45779084 #>>45779157 #
zb3 ◴[31 Oct 25 21:56 UTC] No.45777144[source]▶
It physically disables USB ports when locked which significantly reduces the attack surface + can be configured to automatically reboot.
replies(2): >>45777712 #>>45778612 #
fph ◴[31 Oct 25 23:08 UTC] No.45777712[source]▶
Two fixes that would be trivial to backport to mainline Android.
replies(3): >>45777832 #>>45777836 #>>45779218 #
ls612 ◴[31 Oct 25 23:27 UTC] No.45777836[source]▶
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.
replies(4): >>45777949 #>>45779169 #>>45779282 #>>45780058 #
int0x29 ◴[31 Oct 25 23:46 UTC] No.45777949[source]▶
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.
replies(1): >>45777984 #
1. ls612 ◴[31 Oct 25 23:52 UTC] No.45777984[source]▶
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”.
replies(2): >>45778484 #>>45779287 #
2. int0x29 ◴[01 Nov 25 01:21 UTC] No.45778484[source]▶
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.

replies(2): >>45778666 #>>45779351 #
3. ls612 ◴[01 Nov 25 01:59 UTC] No.45778666[source]▶
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.
replies(1): >>45779294 #
4. strcat ◴[01 Nov 25 04:37 UTC] No.45779287[source]▶
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.
5. strcat ◴[01 Nov 25 04:39 UTC] No.45779294{3}[source]▶
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.
replies(3): >>45780251 #>>45780896 #>>45782249 #
6. strcat ◴[01 Nov 25 04:54 UTC] No.45779351[source]▶
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.

replies(1): >>45785334 #
7. commandersaki ◴[01 Nov 25 09:06 UTC] No.45780251{4}[source]▶
Citation needed.
8. Sesse__ ◴[01 Nov 25 11:40 UTC] No.45780896{4}[source]▶
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?
9. ls612 ◴[01 Nov 25 15:10 UTC] No.45782249{4}[source]▶
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.
10. oddmiral ◴[01 Nov 25 21:04 UTC] No.45785334{3}[source]▶
Any info on recent ban of SafeDot by Android and GOS? Any plans to implement SafeDot as an official GOS app?
replies(1): >>45785485 #
11. int0x29 ◴[01 Nov 25 21:19 UTC] No.45785485{4}[source]▶
Isn't that now a native android function?
replies(1): >>45786385 #
12. oddmiral ◴[01 Nov 25 23:18 UTC] No.45786385{5}[source]▶
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).
replies(1): >>45788515 #
13. oddmiral ◴[02 Nov 25 07:31 UTC] No.45788515{6}[source]▶
It works properly again after post on HN. :-/