A deep dive into Cellebrite: Android support as of February 2025

16 March 2025 - Advocacy

In the previous blog post, we summarized part of the Cellebrite product history, and grasped some insights on the market of surveillance software and equipment aimed at mobile forensics. In this blog post, we will explore the current unlocking capabilities, as per their February 2025 documentation distributed to customers. We’ll also introduce some concepts and terminology, and hint at basic mitigations, though proper follow up will come in subsequent posts.

For a very detailed and insightful write-up to help understand Android encryption, read “Android Data Encryption in depth” by Quarkslab or watch the their RECON23 talk.

Glossary #

To understand the following content, it is useful to recap some of the terminology generally used in the field:

  • Cold: Powered off device, with content likely to be encrypted at rest.
  • Warm/Hot: Powered on device, likely in AFU state or unlocked.
  • File Based Encryption (FBE): A method of encrypting individual files rather than the entire disk, allowing different encryption keys for different files based on user authentication and device state.
  • Full Disk Encryption (FDE): A method of encrypting the entire storage of a device requiring the PIN or passphrase to decrypt upon boot. Used mostly before Android 7, deprecated from Android 13 onwards.
  • After First Unlock (AFU): A powered-on device that has been unlocked at least once after boot.
  • Before First Unlock (BFU): A powered-off device or a powered-on device that has not been unlocked since boot.
  • Trusted Execution Environment (TEE): A secure, isolated environment within a processor that handles cryptographic operations and protects sensitive data from the main operating system. If no secure element is present, it is the main security context.
  • Secure Element (SE/eSE/iSE): A hardware security chip, supported from Android 9 onwards, that implements cryptographic operations and key storage in a dedicated hardware component, such as the Titan chip. It is complementary to the TEE and not a requirement to run android or FBE.
  • Keystore: A system service in Android that provides a secure way to store and manage cryptographic keys. It ensures keys are not accessible to user-space applications and can only be used in secure operations, such as encryption, decryption, and signing. Keystore supports hardware-backed security when available.
  • Keymaster: A lower-level component that works with Keystore, handling cryptographic operations within a Trusted Execution Environment (TEE) or secure element module (e.g., Titan M/Titan M2).
  • Secure Startup: A feature on Samsung Knox devices using FDE that encrypts the main key with the user PIN or password. If not enabled, user credentials are not actually required to decrypt the data.
  • Credential Encrypted (CE) Storage: A type of encrypted storage that is only accessible after the user authenticates, ensuring sensitive data is protected until the device is unlocked.
  • Device Encrypted (DE) Storage: A form of encryption that protects data even before the user logs in, but is accessible after boot without requiring user authentication. It is generally used for system-critical files.
  • Full File System Extraction (FFS): A technique used to obtain a complete copy of a device’s file system, after operating system decryption. Analysis could also allow the retrieval of deleted files.
  • Brute Force (BF): Brute forcing PINs and password varies a lot depending on software and hardware implementations. The worst case is the extraction of encrypted keys and offline bruteforcing. Other cases include bypassing throttling on the TEE or secure elements for online bruteforcing.
  • Security Patch Level (SPL): Indicates the date or version of the latest security updates applied to a device.

For more information, read the GrapheneOS forum post discussing July 2024 Cellebrite capabilities, and the description of their encryption systems from Samsung Knox. All modern Android devices have a TEE. Some devices, for instance Google Pixels, can have an extra secure element, like the Titan M. Despite Google’s hardening efforts, exploitation is incredibly difficult, and vulnerabilities are very costly, but not impossible.

The February 2025 support matrix #

Cellebrite, as far as we know, publishes a support matrix for Android-based and iOS-based devices monthly or at least multiple times a year. The latest version available at time of writing is version 7.73.1 released on February 2025.

Below is a description of the automated process. Clearly, if the phone is unlocked or if the PIN or password are already known, the process is straightforward.

High-level description of the automated process for obtaining file system dumps

Unlocking non-flagship devices is usually easier for several reasons:

  • Many manufacturers fail to promptly release security updates, or in some cases, never release them at all.
  • Different processors have varying security stacks and hardening measures. A secure element adds significant protections compared to device with only a TEE, but it is not required and often not present.
  • It is well known that some MTK (MediaTek) processors are vulnerable to bootrom exploits and the whole trust chain can be compromised by anyone, including the TEE. Bootrom exploits are not patchable.
  • If a manufacturer has not invested in securing their devices, they may disable common security mitigations or introduce privileged software that weakens overall security.

Support matrix, high-level per chipset and manufacturer

As seen in the slides, there is a reason why almost every non-Pixel, non-Samsung device is considered unlockable, with only a few exceptions. Even using LineageOS, which typically ensures at least some level of security updates, does not make a significant difference if the underlying platform and binary blobs are not secure, which is almost never the case.

Support matrix, distinction between cold and hot per manufacturer.

Brute-force can take different forms. A root exploit could allow active bruteforcing, involving methods to bypass throttling or significantly speed up the process in various ways. A TEE exploit (or, for instance, a secure boot bypass as shown in MediaTek chips by Quarkslab) could allow for offline bruteforcing, making any numerical PIN shorter than 10 digits useless. This serves as a good reminder that a 6-digit PIN or pattern will always be cracked. Increasing the length and complexity, ideally by using a password instead, provides a meaningful layer of mitigation.

Support matrix, MediaTek- and Exynos-based devices.

As anticipated, if you have a MediaTek-based device, while it is still worth using a long password, there is practically no mitigation possible, except ditching it.

Support matrix, older Pixel devices up to the 5/5a.

Pixel devices remain quite a solid choice if kept updated. While it seems that for the standard Google ROM there are working exploits available to perform the FFS extraction in AFU state, on the contrary GrapheneOS additional hardening and protections are effective, and have been so since 2022. Brute force is generally not available, because the user credentials are stored in the the secure element, and thus cannot be extracted and active attempts are heavily throttled.

Support matrix, newer Pixel devices until the 9.

As you could have guessed, the more solid choice for an Android device is a newer Pixel, running GrapheneOS and with a strong password. Biometric authentication works differently, and it is generally not the main target of these attacks, meaning unless your threat model implies that you could be physically coerced to unlock your device, it is safe to use. That said, using a strong password is a minor daily inconvenience: you will only be prompted for it after a power cycle. Applications that offer separate passwords and encryption, such as Signal or many password managers should have it enabled to maximize protections in case everything else fails.

Conclusions #

If you think you could be in a situation where your device could be seized, it is always wise to turn it off first. You should also change your PIN, if you use one, as soon as possible in favor of a strong password. The same applies if your device currently has no PIN or if you are using a pattern. If you think there is a high chance of you being eventually targeted, you should move to a Pixel device using GrapheneOS, even just a secondhand older one (from the 6a onwards).

As we stated in the first blog post, this market is unregulated and is prone to countless abuses, as widely reported by Amnesty against civil society, but possibly in instances that could be harder to detect, such as surveillance connected to gender violence. While we do not currently have direct evidence of these occurrences, anybody with a license could be peforming these services, and we know they have been sold in the double-digit figures in Italy alone.