Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

It’s still a valid question. We have this huge corporation that’s doing so many things, constantly lobbying for policy, obscene revenue all while people are exploiting the apk out of their OS.

In fact, looking at the news this week, the same question applies to Microsoft and Apple as well. Are they too big and distracted to care about security?

Are you affiliated with the project? I see all your posts are about Graphene OS. On HN it is customary to state it: you often see "author here" in discussions where the author joins. If you are part of the team I would suggest against using the third person ("they have a team...").

I know strcat is the lead Graphene OS developer, and it seems you and Andromxda are very knowledgeable about the project and very active on this thread.

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

https://grapheneos.org/features

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.

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.

Not really.

iOS in lockdown mode has multiple features disabled (or crippled, depending on how you look at it), while GrapheneOS is just..... secure by design with secure defaults.

https://support.apple.com/en-us/105120

In iPhone also you cannot just turn on/off/adjust these protections one by one, it's all or nothing.

Google Wallet works but tap-to-pay NFC payments don't because Google enforces strong Play Integrity for that portion. They only allow Google certified OSes to use it. It's a sad choice on their part, not GrapheneOS' fault or choice.

Which particular thing you consider inconvenient or even annoying? You can even install Google Play there.

I see just one minor tradeoff - no face unlock.

[dead]

No American company has a choice when the Feds want data stored on a company's server.

That doesn't stop Apple or any other company from designing devices that attempt to keep prying eyes out of the data stored on your device.

Let's be very clear: this is still Google's choice. Google could build a phone that they can't be compelled to do anything to after the phone is sold to their customer, but Google alone chooses to not invest in the security of the phones they're selling to their customers. Because: what is good for the government is now equally good for Google.

Do we not remember how Google immediately enabled TLS everywhere, internally, post-Snowden [0]? Remember when Google was "outraged"? Where are those people now? They surely don't work at Google anymore. It's amazing how enshittified Google and Apple have become in a decade.

[0] https://www.bbc.com/news/world-us-canada-24751821

google even has specially signed fw that let you root the device and unlock anything that doesn't rely on the passcode. secureboot passing and all. i can't imagine that the nsa doesnt have them. after that you just gotta crack the usually very simple passcode. wouldny be surprised if thats what cellrite has lol.

In France it is indeed a popular expression that means 'stolen' or 'acquired by non-disclosable means'

Yep: https://en.wiktionary.org/wiki/fall_off_the_back_of_a_truck

I'm not disputing that. :)

It's a possibility. Graphene has some traction though and if a potential high-importance target is running the OS, Cellebrite wouldn't want to be doing emergency vulnerability research to respond.

Perhaps there is an argument to be made that this is a reason "computer security" should not be delegated to a third party, such as an advertising services company like the ones in Silicon Valley, Redmond or Seattle

The reasoning is that the company, being concerned with online advertising and reach,^1 has the incentive to ensure that the software becomes popular with the largest possible number of users, perhaps even achieving monopoly power. According to traditional HN commentary, this makes the company and its software a preferred target for exploits by virtue of its popularity

1. Online surveillance practices to potentially support targeted advertising services, where the companies wantonly collect enormous quantities of data about millions of people, also makes them a target for exploits, e.g., "data breaches"

Consider an alternative status quo where computer owners, i.e., software users, have many options to choose from, including many operating systems, browsers, "app stores", "platforms", and so on

None of the options may be necessarily better choices for "security" for technical reasons^2 but the fact that those who target software from a small number of advertising services juggernauts with millions of users ("lucrative targets") are denied access to such lucrative targets, because the lucrative targets do not exist, is an improvement to "security" overall

2. But some may compete and attempt to distinguish themselves on this basis

In this alternative status quo there would likely be requirements that software be compliant with open standards and interoperable, allowing computer users to write, edit, compile, install and choose whatever software they desire, from any source, including their own brain, i.e., they might choose to write, compile and install their own software on their own computers

Maybe with a standardised size suitable for the thin phones we use nowadays, and to make the wires usable in any orientation they can also have one axis of symmetry, maybe along it's primary axis?

...with the Google software.

US is the same. I dialed 911 once as a child from an American phone in Indonesia without a SIM card in it. Freaked out and hung up.

Is it E911 or an A-GPS issue?

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

Willingness to pay great developers and engineers to build secure hardware,

understanding sec,

them observing actual demand for security.

History says don't hold your breath.

We get lucky once in a while, like with Google's hardware (without their software).

The hardware Samsung provides is not up to spec.

Probably their legal obligation to comply with secret government orders (FISA, NSL etc - the government probably already said don't make unhackable phones or else) and their informal wish to remain on the regime's good side.

https://grapheneos.org/features#duress :D

Cooperation under duress is still cooperation.

this is actually not the case on modern android lol

[dead]