53 min read

> Where you are: Part III, Chapter 24 of 40, and the last chapter of the digital-forensics part. Chapter 23 — Network Forensics followed evidence out onto the wire — packets, flows, NetFlow, the captured session. Now we come back to the endpoint...

In This Chapter

Exercises Quiz Case Study 01 Case Study 02 Key Takeaways Further Reading

Chapter 24: Mobile Device Forensics — Extracting Evidence from Phones and Tablets

Where you are: Part III, Chapter 24 of 40, and the last chapter of the digital-forensics part. Chapter 23 — Network Forensics followed evidence out onto the wire — packets, flows, NetFlow, the captured session. Now we come back to the endpoint, but to the most personal endpoint a person owns: the device in their pocket. Chapter 11 — Mobile Device Recovery taught you to get a cooperative owner's data back from a phone; this chapter is its forensic twin — the same soldered storage and the same hardware encryption, but now under a warrant, often against an uncooperative subject, with everything you do bound for a courtroom. This is where anchor case #4 — the forensic image analyzed in court — moves from the laptop to the handset, because in a modern case the phone is frequently the single richest source of evidence there is.

Learning paths: 🔍 Forensic Examiner owns this chapter outright: mobile is now the most common evidence type in both criminal and civil matters, and the acquisition pyramid here is the core skill. 🛡️ Incident Response cares about corporate, BYOD, and MDM-managed phones, and about compromised devices used as a foothold. 📜 Legal/eDiscovery must read the encryption-and-compulsion section and the message-authentication discussion closely — phone messages win and lose cases. 💾 Data Recovery technicians should read this for the boundary: your home is Chapter 11, and the moment a recovery job turns up evidence of a crime, you need to already understand the rigor this chapter demands.

The phone is the witness that goes everywhere

A hard drive sits on a desk. A server lives in a rack. A phone goes to bed with its owner, rides in their pocket to work, sits on the restaurant table, and records — quietly, continuously, with timestamps — where it was, what it connected to, who it talked to, how many steps its owner took, and what apps were on the screen at 2:14 a.m. No other device in the history of evidence has been so intimate, so constant, and so honest. When examiners say the phone is "the witness that goes everywhere," they are not being poetic. They are describing a sensor package strapped to a human being for sixteen hours a day, logging to dozens of SQLite databases the owner has never heard of.

That is why mobile forensics has, in roughly a decade, moved from a niche specialty to the center of the discipline. A homicide is now reconstructed from health-app step counts and "significant locations" caches. A fraud is unwound from messaging-app threads and screenshot timestamps. A custody dispute turns on call logs and photo geotags. A corporate trade-secret case — anchor #2 of this book, the engineer who covered their tracks — increasingly includes a personal phone the employee used to photograph a monitor full of CAD drawings, because no USB device was ever plugged in. The evidence migrated to the handset, and so did the examiner.

Consider the intake that anchors this chapter. A sealed evidence bag arrives at your lab. Inside is a smartphone, seized under a search warrant in a child-exploitation investigation — anchor case #4, which recurs from Chapter 5 — The Forensic Process and which we handle, here as everywhere, clinically and non-graphically: procedure, law, and ethics only. The warrant authorizes examination of the device for specific categories of evidence. The phone is powered on. The bag is a Faraday bag, because somewhere a person who knows the passcode may be trying to wipe it remotely right now. Your entire job — acquisition, analysis, reporting, and one day testimony — flows from the next decisions you make about that warm, glowing, network-isolated object. Everything in this chapter is in service of getting its evidence out in a way that is both technically maximal and legally bulletproof, and of knowing, honestly, when the device will not give it up.

Why This Matters. Theme #4 of this book is technology changes, principles don't. Mobile is the proving ground for that claim. The hardware churns every year — new SoCs, new Secure Enclave generations, new file-based-encryption schemes, a new flagship that closes the exploit that worked last quarter — and the working examiner who chases capabilities will always be a step behind. What does not change is the method: understand the security model, isolate and preserve the device, acquire at the highest forensically sound level you can reach, verify with hashes, parse with validated tools, corroborate across artifacts, and report findings with their limitations intact. Learn the principles and the capabilities become details. Chase the capabilities and you will be obsolete by the next iOS release.

Why mobile is its own discipline

You already met the architectural facts in Chapter 11, so we will not re-derive the iOS key hierarchy or the Android FBE model from scratch — go back and reread those sections, because every word of them applies here. What changes in the forensic context is the stakes attached to each fact.

The storage is soldered and OS-mediated. On a desktop you attach the drive to a hardware write-blocker and image it bit-for-bit (Chapter 14 — Forensic Acquisition); the original is never written to, and admissibility follows naturally. On a phone, the NAND is a BGA package and the only practical path to its contents runs through the device's own processor, OS, and security hardware. There is no write-blocker for a running iPhone. This collides head-on with theme #2 — the original is sacred — because on mobile you frequently cannot acquire data without changing the device at all. You enable USB debugging; you install an extraction agent; you exploit the bootrom; you root the phone. Every one of those is a modification of the original. Mobile forensics therefore does not pretend the original is pristine — it does the next best thing: it minimizes, documents, and justifies every change, and it validates that the changes did not alter the evidence you care about. That shift — from "never touch the original" to "touch it as little as possible, and prove what you touched" — is the single biggest mental adjustment for an examiner coming from disk work.

Encryption is on by default and hardware-bound. The same Secure Enclave UID and Android TEE/StrongBox keystore that defeat the recovery technician in Chapter 11 defeat the forensic examiner too — with one difference: the examiner may have legal authority and specialized tooling to attempt a passcode, an option a private recovery shop neither has nor should have. We treat that whole domain in its own section below, because the line between "lawful forensic unlock" and "illegitimate access" is exactly where careers are made or ended.

And the ecosystem is fragmented and fast. Thousands of phone models, two dominant OSes with many versions, and an app store where the location of every artifact can change with an app update. Disk forensics rewards deep knowledge of a handful of file systems; mobile forensics rewards that plus a tolerance for a moving target and a habit of validating where today's version of WhatsApp actually writes its database before you testify about it.

The acquisition pyramid: five levels of mobile extraction

There is no single "image the phone" step in mobile forensics the way there is for a hard drive. Instead there is a pyramid of acquisition methods, ordered from least invasive and least complete at the top to most invasive and most complete at the bottom. The governing principle is simple and you should say it out loud on every case: acquire at the highest (most complete) level you can reach that is forensically sound and within your authority — and document everything you cannot reach and why. The classic model has five levels.

                 MOBILE ACQUISITION PYRAMID
                 (top = least data, least invasive;
                  bottom = most data, most invasive)

                    ╱╲   1. MANUAL
                   ╱  ╲     scroll & photograph the screen
                  ╱────╲    no special tools; reproducible by anyone
                 ╱      ╲  2. LOGICAL
                ╱        ╲    backup / API / content providers
               ╱──────────╲   the "supported, sanctioned" data set
              ╱            ╲ 3. FILE SYSTEM
             ╱              ╲   full file system: app DBs, caches, plists,
            ╱────────────────╲  SQLite WAL/journal, deleted records inside DBs
           ╱                  ╲ 4. PHYSICAL
          ╱                    ╲  bit-for-bit image of the flash partition(s)
         ╱──────────────────────╲ incl. unallocated, slack, deleted files
        ╱                        ╲ 5. CHIP-OFF / JTAG / ISP
       ╱__________________________╲  remove or tap the NAND directly — LAST RESORT
                                       (on encrypted devices: returns ciphertext)

  Completeness ↑  as you descend.   Forensic soundness ↓  (more device change)
  Recoverable deleted data appears at level 3 and explodes at level 4.

