Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

arstechnica.com

Post reply on HN
Print view View original

341–350 of 372 posts

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#341

Post by fragmede »

rollcat wrote: post #227
MYEUHD wrote: post #212

Earlier quoted context omitted.

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

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#342

Post by oddmiral »

oddmiral wrote: post #334
int0x29 wrote: post #323

Earlier quoted context omitted.

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

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#343

Post by chopin »

russianGuy83829 wrote: post #40
fluidcruft wrote: post #8

Earlier quoted context omitted.

Is there anything actually preventing Samsung or another vendor from adopting GrapheneOS's security innovations?

GrapheneOS is seemingly working with an OEM to make a GrapheneOS smartphone. Its probably not samsung, but would still be an established vendor

I'd love this for a Fairphone.

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#344

Post by strcat »

whitepoplar wrote: post #320
strcat wrote: post #144

Earlier quoted context omitted.

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 va…

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.

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#345

Post by strcat »

commandersaki wrote: post #197
strcat wrote: post #158

Earlier quoted context omitted.

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…

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.

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#346

Post by strcat »

Sesse__ wrote: post #223
strcat wrote: post #158

Earlier quoted context omitted.

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…

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.

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#347

Post by saagarjha »

Sanzig wrote: post #252
saagarjha wrote: post #218

Earlier quoted context omitted.

No, it's just that the user will not put up with a system like GrapheneOS.

How so? Graphene is perfectly useable for a non-technical user. And once you install Play Store, it's almost indistinguishable UX-wise from any other Android phone.

If you look around this thread you will find plenty of people explaining what doesn’t work for them. Of course the GrapheneOS people will explain that this is actually the fault of the banks or the apps or whatever and I would probably agree, but that still makes it hard to recommend to casual users.

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#348

Post by saagarjha »

udev4096 wrote: post #297
saagarjha wrote: post #218

Earlier quoted context omitted.

No, it's just that the user will not put up with a system like GrapheneOS.

Put up what exactly? You think privacy and security is readily available to everyone who just desires so? If by "put up", you mean not even putting normal efforts, then sure. That user, along with you, fully deserves to get tracked, profiled and fingerprinted to the maximum extent of mass surveillance

> You think privacy and security is readily available to everyone who just desires so?

No, I but I would like to make it so. I find your view that people “deserve” privacy to be incredibly depressing and antithetical to the spirit of user empowerment.

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#349

Post by saagarjha »

udev4096 wrote: post #298
Sanzig wrote: post #252

Earlier quoted context omitted.

How so? Graphene is perfectly useable for a non-technical user. And once you install Play Store, it's almost indistinguishable UX-wise from any other Android phone.

He's a fucking ignorant normie. He has never even tried to install GOS because if he did, he would know how almost identical the experience is with Android and there are no privileged google processes running on your phone which not only hog the resources but sends every single bit of information about your whole life

I have tried installing it, for your information

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#350

Post by strcat »

ls612 wrote: post #275
strcat wrote: post #158

Earlier quoted context omitted.

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…

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 unencryp…

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.

Post reply on HN