Cellebrite (Israeli company, NYSE: CLBT) and GrayKey (made by Magnet Forensics, formerly Grayshift) dominate the commercial mobile forensic market. Together they're used by law enforcement in roughly every Western country, by border agencies, and by an unknown number of less savory clients abroad. Both rely on a rotating mix of public and private exploits to extract data from locked phones — they are not, as the marketing implies, universal master keys.
Understanding what these tools can and can't do matters because the public conversation tends toward two extremes: "they can break any phone instantly" and "modern encryption defeats them." Neither is correct.
The Three Extraction Tiers
Forensic vendors classify what they can pull from a device into a hierarchy. The terminology varies; the concept is the same.
- Logical extraction — Data the device willingly hands over to a connected computer: photos, contacts, call logs, some app data exposed via the standard backup APIs. Requires the device to be unlocked (or "AFU" — after first unlock — for some types).
- File-system extraction — Full read of the user-data partition. Requires bypassing the lock screen and, on iOS, defeating Secure Enclave protections that gate file access on the user passcode.
- Physical / full-file-system extraction — Bit-for-bit copy of flash storage, including deleted-but-not-overwritten data. The gold standard for forensics and the hardest tier to achieve on modern hardware.
Cellebrite's "Advanced Logical" and "File System" extractions and GrayKey's "Full" extraction map roughly to tiers 2 and 3. The tier that's actually possible depends on the device model, OS version, and whether the device is currently AFU or BFU.
AFU vs BFU — The Single Most Important Distinction
Modern iOS and Android phones encrypt user data with a key that's derived in part from the user's passcode. After a reboot, before the user has typed their passcode once, the device is in BFU state: "Before First Unlock." Most user data is still encrypted at rest, the cryptographic keys are not in RAM, and even much of what the OS itself wants to display is unavailable.
Once the user has typed their passcode at least once since boot, the device transitions to AFU: "After First Unlock." The keys for most user-data classes are now resident in protected memory. The device may be locked from the user's perspective, but most of its data is decryptable in place.
The simplest meaningful action you can take if you anticipate device seizure is to reboot the phone. A freshly-rebooted (BFU) device is substantially harder for forensic tools to extract from than an AFU device, regardless of vendor. iOS hardens BFU; recent Android devices increasingly do the same.
What Forensic Tools Actually Get From Each State
| State | iOS (recent) | Android (recent, GrapheneOS / Pixel) |
|---|---|---|
| Unlocked | Full extraction possible | Full extraction possible |
| AFU (locked, used since boot) | Most user data extractable via known exploits; success rate varies by iOS version | App data in "credential-encrypted" storage extractable; "device-encrypted" subset accessible too |
| BFU (rebooted, unused) | Very limited — keys not in memory; success requires breaking the passcode itself | Strongly protected on Pixel + GrapheneOS; less protected on some OEM Androids |
Passcode Brute-Force: How Long Does It Take?
Both Cellebrite and GrayKey perform offline passcode brute-force against extracted key material when they can get it. The Secure Enclave / Titan M chips deliberately throttle attempts — you cannot simply hammer all possible 6-digit PINs.
For a numeric-only passcode, attempt times are roughly:
- 4-digit: ~10,000 combinations, broken in hours.
- 6-digit: ~1,000,000 combinations, broken in days to weeks depending on tool generation and hardware.
- 8-digit: ~100,000,000 combinations, often beyond economic tractability for routine cases.
- Alphanumeric passphrase (8+ chars random): Computationally infeasible for current tools.
The takeaway: an alphanumeric passphrase of meaningful length is the single biggest improvement most users can make to their device's resistance against forensic extraction. The default 6-digit PIN is dramatically weaker than most people assume.
Application Data and the App Threat Model
Even when a forensic tool achieves a file-system extraction, individual apps can resist by encrypting their own data with keys not derivable from the passcode alone. Signal's database is encrypted with a key stored in the Keystore / Secure Enclave; Telegram (in passcode-locked mode) similarly protects its data. Most mainstream apps, however, store their data in plain SQLite databases that are decrypted as soon as the device is.
For email and chat specifically, the question is: is the local copy of my messages encrypted with a key that survives device extraction? Most messengers' answer is no — once the device's encryption is bypassed, the app's data is in clear SQLite.
The "Cellebrite Was Backdoored" Story
In 2021, Signal's then-creator Moxie Marlinspike published a memorable analysis after acquiring a Cellebrite UFED kit: he found multiple memory-corruption vulnerabilities in Cellebrite's own software that could be triggered by specially-crafted files on a phone being analyzed. This was funny, embarrassing for Cellebrite, and a useful reminder that forensic software is itself software with bugs. It is not, in practice, a reliable defense — the discovered bugs were patched, the broader fact that Cellebrite functions on most devices most of the time did not change.
Defensive Posture: What Actually Helps
- Use a strong passphrase, not a PIN. 8+ random alphanumeric characters defeats current offline brute-force on Secure Enclave / Titan-M hardware.
- Reboot before crossing a border or in any other anticipated-seizure situation. BFU state is materially better protected than AFU on every modern platform.
- Run a recent OS. Most public Cellebrite/GrayKey exploits target known-old iOS/Android versions. Newer versions are not invulnerable, but the attack window is much narrower.
- Consider GrapheneOS on a Pixel for high-risk threat models. GrapheneOS adds aggressive USB-port hardening, optional auto-reboot after a configurable idle period (returning the device to BFU), and a duress PIN that wipes the device. See our GrapheneOS guide.
- Keep sensitive data in apps that encrypt locally with a separate key. Disk encryption alone is insufficient when the disk key gets compromised.
- Power off when not in active use if you're at meaningfully elevated risk. The cost is convenience; the benefit is BFU at all times.
Legal Compulsion and the Fifth Amendment Question
In the U.S., the legal landscape on whether you can be compelled to unlock a phone is jurisdictionally fractured. The general pattern in 2026: courts increasingly treat compelled biometric unlock (face, fingerprint) as not protected by the Fifth Amendment, while compelled passcode disclosure is more often protected as testimonial. This is a major argument for relying on a passphrase rather than biometric unlock as your primary authenticator, depending on where you live and what protections matter to you.
None of this is legal advice — but it is the operational reason many security professionals reflexively disable biometric unlock when crossing borders or in other elevated-risk contexts.
A forensic extraction tool is a budget, an exploit, and time. Strong encryption raises the cost on all three. None of them set it to infinity.
Where Haven Fits
Haven encrypts its local message database with a key derived from your passphrase (PBKDF2 + HKDF) — the key never lives on disk in extractable form, and is wiped from memory after a configurable idle period. Even if a forensic tool achieves a full file-system extraction of your phone, the Haven database is encrypted at rest with a key that requires your passphrase to derive. We can't promise immunity from every future exploit — no one honestly can — but the architectural baseline is built around the assumption that the device's own encryption is one layer, not the only layer.