Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

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

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?

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.