14.1 Mobile Device Forensics: Manual, Logical, File System & Physical Extraction (Android/iOS)

14.1 Mobile Device Forensics: Manual, Logical, File System & Physical Extraction (Android/iOS)

Quick Answer: Mobile device forensics requires balancing data recovery depth against hardware and cryptographic constraints. The extraction hierarchy spans four core tiers: Manual (photographing the screen UI), Logical (API-based extraction using Android ADB or iOS iTunes backup protocols and lockdown pairing records), File System / Advanced Logical (extracting application sandboxes, system databases, and logs via bootloader exploits like checkm8 or temporary root agents), and Physical (bit-by-bit raw flash dumps of NAND partitions via EDL mode, JTAG, or ISP). Device security hinges on whether the handset is in Before First Unlock (BFU) state—where master encryption keys remain sealed in the Secure Enclave Processor (SEP) or Trusted Execution Environment (TEE)—or After First Unlock (AFU) state, where master keys reside in volatile RAM, permitting extensive file system extraction.

---

The Mobile Forensics Extraction Hierarchy

The National Institute of Standards and Technology (NIST SP 800-101 Rev. 1) and the Scientific Working Group on Digital Evidence (SWGDE) establish an extraction hierarchy for mobile devices. As an examiner ascends the extraction pyramid, technical complexity, equipment cost, and device risk increase, but so does the volume of recoverable data—specifically deleted records and unallocated database pages.

+-------------------------------------------------------------------------+
|                    MOBILE FORENSIC EXTRACTION PYRAMID                   |
+-------------------------------------------------------------------------+
|                         /\                                              |
|                        /  \         LEVEL 5: Micro Read (Electron Beam) |
|                       /----\        ----------------------------------- |
|                      /      \       LEVEL 4: Chip-Off / JTAG / ISP      |
|                     /--------\      ----------------------------------- |
|                    /          \     LEVEL 3: Physical Extraction (NAND) |
|                   /------------\    ----------------------------------- |
|                  /              \   LEVEL 2: File System / Advanced Log.|
|                 /----------------\  ----------------------------------- |
|                /                  \ LEVEL 1: Logical Extraction (APIs)  |
|               /--------------------\----------------------------------- |
|              /                      \ LEVEL 0: Manual UI Inspection     |
|             +------------------------+                                  |
+-------------------------------------------------------------------------+

1. Level 0: Manual Extraction

• Mechanics: The forensic examiner physically navigates the mobile device's user interface using the touchscreen or physical keypad, viewing and recording displayed data.
• Documentation: Conducted inside a specialized RF-shielded Faraday box equipped with internal viewing glass and integrated gloves. High-resolution digital video cameras or DSLR setups document every screen transition to maintain evidentiary integrity under Federal Rule of Evidence 901.
• Advantages: Essential when a device is locked with an unknown passcode, biometric unlock fails, the physical USB data port is damaged, or specialized acquisition cables are unavailable.
• Limitations: Highest degree of forensic contamination. Navigating the UI alters application state, updates system access timestamps, creates temporary cache records, and cannot recover deleted records, SQLite unallocated space, or hidden system artifacts.

2. Level 1: Logical Extraction

