Source? It doesn’t make sense that it’s settings dependent.
It could conceivably be affected by Lockdown Mode on iOS for example. We don’t have the full slides here so I don’t know for sure, but from what I’ve heard at least some of the (1), (3), etc. footnote indicators in the chart refer to notes that the attack is time-sensitive.
This likely refers to iOS switching to USB Restricted Mode after 1 hour of being locked. I believe Lockdown Mode would decrease that timeout to 0.
There are no footnotes for the iPhone 12 and later on the latest iOS versions. They would probably look like clowns if they claimed that they could extract the data and, after being asked for assistance, said that they couldn’t because of Lockdown Mode.
At this point, I’m just assuming that they’re working on different ways of exploiting these devices. Both GrapheneOS and iOS have strong USB protections, so these companies are forced to adapt.
They would get access to basically everything apart from the /data partition. But the thing is that GrapheneOS will have an optional toggle to use the Owner primary lock method as a boot passphrase, so Cellebrite is cooked on that front too.
Here’s the Cellebrite Premium 7.69.5 iOS Support Matrix from July 2024.
404media recently published an article based on the same April 2024 docs we received in April and published in May. Many tech news sites including 9to5Mac made incorrect assumptions treating that as current.
Here’s the Cellebrite Premium 7.69.5 Android Support Matrix from July 2024 for Pixels. They’re still unable to exploit locked GrapheneOS devices unless they’re missing patches from 2022. A locked GrapheneOS device also automatically gets back to BFU from AFU after 18h by default.
GrapheneOS is defending against these tools with generic exploit protections rather than by patching specific vulnerabilities. Until recently, it’s likely that it was our generic memory corruption exploit mitigations including hardened_malloc which was successfully stopping this.
In February 2024, we added a new feature for disabling the USB-C port at a hardware level. In March 2024, we set the default mode to “Charging-only when locked, except before first unlock”. In June 2024, we increased the default security level to “Charging-only when locked”.
Later in June 2024, we extended our software-level USB protection, merged it into the newer hardware-level protection feature and extended the hardware-level protection to pogo pins on the Pixel Tablet. There’s extremely strong protection against these USB-based attacks now.
Here’s the Cellebrite Premium 7.69.5 Android Support Matrix from July 2024 for overall Android devices. Other than the Titan M2 on the Pixel 6 and later not being successfully yet to bypass brute force protection, it’s largely just based on what they’ve had time to support.
In January 2024, we reported several vulnerabilities being exploited by the XRY tool from MSAB to get data from Android devices including stock OS Pixels. In April 2024, Pixels shipped a reset attack mitigation we proposed preventing the whole attack vector. We plan to expand it.
Currently, non-Pixel devices are still vulnerable to these reset attacks. In June 2024, Android 14 QPR3 included another feature we proposed providing wipe-without-reboot support for the device admin wipe API. We shipped this early and use it in our duress PIN/password feature.
We also began triggering a full compacting garbage collection cycle in system_server and SystemUI when the device is locked based on info about these attacks. This releases memory for no longer allocated objects to the OS, where our generic zero-on-free feature clears all of it.
In the near future, we plan to ship support for adding a PIN as a 2nd factor to fingerprint unlock to enable users to use a strong passphrase combined with PIN+fingerprint secondary unlock for convenience. We have an initial implementation, but it needs more work before shipping.
We’re going to continue advancing the state of the art for protection against exploitation. Hardware vendors are welcome to collaborate with us if they want to protect users. We’re regularly filing vulnerability reports and making suggestions to improve the security of Pixels.
4 Likes
It’s interesting to see that they barely have any exploits for the iPads. Probably because they prioritize phones.
1 Like
Lockdown mode is a problem. Apparently access to control panel is also a requirement for AFU iOS acquisition.
Full Cellebrite manuals, enjoy
3 Likes
May 2021, and I think it is public info as I found 2023 manual by just searching online.
GOS admin says AFU or FFS means they exploit the OS and extract all the data unencrypted without needing to know the device lock method.
Got it! Thank you for clarifying this.
Not quite. AFU and FFS are two different things. FFS refers to extraction of the files from an unlocked device.
BF refers to the ability to actually find the unlock password via brute force.
Source is the exact link you posted. Following section (notice keyword unlocked):
Glossary:
BFU: Before First Unlock exploitation of OS
BF: Brute Force password after BFU exploitation, which requires bypassing secure element brute force protection if implemented
AFU: After First Unlock exploitation of OS
FFS: Full Filesystem Extraction from an unlocked device
2 Likes
read the linked comment
BFU refers to exploiting a device Before First Unlock. BF refers to whether they can brute force lock methods after BFU exploits., which they cannot for Pixel 6 or later / iPhone 12 or later due to the more hardened secure elements. AFU refers to exploiting a device After First Unlock, which obtains access to nearly all the data.
Does Samsung Autoblock feature protect from Cellebrite?
No.