On November 19th, 404Media published a news article with the device support chart for Magnet Forensics GrayKey, a forensic device extraction kit used exclusively by governments and a competitor of Cellebrite's UFED and MSAB XRY. The article contains data on the devices supported by GrayKey and the best extraction type available for the device based on monthly Security Patch Level. The results available from the charts are the same as our expectations made from our insights with other forensic company activities and people who inform us of their capabilities. We also are seeing a domino effect of further publications of leaked capabilities from forensic firms after our publication of the April and July 2024 Cellebrite device support matrix.

From what you can see in the GrayKey documentation, our previous disclosure of vulnerabilities affecting Stock OS Pixel devices that were exploited by forensics firms such as MSAB in the start of the year have disrupted their capabilities. We reported those exploits to Google in January 2024 with multiple proposals on how to stop it. In April 2024, the first two patches for these vulnerabilities were shipped and we can see that since April 2024 the extraction capability for GrayKey on all Pixel devices they supported were downgraded.

We have a good idea of what was happening based on the detailed info we obtained about MSAB's XRY exploit tool. 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 for the fastboot mode. Google addressed this in April 2024 by implementing our proposal of zeroing memory on boot. Graykey was downgraded from Full access to Partial access in April 2024 and has stayed that way since.

Cellebrite Premium is clearly exploiting the stock Pixel OS via USB rather than using this approach. Therefore, Cellebrite didn't lose any capabilities on the Stock OS because of the improvement - however they lost brute force capability. Our exploit protections have been successfully blocking Cellebrite even before major improvements in 2024 and GrapheneOS is still unaffected by their tools.

The device's data is divided in 2 parts: The 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.

Partial access means limited access to operating system metadata and the Device Encrypted data and we are not concerned over such a limited data scope.

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. USB is preferred because it provides little tampering with the OS and maintains forensic soundness.

At this current point in time Cellebrite is certainly the industry leader when it comes to Pixel research. Their research teams follow the same trends and innovations and want to research attacks for security technologies we desire or have inherited on our platforms when they have become available, such as MTE and PAC. A GrapheneOS extraction capability of any kind is high-demand for any company in the forensics industry and they appear dedicated to want to be first which makes sense as they are certainly the largest. We will continue providing commensurate response to any new threats.

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 maximum 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. You can also enable turning off Wi-Fi and Bluetooth via timers, which we plan to extend to NFC. You should also get any of the 4 currently available 9th gen Pixels to use GrapheneOS. They have more cellular radio hardening and GrapheneOS-specific kernel hardening implemented right now, but 8th gen is likely going to upgrade to the same 6.1 kernel branch soon.

We strongly recommend 8th/9th gen Pixels for greatly improved security on GrapheneOS via hardware memory tagging. It's enabled for the base OS including apps by default and opt-in for user installed apps, whcih we recommend, and then opt-out per app for apps with bugs it catches.