A physical extraction is a forensic acquisition that reads the raw storage of a mobile device sector by sector, producing a bit-for-bit image that a laboratory can then decode, parse and interpret. Unlike a logical acquisition, which asks the phone politely for the data it is willing to hand over, a physical acquisition ignores the application layer and works directly with the underlying storage. Where it succeeds, it reaches deleted messages, orphaned media, application databases, journal files and system caches that no lighter method can see.
In practice, the phrase covers a family of techniques, each with different pre-conditions, different risk profiles and different admissibility considerations. A defensible instruction begins with matching the method to the device, not with promising the client a specific outcome.
The extraction family, in plain terms
| Method | What it produces | Typical pre-conditions |
|---|---|---|
| Logical | Visible user data through the phone's own interfaces | Unlocked device, trusted USB pairing |
| File system | The accessible file system, including some system files | AFU state, valid pairing or supported agent |
| Full file system | The complete file system including protected containers | Supported vendor exploit or developer trust |
| Physical (BFU) | Bit-for-bit image before first unlock — usually encrypted at rest | Supported bootrom or bootloader vulnerability |
| Physical (AFU) | Bit-for-bit image after first unlock, with keys resident in memory | Device seized live, kept awake, examiner-controlled |
| Chip-off / JTAG | Direct read of NAND flash after de-soldering or test-point access | Damaged or unbootable devices; last resort |
What a successful physical extraction actually reaches
- Deleted messages still present in SQLite WAL journals, freelist pages and unallocated database space.
- Media removed from the gallery but persisted in application containers, thumbnail caches or CameraRoll shadow directories.
- Application data for messengers (WhatsApp, Signal, Telegram, Snapchat), dating platforms, banking apps and encrypted vaults.
- System artefacts: KnowledgeC and biome streams on iOS; usagestats, notification history and location caches on Android.
- Push token history, Wi-Fi association logs and Bluetooth pairing records that place a device in a location.
Where the modern security model stops the tool
Every modern iPhone and every recent Android device implements hardware-backed full-disk encryption tied to the user passcode and to a secure element (Secure Enclave on iOS, Titan M or vendor equivalents on Android). In the Before First Unlock (BFU) state, the class keys required to decrypt user data are not resident in memory; a physical image taken in that state is largely encrypted ciphertext. Without the passcode, or without a supported exploit for the exact hardware and firmware combination, the image cannot be decoded regardless of how it was acquired.
This is why reputable examiners refuse to quote on unlock outcomes sight unseen. The right question is not "can you get in?" but "for this model on this iOS or Android build, what depth of extraction is currently supported by Cellebrite, GrayKey, XRY or MSAB, and what evidence is in scope at that depth?" That question can be answered honestly in a scoping call.
Any provider guaranteeing a physical extraction on a modern device without first checking the exact model and firmware version is either misusing the term or overselling capability that does not exist.
How the process is actually run
- 01Triage. Confirm make, model, iOS/Android build, device state (BFU/AFU), battery level and passcode availability, before the device is powered on again.
- 02Isolation. Faraday bag or airplane mode with disabled Wi-Fi and Bluetooth; document time, examiner and device state in a contemporaneous note.
- 03Acquisition. Attempt the highest-depth supported method for that hardware/firmware combination; fall back down the ladder only if higher methods are unavailable.
- 04Verification. SHA-256 hash of the image at acquisition, recorded on the exhibit paperwork; every downstream copy re-hashed and reconciled.
- 05Decoding and analysis. Work exclusively on the image, never on the handset. Parse databases, carve unallocated space, reconstruct conversations with sender attribution and timestamps intact.
- 06Reporting. A CPR Part 35 (or CrimPR Part 19 / FPR Part 25) compliant report setting out what was extracted, by what method, what the method can and cannot support, and what the artefacts actually mean.
When physical extraction is the right instruction
If the case turns on deletion, denial or the absence of a message, physical extraction (or full file system, where supported) is usually the only route to a defensible answer, because those are the only methods that reach the journal files and unallocated space where deleted content persists. If the case turns on messages that are still visible on the handset, a lighter method is often proportionate — and cheaper — while producing the same evidential value.
The right method is the one that answers the pleaded issue at the lowest cost. Instructing the deepest available method by default wastes budget on questions the case does not turn on, and instructing the lightest method by default risks a report that cannot address the question actually in dispute.
Common failure modes we see in instructing parties
- Powering the device on to "just check" before it arrives at the laboratory — this can move a BFU device into AFU and burn one-shot exploit windows.
- Factory-resetting a device before instructing an examiner, which destroys almost all recoverable content.
- Allowing an in-house IT team to make a backup via iTunes or a Mac; the backup is not hash-verified and is not the same as a forensic image.
- Instructing an examiner on the eve of trial and expecting a physical extraction to complete within days; complex modern devices routinely take a week or more to decode fully.
Frequently asked questions
No. Support depends on the exact model, the iOS build at seizure, whether the device is in BFU or AFU state, and whether a current tool chain (Cellebrite Premium, GrayKey, XRY) supports that combination. Reputable examiners will tell you the answer for your specific device before quoting.
For BFU/AFU software-based methods, no — the handset is returned in the same state. For chip-off or JTAG, the device is opened and, in the case of chip-off, is not usable afterwards. Chip-off is used only as a last resort on damaged or unbootable devices.
Often, but not always. Recovery depends on how the application stores and vacuums its database, how long ago the deletion took place, and how much the device has been used since. Early preservation dramatically improves recovery.
The image itself is admissible, but if the data cannot be decrypted the exhibit is of no evidential value. Where the passcode is available under section 49 RIPA or by consent, the same image becomes a complete evidential record.
Physical is a sector-by-sector image of the raw storage; full file system is a complete copy of the decrypted file system. On modern devices, full file system extractions typically produce equivalent evidential value to physical, and are now the more common deep method.