https://x.com/josephfcox/status/1858883894050754795
We have a good idea of what’s happening here based on the detailed info we obtained about MSAB’s XRY exploit tool. We reported those exploits to Google in January 2024 with multiple proposals on how to stop it. April 2024 is when the first 2 shipped.
Our thread on the April 2024 Pixel patches for 2 of the issues we reported is here:
https://x.com/GrapheneOS/status/1775305179581018286
XRY was exploiting littlekernel-based fastboot mode firmware used on Pixels via USB. Many other devices also use littlekernel for this, or the higher attack surface EDK2.
CVE-2024-29745 is the identifier for the reset attack vulnerability we reported in fastboot mode. Google addressed this in April 2024 by implementing our proposal of zeroing memory on boot. This explains why Graykey was downgraded was Full access to Partial access in April 2024.
Cellebrite Premium is clearly exploiting the stock Pixel OS via USB rather than using this approach. Therefore, Cellebrite didn’t lose any capabilities because of the improvement. Our exploit protections have been successfully blocking them even before major improvements in 2024.
Data is divided in 2 parts: vast majority of data is Credential Encrypted (CE) per-profile and a small portion of OS data is Device Encrypted (DE). DE data is available to the OS Before First Unlock (BFU). Exploiting fastboot mode will only give DE data since April 2024.
One of our planned features is a boot authentication toggle to request the Owner lock method in early boot. This will protect the small amount of DE data such as installed packages and saved Wi-Fi networks from firmware/hardware exploits. However, it’s not sensitive user data.
Cellebrite’s approach of exploiting the OS itself is more difficult but they avoided having nearly all their capabilities wiped out by the reset attack mitigation we successfully got Pixels to implement. Other Android devices haven’t implemented reset attack mitigation though.
The way Google implemented it only covers fastboot mode. We wanted them to cover the OS boot modes too but they haven’t shipped it yet. Our zero-on-free feature addresses it for OS reboot/shutdown and we plan to add zero on boot too until we convince them to add it in firmware.
Cellebrite’s approach involves attacking the OS itself so all of our generic memory corruption exploit protections and other defenses are there to stop it. We also nearly fully wiped out the USB attack vector for the OS with our 2024 overhaul of our USB attack surface reduction.
By default, GrapheneOS disables new USB-C connections as soon as the device is locked at both a hardware and software level. It then fully disables USB-C data at a hardware level once existing connections end or right away if there weren’t any. They’d need another attack vector.
For example, they could still target GrapheneOS via Wi-Fi, Bluetooth or cellular. However, getting into the device from any of those will still be much harder than with the stock OS, and it’s more complex than USB in general. There’s a reason they have always preferred USB.
Since 2021, we’ve had an auto-reboot timer feature which reboots the device after it’s locked if it isn’t unlocked before the timer expires. iOS recently added this with a hard-wired 72 hour timer. Our default is 18 hours but users can configure it from 10 minutes to 72 hours.
If you need max protection, using the 10 minute auto-reboot would be ideal. There’s also the option to fully disabling USB-C while OS is booted by also disabling charging including USB-PD. Can also enable turning off Wi-Fi and Bluetooth via timers, which we plan to extend to NFC.