Mobile Forensic Acquisition

A mobile phone is a self-contained evidence vault — call history, messages, location data, photos, app data, and cloud sync records. How you extract that evidence depends on the phone's state, its PIN, and the tools available; this chapter maps the options from least to most invasive.

12.1Types of Mobile Evidence

Mobile evidence comes from four distinct locations. A thorough investigation draws from all four; missing even one can leave critical gaps.

Internal storage — the phone's flash memory. This is the richest source:

• Call logs: every incoming, outgoing, and missed call with phone number, duration, timestamp, and direction. Typically stored in a SQLite database.
• SMS and MMS messages: body text, sender/recipient number, timestamp, read/unread status; MMS includes media attachments.
• Contacts (address book): names, numbers, email addresses, and any notes associated with contacts.
• Photos and videos: media files, often with embedded EXIF metadata including GPS coordinates, device model, and timestamp of capture.
• Installed apps and app data: every installed application leaves a data directory containing databases, cached content, account tokens, and preferences.
• Browser history: visited URLs, search queries, bookmarks, cached web pages.
• Email client data: local copies of emails, account credentials, attachments.
• Calendar entries and notes: appointments, reminders, free-text notes.

SIM card data. A separate physical evidence source:

• ICCID (SIM serial number)
• IMSI (subscriber identifier)
• ADN phonebook (contacts stored on the SIM, not the phone)
• SMS messages stored in the SIM's fixed slots
• LOCI — the last Location Area Identity (LAI) the SIM registered with
• LDN (Last Dialled Numbers)

External SD card. Many Android phones allow inserting a microSD card for extra storage. The SD card may contain media files, downloaded documents, and app data stored externally. It must be acquired separately from the internal storage; a logical extraction of the phone alone will not cover the SD card.

Network / operator records (obtained via legal process). Held by the telecom operator, not the device:

• CDRs (Call Detail Records): every call and SMS with calling/called number, timestamp, duration, and serving cell tower ID.
• Tower dump: a list of all IMSIs attached to a specific cell tower during a specified time window — used to place suspects at a scene.
• Subscriber records: name, address, and identity document linked to the phone number and IMSI.
• IPDR (Internet Protocol Detail Records): data sessions with assigned IP address, bytes transferred, start/end timestamps, and serving cell ID. Mandatory for Indian operators to retain under law.

Cloud sync data. Modern phones continuously back up to cloud services. Even after a device is seized or wiped, cloud records may survive:

• iCloud (Apple): messages (if end-to-end encryption Advanced Data Protection is off), photos, contacts, call history, device backups.
• Google Account: Gmail, Google Drive files, Android backup, location history (Timeline), Photos.
• Samsung Cloud: Samsung device backups, contacts, notes.
• Cloud records may predate the device seizure and contain data that was deleted from the phone before seizure.

12.2Acquisition Methods — Four Levels

Think of acquisition methods as a pyramid. At the bottom sit the fastest, least invasive methods that recover the least data. At the top sit the most complete methods, which are also the most technically difficult and carry the highest risk of damage to the device. Choosing the right level depends on what evidence you need, what tools are available, and whether the device is locked.

Level 1 — Manual extraction (least complete). The examiner physically handles the phone, reads the screen, and photographs or manually notes what is visible — messages, call logs, contacts, photos. No specialised software is required. Appropriate for quick triage when tools are unavailable, or for fragile devices where connecting a cable risks further damage. Critical limitation: hidden data, deleted data, and anything below the visible app surface is completely missed.

Level 2 — Logical extraction. Software communicates with the phone over USB using standard protocols:

• Android: ADB (Android Debug Bridge) — requires USB debugging to be enabled. Commands like adb backup and adb pull export the phone's active data.
• iOS: iTunes backup or libimobiledevice library — connects via the trusted pairing record.

Logical extraction exports active (non-deleted) data: contacts, messages, photos, app data in a readable format. It does not reach unallocated space, deleted records, or hidden system directories. No root or jailbreak is needed for basic logical extraction.

Level 3 — File system extraction. Obtains the full directory tree of the device's file system, including hidden app directories, system files, and app databases that logical extraction cannot reach. Requires:

