Phones hold more evidence about an incident than almost any other device, yet they are encrypted by default, change state constantly and can be wiped remotely the moment they reconnect to a network. Mobile forensics is the practice of preserving, acquiring, examining and reporting on data from smartphones and tablets so that the results are repeatable and defensible. This guide explains how evidence is preserved, the acquisition types (logical, file system and physical) and what each yields on iOS and Android, how encryption and device state shape what is possible, how to check a device for commercial spyware with the Mobile Verification Toolkit (MVT), and the consent and legal points to settle first. It is written for corporate investigators, incident responders and security teams supporting executives, journalists or other at-risk users. It is not legal advice and does not cover techniques for bypassing device security.
Key takeaways
- Preservation comes first. Isolate the device from networks, keep it powered, document its state and record every interaction, because remote wipe, incoming messages and lock timers all change the evidence.
- Acquisition type decides what you see. Logical acquisition returns what the operating system exposes, file system acquisition adds app databases and system files, and physical acquisition can reach deleted data but is rarely possible on modern encrypted devices.
- Device state matters as much as tools. On iOS most third-party app data is in Data Protection Class C, available only after the first unlock since boot, so a device that is rebooted or powered off can lose access to much of its data.
- Spyware checks are a different job. MVT compares backups and diagnostic data against published indicators, but public indicators alone cannot prove a device is clean.
- Consent and authority before extraction. Corporate ownership of a device does not settle every privacy question, and MVT's licence prohibits use on devices of people who have not consented.
The mobile forensic process
NIST SP 800-101 Rev. 1, Guidelines on Mobile Device Forensics, structures the work into preservation, acquisition, examination and analysis, and reporting, with tool validation throughout. The guidance is from 2014 and predates today's full-disk and file-based encryption, but its process and its warnings about evidence integrity remain the reference point.
| Phase | Goal | Key outputs |
|---|---|---|
| Preservation | Stop the device or its data changing | Photographs, state notes (screen, time, battery, signal), isolation method used, custody record |
| Acquisition | Copy data with the least invasive method that answers the question | Extraction files, tool name and version, hashes, acquisition log |
| Examination | Extract and decode artefacts | Parsed databases, messages, call logs, locations, app data |
| Analysis | Answer the investigative questions | Timeline, findings tied to specific artefacts |
| Reporting | Present results others can verify | Report with methods, tools, hashes, limitations |
Preserving a mobile device
Most mobile evidence is lost in the first hour through avoidable actions. SP 800-101r1 points out that remote lock and wipe commands, incoming calls and messages, and location reporting can all alter data, and it compares three isolation approaches.
| Isolation method | Advantage | Risk |
|---|---|---|
| Airplane mode | Fast, keeps device on and unlocked state intact | Requires interacting with the device (document each step); may not stop GPS on every device |
| Power off | Stops all radios and remote commands | Re-enables passcode protection and, on modern devices, returns data to its most protected state |
| Keep on inside RF shielding | No interaction needed | Drains battery quickly; shielding may only attenuate signals (NIST cites testing where SMS most often got through); cables can act as antennas |
- Document before touching: photograph the device, screen, cables and surroundings. Record the displayed time, service status, battery level and notification icons, and compare the device clock with a reference clock.
- Keep it powered: connect to a power source, ideally a portable pack inside the shielded container, so the device stays in its unlocked-since-boot state.
- Collect credentials lawfully: passcodes, backup passwords and the user's cloud account details may be needed later. Obtain them through the employee, policy or legal process, not by guessing.
- Prevent remote wipe from your own side: ask the MDM team to suspend wipe and retire actions for the device, and record that request.
- Record custody: who seized the device, when, where, its condition and every subsequent transfer.
Acquisition types compared
SP 800-101r1 describes a five-level tool classification, from manual extraction (photographing the screen) through logical extraction, hex dumping and JTAG, chip-off and micro read. Higher levels are more technical, invasive and expensive, and carry more risk of altering or destroying data. Working practice today groups methods into the three acquisition types below.
| Type | How it works | What you get | What you miss |
|---|---|---|---|
| Manual | Examiner navigates the interface and records the screen | Visible content only; useful as a last resort or for quick validation | Deleted data, hidden app data; every action changes the device |
| Logical | Tool uses operating system interfaces or backup services (for example an iOS backup or Android backup over USB) | Contacts, messages, call logs, photos and data apps choose to include in backups | Data apps exclude from backup, most system logs, deleted records, unallocated space |
| File system (full file system) | Copies the file system as the OS sees it, usually needing elevated access to the device | App sandboxes, SQLite databases with write-ahead logs, system databases, caches, keychain items where accessible | Unallocated space; data still encrypted under keys that are not available |
| Physical | Bit-for-bit copy of flash storage (historically via boot loaders, JTAG or chip-off) | Raw storage including deleted objects and unallocated space | On modern encrypted devices raw images are of little use without the keys, and these methods are rarely available |
- Choose the least invasive method that answers the question: SP 800-101r1 warns that once a higher-level method is used, lower-level ones may no longer be possible.
- Logical and physical views differ: logical data is easier to read but omits deleted data and remnants; physical images can expose them but need parsing, decryption and decoding.
- Cloud is a source too: iCloud, Google account data, messaging backups and enterprise SaaS often hold data no longer on the device. Accessing it needs its own authority and has its own logs.
For broader evidence-handling principles, see the Digital Forensics (DFIR) Guide.
Encryption and device state
On modern devices, encryption and lock state matter more than any acquisition tool. Apple's Platform Security documentation describes four Data Protection classes for files on iOS and iPadOS.
| Class | Availability | Forensic meaning |
|---|---|---|
| A: Complete Protection | Key discarded shortly after the device locks | Readable only while unlocked |
| B: Protected Unless Open | Files can be written while locked; key wiped when the file closes | Limited access while locked |
| C: Protected Until First User Authentication | Key stays in memory after the first unlock since boot | Default for third-party app data; available after first unlock (AFU), not before (BFU) |
| D: No Protection | Protected only by the device UID | Encrypted, but available without the passcode |
- Before first unlock vs after first unlock: a device seized while running and unlocked at least once since boot exposes far more than one that has been restarted. This is the main reason to keep devices powered.
- Android: file-based encryption on current Android versions works on a similar principle, with credential-encrypted storage unavailable until the user unlocks after boot. Vendor implementations vary, so validate tool support per model and version.
- Lockdown Mode on iOS: since iOS 16, Lockdown Mode requires the device to be unlocked before it will connect to an accessory or computer, and the device cannot enrol in MDM. Expect it on devices of high-risk users and plan collection with their cooperation.
- Backup encryption helps defenders: MVT recommends enabling backup encryption with a strong password for more accurate detection, and warns that the backup is unusable without that password.
Checking devices for spyware with MVT
The Mobile Verification Toolkit was released by Amnesty International's Security Lab in July 2021 as part of the Pegasus Project and is still maintained by Amnesty and contributors. It is a command-line tool for consensual forensic analysis of iOS and Android devices to identify traces of compromise.
- What it analyses on iOS: iTunes or Finder backups (encrypted recommended), full file system dumps and sysdiagnose archives, parsing records such as call history, messages and browsing data to find attack vectors like malicious links.
- What it analyses on Android: the recommended workflow runs
mvt-android check-androidqfon output from AndroidQF, a collector that gathers a backup, a bugreport and system logs. Intrusion logs are also checked where Android Advanced Protection and Intrusion Logging were enabled. Direct analysis over ADB has been removed. - How detection works: extracted records are compared against indicators of compromise in STIX2 format, including those published by Amnesty and other research groups. Optional VirusTotal lookups of non-system APK hashes are off by default.
- Limits stated by the project: MVT is not intended for end-user self-assessment, and public indicators are insufficient to determine that a device is clean. Comprehensive triage needs non-public indicators and threat intelligence, for which the project points to Amnesty's Security Lab and Access Now's Digital Security Helpline.
- Android has less to work with: MVT notes that Android offers fewer complete forensic data sources than iOS, backups are limited and being deprecated, and bugreport formats vary between versions and vendors.
A negative MVT result therefore means "no known indicators found in the data collected", never "not compromised". For threat context, see the Commercial Spyware Guide and the Mobile Malware Guide.
Examination and analysis
- SQLite is the core artefact: messages, call logs, browser history and most app data live in SQLite databases. Examine the write-ahead log and journal files alongside the main database, because recent changes and some deleted records may only be there.
- Normalise time: mobile platforms and apps store timestamps in several epochs and time zones. Record the conversion used for each artefact.
- Corroborate across sources: tie a suspicious link in a message to browser history, network usage records and MDM or mobile threat defence logs before concluding.
- Map behaviour to ATT&CK for Mobile: useful techniques include Phishing (T1660), Drive-By Compromise (T1456), Exploitation for Initial Access (T1664), Exploitation for Privilege Escalation (T1404), Download New Code at Runtime (T1407), Location Tracking (T1430), Call Log collection (T1636.002) and File Deletion (T1630.002), which is common in spyware that cleans up after itself.
- Validate tools: SP 800-101r1 stresses tool validation, and NIST's Computer Forensics Tool Testing (CFTT) programme publishes tool test reports, including in its mobile devices area. Test tool versions against known reference data before relying on them.
Integrity, hashing and reporting
- Hash every extraction: compute a cryptographic hash of each acquired file or image and verify it throughout the evidence lifecycle. If a tool does not hash, hash its output separately.
- Expect live device variation: NIST notes that back-to-back acquisitions of a live device can produce different whole-image hashes because the clock and other data keep changing, while individual file hashes usually match. Explain this in the report instead of hiding it.
- Log every action: the method, tool and version, settings, time, and any interaction with the device, especially for manual steps such as enabling airplane mode.
- State limitations: data not accessible (BFU state, excluded app data, missing backups), indicators used and their date.
Legal, consent and policy considerations
This section is general information, not legal advice. Rules differ by country, sector and employment contract, so agree the approach with counsel before acquiring.
- Ownership and authority: corporate-owned, BYOD and personal devices carry different rights. A mobile device policy that sets out investigation rights, signed at enrolment, removes most ambiguity. See the Mobile Device Security Guide.
- Consent: obtain informed, written consent from the device user for any extraction outside a formal legal process. For spyware checks of at-risk staff, consent is both an ethical requirement and an MVT licence condition.
- Proportionality and data minimisation: a full extraction captures personal messages, photos, health and location data. Scope searches to the investigative question, restrict access, and set retention and deletion for extracted data under privacy law such as GDPR.
- Law enforcement handover: where criminal activity is suspected, consider whether the device should be preserved untouched for police rather than examined internally.
Where identity fits
Phones are now authenticators. Seized or compromised devices may hold passkeys, authenticator app seeds, refresh tokens for enterprise apps, VPN certificates and app-embedded API keys. Investigations should list which tokens and enrolments the device held and revoke them centrally, not only wipe the device. Hard-coded credentials in mobile apps are a recurring finding, as in the hard-coded AWS keys Symantec found in 1,859 Android and iOS apps. See the Mobile App Security Guide.
Implementing a mobile forensic capability
- Define scope and authority: decide which cases you handle internally (policy breaches, spyware checks, insider data theft) and which go to external specialists or police.
- Write the policy first: device ownership, investigation rights, consent forms, data retention for extractions.
- Build a preservation kit: RF shielding bags, verified for the bands you need, power packs, cables, evidence bags, custody forms and a camera.
- Choose and validate tools: one commercial or open source acquisition tool for logical and file system extraction, MVT for spyware triage, and a SQLite browser; validate each on test devices before casework.
- Pilot on test devices: run full procedures on enrolled test phones for each major OS version you support, and record what each acquisition type returns.
- Integrate with MDM and identity: agree how to suspend remote wipe, pull MDM inventory and revoke device-bound credentials.
- Review after each case: update procedures when OS versions or tool support change; if a method proves unreliable, roll back to the last validated procedure.
Measuring the capability
- Preservation success rate: share of seized devices kept powered and isolated without unrecorded interaction.
- Time to acquisition: hours from seizure to verified, hashed extraction.
- Tool validation currency: percentage of supported OS versions validated with the current tool versions.
- Indicator freshness: age of the indicator sets used in spyware checks at the time of each scan.
- Credential revocation completeness: share of cases where every token and enrolment on the device was identified and revoked.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-101 Rev. 1 | Preservation, acquisition, examination and analysis, reporting | Core process and tool classification for mobile forensics |
| NIST CSF 2.0 | RS.AN-03, RS.AN-06, RS.AN-07 | Root cause analysis; recording investigative actions; preserving integrity and provenance of incident data |
| NIST SP 800-53 Rev. 5 | IR-4, IR-5 | Incident handling; incident monitoring |
| ISO/IEC 27001:2022 | A.5.28 | Collection of evidence |
| MITRE ATT&CK for Mobile v20 | T1660, T1664, T1404, T1407, T1430, T1636.002, T1630.002 | Behaviours to look for when analysing a suspected compromise |
Common failure patterns
- Powering off "to be safe": it re-locks data into its most protected state and can make file system acquisition impossible.
- Trusting a single shielding bag: untested shielding lets messages or wipe commands through, and a charging cable through the bag can act as an antenna.
- Calling a device clean after an MVT scan: public indicators only catch known campaigns; report what was checked and when.
- Examining without authority: extracting a personal or BYOD device without consent or legal basis can make evidence unusable and expose the organisation.
- Unvalidated tool versions: a tool update that mis-parses a new OS version produces wrong timestamps or missing records.
- Wiping instead of revoking: remote wiping a compromised phone destroys evidence and still leaves its tokens and enrolments valid elsewhere.
Practitioner checklist
- Publish a mobile investigation policy covering ownership, consent and data retention.
- Keep a tested preservation kit with verified RF shielding and power.
- Document device state with photographs and a reference clock before any interaction.
- Suspend MDM wipe actions for seized devices and record the request.
- Choose the least invasive acquisition that answers the question, and log every step.
- Hash every extraction and re-verify before analysis and reporting.
- Run MVT with current indicators for spyware triage, and escalate positive or ambiguous results to specialists.
- Validate tools against test devices for each supported OS version.
- Revoke device-bound credentials, passkeys and tokens as part of every compromise case.
Standards and references
- NIST: SP 800-101 Rev. 1 Guidelines on Mobile Device Forensics
- NIST: Computer Forensics Tool Testing Program
- Amnesty International Security Lab: Mobile Verification Toolkit documentation
- Mobile Verification Toolkit: Android methodology
- Apple: Platform Security, Data Protection classes
- Apple: About Lockdown Mode
- Google: Android Advanced Protection
- MITRE ATT&CK: Mobile Matrix
Related NHI Mgmt Group resources: Digital Forensics (DFIR) Guide · Incident Response Guide · Commercial Spyware Guide · Mobile Device Security Guide · Memory Forensics Guide