• Mechanics: Communicates directly with the operating system through standardized manufacturer application programming interfaces (APIs) or backup protocols over a USB connection.
• Android Acquisition Mechanisms:
  • Android Debug Bridge (ADB): If USB Debugging is enabled, the examiner invokes ADB over a workstation terminal or forensic workstation:

    # Generate a full logical backup of all user applications and shared storage
    adb backup -apk -shared -all -system -f android_logical_backup.ab
    
    # Pull accessible shared user media from emulated external storage
    adb pull /sdcard/ /evidence/android_sdcard_dump/
    

  • Content Providers: Forensic suites deploy a temporary signed helper application (agent) via ADB that queries native Android Content Providers (content://contacts/people, content://sms/inbox) to extract call logs, address books, and SMS messages.
• iOS Acquisition Mechanisms:
  • MobileDevice Framework & Apple Backup Protocol: Leverages Apple's AFC (Apple File Conduit) and backup service (com.apple.mobilebackup2).
  • Pairing Records (Lockdown Plists): When an iOS device is trusted by a host computer, an encrypted pairing record is stored on the host containing the device's unique identifier and cryptographic pairing keys:
    • Windows: %ProgramData%\Apple\Lockdown\<UDID>.plist
    • macOS: /var/db/lockdown/<UDID>.plist
    • Forensic Utility: If an examiner seizes a suspect's locked iPhone alongside their authorized computer, importing this lockdown plist onto the forensic workstation allows bypassing the lock screen trust prompt, enabling a full logical backup without knowing the passcode.
• Limitations: Only acquires data exposed by the OS backup protocol. Excludes operating system system logs, unallocated flash space, deleted database records, and many third-party application sandboxes that flag android:allowBackup="false" or iOS Data Protection Class A containers.

3. Level 2: Advanced Logical & Full File System (FFS) Extraction

• Mechanics: Bridges the gap between logical API extraction and physical raw dumps. FFS extracts the entire directory structure, file hierarchy, extended attributes, symbolic links, system logs, and application sandboxes from the active file system (ext4/F2FS on Android, APFS on iOS).
• Exploitation & Agent-Based Extraction:
  • checkm8 (iOS): An unpatchable bootrom (SecureROM) vulnerability affecting Apple A5 through A11 Bionic chips (iPhone 4S through iPhone X). Because the flaw exists in read-only mask ROM executed prior to iOS signature enforcement, it allows loading custom bootloaders and executing kernel-level code, granting direct read access to /private/var/ on AFU devices.
  • Agent Acquisition: Commercial forensic suites (Cellebrite, MSAB, Oxygen) dynamically inject a privileged agent into device memory utilizing known local privilege escalation (LPE) vulnerabilities or OEM-specific engineering authorization tokens.
• Evidentiary Yield: Yields full SQLite databases (including active WAL and SHM files), property lists (.plist), Apple Keychain items (when decrypted with hardware keys), and third-party end-to-end encrypted messaging databases (Signal, WhatsApp, Telegram).

4. Level 3: Physical Extraction

• Mechanics: Performs a bit-by-bit (raw image) dump of the physical non-volatile NAND flash memory chips (eMMC, UFS, NVMe). Captures the master boot record, partition tables, allocated file blocks, unallocated space, slack space, and hidden OEM recovery partitions.
• Low-Level Hardware Bootloader Bypasses:
  • Qualcomm EDL (Emergency Download) Mode: Qualcomm Snapdragon chipsets feature a primary bootloader recovery mode triggered via test points, special EDL cables (shorting D+ to GND), or key combinations. Examiners upload a cryptographically signed OEM programmer (known as a Firehose loader or Sahara protocol loader) directly into SoC internal SRAM to dump raw NAND storage over USB without booting Android.
  • MediaTek (MTK) BROM Mode: Exploits vulnerabilities in MediaTek BootROM (e.g., kamakiri bypass) via SP Flash Tool or forensic suites to disable hardware security watchdogs and dump eMMC/UFS partitions.
  • Samsung Download / Odin Mode: Utilizes proprietary Samsung low-level flashing protocols on Exynos chipsets to flash custom forensic recovery environments (e.g., TWRP) or dump storage directly.

---

Hardware-Level Direct Extraction Methodologies

When mobile devices suffer catastrophic physical damage (cracked motherboards, destroyed USB controllers) or aggressive firmware locks prevent USB communication, forensic examiners utilize hardware-level extraction.

+-------------------------------------------------------------------------+
|                 HARDWARE EXTRACTION METHOD COMPARISON                   |
+-------------------------------------------------------------------------+
| Method   | Physical Invasiveness | Soldering Skill | Risk to Device     |
|----------|-----------------------|-----------------|--------------------|
| JTAG     | Moderate (Test Pads)  | High (Micro)    | Low to Moderate    |
| ISP      | High (Trace Tap)      | Extremely High  | Moderate to High   |
| Chip-Off | Destructive (Desolder)| Master / Lab    | Critical (Heat/Pad)|
+-------------------------------------------------------------------------+

1. JTAG (Joint Test Action Group - IEEE 1149.1)

• Architecture: Developed as a boundary scan standard for testing printed circuit boards (PCBs) and integrated circuits post-manufacturing.
• Signals & Test Access Port (TAP): The TAP controller is driven by five dedicated hardware lines:
  1. TDI (Test Data In): Serial data input line shifted into device test registers.
  2. TDO (Test Data Out): Serial data output line read from boundary scan cells.
  3. TCK (Test Clock): Synchronizes internal state machine transitions.
  4. TMS (Test Mode Select): Directs transitions across the 16-state TAP controller.
  5. TRST (Test Reset): Optional asynchronous hardware reset line.
• Forensic Execution: Examiners solder microscopic wires to JTAG test pads on the motherboard and connect them to a JTAG emulator (e.g., Riff Box, Medusa Box). The CPU is instructed to halt its execution cycle, and the memory controller is commanded to read the raw contents of physical flash memory through the processor's boundary scan logic.
• Limitation: Very slow transmission speeds (often under 1 MB/s); newer processors disable or cryptographically fuse off JTAG ports during production packaging.

2. ISP (In-System Programming)

• Architecture: Bypasses the device processor entirely by connecting directly to the communications bus between the flash memory controller and the CPU.
• Wiring Infrastructure: Examiners solder microscopic copper fly-wires (0.02 mm jumper wires) to specific surface-mount test points or passive resistor pads on the motherboard:
  • CMD (Command Line): Transmits read commands.
  • CLK (Clock Line): Synchronizes bus timing.
  • DAT0 (Data Line 0): High-speed serial data extraction channel.
  • VCC (Core Power): Typically 2.8V–3.3V to power flash memory logic.
  • VCCQ (I/O Power): Typically 1.8V for flash controller I/O buffers.
  • GND (Ground): Common reference point.
• Forensic Execution: The fly-wires connect to an eMMC/UFS host adapter (e.g., EasyJTAG Plus, Z3X, PC-3000 Flash). The adapter supplies low voltage to power only the NAND flash memory, extracting a raw physical dump without energizing the CPU, baseband, or display.

3. Chip-Off Extraction

• Architecture: The ultimate, destructive hardware extraction technique. The flash storage chip is physically removed from the printed circuit board.
• Packaging Formats: Targets Ball Grid Array (BGA) components: BGA-153, BGA-162, BGA-221 (eMMC/eMCP), and BGA-254 (UFS).
• Desoldering Protocol:
  1. The motherboard is stabilized on a pre-heating plate (~100°C) to prevent board warpage.
  2. A precision hot-air rework station or infrared (IR) desoldering station applies controlled thermal energy (~240°C–260°C) to melt the lead-free solder balls underneath the BGA chip.
  3. The chip is lifted using vacuum tweezers. Excessive heat or mechanical prying can delaminate the silicon substrate or rupture solder pads, resulting in permanent, irreversible data loss.
  4. Solder residues are cleaned using flux and desoldering braid; the chip is cleaned in an ultrasonic bath with isopropyl alcohol (IPA).
  5. The chip is placed into a precision spring-loaded socket reader (e.g., UP828, PC-3000 Flash) to perform a direct block-level dump.
• The Encryption Roadblock: While chip-off was highly effective on legacy devices (Android 4.x and earlier), modern smartphones employ hardware-bound File-Based Encryption (FBE). Extracting raw NAND flash produces encrypted ciphertext that cannot be decrypted without the unique cryptographic keys burned into the host SoC's hardware fuses and Secure Enclave.

---

Mobile Operating System Security Architectures

+-------------------------------------------------------------------------+
|               ANDROID VS. IOS FORENSIC SECURITY COMPARISON              |
+-------------------------------------------------------------------------+
| Security Feature       | Android Architecture    | iOS Architecture     |
|------------------------|-------------------------|----------------------|
| Hardware Security      | ARM TrustZone / Titan M | Secure Enclave (SEP) |
| Default Encryption     | File-Based (FBE)        | Data Protection (FBE)|
| Boot Integrity Check   | dm-verity / AVB 2.0     | Secure Boot Chain    |
| Hardware Master Key    | Silicon eFuse / TEE Key | Hardware UID (fused) |
| Direct Boot Support    | Yes (DE vs CE Storage)  | Yes (Class C vs A)   |
| Ephemeral RAM Keys     | Destroyed upon reboot   | Purged upon reboot   |
+-------------------------------------------------------------------------+

Android Security Model

• Application Sandboxing & SELinux: Each installed app runs under a distinct Linux User Identifier (UID, e.g., u0_a145). Security-Enhanced Linux (SELinux) in enforcing mode strictly restricts process interactions using Mandatory Access Control (MAC) policies, preventing unauthorized processes from inspecting neighboring application sandboxes in /data/data/.
• dm-verity (Device-Mapper Verity): Part of Android Verified Boot (AVB). Uses a cryptographic Merkle hash tree to validate the block-level integrity of the base system partitions (/system, /vendor). If an examiner attempts to alter system partitions to inject an acquisition binary, dm-verity halts boot execution or triggers a factory reset.
• Full-Disk Encryption (FDE) vs. File-Based Encryption (FBE):
  • FDE (Legacy, Android 5.0–9.0): Entire user data partition (/data) encrypted with a single key protected by the user's lockscreen credentials. The phone cannot boot or receive calls until the passcode is entered.
  • FBE (Modern, Mandatory since Android 10): Individual files are encrypted with distinct cryptographic keys. Introduces Direct Boot mode, creating two storage tiers:
    1. Device Encrypted (DE) Storage: Encrypted with a key derived from hardware secrets and TEE, accessible as soon as the operating system boots, prior to any user passcode entry. Powers essential alarms, incoming telephone calls, and accessibility services.
    2. Credential Encrypted (CE) Storage: Encrypted with a key derived from the user's lockscreen credential (PIN, password, pattern) combined with TEE hardware secrets via key derivation algorithms (scrypt, Argon2id). CE storage remains completely locked and inaccessible until the user enters their credential.

iOS Security Architecture

• Secure Enclave Processor (SEP): A dedicated hardware security coprocessor running its own customized microkernel (SEPOS). SEP features secure boot, an on-chip random number generator (TRNG), and an isolated AES-256 hardware cryptographic engine.
• Silicon Hardware Keys:
  • UID (Unique Device Identifier): A 256-bit AES key permanently fused into the application processor silicon during manufacturing. It cannot be read by software or firmware; the hardware AES engine uses it directly for cryptographic operations. This ensures that encrypted data from an iPhone cannot be decrypted on any other hardware.
  • GID (Group Identifier): A key common to all processors in a device family, used for firmware validation.
• iOS Data Protection API Classes: iOS assigns every file to a specific protection class based on when its encryption key should be available in memory:
  • Class A (NSFileProtectionComplete): Maximum protection. The file key is decrypted and kept in RAM only while the device is actively unlocked. The instant the screen locks, the file key is purged from volatile memory. (e.g., Mail attachments, Health data).
  • Class B (NSFileProtectionCompleteUnlessOpen): The file key is created when the file is opened. If the screen locks while the file is open, the key remains in RAM until the file handle is closed.
  • Class C (NSFileProtectionCompleteUntilFirstUserAuthentication): The default iOS protection class. The file key is loaded into volatile memory after the user unlocks the device for the first time post-boot and remains in RAM indefinitely, even when the screen is locked, until the device is completely powered down or rebooted. (e.g., Photos, SMS databases, App sandboxes).
  • Class D (NSFileProtectionNone): Encrypted only with the device UID; available at all times without user authentication (system boot files).

---

The Critical Device States: BFU vs. AFU

In modern mobile forensics, whether a seized device is in BFU or AFU state determines the scope of evidence recovery.

+-------------------------------------------------------------------------+
|                    BFU VS. AFU FORENSIC STATE MATRIX                    |
+-------------------------------------------------------------------------+
| Metric / Capability    | Before First Unlock (BFU) | After First Unlock |
|------------------------|---------------------------|--------------------|
| Power State            | Powered off or rebooted   | Energized & locked |
| Master Keys in RAM     | None (Locked in SEP/TEE)  | Present in RAM     |
| Credential Storage     | Locked (Unmapped)         | Decrypted in RAM   |
| Class C iOS Data       | Inaccessible (Encrypted)  | Extractable        |
| Android CE Storage     | Inaccessible (Encrypted)  | Extractable        |
| Full File System Yield | Minimal (Only DE / Class D)| Maximum (Full Apps)|
| USB Restricted Mode    | Active immediately        | Active after timer |
+-------------------------------------------------------------------------+

1. Before First Unlock (BFU)

• Operational Condition: The smartphone is powered on, but the user has never entered their passcode since the boot event (e.g., seized immediately after a reboot or fresh power-on).
• Cryptographic Reality: The master file encryption keys have never been derived or loaded into volatile system memory. The keys remain locked inside the hardware Secure Enclave or ARM TrustZone.
• Forensic Scope: Highly restricted. On Android, only Device Encrypted (DE) storage is accessible (basic system configs, incoming call daemons). On iOS, only Class D files are readable. Third-party application data (WhatsApp, Signal, banking apps, photos) is encrypted ciphertext.

2. After First Unlock (AFU)

• Operational Condition: The device has been unlocked by the authorized user at least once post-boot. Even if the screen is currently locked and blacked out, the device remains in AFU state until powered off.
• Cryptographic Reality: The user passcode was successfully verified by the SEP/TEE, deriving the master file encryption keys and loading them into the operating system kernel's volatile memory. Class C and CE storage keys remain resident in RAM to process background tasks, push notifications, and incoming messages.
• Forensic Scope: High yield. Exploits or forensic agents injected into the running operating system can leverage the resident keys in memory to decrypt and acquire the complete file system (FFS), recovering third-party app databases, SMS, chat histories, and media.

[!IMPORTANT] First Responder Critical Rule: Never reboot, power off, or allow the battery to deplete on a seized mobile device! Powering down an AFU device forces it into BFU state, permanently purging encryption keys from RAM and reducing recoverable forensic evidence by up to 90%.

---

Commercial Mobile Forensic Toolsets

Digital forensic labs rely on validated commercial suites for mobile acquisition and analysis:

---

Real-World Forensic Case: The Locked Smartphone at a Narcotics Scene

Scene Triage & Acquisition Decision

During a federal narcotics raid, investigators seized an iPhone 11 and an Android Google Pixel 6. The iPhone screen was locked, displaying recent push notifications for an encrypted messaging service. The Google Pixel was powered off on a nightstand.

Forensic Methodology

1. Signal & Power Isolation: The examiner immediately connected the locked iPhone to an external battery pack to prevent power loss and placed both handsets into individual RF-shielded Faraday bags to prevent remote-wipe commands via Apple Find My or Google Find My Device.
2. State Assessment:
   • iPhone 11: Classified as AFU (After First Unlock) because it was powered on and actively displaying notifications. The examiner knew master Class C encryption keys were active in RAM.
   • Pixel 6: Classified as BFU (Before First Unlock). Powering it on in the lab would still leave it in BFU state, with Credential Encrypted (CE) storage inaccessible without the lockscreen PIN.
3. Lockdown Pairing Extraction: Investigators seized the suspect's MacBook Pro from the scene. The forensic examiner located the file /var/db/lockdown/<UDID>.plist on the MacBook. By importing this pairing certificate into Cellebrite UFED, the examiner established a trusted pairing connection to the locked iPhone without entering the passcode, successfully acquiring an Advanced Logical / File System extraction.
4. Outcome: Analysis of the iPhone's decrypted /private/var/mobile/ file system revealed SQLite chat databases documenting wholesale narcotics shipments, complete with GPS coordinates and supplier contact identifiers.

---

Rooting of Android and Jailbreaking of iOS Devices

Rooting (Android) and jailbreaking (iOS) remove the vendor's privilege restrictions so that arbitrary code may run with superuser rights and the whole file system becomes readable. The blueprint treats this as its own topic because it cuts two ways: it is both an acquisition technique and an evidentiary liability.

How Each Is Achieved

checkm8 matters disproportionately because it lives in read-only boot ROM: Apple cannot patch it on affected hardware, and it executes before the operating system, which is why forensic suites can obtain a full file system extraction from an A11-or-earlier device without modifying the user data partition.

Detecting a Device That Was Already Rooted or Jailbroken

This detection matters for two opposite reasons. If the suspect rooted the device, the security model that normally protects app sandboxes is gone, which broadens what an examiner can recover and weakens any argument that only the device owner could have written a given file. If the examiner's process rooted it, that is a modification of the evidence.

[!WARNING] Rooting or jailbreaking a seized device modifies it. Unlocking an Android bootloader triggers a mandatory factory reset that wipes user data on essentially every modern device — an irreversible destruction of the evidence. Jailbreaking writes to the file system and changes timestamps. The forensically defensible order is therefore: exhaust manual, logical, and advanced-logical methods first; use exploit-based file-system extraction (checkm8-class) that does not modify user data where the hardware permits; and treat a modifying root or jailbreak as a last resort requiring documented authorization, a stated justification, and a full record of every change made. Where an alternative method exists, using a destructive one is itself a finding against the examiner.