Cellebrite Premium July 2024 documentation

stopthefeds

FFS refers to extracting data when they have the PIN/password to unlock it already. Having an unlocked device doesn't mean you can extract all of the data from it. Their tool requires unlocking, enabling developer options (requires authentication), enabling ADB, authorizing ADB access from their tool and then uses unintended functionality in ADB to extract all of the data. FFS is their baseline capability which generally works everywhere as long as the user doesn't have a device admin app disabling ADB. They could far more easily exploit the OS after unlocking it but those aren't the kinds of exploits done by the Cellebrite Premium tool and would require something else.

BF refers to brute force attacks after they've exploited the devices, which implies also exploiting the secure element on devices providing throttling with one.

stopthefeds AFU means they can exploit the device in AFU and obtain nearly all the data from it even without the BF capability. They have a capability not listed in this table called IPR which was listed for previous versions of the table which enables them to obtain the PIN/password for iOS when they have the AFU capability. It's possible they support this on each version with AFU support now so they stopped listing it. The details of IPR are unclear and it seems it only works when the memory hasn't been reused for something else. It's definitely not supposed to be possible but iOS was or still is making a mistake enabling it. It may be fixed by now.

stopthefeds It's back at rest in terms of the disk encryption. However, data can persist in memory in parts of the kernel, SystemUI, system_server and other system-wide software such as driver services. Our zero-on-free implementation in the kernel and userspace helps clear data as soon as possible but it won't clear something that's not released. @ryrona mentioned the in-memory log buffer which is one example. No sensitive data is supposed to be logged there but not all apps will respect that and the interpretation of what that means varies throughout the OS and apps. It's not the only example, just one of them. If you want to get back to a clean BFU state, you inherently need to reboot.

Zw10704 GrapheneOS is clearly doing better than iOS for this as shown by the data above and other information. Why would we recommend an OS being consistently successfully exploited over GrapheneOS which is consistently resisting it? Look at the information in the thread.

Zw10704 Knox isn't a specific technical thing but rather Samsung's branding for a bunch of standard security features and a small number of low impact Samsung-specific features. Pixels have much better overall hardware, firmware and software security than Samsung devices along with supporting using GrapheneOS for a massive upgrade to privacy and security. Despite us not making the hardware, GrapheneOS uses hardware-based security features not used by either Galaxy or Pixel devices in addition to all the standard hardware-based security features used by the stock Pixel OS. Examples are hardware memory tagging in hardened_malloc and Vanadium for detecting memory corruption in production instead of only for development, pointer authentication codes in userspace rather than only the kernel, branch target identification throughout the kernel and userspace to cover what type-based CFI doesn't, hardware-based USB-C port control, etc. These examples show how GrapheneOS is not only a software-based security project but is also leveraging hardware security much more. Recommend reading through https://grapheneos.org/features, just bear in mind some recent features like 2-factor fingerprint unlock aren't included there yet and the amount of coverage on the page is not directly connected to the importance/impact.