flighty_sloth Their documentation says they can exploit all major Android OEM devices both BFU and AFU. If they're BFU, data in profiles is at rest and they need to brute force to obtain it. It says they cannot do a brute force on the Pixel 6 and later but can on all the other listed brands, since they apparently haven't been able to exploit the Titan M2 even for older versions. Their documentation also states they cannot exploit GrapheneOS either BFU or AFU except devices with a patch level earlier than late 2022. This documentation is listing capabilities rather than explaining why anything is the way it is, so we don't know that. We don't have any reason to think they're either exaggerating or understating their capabilities in these official docs.
Being able to brute force only means they can brute force at the rate the device is able to do key derivation unless they have a way to extract the hardware bound key or this part of it wasn't properly implemented. Pixel 3 and later added time-based throttling based on the secure element, which Cellebrite apparently hasn't been able to defeat for the Pixel 6 and later even for older releases.
We don't know much about what other forensic companies can do or what governments have developed themselves, but we have access to Cellebrite's official list of capabilities for law enforcement, governments, etc. as of April 2024. It indicates to us that we were much more successful than we expected at defeating their attacks even before our recent focus on it since around January after we found out about the MSAB/XRY use of a fastboot mode firmware vulnerability.
Fastboot mode attack surface for recovering data from the OS in AFU mode was eliminated in the April security update due to us reporting it being exploited in the wild with a proposal on how to prevent doing it. Ideally, memory would be encrypted with a per-boot key in the SoC both to greatly raise the bar for extracting data from it and so that it gets purged on reboot by simply rotating a key instead of having to actively wipe it. We hear some other companies were using this too. We did not receive any info which would indicate that they were able to use this attack method against GrapheneOS, but we were very concerned about that possibility which is why we pushed hard to get it addressed in the firmware instead of depending on attempting to work around it in the OS or depending on our auto-reboot feature.