• Root on Android (superuser access to the device's Linux kernel)
• Jailbreak on iOS (bypassing Apple's code-signing restrictions)

With file system access, examiners can read SQLite databases directly, access deleted records within those databases (if not yet overwritten), and examine app caches and shared preference files. Tools: UFED (Cellebrite), Oxygen Forensic Detective, Magnet AXIOM.

Level 4 — Physical extraction (most complete). A bit-for-bit image of the device's flash memory chip — the digital equivalent of a forensic disk image. Includes all allocated space, unallocated space, and deleted data fragments. Three main techniques:

• JTAG (Joint Test Action Group): connecting test probes to the device's JTAG debug port on the circuit board; reads memory directly via the debug interface without removing the chip.
• Chip-off: physically removing the NAND flash chip from the circuit board and reading it with a chip reader. Provides the most complete image but carries a real risk of destroying the chip (and all evidence) if done incorrectly.
• EDL (Emergency Download Mode): a Qualcomm-specific mode (used in many Android devices with Qualcomm processors) that allows memory to be read over USB by sending a special bootloader command. Less destructive than chip-off.

Physical extraction requires specialist hardware, deep technical knowledge, and acceptance of a risk of permanent damage. It is justified when lower methods are blocked by encryption or device lock.

12.3Android Forensics

Android is an open Linux-based operating system, which gives forensic examiners more accessible paths to evidence than iOS — particularly when the device can be rooted.

Android storage layout. The underlying Linux file system organises evidence at predictable paths:

• /data/ — the user data partition; encrypted by default on Android 6.0+; contains all app data and system settings.
• /data/data/[package.name]/ — each installed app has its own sandboxed directory named by its package identifier. The subdirectories inside are standardised:
  • databases/ — SQLite database files for that app
  • shared_prefs/ — XML preference files (often include account tokens, settings, login state)
  • cache/ — temporary cached data (may contain recently viewed images, web content)
  • files/ — arbitrary files the app chose to store (e.g. WhatsApp stores its encryption key here)
• /sdcard/ or /storage/emulated/0/ — the user-accessible "internal SD" area; media files, downloads.
• /sdcard/DCIM/ — camera photos and videos with EXIF metadata.
• /data/system/ — system-level data: installed package list, accounts, gesture lock hash, password key.

ADB (Android Debug Bridge). The primary logical acquisition tool for Android. Requires USB debugging enabled in Developer Options. Key commands:

• adb backup — creates a full backup archive (format: .ab, parseable with Android Backup Extractor)
• adb pull /sdcard/ — copies the user-accessible storage to the examiner's machine
• adb shell — opens a command-line shell; with root access, provides direct file system access

Android encryption. Android 6.0 introduced mandatory Full Disk Encryption (FDE). Android 7.0 and later use File-Based Encryption (FBE), which encrypts each user's files individually with a key derived from their PIN/password/biometric. Without the correct PIN or password, the data partition is unreadable. Approach: attempt common PINs, check if device supports fingerprint unlock (biometrics bypass passcode entry), use specialised tools (Cellebrite UFED, GrayKey) to attempt PIN brute-force on vulnerable firmware versions.

Key app artefacts on Android:

WhatsApp forensics — critical detail. WhatsApp messages are stored in msgstore.db, which is AES-256 encrypted. The encryption key is stored in /data/data/com.whatsapp/files/key. You need both files to decrypt the database. Without the key, msgstore.db is unreadable. WhatsApp also creates backups in /sdcard/WhatsApp/Databases/ — the backup files (msgstore-YYYY-MM-DD.1.db.crypt15) use a different key derived from the Google account. On-device, the plain key file is the target.

12.4iOS Forensics

iOS is designed with a strong security model: hardware-level encryption, application sandboxing, and regular updates that close exploitation windows. This makes iOS forensics more challenging than Android and more dependent on specific tool capabilities for specific iOS versions.

iOS architecture for forensics. Every iPhone/iPad has a dedicated Secure Enclave — a separate co-processor that stores biometric templates (Face ID, Touch ID) and passcode-derived encryption keys. The main file system is encrypted with a hardware AES engine using keys tied to the device's unique ID (UID) fused into the chip at manufacture. This means:

• The storage is useless without the device — taking the flash chips to another machine does not help.
• The passcode is used to unwrap the encryption keys; without the passcode, data is inaccessible even with physical access to the chip.

Evidence source 1 — iTunes / Finder backup. When an iPhone is backed up to a PC or Mac, the backup is stored locally:

• Windows: %APPDATA%\Apple Computer\MobileSync\Backup\[device-UDID]\
• macOS: ~/Library/Application Support/MobileSync/Backup/[device-UDID]/

An unencrypted iTunes backup can be parsed immediately with tools like iMazing, Oxygen Forensic Detective, or Cellebrite UFED. It contains: SMS/iMessages, call history, app data, photos, voice memos, health data, and Safari history. An encrypted iTunes backup requires the backup password (separate from the device passcode) — if the backup password is unknown, it cannot be bypassed and must be brute-forced.

Evidence source 2 — iCloud backup. Apple stores iCloud backups encrypted on its servers. Investigators can obtain iCloud data via:

• Credentials (Apple ID + password + 2FA code) — allows direct download using tools
• Legal process (court order / LER to Apple) — Apple can provide non-end-to-end-encrypted categories of iCloud data (backups, iCloud Drive, Photos, contacts, calendar, mail)
• Advanced Data Protection (ADP): if the account holder has enabled ADP, Apple cannot access the data even with a court order; only the account holder's devices hold the keys.

Evidence source 3 — Direct extraction with jailbreak. If a public jailbreak is available for the device's iOS version, the examiner can install it to gain root access and perform a full file system extraction. Tools: checkra1n (for iPhone 5s–X on iOS 12–14.8, hardware-based exploit), palera1n (for A9–A16 on iOS 15–16). There is no public jailbreak for the latest iOS versions on the newest hardware; in these cases, law-enforcement-only tools like Cellebrite Premium or GrayKey may be able to extract data by exploiting undisclosed vulnerabilities.

Key SQLite databases in iOS:

• HomeDomain/Library/SMS/sms.db — iMessages and SMS messages (tables: message, chat, handle)
• HomeDomain/Library/CallHistoryDB/CallHistory.storedata — call log (calls, facetime, whatsapp calls if using standard iOS dialler)
• HomeDomain/Library/Safari/History.db — Safari browsing history
• HomeDomain/Library/Caches/com.apple.MobileSMS/ — image attachments
• AppDomain-com.apple.Maps/ — Maps search history and favourites

Location artefacts on iOS:

• KnownLocations.storedata — significant locations the device has recognised (home, work)
• Wi-Fi network list with geolocation estimates from Apple's Wi-Fi location database
• Google Maps and Apple Maps search history
• Photo library GPS EXIF metadata

12.5Location Evidence & Cell-Tower Analysis

Mobile location evidence appears in two distinct forms: network-side records (held by the operator) and device-side records (held on the phone). Both have different precision levels, different legal processes to obtain, and different forensic weight.

Cell ID / CGI (Cell Global Identity). Every individual sector of every BTS has a unique identifier: MCC + MNC + LAC (Location Area Code) + Cell ID. When a phone makes or receives a call, sends an SMS, or performs a location update, the serving cell's CGI is recorded in the CDR. The CDR therefore places the subscriber within that cell's coverage area at that time.

Cell coverage area depends on the environment:

• Dense urban: 200 metres to 1 kilometre radius (many small cells)
• Suburban: 1–5 kilometres radius
• Rural: up to 35 kilometres radius

This means CDR cell-tower location is not precise — it places a suspect within a potentially large area, not at a specific address. Expert testimony about tower coverage areas is typically required to explain CDR location evidence in court.

Tower dump. The investigator requests from the operator a list of all IMSIs that were attached to a specific cell tower during a specified time window (e.g. the hour during which a crime occurred at that location). This is used to narrow down suspects who were physically near a crime scene. Tower dumps raise significant privacy concerns because they capture data from all persons in the area, not just suspects — their use is subject to judicial oversight in India.

Triangulation / Multilateration. If the network has collected signal measurements from three or more towers simultaneously — such as timing advance values or signal strength — the device's position can be estimated by calculating the intersection of the coverage circles. In dense urban networks this can achieve 50–300 metre accuracy. This data is not present in standard CDRs; it must be specifically requested from the operator and is not always retained.

4G/5G data session location. Data session records (IPDRs) include the serving cell ID, providing continuous location evidence for smartphones that are connected to data networks — even when no voice call or SMS is made. A smartphone on 4G generates location-timestamped records every few minutes as it maintains a data connection.

GPS EXIF metadata in photos. This is often the most precise location evidence available from a mobile device. When a photo is taken on a phone with location services enabled for the camera app, the GPS coordinates are embedded in the image file's EXIF metadata:

• GPSLatitude and GPSLatitudeRef — latitude (degrees, minutes, seconds + N/S)
• GPSLongitude and GPSLongitudeRef — longitude (degrees, minutes, seconds + E/W)
• GPSDateStamp and GPSTimeStamp — UTC date and time of capture
• GPSAltitude — elevation in metres

Attackers often forget that photos sent or posted online carry this data. An image described as being taken at an "unknown location" may contain the sender's exact GPS coordinates, accurate to within a few metres. EXIF can be examined with tools like ExifTool, Autopsy, or any image forensics software.

Combining location evidence. In practice, examiners combine multiple sources:

1. CDR cell tower IDs (broad area, operator holds)
2. IPDR serving cell IDs (more frequent, data-session level)
3. Device GPS logs and app location history (precise, device holds)
4. Photo EXIF GPS (precise, timestamp-tied to an image)
5. Wi-Fi geolocation (Wi-Fi router MAC addresses mapped to locations by Apple/Google databases)

Each layer adds precision and corroborates the others. The strongest location evidence chain runs from CDR (places the phone in a cell area) through IPDR (continuous data session timestamps) to GPS EXIF (places the device at an exact coordinate).