The pyramid is not a menu where lower is always better. It is a decision under constraints: what the device, its lock state, its OS version, your tools, and your legal authority permit today. A perfect physical image is worthless if obtaining it requires an exploit you do not have or a modification your authority does not allow. Often the honest, defensible answer is "a full file-system extraction was the highest level achievable on this model at this iOS version, and here is why physical was not possible." Let us walk each level.

Level 1 — Manual extraction

Manual extraction is exactly what it sounds like: you operate the phone by hand and document the screen — photographs of each message thread, each call-log entry, each photo, ideally with a documentation stand and a camera, or by screen-recording while you scroll. It requires no special hardware and no exploit; anyone can do it, which is also its forensic strength — a second examiner can reproduce it.

Its weaknesses are equally obvious. It is slow, it is error-prone (miss one swipe and you miss a message), it captures only what the UI chooses to show you (no deleted records, no metadata, no underlying database), and operating the live device changes its state (you generate new "last opened" timestamps, mark messages read, and so on). Manual is therefore a supplement and a fallback, not a primary method: you use it to capture something an automated tool failed to parse, to document the phone's visible state at intake, or as the only option on a device no tool supports. When you do it, narrate and timestamp every action so the manipulation is part of the record, never a silent contamination.

Level 2 — Logical extraction

Logical extraction pulls the data the device's own sanctioned interfaces are willing to hand over: an iTunes/Finder backup on iOS, the (now largely deprecated) adb backup and content-provider queries on Android, vendor backup APIs. You are asking the OS, through documented channels, "give me your messages, contacts, call logs, photos, and app data," and taking what it offers. It is fast, it is well supported by every commercial tool, and — crucially — it usually requires the device to be unlocked or the backup password known, which means it typically applies to cooperative-subject, consent, or AFU situations.

Its ceiling is the backup format itself. A logical extraction gives you the current, live records the backup includes — and not the application-private data the backup excludes, the system caches, or (with rare exceptions) deleted records. It is the same iTunes-backup Manifest.db world you learned to parse by hand in Chapter 11; the difference is posture, which we will return to in a moment. For many cooperative cases a logical extraction is sufficient — it answers the question — and a good examiner does not desolder a chip to prove a point a backup already proved.

Level 3 — File-system extraction

This is the level that separates real mobile forensics from "I read the backup." A file-system (often abbreviated "full file system," FFS) extraction copies the entire user data file system — not just what a backup exposes, but every application's private directory, every cache, every plist, every SQLite database and its -wal and -journal side files, and the metadata the backup format strips out. On iOS that means the contents of /private/var/mobile/... in full; on Android it means a copy of the /data partition's file tree.

Why it matters so much: most mobile evidence is SQLite, and SQLite keeps deleted records in freelist pages and in the write-ahead log until they are overwritten or vacuumed (we devote a whole section to this below). A backup hands you the database's live rows; a file-system extraction hands you the database file, including the unallocated regions inside it where deleted messages and call entries still live. This is deleted is not destroyed (theme #1) operating inside a database file, and it is invisible to a level-2 logical pull. File-system extraction is also where you reach the protected, AFU-only data: the keychain-adjacent stores, the Health database, knowledgeC.db, the location caches.

The cost is invasiveness. Reaching the full file system generally requires elevated access the OS does not normally grant: a jailbroken or agent-instrumented iPhone, a rooted Android, or an exploit-based tool that installs a temporary extraction agent. Each of those modifies the device, which is why this level lives below logical on the soundness axis and why documenting and validating the modification is non-negotiable.

Level 4 — Physical extraction

