Inside a Seized Smartphone: What Investigators Can and Cannot Extract
A practical guide to mobile device forensics on a seized handset: the four extraction levels, what each yields, why modern encryption and lock states often defeat extraction, how to preserve a phone, and admissibility.
A seized smartphone is often the single richest source of evidence in a modern investigation, but it is also one of the most misunderstood. Popular belief holds that any phone can be unlocked and emptied by the right tool. The reality is more constrained: what you can recover depends heavily on the make and model, the operating system version, whether the device is locked, and the precise state it was in when you took custody. This guide is general professional guidance for officers, investigators and analysts. It is not legal advice. Everything below assumes you are acting under proper legal authority: a device should only be seized and searched on a lawful basis, and in most jurisdictions searching the contents of a phone requires its own search authority distinct from the power to seize it.
- Phone extraction comes in four broad levels: manual, logical, file-system and physical. Each yields progressively more data but is progressively harder to achieve on modern devices.
- The most important variable on a locked phone is its lock state: Before First Unlock (BFU) versus After First Unlock (AFU). A device seized in AFU is far more recoverable than the same device in BFU.
- Modern iOS and Android devices use hardware-backed, passcode-derived encryption. A current, fully updated handset with a strong passcode, seized cold in BFU, is frequently not extractable by any lawful means available to you.
- Preservation decisions made in the first minutes (network isolation, power, avoiding interaction) often determine whether any evidence is recoverable at all.
- Recovered data is only useful if its integrity is provable: hash on acquisition, document the chain of custody, and meet your jurisdiction's electronic-evidence certification rules.
Seizure and search authority
Seizing a phone and searching its contents are two different acts. In the United States, the Supreme Court held unanimously in Riley v. California (2014) that police generally need a warrant to search the data on a cell phone, even after a lawful arrest. The Court accepted that officers may seize and secure the device incident to arrest, including isolating it to prevent remote tampering, but the data search itself requires a warrant. Many jurisdictions follow the same logic: the power to take the handset is not the power to read it.
In India, seizure and search powers flow from the criminal procedure code in force and any specific statute under which you are operating, and the contents of the device are electronic records governed by evidence law. Treat the lawful basis for the data search as a precondition, not an afterthought. The forensic process described below should begin only once that authority is in place and documented.
Preserving a seized phone
The condition of the device when it reaches the examiner is decided at the scene. International good practice, reflected in ISO/IEC 27037, frames this around a first responder role and a specialist role, and around four qualities the whole process must satisfy: auditability, repeatability, reproducibility and justifiability. In plain terms, everything you do to the phone should be recorded and defensible.
- Photograph the device in place and note its visible state: powered on or off, screen content, any visible notifications, and whether it is plugged in.
- Isolate it from networks immediately. Use a Faraday bag, or as a fallback enable airplane mode if and only if you can do so without unlocking or otherwise altering protected data. Network isolation prevents a remote wipe, remote lock, or incoming data that overwrites evidence.
- Do not power a phone off if it is already on and unlocked or in an unlocked-since-boot state, unless policy requires it. Powering down can drop a recoverable device into a far less recoverable state.
- Keep the device charged. A battery that dies can force a reboot into the harder lock state and can lose volatile data held only in memory.
- Avoid interacting with the screen. Repeated failed passcode entries can trigger lockouts or, on some configurations, data-protection responses. Do not guess passcodes.
- Record the make, model and operating system version if visible, and bag any SIM cards, memory cards, cables and the original packaging or notes that may carry passcodes.
The four extraction levels
Mobile extraction is conventionally described as a ladder of methods. Higher levels return more and deeper data but demand more access, more capable tooling, and a device that is not fully locked down.
| Level | How it works | Typical reach |
|---|---|---|
| Manual | An examiner navigates the live device by hand and photographs or records what is on screen. | Only what the user could see. No deleted data. High risk of altering the device. |
| Logical | The tool asks the phone, through its own interfaces and backup mechanisms, to hand over data. | Active app data, contacts, call logs, messages, media that the device chooses to expose. Limited or no deleted content. |
| File system | Acquisition of the device's file structure, including application databases and supporting files. | App databases, caches, some logs and configuration, and deleted records that survive inside databases. Requires unlock or an unlocked state. |
| Physical | A bit-for-bit image of storage. | The fullest picture, including unallocated space and remnants of deleted data, but on encrypted modern phones the image is meaningless without the keys. |
The crucial modern caveat is on the physical row. On a current encrypted handset, obtaining a raw image of the storage chips gives you only ciphertext. Without the decryption keys, which are tied to the passcode and hardware, a physical image is unreadable. This is why the encryption and lock-state discussion below matters more than the choice of extraction level.
What each level yields
When extraction succeeds, a phone can yield far more than messages and call logs. Depending on the level and the apps installed, that can include chat content and attachments, photos with embedded location and timestamp metadata, app usage and account artefacts, browser history, stored credentials and authentication tokens, health and sensor data, and location history reconstructed from app and system databases.
Deleted data is frequently misunderstood. Recovery is most realistic where a deleted record still sits inside an application database that has not yet been compacted, less realistic from encrypted unallocated space, and not guaranteed in any case. Treat deleted-data recovery as possible but never assumed, and never promise it to a court or a commander in advance.
Encryption and lock states
Modern phones encrypt user data by default and bind the keys to dedicated security hardware: Apple's Secure Enclave on iOS, and on Android hardware-backed keystores including the StrongBox class of tamper-resistant modules on supported devices, layered over file-based encryption. The keys that protect most user data are derived from the user's passcode combined with a hardware key that cannot be extracted. That design has two consequences for you.
First, the lock state at seizure is decisive. A device that has been unlocked at least once since it last booted is in the After First Unlock (AFU) state: encryption keys for much user data are resident in memory, so an extraction has far more to work with. A device that has been powered on but never unlocked since boot is in the Before First Unlock (BFU) state: the keys protecting most user content are not available, so even a successful acquisition returns mostly system data, not the user's messages and photos. Practitioners therefore prioritise keeping an AFU device alive and isolated, and acting quickly, because reboots, power loss and timeouts can return a device to BFU.
Second, brute force is bounded by hardware. The security processor deliberately slows each passcode attempt and enforces escalating delays and, on many configurations, attempt limits. A short numeric PIN on an older device may be tractable; a long alphanumeric passcode on a current, fully patched device usually is not, within any realistic time. The honest position is that a modern, updated handset with a strong passcode, seized in BFU, is often not extractable by any lawful means available to you. Capability also varies constantly with operating-system patch levels, so any claim that a particular phone can be opened should be tested against the actual device, not assumed.
Device data vs cloud data
Much of what users assume lives on the phone actually lives in the cloud, and much of what is on the phone is a synced copy of cloud data. This boundary matters legally and practically. Where a device extraction is blocked by encryption, lawfully compelled cloud production from the relevant service provider may reach backups, synced messages, photos and account records that the handset will not give up. Conversely, authentication tokens recovered from a device can in some cases provide account access, which raises its own authority questions and should never be used to reach into accounts without a clear, separate legal basis. Treat on-device data and provider-held cloud data as distinct evidence sources with distinct legal routes.
Tooling and what it cannot do
Commercial mobile-forensic suites broadly fall into acquisition tools, which pull data off the device, and analysis tools, which parse, decode, search and present it. Mature products combine both and maintain large libraries of app-format parsers so that recovered databases can be rendered into readable conversations, timelines and location plots. Used correctly they save enormous time and reduce error.
What they cannot do is defeat the laws of cryptography. A forensic suite does not magically decrypt a BFU device whose keys are not present, and its supported-device lists are constantly chasing operating-system updates. Validate your tools, understand the difference between what a tool collected and what it merely inferred or decoded, and be able to explain the method in court. A tool's conclusion is not evidence in itself; the underlying data, properly acquired and verified, is.
Integrity and admissibility
Recovered data is only useful if you can prove it is what you say it is and that it was not altered. The universal mechanism is cryptographic hashing: compute a hash of the acquired image or dataset at the point of acquisition, record it, and re-verify it later so that any change would be detectable. Maintain an unbroken, documented chain of custody from seizure to analysis to production, and keep contemporaneous notes of every action taken on the device, consistent with the auditability and repeatability principles of ISO/IEC 27037.
Jurisdictions add their own certification rules for electronic evidence. In India, the admissibility of electronic records is now governed by Section 63 of the Bharatiya Sakshya Adhiniyam, 2023, which came into force on 1 July 2024 and replaced Section 65A and Section 65B of the Indian Evidence Act, 1872. Section 63 broadens the language from a computer to a computer or any communication device, and its certification requirement under Section 63(4) is widely read as expecting certification covering both the person responsible for the device and an expert, including device details and hash values. Build your process so that the certificate can be produced cleanly, and confirm the current requirement and format with your prosecuting authority, as practice continues to develop.
Frequently asked questions
Can investigators unlock any seized phone? No. A current, fully updated iOS or Android device with a strong passcode, seized in the Before First Unlock state, is frequently not extractable by any lawful means available to a typical investigator. Capability is model-specific, version-specific and changes with each security update.
Why does it matter whether the phone was on and unlocked when seized? Because the encryption keys for most user data are loaded into memory only after the first unlock since boot. A device in the After First Unlock state yields far more than the same device in Before First Unlock. This is why preserving power and network isolation, and acting quickly, are so important.
Should I switch a seized phone off? Generally no, not if it is on, unless policy or safety requires it. Powering down can drop the device into the harder lock state and lose volatile data. Isolate it from networks instead, and keep it charged, until an examiner takes over.
If the device is locked, is the evidence lost? Not necessarily. Data synced to a cloud account may be obtainable from the service provider under separate legal authority, even when the handset itself cannot be opened. Device data and provider-held cloud data are distinct sources with distinct legal routes.
This guide is part of our Guides for Investigators & Police reference series, covering Foundations, Mobile, Web & Social, Crypto, Cloud and AI.