Mobile Data Extraction
Smartphones carry more evidentiary density than almost any other device examiners encounter — messages, location history, cached credentials, and deleted records recoverable long after a user thinks they're gone.
What is mobile forensics?
Mobile forensics is the acquisition and analysis of data stored on smartphones and tablets — contacts, messages, call logs, media, application databases, and system artifacts. Unlike a traditional desktop, a modern smartphone is a sealed, encrypted, tightly sandboxed device, which makes acquisition tier selection the single most consequential decision an examiner makes.
The three acquisition tiers — logical, file-system, and physical — trade off access depth against invasiveness, cost, and legal risk. Choosing the right tier for a given device, OS version, and case requires understanding what each tier can and cannot see.
Logical Extraction
OS-exposed data via backup APIs — fast, low-risk, but no deleted records.
File-System Extraction
Full access to live files and app databases, including SQLite WAL files.
Physical Extraction
Raw flash bit-for-bit — deleted, unallocated, and slack space included.
Step-by-Step Methodology
The sequence a careful examiner follows, in order.
- 1
Preserve before you touch it
Place the device in a Faraday bag immediately, engage airplane mode where safe to do so, and maintain power via an isolated battery pack to prevent both remote wipe and lock-triggered encryption re-engagement.
- Photograph the device's screen state and physical condition before bagging
- Note whether the device is unlocked at seizure — this determines available options
- 2
Select the correct extraction tier
Choose logical, file-system, or physical extraction based on the device model, OS version, lock state, and what evidence category the case actually requires.
- Logical: adb backup, iTunes/Finder encrypted backup
- File-system: full sandbox access via checkm8-class exploits or vendor tooling
- Physical: JTAG, ISP, or chip-off for locked/damaged devices
- 3
Acquire and hash
Run the extraction with validated tooling (Cellebrite UFED, Magnet AXIOM, MSAB XRY, or open-source equivalents), then hash the resulting extraction package immediately.
- 4
Parse app databases
Run ALEAPP or iLEAPP against the extraction to automatically decode hundreds of known artifact formats, then manually inspect key SQLite databases (msgstore.db, contacts2.db, call_log) with a SQLite browser for anything the automated parser missed.
- 5
Recover deleted records
Inspect SQLite Write-Ahead Log (-wal) and rollback journal (-journal) files for unflushed deleted rows, and scan freelist pages within the main database file for remnants of records marked free but not yet overwritten.
- 6
Extract media metadata
Pull EXIF data (GPS, timestamp, device model) from photos and videos in the native camera roll, noting that shared/downloaded copies from messaging apps are frequently stripped of this metadata.
- 7
Document and report
Record the exact extraction tier used, tool and version, hash values, and a clear justification for any invasive technique (JTAG/chip-off) given its destructive or higher-risk nature.
Tools Comparison
Sortable — click any column header.
Commands & Code
Copy-ready snippets used in real workflows.
# Confirm device is authorized and visible
adb devices
# Full logical backup (legacy API, app-dependent opt-in)
adb backup -apk -shared -all -f evidence_backup.ab
# Pull a specific file/directory (requires elevated shell access)
adb pull /sdcard/DCIM ./extracted_dcim
# Pull WhatsApp's message database on a rooted device
adb shell "su -c 'cp /data/data/com.whatsapp/databases/msgstore.db /sdcard/'"
adb pull /sdcard/msgstore.db ./evidence/# Hash the extraction package immediately after acquisition
sha256sum evidence_backup.ab > evidence_backup.ab.sha256
# Re-verify before analysis begins
sha256sum -c evidence_backup.ab.sha256-- Open the WAL directly alongside the main database
-- (do not let SQLite auto-checkpoint the WAL into the main file first)
PRAGMA journal_mode;
-- Inspect message table row count vs. what the app UI displays
SELECT COUNT(*) FROM message;
-- Look for rows whose key_remote_jid indicates a deleted-for-everyone marker
SELECT _id, key_remote_jid, data, timestamp
FROM message
WHERE remote_resource IS NOT NULL
ORDER BY timestamp DESC
LIMIT 50;Legal & Ethical Considerations
- Obtain a warrant, informed consent, or valid statutory authority before any extraction — logical, file-system, or physical alike.
- Screen-lock bypass techniques must only be used within the scope of explicit legal authorization; unauthorized circumvention can itself violate computer-misuse statutes.
- JTAG and chip-off are physically destructive or device-altering — document the justification for escalating to these tiers and obtain sign-off where your process requires it.
- Cloud/token-based acquisition of synced data may implicate a third-party provider and cross-border data rules — involve legal counsel before pulling cloud-stored content.
Common Mistakes
- Defaulting to logical extraction when the case requires deleted-message recovery — logical tier will not surface WAL or freelist remnants.
- Letting the device sit powered-on and network-connected after seizure, allowing the WAL to checkpoint and overwrite recoverable deleted records before acquisition.
- Treating EXIF GPS data pulled from a messaging app's cached copy as reliable — most platforms strip metadata on upload/download.
- Skipping hash verification immediately after acquisition and only doing it later, losing the ability to prove the extraction package was unaltered from the moment of creation.