A physical extraction is the mobile analogue of the disk image you know from Chapter 14: a bit-for-bit copy of the flash storage (or of the userdata//data partition), including allocated files, deleted files whose file-system pointers are gone, slack, and unallocated space. From a physical image you can carve files (Chapter 7 — File Carving), recover deleted files the file system no longer references, and analyze the raw structures — everything Part II taught you to do to a disk image.

The catch — and it is the catch that dominates modern mobile forensics — is encryption. On a current phone, a physical image of userdata is a perfect bit-for-bit copy of ciphertext. Without the keys, which are bound to the Secure Enclave or the TEE and gated behind the user's credential, the bytes are noise. A true, decrypted physical extraction on a modern device is only possible when you have defeated or been given the encryption (known passcode + AFU, a working exploit chain), at which point the "physical" tools actually produce a decrypted file-system-plus-unallocated image. On older or unencrypted devices, a raw physical read is genuinely powerful; on a 2020s flagship, "physical" without keys is the cloned-safe problem from Chapter 11.

Level 5 — Chip-off, JTAG, and ISP

At the bottom of the pyramid are the hardware techniques: chip-off (desolder the BGA NAND package and read it in a programmer), JTAG (drive the CPU's boundary-scan port to read memory through the processor), and ISP (solder to the eMMC/UFS test points and read in place). These were detailed in Chapter 11; the forensic facts are identical and the disappointment is the same: on an encrypted device, all three return ciphertext. They are a last resort, reserved for dead boards, unencrypted/legacy devices, devices no software method supports, and cases where preserving the physical NAND is itself the goal. Chip-off is also destructive to the mount and risks heat damage, so it sits at the very bottom for good reason: maximum data potential, maximum invasiveness, and — on a modern locked phone — frequently maximum disappointment.

Recovery vs. Forensics. The five levels are the same techniques a recovery technician uses in Chapter 11; what changes is authority, goal, and rigor. A recovery tech does a logical pull because it is the fastest way to restore the owner's texts. A forensic examiner does a logical pull because it is the highest level the device permits and then documents that ceiling for the court — "a file-system extraction was attempted and failed on this OS version; logical was the maximum achievable; the limitation is noted." The recovery tech stops when the data is back. The examiner keeps going to the highest sound level and records, hashes, and validates every step, because the deliverable is not the data — it is provable, court-admissible data plus an honest account of what could not be reached. Same cable, same exploit, entirely different paperwork.

Chain of Custody. Every level produces an output file or image, and every output gets the same treatment as a disk image: compute a hash immediately (the tools embed extraction hashes; verify and record them), store the original extraction read-only, and work on a copy. A defensible note reads: "Cellebrite UFED full-file-system extraction of Apple iPhone (model A2403, iOS 16.3.1), device serial F2L…, performed [date/time] under warrant #…; extraction archive phone.ufd/.zip, SHA-256 7b91…; examiner [name]; device returned to evidence storage, Faraday bag re-sealed." Because mobile acquisition changes the device, the chain-of-custody record must also state precisely what was changed — "USB debugging enabled," "extraction agent installed and removed," "device kept powered to preserve AFU state" — so the modifications are disclosed, not discovered on cross.

iOS forensics

Apple controls the silicon, the OS, and the security model, which makes iOS the more predictable platform to examine even though it is often the harder one to crack. Build the security model into your bones (the full version is in Chapter 11 and it returns in Chapter 29 — Encrypted Device Forensics); here we apply it to acquisition.

The security model, applied to acquisition

Three facts drive every iOS acquisition decision. First, file-level encryption with hardware-bound keys: every file is encrypted under a key that ultimately depends on the Secure Enclave's fused UID, so ciphertext copied off the NAND is useless without the original SEP. Second, Data Protection classes and the AFU/BFU distinction: most app data is class C ("Complete Until First User Authentication"), whose keys become available after the first unlock following boot and stay resident until reboot. Therefore an AFU device (booted and unlocked at least once, not since rebooted) yields the bulk of its data to a capable tool, while a BFU device (freshly booted, never unlocked) yields almost nothing but the unprotected scraps. Third, the Secure Enclave throttles passcode guessing in hardware: you cannot lift the encrypted blob to a cluster and brute-force offline; only the original phone's SEP can test a passcode, slowly, with escalating delays and optional auto-wipe.

The operational consequences are immediate and they shape intake. Keep a seized AFU phone alive and unlocked-state. Do not let it power off (BFU on next boot), do not let it lock-and-reboot, keep it charged, and isolate it from the network so it cannot be remotely wiped or pushed into a locked state. This is the live-acquisition discipline from Chapter 15 — Live Response and Triage applied to a handset: the volatile, decryptable state lives in RAM-resident keys, and a reboot evicts them.

Why This Matters. A phone arriving powered-on and unlocked-since-boot is a fundamentally different — and far better — evidence prospect than the identical phone arriving powered-off. The data is the same; the accessibility is not. This is why first-responder training drills "do not power it down, do not let it die, bag it in a Faraday with a battery pack" — the difference between AFU and BFU can be the difference between a full file-system extraction and a forensic dead end, on bit-for-bit identical hardware. Theme #5, know your limitations, starts before you ever touch a tool: the device's state at seizure sets your ceiling.

iTunes/Finder backups as a forensic source

The fastest sound iOS acquisition, when you have an unlocked device or a known backup password, is to make (or analyze an existing) iTunes/Finder backup — the Manifest.db world you learned by hand in Chapter 11. The forensic twist is one setting that you, the examiner, should usually turn on: encrypted backup.

Counterintuitively, an encrypted iTunes backup contains more than an unencrypted one. An unencrypted backup deliberately omits the most sensitive stores; an encrypted backup additionally includes saved passwords and the keychain, Health data, call history, and Wi-Fi settings. So a standard forensic move on a cooperative or AFU iOS device is to set a backup password you choose (recording it in your notes), create an encrypted backup, and then decrypt it with that password to expose the keychain and Health data a plain backup would have withheld. Tools automate this; the point is to understand why you flip the switch — you are trading a known, documented modification (setting a backup password) for a materially larger, decryptable evidence set.

The backup's Info.plist hands you the device's identity for the report — serial, IMEI, phone number, product type, last-backup date — tying the data to a specific handset. And the database files inside are ordinary SQLite, recognizable by their 16-byte header, the same magic you have seen since Chapter 2:

  Offset    00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F   ASCII
  00000000  53 51 4C 69 74 65 20 66  6F 72 6D 61 74 20 33 00   SQLite format 3.
  00000010  10 00 01 01 00 40 20 20  ...                       ^^^^ page size
            (bytes 16-17 = 0x1000 = 4096-byte pages, big-endian)

The Apple .plist metadata files come in two flavors. XML plists begin with <?xml; binary plists begin with the magic 62 70 6C 69 73 74 30 30 — the ASCII string bplist00 — and need a plist parser (every forensic suite and Python's plistlib handle both):

  Offset    00 01 02 03 04 05 06 07   ASCII
  00000000  62 70 6C 69 73 74 30 30   bplist00     ← binary property list
            (trailer at end-of-file gives object count + offset table)

The keychain

The iOS keychain is the encrypted store for the device's secrets: account passwords, authentication tokens, Wi-Fi passphrases, certificates, and many apps' credentials. Forensically it is extraordinary, because tokens and saved passwords often unlock cloud accounts that hold even more evidence (the bridge to Chapter 31 — Cloud Forensics). Each keychain item carries its own Data Protection class, and that class governs whether you can ever read it: items marked WhenUnlocked or AfterFirstUnlock can be decrypted from an encrypted backup or an AFU extraction, while items marked ...ThisDeviceOnly are bound to the SEP and do not migrate — they cannot be carried off in a backup and read elsewhere, by design. Knowing which is which keeps you from overclaiming: "the device's saved Gmail token was recovered from the keychain" is a finding; "all of the device's secrets were recovered" usually is not, because the device-only items stayed behind.

APFS and file-system extraction

Since iOS 10.3 the data volume is APFS (Apple File System): copy-on-write, with native snapshots, clones, and per-file encryption. Three APFS behaviors matter to an examiner. Copy-on-write means an overwritten block is written elsewhere and the old block lingers until reclaimed — friendly to recovery. Snapshots are point-in-time images of the volume that iOS creates (for example, before OS updates); a file-system extraction that captures snapshots can reveal prior states of files, including data the user later changed or deleted. And the per-file encryption is the class-key system above, so a file-system extraction only yields plaintext for the classes whose keys are available in the device's current state (AFU vs. BFU again).

A full-file-system extraction is the iOS sweet spot when you can reach it: it captures every app's private SQLite databases with their -wal/-journal files, the caches, the plists, and the protected stores (Health, location, knowledgeC.db) that backups omit. Reaching it requires elevated access — historically a jailbreak, today an exploit-based agent delivered by a commercial tool — which is a documented device modification, not a free lunch.

checkm8 and the limits of the modern era

No iOS topic generates more confusion than checkm8. In 2019 the researcher axi0mX published a bootrom exploit affecting Apple SoCs from the A5 through the A11 — that is, roughly the iPhone 4S through the iPhone 8, 8 Plus, and X. Because the flaw is in read-only bootrom code, Apple cannot patch it on affected hardware; it is permanent for those models. For forensics, checkm8-class capability enables booting a custom environment that can perform BFU extraction of the unprotected data even on a locked device, and — with the passcode, or after a successful passcode attack — a full AFU/file-system extraction. It is the technical backbone of several law-enforcement tools for legacy iPhones.

Then comes the wall. The A12 and later SoCs (iPhone XS/XR, 2018, onward) are not vulnerable to checkm8, and Apple hardened the Secure Enclave against the offline and replay tricks that made older devices tractable. On current hardware, the realistic options narrow to: a known passcode (consent, compelled production, or AFU state) feeding a normal extraction; or a commercial exploit service — Cellebrite Premium, Grayshift's GrayKey — whose success is model-, OS-version-, and patch-level-dependent and frequently lags the latest iOS by months or fails outright. There is no public, durable, A12-and-later "just unlock it" capability, and any vendor who implies otherwise is selling hope. This is theme #4 in one paragraph: the exploit that owned every phone in 2019 owns nothing made after 2018, and the only durable lesson is the principle, not the trick.

Tool Tip. When you have a file-system extraction (or even a logical one) and want a free, transparent, court-explainable parser, reach for iLEAPP (the iOS Logs, Events, And Plists Parser, by Alexis Brignoni). It ingests an extraction and emits an HTML/CSV report covering hundreds of artifacts — knowledgeC.db app usage, Safari history, com.apple.routined significant locations, Health, Wi-Fi, and more. Because it is open source you can read exactly how each artifact is parsed and cite that in your methodology — invaluable under Daubert (Chapter 27 — Expert Testimony). Use it to validate commercial-tool output: when iLEAPP and Cellebrite Physical Analyzer agree on a timestamp, your finding is robust to either tool's bug.

Limitation. State the A12 reality to investigators before they pin a case on the phone's contents. For an A12-or-later iPhone that is locked, BFU, with an unknown passcode and no exploit available for its OS version, full extraction may be impossible by any means available to you, exactly as in Chapter 11. "Extraction was not achievable on this device at this OS version" is a complete, professional finding, and saying it early saves a case from being built on evidence that will never arrive.

Android forensics

Android trades Apple's uniformity for sprawl: many manufacturers, many chipsets, many OS versions, many security implementations. The encryption reality matches Apple's — File-Based Encryption (fscrypt) is default from Android 10, with per-file keys protected by the TEE (ARM TrustZone) and, on the strongest devices, a StrongBox security chip with hardware-enforced attempt throttling (the model from Chapter 11). But the variance is enormous, which means both more opportunities and more pitfalls than iOS.

Logical acquisition with ADB

When the device is unlocked and USB debugging is authorized, the Android Debug Bridge (adb) is the sanctioned logical channel — with the same prerequisites that frustrate beginners: USB debugging enabled in Developer Options, the device unlocked (so Credential-Encrypted data is available), and the host authorized via the on-screen RSA-fingerprint prompt. Without all three, adb cannot reach user data; that gate is a security feature, not a bug.

The old workhorse adb backup -all is deprecated and largely neutered from Android 12 onward (most apps opt out; newer releases return little). What still works for a logical pull is a combination of shared-storage copies and content-provider queries, which ask Android's structured data providers directly:

# Confirm the device is visible and authorized
adb devices -l
# 9A271FFBA00123   device  product:redfin model:Pixel_5 ...   ("device" = authorized)

# Identify the device for the report
adb shell getprop ro.product.model            # Pixel 5
adb shell getprop ro.build.version.release     # 13
adb shell getprop ro.build.version.security_patch

# Query structured data via content providers (logical level)
adb shell content query --uri content://call_log/calls \
  --projection number:date:duration:type
adb shell content query --uri content://sms \
  --projection address:date:type:body
adb shell content query --uri content://com.android.contacts/data \
  --projection display_name:data1

# Pull shared media (the common, owner-visible win)
adb pull /sdcard/DCIM        ./dcim
adb pull /sdcard/Download     ./download

# A full diagnostic snapshot (logical, broad)
adb bugreport ./bugreport.zip

Logical acquisition on Android is fast and well supported, but its ceiling is the same as iOS: it reaches shared storage and what providers expose, not the protected /data/data/<package>/ app-private directories where the message databases, account tokens, and the richest evidence live. For those you need file-system or physical access — which on Android usually means root.

Rooting for full access — the forensic dilemma

To copy /data in full you generally need root, and rooting is the central ethical and methodological problem of Android forensics, because rooting modifies the device. There are two broad approaches, and the distinction is forensically load-bearing:

  • Temporary / exploit root — a vulnerability is used to gain root for the current boot only, nothing is written to persistent partitions, and the change evaporates on reboot. This is the forensically preferable path because it perturbs the evidence the least.
  • Permanent root (e.g., flashing Magisk) — modifies the boot partition and persists. It is more reliable but writes to the device, a larger and more disclosable change, and on many modern phones it trips Verified Boot or requires unlocking the bootloader, which itself wipes userdata on most devices — a catastrophic, irreversible loss of the very evidence you came for.

That last point is the trap that has destroyed cases: unlocking the bootloader to root a phone factory-resets it. Never unlock a bootloader on an evidence device without certainty about its wipe behavior; the default on Pixel and most modern Androids is "unlock = wipe." When rooting is justified and performed, you must document exactly what you did, why it was necessary, and validate that it did not alter the data you report on — typically by reasoning about which partitions the method touches and by corroborating findings across independent artifacts. This is theme #2 at its hardest: you cannot keep the original perfectly pristine, so you minimize, disclose, and prove.

Ethics Note. Rooting an evidence phone is a deliberate modification of original evidence, and you do it only with authority, only when a lower level cannot answer the question, and only with full documentation. Doing it casually — "I always root them, it's faster" — is how an examiner ends up explaining on cross why they altered the defendant's device with a method they cannot fully account for. The fuller treatment of justified-modification and validation lives in Chapter 28 — Ethics; the rule of thumb is: every change to the original must be necessary, authorized, documented, and validated, or it does not happen.

Partition analysis: userdata and friends

An Android device's storage is partitioned with GPT, and an examiner should be able to read the layout. The prize is userdata (mounted at /data), which holds every app's private data; on modern FBE devices a small metadata partition holds encryption metadata so that even file names and sizes in /data are protected before first unlock. Other partitions — boot, system, vendor, super (on dynamic-partition devices) — matter for integrity and for rooting decisions.

  Typical modern Android partition layout (parted/gpt view, abbreviated)
  Number  Name        Filesystem   Notes
   ...
   24     metadata    ext4         FBE key metadata (protects /data pre-unlock)
   25     userdata    ext4 / f2fs  /data  ← THE PRIZE: all app-private data
   ...
   (system/vendor often inside a 'super' dynamic partition on recent devices)

The /data file system is ext4 or F2FS (Flash-Friendly File System, log-structured, common on modern phones because it suits flash garbage collection). A physical image of userdata — obtainable with root via dd-style reads to an external target, or by a commercial tool — gives you allocated files, deleted files whose inode pointers are gone, slack, and unallocated space, all parseable with the Part II disk-forensics toolkit (The Sleuth Kit's fls/icat, carving, ext4 inode analysis from Chapter 4 — File Systems). And the same caveat governs: if userdata is FBE-encrypted and the credential is unknown, that bit-for-bit image is ciphertext.

EDL, MediaTek, and low-level imaging

Below the OS, many chipsets expose a flashing/repair mode that can, in principle, image storage. Qualcomm's EDL (Emergency Download, USB "9008") mode is driven by signed, model-specific "firehose" programmers; MediaTek exposes a BROM (boot ROM) download mode driven by a Download Agent. In the right hands, with the right signed loaders, these can read partitions beneath a running OS — genuinely useful for unencrypted or older devices, for damaged devices, and for some specialized law-enforcement workflows.

Two cautions keep EDL/MTK in proportion. First, modern devices demand vendor-signed, model-specific loaders that are not freely available, and security-hardened SoCs have closed many of these doors. Second — and this is the recurring refrain — even a successful EDL/BROM read of a modern device returns an encrypted userdata image. EDL is a tool for the unencrypted/legacy corner of the landscape and for shops with the right signed loaders, not a universal "image any locked Android" button. Treat "EDL unlocks anything" claims with the same skepticism as iPhone chip-off claims.

Recovery vs. Forensics. An adb pull of /sdcard/DCIM is a fine recovery move — fast, owner-authorized, gets the photos back (Chapter 11). As forensics it is weak: it is selective, it can touch access times, and it cannot reach /data/data where the real evidence hides. The forensic examiner with authority over the same phone reaches for file-system or physical extraction — temp-root + dd, or Cellebrite/AXIOM/XRY — to capture the protected partitions with verifiable integrity. Same cable and often the same exploit; the difference is that the examiner captures everything the law and the device allow, hashes it, and can prove on the stand that the bytes are unaltered.

Mobile artifacts: where the evidence lives

Once you have an extraction, the work becomes artifact analysis — and here is the single most important structural fact about modern mobile evidence: almost all of it is SQLite. Messages, call logs, contacts, browser history, photo libraries, location caches, health data, and the internal stores of nearly every app are SQLite databases. Learn to read SQLite forensically and you can read a phone; the artifact locations shift with OS and app versions, but the format is constant. The canonical paths below are stable enough to memorize and are collected in Appendix D — Forensic Artifact Locations; always verify the current path on the version in front of you.

Calls, SMS/MMS, and RCS

Call logs and messages are the backbone of most cases. On iOS, SMS/iMessage live in sms.db (HomeDomain → Library/SMS/sms.db), with messages in the message table joined to handle (the other party) and chat; the call log is CallHistory.storedata (Library/CallHistoryDB/). On Android, SMS/MMS live in the telephony provider's mmssms.db (/data/data/com.android.providers.telephony/databases/, sms and pdu tables), and the call log in the contacts provider's contacts2.db (calls table). RCS — the carrier-grade successor to SMS, used by Google Messages — is stored separately in bugle_db (/data/data/com.google.android.apps.messaging/databases/), and examiners who only parse mmssms.db miss the RCS conversations entirely, a common and costly oversight on current Androids.

iOS timestamps are a particular trap worth coding once. The date columns are Mac absolute time (Cocoa/CFAbsoluteTime) — seconds since 2001-01-01 UTC — and since iOS 11 sms.db stores them in nanoseconds since that epoch. Convert carefully:

import sqlite3, datetime

# Cocoa/Mac-absolute epoch (2001-01-01) is 978307200 s after the Unix epoch (1970-01-01)
COCOA_EPOCH = 978307200

def cocoa_to_utc(value: int) -> datetime.datetime:
    # iOS 11+ sms.db stores nanoseconds; older iOS and many DBs store seconds.
    secs = value / 1_000_000_000 if value > 1_000_000_000_000 else value
    return datetime.datetime(1970, 1, 1, tzinfo=datetime.timezone.utc) \
        + datetime.timedelta(seconds=COCOA_EPOCH + secs)

con = sqlite3.connect("sms.db")           # work on a COPY, never the extraction original
for rowid, text, dt, is_from_me, party in con.execute(
        "SELECT m.ROWID, m.text, m.date, m.is_from_me, h.id "
        "FROM message m LEFT JOIN handle h ON m.handle_id = h.ROWID "
        "ORDER BY m.date"):
    print(cocoa_to_utc(dt).isoformat(), "->" if is_from_me else "<-", party, repr(text))

Get that epoch wrong and your entire timeline is off by 31 years — a mistake that has actually reached reports. Android, by contrast, generally stores Unix milliseconds; the lesson is the same: know each artifact's time base and validate it against a known event before you build a timeline (Chapter 21 — Timeline Analysis).

Contacts, photos, and geolocation

Contacts come from AddressBook.sqlitedb (iOS) or contacts2.db (Android). Photos and videos are doubly valuable: the media files carry EXIF metadata, and a library database indexes them with rich attributes. On iOS the media lives under /private/var/mobile/Media/DCIM/ and the catalog is Photos.sqlite (/private/var/mobile/Media/PhotoData/), a Core Data store whose ZASSET/ZADDITIONALASSETATTRIBUTES tables hold per-photo timestamps and — when location services were on — latitude and longitude. The EXIF block inside a JPEG is the same FF D8 FF E1 … Exif structure you carved in Chapter 11 and analyze fully in Chapter 20 — Photo, Video, and Document Forensics; for mobile cases the GPS tags are often the headline, because they place the device — and by inference its owner — at a location and time.

  JPEG with EXIF GPS (mobile camera photo)
  FF D8 FF E1 ....  Exif  MM .* ........            ← SOI + APP1 "Exif", TIFF big-endian
     IFD0  -> Make="Apple"  Model="iPhone 13"  DateTime="2024:03:15 19:04:11"
     GPS IFD:
        GPSLatitudeRef  = "N"   GPSLatitude  = 40 44 54.3
        GPSLongitudeRef = "W"   GPSLongitude = 73 59 09.0
        GPSDateStamp    = "2024:03:15"  GPSTimeStamp = 23:04:09 UTC
  footer: FF D9 (EOI)

Messaging apps and the encryption-within-the-app problem

Third-party messengers are where many investigations actually live, and each has its own storage and its own encryption posture — a reminder that defeating the device encryption is not the end of the road. WhatsApp on Android keeps msgstore.db in /data/data/com.whatsapp/databases/; its backups are AES-encrypted as msgstore.db.crypt14 (now crypt15 for end-to-end-encrypted backups), with the key in /data/data/com.whatsapp/files/key — so a file-system extraction that captures both the crypt file and the key lets you decrypt, while a logical pull of only the crypt file does not. Signal deliberately stores its messages in an encrypted SQLCipher database whose key is held in the Android Keystore / iOS keychain; without that key — which a mere logical extraction will not surrender — the Signal database is unreadable even after you are inside the phone. Telegram caches a great deal locally but keeps "secret chats" device-bound. The forensic lesson: device access is necessary but not always sufficient — an app can encrypt its own data with a key you must also extract, and the strongest privacy apps are designed precisely so that owning the phone is not enough.

Limitation. Be honest about app-layer encryption. A full file-system extraction of a phone with Signal installed may yield Signal's existence and metadata (the app is present, accounts, timestamps of the DB file) but not the message contents, because the SQLCipher key is gated behind the keystore and the user's credential. "Signal was installed and in use; message content was not recoverable from the available extraction" is the correct, defensible finding — not a failure of skill, but the privacy guarantee working as designed (theme #5).

Location history, Wi-Fi, and the device's own movement log

Beyond photo geotags, phones keep several location stores. On iOS, com.apple.routined (Cache.sqlite, Local.sqlite) records "Significant Locations" — places the device visited frequently, with coordinates and timestamps — and knowledgeC.db (/private/var/mobile/Library/CoreDuet/Knowledge/) is a treasure: a system-wide activity log whose ZOBJECT table records app usage (/app/usage, /app/inFocus), device lock/unlock, and screen state, all in Mac absolute time. knowledgeC.db can answer "was the phone in active use, and which app was on screen, at 19:04?" with startling precision; newer iOS migrates some of this into protobuf "Biome" streams under /private/var/mobile/Library/Biome/, which iLEAPP parses. On Android, fine-grained location history largely lives in the Google account cloud (reached via legal process or Google Takeout — Chapter 31), but on-device caches and the GMS data hold useful traces.

Wi-Fi connection history is a quietly powerful geolocation source. A phone remembers the networks it has joined — SSIDs and, crucially, BSSIDs (the access point's MAC address) — in com.apple.wifi.plist (iOS) or WifiConfigStore.xml (/data/misc/wifi/, Android). A BSSID can be looked up in public wardriving databases (such as WiGLE) to resolve the physical location of that access point, so "the device connected to a network whose BSSID geolocates to [address] at [time]" places the phone there independently of GPS. Combined with significant-locations data and photo geotags, the phone's own records often reconstruct a movement timeline the owner never knew they were creating — theme #3, every action leaves a trace, written in Wi-Fi joins.

Health and fitness data

Modern phones are also activity sensors. iOS Health stores steps, heart rate, workouts, and more in healthdb_secure.sqlite (/private/var/mobile/Library/Health/), a protected store reachable via an encrypted backup or AFU file-system extraction. Health data has decided real cases: a step-count spike or a heart-rate change at a particular minute, a workout track with GPS, or simply the absence of movement when the owner claimed to be active, can corroborate or contradict an account of events. It is also intensely private medical data, which raises the scope and ethics concerns we return to below.

Deleted records inside SQLite — "deleted is not destroyed," again

Here the foundational theme of this book reappears in a new place. When an app "deletes" a message, it usually issues a SQL DELETE, which marks the record's space as free within the database file — it does not scrub the bytes. The deleted record persists in the page's unallocated area and in freelist pages until SQLite reuses that space or a VACUUM compacts the file. Worse (for the would-be deleter) and better (for you), SQLite's write-ahead log — the -wal side file — holds recent transactions not yet checkpointed into the main database, frequently containing older versions of records, including pre-deletion content. This is precisely why a file-system extraction (which captures the .db and its -wal and -journal) recovers deleted messages that a logical extraction (which reads only the live rows) never sees.

   SQLite database on disk during normal use
   ┌──────────────────────────┐      ┌──────────────────────────┐
   │  msgstore.db (main file)  │      │  msgstore.db-wal          │
   │  ┌────────────────────┐   │      │  recent transactions not  │
   │  │ live rows          │   │      │  yet checkpointed:        │
   │  ├────────────────────┤   │      │   - new messages          │
   │  │ FREELIST pages     │◀──┼──────┼─  - PRE-DELETE versions    │
   │  │ (deleted records   │   │      │     of "deleted" rows      │
   │  │  linger here)      │   │      └──────────────────────────┘
   │  └────────────────────┘   │
   └──────────────────────────┘
   Recovering deleted messages = parse main-file unallocated + freelist + WAL.

Forensic SQLite parsers (Cellebrite Physical Analyzer, Magnet AXIOM, and open tools that walk freelist pages and the WAL) reconstruct these deleted records routinely. The conceptual carve mirrors file carving from Chapter 7: you scan the unallocated regions of the database file for record structures rather than scanning a disk for file signatures.

Recovery vs. Forensics. The sms.db/msgstore.db file is the textbook dual-purpose artifact. For a 💾 recovery client who deleted a thread by accident, you pull the deleted rows from the WAL and freelist and hand the messages back. For a 🔍 examiner, the same deleted-record recovery is evidence — and it carries an extra obligation: you must be able to explain, clearly and defensibly, where a recovered "deleted" message came from (freelist page N, or WAL frame M), why that location proves it was deleted rather than fabricated, and what the tool did to reconstruct it. Same bytes; one job restores them, the other must prove them.

War Story. An assault suspect insisted he had never contacted the victim and had "deleted nothing." His phone's logical backup was, indeed, clean — the threatening messages were gone from the live tables. But the file-system extraction captured mmssms.db-wal, and inside the write-ahead log were the pre-deletion frames: the messages, their timestamps, and the recipient, exactly as sent. He had deleted the rows; he had not, and could not, delete the log of the deletion. The absence in the live table and the presence in the WAL together told the whole story — theme #3, in a single side file most users do not know exists.

Everything converges, as in Chapter 11, on the locked, encrypted, passcode-unknown device. But the forensic examiner faces this wall differently from the recovery technician, because the examiner may have two kinds of leverage the recovery shop never has: a lawful path to compel or obtain the passcode, and access to specialized tools that attack it. Both have hard limits, and the line between legitimate and illegitimate runs straight through here.

Technical approaches

The easiest technical "attack" is no attack at all: a known passcode, obtained by consent, by lawful compulsion, or because the device was seized in the AFU state. With the passcode (or AFU state), a normal extraction proceeds and the encryption is a non-issue. This is, by a wide margin, how most locked-device cases are actually solved.

When the passcode is unknown, the realistic technical options are exploit-based services — GrayKey (Grayshift) and Cellebrite Premium chief among them — which use device- and OS-version-specific vulnerabilities to enable passcode guessing or extraction. Their effectiveness is governed by the hardware facts you already know: the Secure Enclave (or Android StrongBox) throttles guesses in tamper-resistant silicon, so even a working exploit may face escalating delays that make a strong alphanumeric passcode infeasible while a 4-digit PIN falls quickly; an AFU device yields vastly more than a BFU one; and the entire capability is a cat-and-mouse with the OS vendor — Apple and Google patch the exploits, the tools find new ones, and on the newest hardware (A12+, recent StrongBox Pixels) there are stretches where no capability exists. The professional posture is to know what is currently possible for the specific model and OS version in front of you, to set expectations accordingly, and never to assume the marketing slide reflects the device on your bench.

Brute-forcing offline — copying the encrypted blob and guessing on a cluster — does not work on modern devices, because the only thing that can test a passcode is the original device's security chip, at the speed it permits. That is the whole point of binding keys to hardware, and it is why "just image it and crack it later" is a recovery-era fantasy on current phones.

Often the faster path to a locked phone is not a tool but a court. The legal landscape — covered in depth in Chapter 25 — The Legal Framework — turns on a few pillars every mobile examiner should recognize:

  • A warrant is required to search a phone. Riley v. California (2014) held that the search-incident-to-arrest exception does not extend to the data on a cell phone; police generally need a warrant. Carpenter v. United States (2018) extended warrant protection to historical cell-site location information. Mobile evidence almost always rides on a warrant, and the warrant's scope governs what you may examine.
  • Compelled passcodes and the Fifth Amendment. Whether the state can force a person to reveal a passcode is genuinely unsettled. A passcode is arguably testimonial (contents of the mind), which the Fifth Amendment protects; but the "foregone conclusion" doctrine may permit compulsion when the government already knows the device is the suspect's and that incriminating data exists, so the act of unlocking "adds little." Courts split, sharply, by jurisdiction.
  • Biometrics versus passcodes. Several courts have treated compelling a fingerprint or face to unlock as non-testimonial — like compelling a physical key — while a passcode remains testimonial; other courts disagree. This unsettled line has a practical consequence at seizure: a device unlockable by biometrics may be compellable in ways a passcode-locked one is not, and a phone that has rebooted (and so requires the passcode rather than biometrics) may be legally harder to open — another reason device state at seizure matters.
  • Consent, third parties, and the border. A device owner may consent; a co-owner's authority is limited; and border searches operate under heightened government authority where the warrant requirement is contested (a live circuit split over "basic" versus "advanced" forensic searches).
  • The All Writs Act and the vendor's role. In the 2016 Apple v. FBI San Bernardino matter, the government sought to compel Apple to build software to bypass a passcode; Apple refused, and the FBI ultimately used a third-party exploit instead — the episode that crystallized the modern "the vendor will not, and increasingly cannot, unlock it for you" reality.

Legal Note. The cleanest, most defensible unlock is the one a court ordered or the owner consented to — not the one your tool achieved. Before any technical attack on a locked device, confirm your authority: the warrant's scope, any order compelling production, and the jurisdiction's stance on compelled decryption. Attacking a device you have no authority to open is not forensics; it is the offense from the cybersecurity book, and no extraction is admissible if the access that produced it was unlawful. When in doubt, the answer comes from Chapter 25 and counsel, not from the keyboard.

Ethics Note. Mobile is where two temptations are strongest, and both are off-limits. The first is overreach — examining beyond the warrant's scope because the data is right there. The second is illegitimate access — coercing a passcode you cannot lawfully compel, or buying grey-market capability to attack a device you lack authority over. The phone is the most intimate device a person owns; the discipline that keeps you on the right side of that intimacy is scope, authority, and documentation. The full treatment, including what you owe the subject as well as the case, is Chapter 28 — Ethics.

Tool demonstration: a logical-plus-file-system workflow

The commercial mobile-forensics market is dominated by a few suites — Cellebrite (UFED for extraction, Physical Analyzer for parsing; Premium for advanced unlock), Magnet AXIOM (acquire and analyze), MSAB XRY/XAMN, and Oxygen Forensic Detective — surveyed in Chapter 36 — The Forensic Toolkit and Appendix C — Tool Reference. They wrap acquisition, decoding, deleted-record recovery, and reporting in a GUI and are the field standard. But you should also know the open-source path, both for budget labs and — more importantly — for validation: a finding confirmed by an independent tool you can read the source of is far stronger under cross-examination.

A representative iOS workflow, mixing sanctioned and open tools:

# 1) Identify the device (libimobiledevice) — for the report
ideviceinfo | grep -E "DeviceName|ProductType|ProductVersion|SerialNumber|InternationalMobileEquipmentIdentity"

# 2) Force an ENCRYPTED backup so keychain + Health are captured (record the password!)
idevicebackup2 encryption on "Examiner-Set-Pass-2024" -s
idevicebackup2 backup ./evidence/iphone_backup/

# 3) Hash the extraction immediately (chain of custody)
find ./evidence/iphone_backup -type f -print0 | xargs -0 sha256sum > backup.sha256

# 4) Parse with iLEAPP (open source; readable methodology)
python ileapp.py -t fs -i ./evidence/iphone_backup -o ./reports/ileapp/
# -> HTML/CSV: knowledgeC app usage, routined Significant Locations,
#    Safari history, Wi-Fi networks, Health, call history, etc.

The equivalent Android open-source parser is ALEAPP (Android Logs Events And Protobuf Parser), pointed at a file-system extraction or an adb/tar collection:

python aleapp.py -t fs -i ./evidence/android_ffs/ -o ./reports/aleapp/
# -> parses bugle_db (RCS), mmssms.db, contacts2.db, WiFi configs,
#    usagestats, and hundreds of app artifacts into one report.

Many examiners run these parsers on a Windows workstation, where the chain-of-custody hashing of the extraction is naturally done in PowerShell — the same pattern you used for backups in Chapter 11, now applied to a device extraction:

# Hash every file in the extraction for an integrity baseline (Chain of Custody)
$ext = "D:\evidence\iphone_ffs"
Get-ChildItem $ext -Recurse -File |
  Get-FileHash -Algorithm SHA256 |
  Select-Object Hash, @{n='RelPath';e={$_.Path.Substring($ext.Length)}} |
  Export-Csv -NoTypeInformation .\extraction_hashes.csv

# Verify the vendor-reported extraction-archive hash matches your own
(Get-FileHash -Algorithm SHA256 "D:\evidence\iphone_ffs.zip").Hash -eq `
  "7B91C0A4..."   # value the acquisition tool recorded; True = unaltered

A Cellebrite-style parse produces output you read the same way regardless of tool — here, illustrative Physical Analyzer-style summary text:

  Extraction: Full File System (Apple iPhone, iOS 16.3.1)   Method: Agent
  Hash (extraction zip) SHA-256: 7b91c0a4... (verified)

  ARTIFACT SUMMARY
  ----------------------------------------------------------------
  Messages (SMS/iMessage) ........ 14,902 (incl. 318 recovered/deleted)
  Call log ....................... 2,114
  Contacts ....................... 506
  Images ......................... 9,773  (4,201 with GPS)
  Locations (routined) ........... 1,338 visited places
  App usage (knowledgeC) ......... 61,540 events
  Wi-Fi networks (known) ......... 47  (BSSIDs available for geolocation)
  Health samples ................. 220,471
  ----------------------------------------------------------------
  Installed: WhatsApp, Signal(*), Telegram, Instagram, Snapchat
  (*) Signal DB present; content not decodable (SQLCipher key not recovered)

Notice three habits baked into that workflow: the device is identified for the report, the extraction is hashed the moment it exists, and at least one open, source-readable tool corroborates the commercial parse. The "(deleted)" message count and the explicit "Signal content not decodable" line are exactly the kind of honest, limit-stating output a court rewards.

Tool Tip. Run the artifacts that carry your conclusion through two parsers. If Cellebrite and iLEAPP independently report the same sms.db message at the same converted timestamp, your finding survives any single tool's parsing bug — and "I corroborated with an independent, open-source tool" is a sentence that holds up under cross. Tool validation is a Daubert expectation, not a nicety (Chapter 27 — Expert Testimony).

Worked example: the phone in the court case

Now we apply the chapter to anchor case #4 — the child-exploitation matter — and we apply it exactly as the bible requires: clinically and non-graphically, procedure and law and ethics only, never any description of content. The point of the anchor here is not the offense; it is the discipline of getting a phone's evidence out and into a report that survives a defense built to attack it.

Intake and preservation. The phone arrives powered on in a Faraday bag (network-isolated to prevent remote wipe and to freeze its state). You photograph it in the bag, document the model, the visible lock state, and the battery level, and you keep it powered through a battery pack inside a shielded enclosure so it neither dies (BFU on next boot) nor locks-and-reboots. The warrant defines your authority and, critically, your scope — the categories of evidence you may search for. You record the seizure-to-lab chain of custody before any extraction.

Acquisition at the highest sound level. Working under the warrant, you determine the model and OS version, confirm what level is achievable, and acquire — here, a full file-system extraction via a supported tool — verifying and recording the extraction hash. You note in the record exactly what the method changed on the device (the agent installed and removed) so the modification is disclosed up front. You then work only on hashed copies.

Analysis, bounded by scope. You parse with a commercial suite and validate load-bearing findings with iLEAPP. The artifacts that matter in a case like this are procedural and metadata-driven: media files and their EXIF/GPS tying the device to locations and times (Chapter 20); file-system and knowledgeC.db timestamps establishing when the device was in use and which app was active, to build an access timeline (Chapter 21); account identifiers (Apple ID, app accounts, recovered tokens from the keychain) tying the device to a person; browser history; and deleted-record recovery from SQLite WAL/freelist where data was removed. Each finding is sourced to a specific artifact and database location.

Scope discipline and plain view. This is the ethically decisive step. If, during a properly scoped examination, you encounter evidence of a different crime outside the warrant's categories, you stop, do not expand the search, document what prompted the concern, and seek a new warrant before proceeding — the digital analogue of the plain-view doctrine, with the contours decided in Chapter 25. Examining "everything because it's all right there" is exactly how good evidence gets suppressed.

The report and the cross-examination drill. Your report (Chapter 26 — The Forensic Report) separates findings from inferences with discipline: "media file X carries EXIF GPS coordinates [...] and a creation timestamp of [...]; knowledgeC.db shows the camera app in focus at that minute" is a finding; "the defendant took the photo" is an inference you flag as such, because a phone proves device activity, not who held it. Anticipate the defense, because it is predictable and legitimate: Could someone else have used the phone? (address with passcode/biometric facts, usage patterns, and corroborating account activity — but concede what cannot be excluded). Are the timestamps reliable? (explain the Mac-absolute-time conversion, validated across tools). Did your extraction alter the evidence? (point to the disclosed, documented modifications and the hash verification). The mock-trial mechanics are Chapter 27.

Ethics Note. Two duties dominate a case like this. First, mandatory reporting: in the United States, 18 U.S.C. §2258A governs provider reporting of CSAM to NCMEC, and examiners operate under related legal and policy obligations to report and to handle such material strictly within authorized channels; you never copy, transmit, or retain it outside the case system, and you follow your jurisdiction's and agency's procedures to the letter. Second, your own well-being: examiners in this work face real risk of secondary traumatic stress. Clinical detachment in the report is not coldness; it is professional self-protection and respect for everyone the case touches — theme #6, the human cost is real, applied to the examiner as well as the victim. Chapter 28 — Ethics treats both duties in full; do not improvise either.

Chain of Custody. Notice how much of this example is paperwork, not extraction. The phone was photographed in the bag, the state and battery recorded, the warrant scope written down, the acquisition method and its device modifications disclosed, the extraction hashed and copied, and every finding sourced to an artifact in a hashed image. That record — not the cleverness of the unlock — is what makes the evidence count. An extraction without it is data; with it, it is evidence.

Common mistakes

  • Letting a seized AFU phone reboot, lock, or die. AFU means the decryption keys are live in memory; a reboot drops the device to BFU and re-locks the bulk of the data. Keep it powered, keep it from rebooting, and isolate it — the single most consequential field error in mobile forensics.
  • Failing to network-isolate the device. A phone left on the network can be remotely wiped or pushed to a locked state before you acquire. Faraday bag, airplane mode, or a shielded room — immediately, every time.
  • Unlocking the bootloader to root an Android. On most modern devices, unlocking the bootloader factory-resets userdata — destroying the very evidence you came for. Never do it on an evidence device without certainty about its wipe behavior; prefer temporary/exploit root that touches no persistent partition.
  • Stopping at a logical extraction when a file-system extraction was achievable. Logical pulls miss app-private data and, critically, the SQLite -wal/freelist where deleted records live. Acquire at the highest sound level you can reach, and document the ceiling when you cannot go higher.
  • Botching the iOS timestamp epoch. sms.db and friends use Mac absolute time (seconds, or nanoseconds since iOS 11, from 2001-01-01). Treating them as Unix time throws the timeline off by 31 years. Convert with the right epoch and validate against a known event.
  • Parsing only mmssms.db and missing RCS. Google Messages RCS conversations live in bugle_db, not the telephony provider. Examine both, or miss entire conversations on a current Android.
  • Assuming device access decrypts every app. Signal (SQLCipher), WhatsApp crypt files, and other apps encrypt their own data with keys you must separately extract. "I'm inside the phone" does not mean "I can read every app."
  • Treating chip-off/EDL as an encryption bypass. On an encrypted device, chip-off, JTAG, ISP, and EDL all return ciphertext — a flawless copy of an unbreakable safe, exactly as in Chapter 11. These help on unencrypted/legacy devices, not on a modern locked one.
  • Exceeding the warrant's scope. Examining categories the warrant does not authorize, or following out-of-scope evidence without a new warrant, gets findings suppressed. Stay in scope; stop and re-warrant for plain-view discoveries.
  • Reporting device activity as person activity. A phone proves what the device did, not who held it. Keep findings ("the camera was in focus at 19:04") rigorously separate from inferences ("the defendant took the photo").

Limitations: knowing when to stop

Mobile forensics is the chapter where theme #5 bites at every level of the pyramid, so be unsentimental about the ceilings. Strong device encryption without the key is final. On a current SoC (Apple A12+, hardened Android StrongBox), a locked, BFU device with an unknown passcode and no available exploit may be unextractable by any means available to you — not difficult, but impossible with present capability. No budget, no chip-off, no EDL changes that, because the keys live in tamper-resistant silicon and the device throttles every guess. "Extraction was not achievable on this model at this OS version" is a complete, professional finding.

App-layer encryption can survive device access. Even inside an unlocked phone, Signal's SQLCipher database and similar stores may be unreadable without keys a logical extraction will not yield; the right finding is "present but not decodable," not a forced guess at content. The acquisition level caps the evidence. A logical extraction simply does not contain the deleted SQLite records a file-system extraction would; if you could only reach logical, say so, and do not imply completeness you did not achieve. Capabilities are a moving target. What a tool unlocked last quarter it may not unlock after the next OS patch; never assume yesterday's success transfers to today's device.

And the hardest, most human limit: a phone proves the device's activity, never definitively who was holding it. You can place a device at a location, in active use, running a particular app, at a precise time — and you cannot, from the artifacts alone, prove the identity of the hands on the glass. Honest reporting states that boundary plainly and lets corroboration (account activity, biometrics, witnesses) carry the attribution. Forcing the phone to say more than it can is how an examiner is dismantled on cross. Know what the device can carry, report exactly that, and let "the evidence is insufficient to determine X" stand as the valid, professional answer it is.

Progressive project: the mobile evidence enters the case file

Your Forensic Case File (the running deliverable from Chapter 5, acquired in Chapters 14–15 and analyzed across Part III) now gains its mobile layer. In Chapter 11's project step you searched the computer image for an iTunes/Finder backup and parsed it forensically; this chapter you analyze the device-level mobile evidence for the case.

  1. Classify your acquisition. For the mobile evidence in your case (a provided extraction or the backup from the Chapter 11 step), state precisely which pyramid level it represents — manual, logical, file-system, or physical — and what that level can and cannot contain. Record the device identity (model, OS, serial/IMEI) and the extraction hash in your chain-of-custody worksheet (Appendix F).
  2. Parse and validate. Run the extraction through a parser (iLEAPP/ALEAPP, or a commercial suite if available) and cross-check at least one load-bearing artifact with a second tool. Convert at least one set of iOS timestamps by hand to prove you control the epoch.
  3. Build a mobile timeline. Extract and time-anchor the high-value artifacts: calls/SMS/RCS, photo EXIF GPS, knowledgeC.db/significant-locations or Android usage/location traces, Wi-Fi BSSID joins, and any deleted SQLite records recovered from WAL/freelist (note exactly where each deleted record came from). Every entry is sourced to an artifact and a database location.
  4. State the limits in writing. For each finding, flag what it does not prove — device-vs-person, browsed-vs-sent, present-vs-decodable, the acquisition-level ceiling — so future-you writes the report honestly. Note any artifact you expected but could not reach, and why.

Save the parser outputs and your mobile timeline into the case-file folder; you will merge them into the master timeline in Chapter 21 and fold them into the final report and the capstone in Chapter 38. The lesson for the case file mirrors the lesson for the lab: the phone often holds the timeline the computer only hinted at — but only the evidence you acquired soundly, validated independently, and reported with its limits will survive a courtroom.

Summary

Mobile forensics is the forensic twin of the recovery work in Chapter 11: the same soldered storage, the same hardware-bound encryption, but now under a warrant, often against an uncooperative subject, with every action bound for court. Because there is no write-blocker for a running phone, the discipline shifts from "never touch the original" to minimize, document, and validate every necessary change — theme #2, adapted to a medium that forces your hand. You acquire along a five-level pyramid: manual (documented screenshots), logical (backups, content providers, the Manifest.db world), file-system (the full app-private tree with SQLite -wal/freelist where deleted records live), physical (bit-for-bit, but ciphertext on a modern locked device), and chip-off/JTAG/ISP as a last resort — always acquiring at the highest sound level you can reach and documenting the ceiling. On iOS, the Secure Enclave, Data Protection classes, and the AFU/BFU distinction govern everything; encrypted iTunes backups expose the keychain and Health that plain backups omit; APFS snapshots can reveal prior states; and checkm8 owns the A5–A11 era while A12-and-later devices stand as a genuine wall. On Android, ADB gives a logical pull, but file-system access needs root — a documented, justified modification, and never a bootloader unlock that wipes userdata — while EDL/MediaTek reads, like chip-off, return ciphertext on encrypted storage. The evidence itself is overwhelmingly SQLite: calls, SMS/MMS and RCS (bugle_db!), contacts, geotagged photos, messaging apps (some, like Signal, encrypted beyond device access), location caches and knowledgeC.db, Wi-Fi BSSID history that geolocates the device, and Health data that times a heartbeat to a minute — with deleted records lingering in freelist pages and the write-ahead log, deleted is not destroyed operating inside a database file. The encryption wall is faced with two kinds of leverage the recovery shop lacks — lawful compulsion or obtained passcodes, and exploit-based tools (GrayKey, Cellebrite Premium) whose success is model-, version-, and patch-dependent and frequently absent on the newest hardware — bounded always by Riley, Carpenter, the unsettled law of compelled decryption, and the warrant's scope. Through it all the method is constant: understand the security model, isolate and preserve, acquire soundly, hash, parse, validate across independent tools, and report findings — never inferences — with their limits intact. The phone is the witness that goes everywhere; your job is to take its testimony in a way a court will believe.

You can now: - Choose and justify a mobile acquisition level from the five-step pyramid — manual, logical, file-system, physical, chip-off — for a given device, lock state, OS version, and authority. - Apply the iOS security model (Secure Enclave, Data Protection classes, AFU/BFU, checkm8 vs. A12+) and Android model (FBE, TEE/StrongBox, root, EDL/MTK) to real acquisition decisions, and explain why each method does or does not defeat the encryption. - Locate and parse the core mobile artifacts — calls, SMS/MMS/RCS, contacts, geotagged photos, messaging-app stores, location and knowledgeC data, Wi-Fi history, and Health — converting iOS Mac-absolute timestamps correctly. - Recover deleted records from SQLite freelist pages and the write-ahead log, and explain on the stand where a recovered "deleted" message came from and why that proves deletion. - Distinguish technical from legal approaches to a locked, encrypted phone, and stay within authority and warrant scope — including the duty to stop and re-warrant on plain-view discoveries. - Acquire, hash, validate across independent tools, and report mobile evidence — separating findings from inferences and stating limits — in a way that withstands cross-examination, handling sensitive material clinically and within mandatory-reporting duties.

What's next. This closes Part III — you can now find evidence wherever it hides, from a disk image to a packet capture to the phone in a pocket. Part IV makes it count. Chapter 25 — The Legal Framework — takes the warrants, consent, compelled-decryption questions, and scope discipline you met repeatedly in this chapter and treats them in full: the Fourth and Fifth Amendments, Riley and Carpenter, FRCP and eDiscovery, Daubert and Frye, GDPR, the CLOUD Act, and MLATs — because the most technically perfect extraction is worthless if the authority behind it does not hold.

Practice in exercises.md, test yourself with the quiz, apply it in the case studies, review the key takeaways, and go deeper with further reading.