47 min read

> Where you are: Part II, Chapter 11 of 40. The recovery chapters so far have treated storage as something you can detach, image, and reason about block by block — a hard drive in Chapter 8, a flash chip in Chapter 9, an array in Chapter 10. A phone...

In This Chapter

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

Chapter 11: Mobile Device Recovery — Smartphones, Tablets, and the Data You Can't Reach Through the Screen

Where you are: Part II, Chapter 11 of 40. The recovery chapters so far have treated storage as something you can detach, image, and reason about block by block — a hard drive in Chapter 8, a flash chip in Chapter 9, an array in Chapter 10. A phone refuses to play along. Its storage is soldered down, hardware-encrypted, and gated by a Secure Enclave that does not care how clever you are. This chapter is where the cheerful recovery promise of the book — deleted is not destroyed — collides with the brick wall of modern mobile encryption, and where "I'm sorry, the photos are gone" becomes a sentence you have to learn to say honestly.

Learning paths: 💾 Data Recovery lives here — this is the owner-cooperative recovery chapter (the client wants you to get their data back and will give you their passcode). 🛡️ Incident Response cares about corporate and BYOD phones, MDM-managed devices, and backups left on company laptops. 📜 Legal/eDiscovery should note that an iTunes backup on a custodian's computer is responsive ESI. 🔍 Forensic Examiner: read this for the boundary — extracting data from an uncooperative suspect's locked phone under a warrant is a different discipline with different tools, and it lives in Chapter 24 — Mobile Device Forensics.

The phone is the photo album now

A woman sets a phone on your bench. It is an iPhone, two generations old, and the back is slightly swollen where the battery has begun to fail. She tells you her husband died four months ago. The phone was his. It has not been charged since the funeral, and now it will not power on. Somewhere in it — she believes — are the last videos of him, the voicemails she never deleted, the photo of the two of them at the lake that she never got around to printing. There is no backup. He never plugged it into a computer. He turned off iCloud because he didn't trust "the cloud." She does not know the passcode.

You have done variants of this job a hundred times with hard drives. In Chapter 1 the opening case was a client's reformatted drive holding ten years of wedding and family photos, and in Chapter 6 and Chapter 7 you got most of it back, because on a magnetic platter or even a half-TRIMmed SSD the data lingers after the pointers are gone. You learned to say deleted is not destroyed and mean it. Increasingly, though, the wedding photos never touch a computer at all. They are born on a phone, live on a phone, and — if the owner is unlucky — die on a phone. The medium changed. And on this particular medium, the comforting law of the prior chapters has an exception large enough to swallow the whole case.

This chapter teaches mobile recovery in three honest layers. First, the easy wins, which are not really phone recovery at all — they are recovery of backups the phone left elsewhere, and of removable media you can pop out and treat like any other flash card. Second, the hard physical jobs — broken screens, water damage, dead boards — where the goal is to get a living device to cooperate just long enough to hand you its data. Third, the wall: the realization that on a modern, passcode-protected, full-disk-encrypted phone, when the owner is gone or the passcode is lost and there is no backup, the data is not "deleted" in any sense you can defeat — it is encrypted, and encrypted-without-the-key is the one form of "lost" this book cannot talk you out of.

Why mobile breaks the rules you learned

Three architectural facts make a phone unlike every storage device in the preceding chapters, and you need all three in your head before you touch one.

The storage is not removable and not addressable in the way you expect. On a desktop you connect the drive to a write-blocker and image it (the discipline from Chapter 5 — The Forensic Process). On a phone, the NAND is a soldered BGA package — an eMMC or UFS chip on Android, a raw or managed NAND package on iPhone — and the only sanctioned path to its contents runs through the phone's own processor, operating system, and security hardware. You do not get to bypass the OS and read raw blocks unless you physically remove the chip (chip-off) or tap its bus (JTAG/ISP), and even then, as you will see, what you read back is usually ciphertext.

Encryption is on by default, hardware-bound, and not optional. Since iOS hardware encryption matured with the Secure Enclave (the A7 chip, iPhone 5s, 2013) and since Android made encryption mandatory for capable devices starting with Android 6.0 (Marshmallow, 2015) and shifted to File-Based Encryption by Android 10, the normal state of a phone is fully encrypted with a key you cannot extract. The encryption key is tangled with a per-device secret fused into the silicon. You cannot copy the encrypted blocks to a fast machine and brute-force the passcode offline, because the only thing on Earth that can test a passcode is the original phone's security chip — and it counts your attempts and gets slower, or wipes, when you guess wrong.

The chip enforces the rules even if you defeat the OS. This is the part that humbles experienced recovery techs. On a 2010-era device you could clone the flash, exhaust the four-digit PIN space, and win. On a Secure Enclave iPhone or a StrongBox-backed Pixel, the attempt counter and the escalating delays live in tamper-resistant hardware that survives an OS exploit. Defeating the software gets you a beautifully cloned pile of encrypted bytes and a security processor that still says no.

Why This Matters. Theme #4 of this book is technology changes, principles don't — image first, work the copy, document everything. Mobile is where you discover the asterisk: the principles hold, but one capability you took for granted does not survive the transition. On magnetic and even solid-state storage, "deleted is not destroyed" is the foundation. On a modern phone, the foundation shifts to a colder truth: encrypted is not accessible. The data may sit there, intact, every bit present — and be as unreachable as if it had been incinerated. Learning where that line falls is the single most valuable thing in this chapter, because crossing it wastes the client's money and your credibility.

A taxonomy of mobile recovery situations

Before any cable comes out of a drawer, you classify the job. Mobile recovery is not one technique; it is a decision tree, and the branches lead to wildly different outcomes — from "fifteen-minute backup restore" to "respectfully decline." Five questions sort almost every case.

  1. Who is asking, and can they prove they own it? A cooperative owner who can authenticate to the device or its cloud account is a recovery job. A locked device handed to you by anyone else — including a grieving family member who does not have the credentials — is at best a legal question and at worst a forensics job that belongs to a different lab under a different authority.
  2. Is there a backup? This is the question that resolves most cases happily, and you ask it first because the answer can end the job before it starts.
  3. What state is the device in — does it boot, does the screen work, is it physically/water damaged? This decides whether you are doing software recovery, board repair, or chip-level work.
  4. Is it locked, and is it encrypted? On modern hardware these are effectively the same question, and the answer is almost always "yes, and yes."
  5. What is the device, exactly, and how old is it? A 2012 Android phone with encryption never enabled and a 2024 iPhone are different planets. Make/model/OS version changes the realistic ceiling on what you can recover.

The first question is always: is there a backup?

The fastest, cleanest, most reliable mobile "recovery" is restoring from a backup the phone already made. It is not glamorous and it is not chip-off, but it succeeds where heroics fail, and a professional reaches for it first. Backups live in three places: a computer (iTunes/Finder for iPhone, vendor tools or adb archives for Android), the cloud (iCloud, Google One/Google account, Samsung Cloud), and sometimes a removable card. The decision tree below is the one you run in your head on every intake.

                          MOBILE DEVICE RECOVERY — TRIAGE
                          ===============================

  Owner present & can authenticate? ──NO──▶ STOP. Not a recovery job.
            │                                Legal/forensic question → Ch.24, Ch.25.
           YES
            │
            ▼
  Is there a BACKUP?
   ├─ Local computer backup (iTunes/Finder, vendor tool)? ─YES─▶ Parse/restore. EASIEST.
   ├─ Cloud backup (iCloud / Google / Samsung)?           ─YES─▶ Authenticate + download.
   └─ Removable SD card with the data?                    ─YES─▶ Pull card, image, carve.
            │
           NO backup
            ▼
  Does the device POWER ON and the screen WORK?
   ├─ YES, and it is UNLOCKED / owner knows passcode ─▶ Pull data live (cable / AirDrop / ADB).
   ├─ Screen broken but board alive ───────────────▶ Pairing record / screen swap / scrcpy.
   ├─ Water / physical damage, board questionable ──▶ Board repair → then treat as above.
   └─ Dead board ──────────────────────────────────▶ Chip-level (and see ENCRYPTION below).
            │
            ▼
  Is the device ENCRYPTED (modern default = YES) and is the passcode UNKNOWN?
   ├─ NO  (old/unencrypted device) ─▶ Chip-off / carving may recover plaintext. Proceed.
   └─ YES (passcode unknown)        ─▶ WALL. Data is intact but unreadable.
                                       Be honest. Recovery effectively impossible
                                       by legitimate means. (Forensic labs with
                                       passcode-attack capability → Ch.24.)

Recovery vs. Forensics. The same artifact — say, an iTunes backup sitting in a folder on the client's laptop — serves both disciplines, and the difference is who, why, and how documented. In recovery the owner says "please get my texts back," you copy the backup, parse it, and hand over the messages; speed and restoration are the goal. In forensics that identical backup is potential evidence: you image the laptop with a write-blocker, hash it, preserve chain of custody, and parse a verified copy so you can later testify that nothing was altered (the discipline from Chapter 14 — Forensic Acquisition). One artifact, two postures. Throughout this chapter, when I describe pulling a backup or imaging a card, the recovery posture is the default; flip into the forensic posture the instant the data might end up in a dispute, and never decide that question casually.

Legal Note. "The owner is present" is doing heavy lifting in that tree. A phone is the most personal device a person owns; pulling data from one you are not clearly authorized to access can violate the Stored Communications Act, the Computer Fraud and Abuse Act, state privacy statutes, and — for a deceased person's device — estate and probate law. Get authority in writing. For a deceased owner, that means the executor of the estate, and even then Apple and Google have their own "digital legacy" processes that may be the only sanctioned route to a cloud account. The full treatment of authority and consent is Chapter 25 — The Legal Framework. When in doubt, do not touch it.

iPhone recovery

The iPhone is the cleaner case to teach because Apple controls the hardware, the OS, and the security model, so the rules are consistent across devices and well documented. The rules are also unusually unforgiving, which makes the iPhone the best teacher of this chapter's hard lesson.

How the iPhone protects data

You cannot reason about iPhone recovery without a working model of its encryption, so build one now; it pays off for the rest of Part II and again in Chapter 29 — Encrypted Device Forensics.

Every modern iPhone's flash is encrypted at the file level. Each file gets its own random file key. That file key is wrapped (encrypted) by a class key that corresponds to the file's Data Protection class — the developer's choice of how available the file should be. The class keys in turn are stored in a keybag, and the keybag is protected by two secrets multiplied together: the UID key — a 256-bit AES key fused into the Secure Enclave at manufacture, never readable by software, unique per device — and, for the protected classes, a key derived from the user's passcode. Because the passcode must be combined with the hardware UID, and the UID never leaves the chip, passcode guessing can only happen on that specific phone, at the speed the Secure Enclave permits.

        iOS DATA-PROTECTION KEY HIERARCHY (simplified)
        ==============================================

   Passcode ─┐
             ├─(PBKDF2, "tangled" with)──▶ Passcode key ─┐
   UID key ──┘   (UID never leaves the SEP)              │
   (fused in Secure Enclave)                             ▼
                                                  ┌──────────────┐
                                                  │  Class keys   │ (in the system KEYBAG)
                                                  │  A  Complete  │  avail only while UNLOCKED
                                                  │  B  CompUnlessOpen
                                                  │  C  Complete-Until-First-Unlock  ◀ default
                                                  │  D  No Protection (UID-only)
                                                  └──────┬───────┘
                                                         │ unwraps
                                                         ▼
                       per-file FILE KEY ──▶ decrypts the file's bytes in NAND

   EFFACEABLE STORAGE (small, separately erasable NAND region)
     holds the key material needed to unlock the keybag.
     ERASE it  →  keybag unrecoverable  →  every file key is gibberish  →  CRYPTO ERASE.

Four Data Protection classes matter:

  • Complete (Class A). Key available only while the device is unlocked; evicted from memory shortly after lock. The most protected data.
  • Complete Unless Open (Class B). Allows a file already open to keep being written while the device locks (think: downloading a large attachment).
  • Complete Until First User Authentication (Class C). The default for most app data. The class key becomes available after the first unlock following a boot and stays available until the device reboots — even if the screen later re-locks. This is the basis of the AFU/BFU distinction below.
  • No Protection (Class D). Wrapped by the UID alone, available even when locked (a tiny amount of data the OS needs before unlock).

That default — Class C — gives you the single most important operational concept in mobile recovery and forensics alike: AFU versus BFU.

   BFU  (Before First Unlock)              AFU  (After First Unlock)
   ---------------------------             --------------------------
   Device booted, NOT yet unlocked         User has unlocked at least once
   since power-on.                         since the last boot.
   Passcode-derived keys are NOT in        Class C keys ARE in memory.
   memory. Class A/B/C data = ciphertext.  Most app data is decryptable
   Almost nothing is accessible.           in place (until reboot).

If a phone is AFU — it booted and someone unlocked it once, and it has not rebooted — then the keys for the bulk of the data are live in memory, and a cooperative-owner recovery is straightforward: the OS will hand you files normally. If a phone is BFU — freshly booted, never unlocked — then even the operating system is staring at ciphertext, and so are you. This is why a forensic best practice for seized phones is "keep it powered, keep it from locking/rebooting" (covered in Chapter 15 — Live Response and Triage), and why a phone that died from a flat battery and now won't boot is a worse recovery prospect than one still warm and unlocked.

Finally, Effaceable Storage: a small, separately erasable region of NAND that holds the key material the keybag depends on. When you tap Erase All Content and Settings, or when a "remote wipe" arrives, the phone does not scrub hundreds of gigabytes — it erases this tiny region in a fraction of a second, which destroys the keybag's root and instantly renders every file key meaningless. That is crypto erase, and it is why an iPhone factory reset is effectively unrecoverable. Hold that thought; it returns in the factory-reset section.

iTunes and Finder local backups

Here is the good news that resolves a large fraction of real iPhone jobs: if the owner ever synced the phone to a computer, there is probably a full backup sitting on that computer's disk, and a backup is plaintext-accessible (or, if encrypted, accessible with the backup password the owner can give you). You are no longer fighting the Secure Enclave; you are reading files off an ordinary computer — exactly the skill set from the earlier chapters.

Backups live at predictable paths. Memorize them; they are also in Appendix D — Forensic Artifact Locations.

  macOS (Finder/iTunes):
     ~/Library/Application Support/MobileSync/Backup/<device-id>/

  Windows (iTunes from Apple):
     %APPDATA%\Apple Computer\MobileSync\Backup\<device-id>\
     = C:\Users\<user>\AppData\Roaming\Apple Computer\MobileSync\Backup\<device-id>\

  Windows (iTunes from the Microsoft Store):
     %USERPROFILE%\Apple\MobileSync\Backup\<device-id>\
     = C:\Users\<user>\Apple\MobileSync\Backup\<device-id>\

Inside a <device-id> folder, the structure has been stable since iOS 10:

  Backup/00008030-001A2B3C4D5E6F70/
   ├── Manifest.db        SQLite: maps every backed-up file to its storage name
   ├── Manifest.plist     backup-level metadata; IsEncrypted, BackupKeyBag, WasPasscodeSet
   ├── Info.plist         device name, IMEI, serial, product type, iOS version, app list
   ├── Status.plist       SnapshotState, IsFullBackup, backup date
   ├── 00/  01/  02/ ... ff/   <- 256 subfolders
   │     └── 3d/3d0d7e5fb2ce288813306e4d4636395e047a3d28   <- a backed-up file

The files are not stored under their real names. Each backed-up file's storage name is the SHA-1 hash of domain-relativePath, and since iOS 10 the file is placed in a subfolder named by the first two hex characters of that hash. The Manifest.db SQLite database is the index that translates between human paths and these hashes. Its Files table has the columns you care about: fileID (the SHA-1 storage name), domain, relativePath, flags (1 = file, 2 = directory, 4 = symlink), and file (a binary plist blob of metadata including the protection class).

Some fileID values are worth committing to memory because they are constant across every iPhone backup in the world:

   sms.db          domain=HomeDomain  path=Library/SMS/sms.db
                   fileID = 3d0d7e5fb2ce288813306e4d4636395e047a3d28

   AddressBook     domain=HomeDomain  path=Library/AddressBook/AddressBook.sqlitedb
                   fileID = 31bb7ba8914766d4ba40d6dfb6113c8b614be442

You can verify the rule yourself: SHA1("HomeDomain-Library/SMS/sms.db") is exactly 3d0d7e5fb2ce288813306e4d4636395e047a3d28. The database files themselves are ordinary SQLite, which you can confirm from the first sixteen bytes — the magic string SQLite format 3\0:

  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)

Knowing all this, recovering a specific artifact from an unencrypted backup is a short script. The following locates the SMS database, proves the SHA-1 rule, and copies it out under its real name so you can open it in any SQLite browser:

import hashlib, os, shutil, sqlite3

backup = r"C:\Users\you\Apple\MobileSync\Backup\00008030-001A2B3C4D5E6F70"

con = sqlite3.connect(os.path.join(backup, "Manifest.db"))
cur = con.cursor()
cur.execute(
    "SELECT fileID, domain, relativePath FROM Files "
    "WHERE domain = 'HomeDomain' AND relativePath = 'Library/SMS/sms.db'"
)
file_id, domain, rel = cur.fetchone()

# Prove the storage name is SHA1(domain-relativePath):
calc = hashlib.sha1(f"{domain}-{rel}".encode()).hexdigest()
assert calc == file_id, "manifest rule mismatch"
print(file_id)          # 3d0d7e5fb2ce288813306e4d4636395e047a3d28

# iOS 10+ : file is in a subfolder named by the first two hex chars.
src = os.path.join(backup, file_id[:2], file_id)
shutil.copy2(src, "sms.db")
print("recovered sms.db ->", os.path.getsize(src), "bytes")

To pull every photo and video instead of one database, query the camera-roll domain and walk the results:

cur.execute(
    "SELECT fileID, relativePath FROM Files "
    "WHERE domain = 'CameraRollDomain' "
    "  AND relativePath LIKE 'Media/DCIM/%' "
    "  AND flags = 1"                       # 1 = regular file
)
os.makedirs("recovered_photos", exist_ok=True)
for file_id, rel in cur.fetchall():
    src = os.path.join(backup, file_id[:2], file_id)
    out = os.path.join("recovered_photos", os.path.basename(rel))
    if os.path.exists(src):
        shutil.copy2(src, out)

On a Windows examiner machine you will often need to find the backups first (a custodian may not know they exist) and hash them before touching anything. PowerShell does both:

# Enumerate iTunes/Finder backups on this Windows host (both install variants)
$paths = @(
  "$env:APPDATA\Apple Computer\MobileSync\Backup",   # Apple-downloaded iTunes
  "$env:USERPROFILE\Apple\MobileSync\Backup"         # Microsoft Store iTunes
)
foreach ($p in $paths) {
  if (Test-Path $p) {
    Get-ChildItem $p -Directory | ForEach-Object {
      $info = Join-Path $_.FullName "Info.plist"
      [pscustomobject]@{
        DeviceId = $_.Name
        Modified = $_.LastWriteTime
        HasInfo  = Test-Path $info
      }
    }
  }
}

# Hash every file in a backup folder for an integrity baseline (Chain of Custody)
Get-ChildItem "$env:USERPROFILE\Apple\MobileSync\Backup\00008030-001A2B3C4D5E6F70" -Recurse -File |
  Get-FileHash -Algorithm SHA256 |
  Export-Csv -NoTypeInformation backup_hashes.csv

Tool Tip. You do not have to script this. Commercial tools — iMazing, Dr.Fone, iMobie PhoneRescue — and the open-source libimobiledevice suite (idevicebackup2, ideviceinfo, idevicepair) read these backups and present messages, call logs, photos, and notes in a tidy UI. The reason to know the Manifest.db structure anyway is twofold: when a commercial tool chokes on a partial or slightly corrupt backup, a five-line script that walks the manifest will often pull the files the GUI gave up on; and when this same backup becomes evidence (the forensics posture), you must be able to explain in plain language to a judge exactly how a name like 3d0d7e5f… maps to "the text messages," with the SHA-1 rule as your proof.

Encrypted backups. If the owner ever ticked Encrypt local backup, the entire backup is AES-256 encrypted with a key derived from their backup password. You will see IsEncrypted = true in Manifest.plist, the Manifest.db itself will be encrypted, and the per-file blobs are unreadable until you supply the password. The derivation is deliberately slow — iOS 10.2 and later run PBKDF2-SHA256 with 10,000,000 iterations (earlier versions used only 10,000, a real weakness Apple fixed) — so brute-forcing a strong backup password is impractical. The practical recovery path is simple: ask the owner for the password. (If they enabled it and forgot it, that is a hard limitation, not a puzzle for you to crack on the client's dime.) Counterintuitively, an encrypted backup contains more than an unencrypted one — it additionally preserves saved passwords/Keychain, Health data, Wi-Fi settings, and call history — so when the owner remembers the password, an encrypted backup is the richer recovery source.

Chain of Custody. When the backup might be evidence — a corporate IP-theft matter, a family dispute, anything contested — do not open it in place. First image the host computer (or at least forensically copy the entire Backup/<device-id> folder), compute and record a hash (hashdeep/MD5/SHA-256 as in Chapter 14), and do every bit of parsing against the verified copy. The backup's own Info.plist conveniently records the device serial, IMEI, phone number, and last-backup date — facts you will cite in the report (Chapter 26 — The Forensic Report) to tie the data to a specific handset.

iCloud extraction

If the local-backup well is dry, the cloud is the next stop — and for many users it is the primary store, because iCloud Backup is on by default and runs nightly over Wi-Fi. With the owner's Apple ID, password, and a two-factor code from a trusted device, you can recover in three ways: restore an iCloud Backup onto a replacement phone (the consumer route), enable and re-sync iCloud Photos / iCloud Drive to a Mac or PC (often the fastest way to land the photos), or use a tool that authenticates and downloads the iCloud backup directly. Note the hard requirements: you need the real credentials and the ability to pass two-factor authentication. Without the second factor you are locked out as thoroughly as any attacker would be — which is the system working as designed.

Two modern wrinkles change the cloud calculus, and you must know both:

  • Advanced Data Protection (ADP). Since late 2022, a user can enable end-to-end encryption for most iCloud categories — backups, photos, notes, and more. With ADP on, Apple itself cannot read the data and cannot produce it; the keys exist only on the user's trusted devices. If your only surviving credential is the password and every trusted device is gone, ADP-protected data is unrecoverable even to Apple. This is the cloud analogue of the on-device encryption wall.
  • Legal process. For non-end-to-end-encrypted iCloud content, Apple will produce data to law enforcement under proper legal process (a warrant). That is a forensic/legal acquisition channel, not a recovery service you can invoke for a private client — it belongs to Chapter 31 — Cloud Forensics and Chapter 25. For a deceased owner, Apple's Digital Legacy program (a designated Legacy Contact plus a death certificate) is the sanctioned path to the account, and you should steer the family toward it rather than attempting workarounds.

Ethics Note. Theme #6 of this book — the human cost is real — is never closer to the surface than in cloud recovery for a bereaved family. The technically minded reflex is to find a way in. The professional reflex is to find the legitimate way in: the executor's authority, Apple's Digital Legacy or Google's Inactive Account Manager, a death certificate. Helping a family through those processes is real service. Phishing a 2FA code, social-engineering a carrier, or guessing security answers is not recovery — it is account compromise, and it is the kind of shortcut that ends careers and re-traumatizes the people you meant to help.

Why chip-off an iPhone is (almost) pointless

On a hard drive, when the controller dies you can sometimes move the platters. On many Android phones, when the board dies you can desolder the eMMC and read it. Surely, then, you can desolder the iPhone's NAND and read the photos? You can desolder it. You will read back gigabytes of ciphertext and nothing else.

The reason is the key hierarchy above. The iPhone's data is encrypted with keys that depend on the UID fused into the Secure Enclave on the logic board — not on the NAND. The NAND holds only encrypted bytes and the encrypted keybag; the secret that unlocks the keybag lives in silicon you cannot read and cannot move. Worse, on iPhones the NAND is cryptographically paired to the processor: you cannot transplant the NAND from a dead phone onto a working donor board and read it, because the donor's SEP has a different UID and will not produce the original device's keys. Chip-off gives you a perfect copy of an unbreakable safe.

This is also why iPhone board repair — not chip transplant — is the only physical avenue that helps: if you can revive the original board (the original SEP, the original UID) and the owner can supply the passcode, the device decrypts itself normally. Get the board working, enter the passcode, pull the data through the OS. There is no shortcut around the SEP, only the front door.

Limitation. State it to clients plainly: for any iPhone with a Secure Enclave (iPhone 5s and newer — which is to say, every iPhone you will realistically see), data recovery without the passcode and without a backup is not a budget question or a skill question. It is a mathematics question, and the math is against you. There is no bench technique, no chip-off, no clever cable that recovers user data from a locked, backup-less, modern iPhone. Sellers who claim otherwise are selling either fraud or law-enforcement-grade passcode-attack capability that does not apply to private recovery work (and even that, per Chapter 24, is model- and state-dependent and frequently fails).

Android recovery

Android is messier than iOS in every direction — many manufacturers, many chipsets, many OS versions, many security implementations — which means both more opportunities and more pitfalls. The core encryption reality is the same as Apple's, but the variance is enormous: an ancient unencrypted handset is genuinely recoverable at the chip level, while a current flagship with a dedicated security chip is as locked as any iPhone.

The fragmented landscape

A few structural facts orient you. Android storage is typically eMMC (managed NAND with an embedded controller) on most devices or UFS (faster, on flagships); both present a logical block device, which matters for chip-off because a managed-NAND dump is already de-interleaved and ECC-corrected, unlike raw NAND. Partitioning is GPT, with a large userdata partition (the prize) and, on modern devices, a small metadata partition that holds encryption metadata. File systems are usually ext4 or F2FS (Flash-Friendly File System, log-structured, common for /data on modern phones because it suits flash garbage collection).

Encryption evolved in two eras. Full-Disk Encryption (FDE) using dm-crypt encrypted the whole userdata partition with a single key (Android 5–9). File-Based Encryption (FBE) using fscrypt (default from Android 10) encrypts each file with per-file keys in two classes: Device Encrypted (DE) storage, available after boot before any unlock, and Credential Encrypted (CE) storage — the bulk of user data — available only after the user authenticates. FBE thus has the same BFU/AFU character as iOS: before first unlock, CE data is ciphertext. Android 9+ adds metadata encryption so that even file names and sizes in /data are protected before unlock. The keys are protected by the device's Trusted Execution Environment (ARM TrustZone), and on the strongest devices by StrongBox — a dedicated tamper-resistant security chip (for example, Google's Titan M/M2) — with Weaver/Gatekeeper throttling that enforces attempt limits in hardware, exactly the way the Secure Enclave does.

ADB extraction

When the owner is present, the device boots, and the screen works, the friendliest Android path is the Android Debug Bridge (adb). It is also the most commonly misunderstood, because it has prerequisites people forget: USB debugging must be enabled in Developer Options, the device must be unlocked (so CE data is available), and the host must be authorized — the first connection pops a dialog showing the host's RSA key fingerprint, and the user must tap Allow. No unlock, no authorization, no adb access to user data. That gate is a feature.

# Confirm the device is visible and authorized
adb devices -l
# List of devices attached
# 9A271FFBA00123   device  product:redfin model:Pixel_5 ...
#   ^ "device" = authorized.  "unauthorized" = approve the on-screen prompt.
#   "offline" / "no permissions" = driver/cable/trust problem.

# What are we dealing with?
adb shell getprop ro.build.version.release   # e.g. 13
adb shell getprop ro.product.model           # e.g. Pixel 5

# Pull user-accessible media (shared storage) — the common recovery win
adb shell ls /sdcard/DCIM/Camera | head
adb pull /sdcard/DCIM          ./recovered_dcim
adb pull /sdcard/Download      ./recovered_download
adb pull /sdcard/WhatsApp      ./recovered_whatsapp     # if present

# Hash what you pulled, so you can prove integrity later
adb shell "find /sdcard/DCIM -type f -exec sha256sum {} \;" > device_hashes.txt

Two limits constrain adb recovery. First, without root you can only read what the shell user is allowed to read — shared storage (/sdcard, which is the user-visible media partition) and the public areas of app sandboxes — not the protected /data/data app-private directories where message databases and account tokens live. Second, the once-handy adb backup command (adb backup -apk -shared -all -f backup.ab) is deprecated and largely neutered from Android 12 onward: most apps opt out, and on newer releases it returns little or nothing. Where adb backup still works (older devices, cooperative apps), the resulting .ab file is a 24-byte header followed by (optionally AES-encrypted) zlib-compressed tar; the standard way to unpack it is the open-source android-backup-extractor (abe.jar):

java -jar abe.jar unpack backup.ab backup.tar       # prompts for password if encrypted
tar xvf backup.tar

Recovery vs. Forensics. adb pull of /sdcard/DCIM is a perfectly good recovery move — fast, owner-authorized, gets the photos back. It is a poor forensic acquisition: it is selective (you chose what to copy), it can update access times, and it cannot reach the app-private data where the real evidence often hides. A forensic examiner with authority over the same phone uses a different toolchain — logical/file-system/physical extraction via Cellebrite UFED, Magnet AXIOM, MSAB XRY, or an exploit-based tool — to capture the protected partitions and to do it with verifiable integrity. That is the Chapter 24 discipline. Same cable, same phone, very different rigor and very different output.

Chip-off, JTAG, and ISP — and the ciphertext problem

When the board is dead or the OS is inaccessible and there is no encryption barrier (an old or deliberately unencrypted device), Android's soldered storage can be read at the hardware level by three escalating techniques.

         eMMC / UFS package on the board
         ──────────────────────────────
                 ┌───────────┐
   CLK ──────────┤           │   ISP  : solder fine wires to the eMMC's
   CMD ──────────┤  managed  │          CLK/CMD/DATA/VCC test points and
   DAT0..7 ──────┤   NAND    │          read it IN PLACE (no desolder).
   VCC/VCCQ ─────┤ controller│
   GND ──────────┤  + flash  │   JTAG : drive the CPU's boundary-scan TAP
                 └─────┬─────┘          (TCK/TMS/TDI/TDO) to command the eMMC
                   BGA pads                via the processor. No desolder.
                                    CHIP-OFF: reflow ~217C+, lift the BGA,
                                              re-ball, read in a socket/programmer.
                                              Destructive to the mount; highest yield
                                              on a dead board.
  • ISP (In-System Programming). Solder directly to the eMMC's clock, command, and data lines (using known test-point maps) and read the chip without removing it. Least destructive of the three; needs a steady hand and good pinouts.
  • JTAG. Use the processor's boundary-scan Test Access Port to command the memory through the CPU. Non-destructive (nothing is desoldered) but requires supported test points and the right jig (RIFF Box, Easy JTAG, Medusa-class tools) and is slow. JTAG support on modern locked-down SoCs has dwindled.
  • Chip-off. Desolder the BGA package outright (reflow to ~217 °C and above), clean and re-ball the pads, and read it in a programmer or socket adapter. Highest yield when the board itself is dead, but it is destructive to the mounting, risks heat damage to the package, and demands skill. Because eMMC/UFS are managed NAND, the dump you get is a logical image (the embedded controller already handled ECC, wear-leveling, and bad-block remapping) — far easier to parse than a raw-NAND dump, which would require you to reconstruct page/spare layout, ECC, and descrambling by hand.

The catch dominates the technique: on an encrypted device, every one of these reads back ciphertext. ISP, JTAG, and chip-off recover the bytes of userdata, but if those bytes are FBE/FDE-encrypted and the key is gated behind the TEE and the user's unknown credential, you have a flawless copy of an encrypted partition and no way to read it. Chip-level recovery on Android is therefore a real, valuable skill specifically for unencrypted or pre-encryption devices, for devices where you legitimately have the credential, and as an evidence-preservation step in forensics — and a waste of a perfectly good chip on a modern locked one.

War Story. In 2016 a security researcher demonstrated "NAND mirroring" against an iPhone 5c: by cloning the flash he could reset the passcode-attempt counter and exhaust the four-digit PIN without triggering the auto-erase. It worked — because the 5c had no Secure Enclave, so the attempt counter lived in NAND, which he could roll back. The same attack against any SEP iPhone fails completely: the counter and the escalating delays live inside the Secure Enclave, where mirroring the external NAND cannot touch them. One technique, two devices, opposite outcomes — a perfect illustration of theme #4. The method that beats last decade's phone is dead on this decade's, and the only durable lesson is the principle: learn where the secret physically lives, because that is where your recovery either succeeds or stops.

Vendor download modes

Many Android chipsets expose a low-level flashing mode intended for repair and firmware recovery — Qualcomm's EDL (Emergency Download, "9008") mode driven by signed "firehose" programmers, MediaTek's download mode, Samsung's Odin/download mode. In principle these can image storage below the running OS. In practice modern devices require vendor-signed, model-specific firehose loaders, and even when you get a raw image it is encrypted just like a chip-off dump. EDL is a genuine tool for the unencrypted/older corner of the landscape and for shops with the right signed loaders; it is not a general bypass for the encryption wall. Treat claims that "EDL recovers any locked phone" with the same skepticism as iPhone chip-off claims.

SD-card recovery from phones

Not everything in a phone is trapped behind the Secure Enclave or the TEE. Many Android phones (iPhones have never had user-accessible card slots) take a microSD card, and that card is removable storage — which means it is exactly the kind of flash media you already know how to recover from Chapter 7 — File Carving and Chapter 9 — SSD and Flash Recovery. Pop the card out, mount it through a USB card reader behind a write-blocker, image it, and work the image.

The decisive question is how the card was used, because Android offers two modes:

  • Portable storage (the common case). The card is formatted FAT32 or exFAT, readable in any computer, camera, or phone. Deleted photos behave like deleted files on any FAT/exFAT volume: the directory entry is marked free and the FAT cluster chain is released, but the data sits in unallocated clusters until overwritten — deleted is not destroyed, the law of the earlier chapters, fully in force. Carving recovers them.
  • Adoptable storage (Android 6.0+, optional). The user "adopts" the card as an extension of internal storage; Android reformats it (ext4/F2FS) and encrypts it with a key stored in the device's keystore. An adopted card is bound to that phone — useless in another device and unreadable without the originating phone's key. If the source phone is dead, an adopted card is as locked as the rest of the phone. Always check whether a card is portable (readable) or adopted (encrypted) before promising results.

For a portable card, the carving workflow is the familiar one: image first, then scan for file signatures. Phone photos are predominantly JPEG and, on newer devices, HEIC. Their headers are unmistakable — the full table is in Appendix A — File Signatures Reference:

  JPEG with EXIF (most camera photos):
  00000000  FF D8 FF E1 .. .. 45 78  69 66 00 00 4D 4D 00 2A   ......Exif..MM.*
            ^^^^^^^^^^^  SOI + APP1   ^^^^^^^^^^^ "Exif"  ^^^^^ TIFF hdr (MM=big-endian)
            footer: FF D9 (EOI)

  HEIC (newer iPhones/Androids):
  00000000  00 00 00 18 66 74 79 70  68 65 69 63 00 00 00 00   ....ftypheic....
  00000010  6D 69 66 31 68 65 69 63                            mif1heic
            ^ 'ftyp' box, major brand 'heic', compatible brands 'mif1','heic'

You can carve a card with photorec/scalpel/foremost (see Appendix H — Command-Line Reference) or with a few lines that scan for the JPEG SOI/EOI markers — the same approach you will reuse throughout recovery work:

# Minimal JPEG carver for a raw card image (illustrative).
SOI, EOI = b"\xFF\xD8\xFF", b"\xFF\xD9"
data = open("card.img", "rb").read()
i, n = 0, 0
while True:
    start = data.find(SOI, i)
    if start < 0:
        break
    end = data.find(EOI, start)
    if end < 0:
        break
    end += 2                                  # include the EOI marker
    open(f"carved_{n:04d}.jpg", "wb").write(data[start:end])
    n += 1
    i = end
print(f"carved {n} JPEGs")

Two phone-specific gifts make card recovery rewarding. First, the camera writes to a predictable tree — DCIM/Camera/ for the main camera, plus app folders like Pictures/, WhatsApp/Media/, and Movies/ — so even structure-aware recovery has a map to follow. Second, Android's gallery keeps a thumbnail cache in DCIM/.thumbnails/ (and apps keep their own caches); when a full-resolution photo is gone and unrecoverable, a postage-stamp thumbnail of it often survives there, which is sometimes the only — and emotionally, still meaningful — trace of a lost image.

Try This. Take a spare microSD card, copy a dozen photos onto it, then delete them and (separately) quick-format it. Image the card to a file with dd/dcfldd, then run photorec against the image and a manual JPEG carve like the script above. Compare: which photos came back intact, which came back truncated, how many duplicate thumbnails the carve produced from .thumbnails/, and whether a quick format (which clears the file-system metadata but not the data clusters) cost you any actual photos. This single exercise teaches more about flash recovery than a chapter of reading — and it is safe, because it is your own card.

Recovery vs. Forensics. That carved JPEG is the textbook dual-purpose artifact. For recovery, you hand the owner their photo and you are done. For forensics, the same file is a small evidence trove: its EXIF block (the Exif marker above) can carry the capture timestamp, the camera make/model, and — if location services were on — GPS coordinates, all of which feed timeline and attribution analysis in Chapter 20 — Photo, Video, and Document Forensics. The carved bytes are identical; whether you treat them as "a memory returned" or "evidence of where a device was on a given day" is a matter of posture and authority, not of the file.

Physical-access problems: broken screens

A surprising fraction of "my phone is dead" jobs are really "my screen is dead" — the device boots and runs fine, but a shattered or black display means the owner cannot unlock it or drive the interface. The data is right there, unencrypted-in-use (the device is AFU as soon as it is unlocked once), and the entire problem is input/output, not cryptography. These are among the most satisfying recoveries because they reward technique over luck.

Broken-screen iPhone

The cleanest iPhone trick exploits pairing records (also called lockdown or trust records). When an iPhone is connected to a computer and the user taps Trust This Computer, the two devices exchange a certificate pair; the host stores a pairing record (on macOS under /var/db/lockdown/, on Windows under %ProgramData%\Apple\Lockdown\). With a valid pairing record, that trusted computer can talk to the phone — and back it up via iTunes/Finder — without the screen, provided the device is in the AFU state (it has been unlocked at least once since its last boot, so the data is decryptable). So the workflow for a broken-screen iPhone is:

  1. Find a computer the owner previously trusted (their own laptop is the first place to look) and confirm the pairing record exists.
  2. Keep the phone powered and do not let it reboot — a reboot drops it to BFU and the pairing record alone will not unlock the data.
  3. Connect and run an iTunes/Finder backup, or use idevicebackup2 / iMazing. The backup completes blind, and you recover from it exactly as in the backup section above.

If no trusted computer exists, or the phone has rebooted to BFU and you cannot tap "Trust" on a dead screen, the reliable fix is the unglamorous one: replace the display assembly. A swapped screen turns the phone back into a normal, drivable device; the owner enters the passcode, and you pull the data conventionally. (A Lightning Digital AV Adapter can mirror the screen to a TV so you can see it, but you still cannot touch a dead digitizer — mirroring helps diagnosis, not unlock.) Screen replacement is cheaper, faster, and more certain than any exotic data-extraction stunt, and it is usually the right recommendation.

Broken-screen Android

Android gives you more I/O options precisely because it is more open. If USB debugging was already enabled and the host is authorized, scrcpy mirrors and controls the phone from your computer over adb — you can see the screen and operate it with your mouse and keyboard, unlock it, and copy files, all without the broken display. If debugging was not pre-enabled, a USB-OTG adapter with a mouse (and sometimes an external monitor over USB-C DisplayPort/HDMI alt-mode, on phones that support it) can let you navigate to enter the PIN and turn on debugging. And as with iPhone, the workmanlike fallback is a display assembly swap. The order of preference is: scrcpy if debugging is on → OTG mouse / external display to enable it → screen replacement → and only then chip-level work (which, on a modern encrypted Android, runs straight into the wall).

War Story. A field tech spent a frustrating afternoon trying to chip-off a Samsung with a smashed screen, convinced it was the only way in, before a colleague asked the obvious question: "Did the owner have USB debugging on?" He did — he was a developer. Thirty seconds of scrcpy, the owner typed his own PIN remotely, and every file came off cleanly with adb pull. The lesson costs nothing and saves everything: exhaust the I/O problem before you assume an encryption problem. A broken screen is almost never a reason to reach for a soldering iron.

Water and physical damage

Liquid is the classic phone killer, and most of the damage is done after the spill — by people who do the wrong things. Your job is to stop the slow-motion destruction (corrosion) and get the board functional enough to surrender its data, ideally to the original board, because of the NAND-pairing problem you met earlier.

The chemistry: water plus electricity plus dissolved minerals equals corrosion and short circuits. Two rules follow. Do not power it on, and remove power as fast as safely possible — a live board in contact with conductive liquid corrodes and shorts; an unpowered wet board can often be cleaned and revived. And the rice is a myth. Rice does not draw moisture out of a sealed phone meaningfully; it can shed starch and dust into ports, and it gives the owner false confidence to wait, during which corrosion advances. The real remedy is mechanical:

  1. Power off; if the design permits, disconnect the battery (an internal battery feeding the board is the source of ongoing corrosion).
  2. Disassemble down to the logic board.
  3. Clean the board — high-purity (≥99%) isopropyl alcohol, which displaces water and evaporates cleanly, often in an ultrasonic cleaner with an appropriate solution to lift corrosion from under chips and connectors.
  4. Inspect under magnification for corroded traces, pads, and components; repair or replace as needed (micro-soldering territory).
  5. Dry thoroughly (desiccant or low-humidity, not rice), reassemble enough to test, and only then attempt power-on.

The encouraging fact: the NAND package itself is robust. It is the surrounding power management, connectors, and traces that usually fail. If you can revive the board — or repair it enough to boot — a modern phone will decrypt itself normally when the owner enters the passcode, and you pull the data through the OS. If the board is truly dead, you are back to chip-off, with all its caveats: on Android, a chip-off of an unencrypted device can still yield data; on any modern iPhone, the NAND is paired to the SEP and a transplant is futile, so the only hope is repairing the original board.

Tool Tip. Water damage is the area where the line between "data recovery" and "board-level repair" blurs into one job, and it is worth being honest with yourself about your bench's limits. Ultrasonic cleaning, hot-air rework, microscope micro-soldering, and PMIC/connector replacement are specialized skills. If your shop does software recovery but not board repair, the right move on a corroded board is often to partner with (or refer to) a micro-soldering specialist rather than cook a salvageable board with an underpowered heat gun. Knowing what your bench cannot do is part of theme #5 — and the data-recovery business side of this calculus is Chapter 13 — The Data Recovery Business.

Factory reset: sometimes, on old phones

"I factory-reset it and now I need the data back" is a common request, and the honest answer has flipped over the last decade — a clean demonstration of theme #4. The deciding factor is whether the device was encrypted, because reset means two very different things on encrypted versus unencrypted storage.

On an unencrypted, older device, a factory reset historically cleared the file-system metadata and re-created an empty userdata — but the underlying NAND blocks still held the old plaintext until they were reused. That is why, around 2014–2015, security researchers buying used Android phones off resale markets recovered tens of thousands of strangers' photos, emails, and contacts from "wiped" handsets via chip-off and carving. The data was never destroyed, only de-indexed — deleted is not destroyed in its purest, most cautionary form.

On an encrypted, modern device, factory reset is crypto erase: instead of scrubbing the data, the device destroys the key. On iPhone, Erase All Content and Settings wipes the Effaceable Storage that anchors the keybag — a fraction of a second of work that turns every file key into noise. On modern Android, reset discards the FBE/FDE master key material in the keystore. Either way, the gigabytes of "data" remain physically on the NAND, perfectly intact, and perfectly meaningless, because the key needed to decrypt them no longer exists anywhere in the universe. A chip-off recovers the ciphertext; nothing recovers the key.

Why This Matters. Crypto erase is the security industry deliberately weaponizing this book's two core ideas against each other. Deleted is not destroyed (theme #1) is true — the data blocks survive the reset. Encrypted is not accessible — the new reality of this chapter — wins anyway, because without the key the surviving blocks are unrecoverable. This is intended behavior: it is what lets you sell or recycle a phone safely, and it is why "wipe the device" is sound security advice now in a way it was not in 2013. For recovery it is brutal and final. So the practical guidance splits cleanly by era: an old or never-encrypted device that was reset is a legitimate chip-off/carving candidate with real hope; a modern encrypted device that was reset is gone, and telling the client "gone" quickly saves them money and false hope.

The encryption wall

Everything in this chapter converges here, on the single most important professional skill in mobile recovery: recognizing the wall, and being honest about it.

Stack up what you now know. Modern phones are encrypted by default. The keys are bound to hardware secrets you cannot extract — the Secure Enclave's UID, the Android TEE/StrongBox keystore. The passcode can only be tested on the original device's security chip, which rate-limits attempts, imposes escalating delays, and can auto-wipe after a threshold. Chip-off, JTAG, ISP, and EDL all return ciphertext when the device is encrypted. Cloud end-to-end encryption (iCloud ADP) removes even the provider's ability to help. Put together, these mean a hard, unglamorous truth:

For a modern, passcode-protected, full-disk-encrypted phone, with the passcode unknown and no backup, recovery of user data is effectively impossible by legitimate means. Not difficult — impossible, in the sense that no amount of money, skill, or equipment available to a private recovery practice changes the outcome. The data is intact and unreadable, and it will stay that way.

You will feel pressure to soften this. The client is desperate; the photos are irreplaceable; surely someone can do it. Hold the line. The professional response is a calm, specific explanation: the device is encrypted; the key is in tamper-resistant hardware and cannot be extracted; without the passcode there is no path; here are the legitimate things we can still check (a forgotten computer backup, an iCloud/Google account, a trusted computer for a broken-screen AFU device, a removable card). If those come up empty, the answer is "the data cannot be recovered," and that is a complete, professional finding — theme #5, know your limitations, stated to a human being who needs the truth more than they need false hope.

Ethics Note. Two temptations live at this wall, and both are off-limits. The first is fraud: promising recovery you cannot deliver, charging for "attempts" you know will fail, or stringing a grieving client along. The second is illegitimate access: trying to compel a passcode you have no right to, social-engineering a carrier or cloud account, or buying grey-market exploit tooling to attack a device you do not have lawful authority over. Both betray the people this work is supposed to serve. The honest practitioner says no to the job before saying yes to either. (The full ethics treatment, including duties when you do find things, is Chapter 28 — Ethics.)

Legal Note. There is exactly one place where attacking a locked, encrypted phone's passcode is a legitimate activity, and it is not recovery — it is forensics under legal authority. Law-enforcement and corporate forensic labs, operating under a warrant or documented consent, use specialized tools (Cellebrite, GrayKey, and others) that exploit device- and OS-version-specific weaknesses to attempt passcode recovery or extraction. Even there, success is model-, version-, and state-dependent and frequently fails outright on current hardware. That entire domain — the tools, their limits, the law that authorizes them, and the chain-of-custody rigor they demand — is Chapter 24 — Mobile Device Forensics, not this chapter. A private recovery client asking you to "just break into it" is asking for something you are neither equipped nor authorized to do.

Recovery and forensic mobile extraction are different jobs

Because this distinction is the spine of the whole book, make it explicit before you leave the chapter. The table below contrasts the recovery posture (this chapter) with the forensic posture (Chapter 24). Many techniques overlap; the authority, goal, and rigor do not.

                        RECOVERY (this chapter)        FORENSICS (Ch.24)
                        ─────────────────────────      ──────────────────────────
  Who owns the device   Cooperative owner/client       Often an UNcooperative subject
  Authority             Owner's request (in writing)   Warrant / documented consent
  Passcode              Owner provides it               Unknown; may be attacked w/ tools
  Primary goal          Restore the data, fast          Preserve & prove evidence
  On the originals      Work fast; image when prudent   ALWAYS image; hash; write-block
  Documentation         Service notes, invoice          Chain of custody, court-ready report
  Tools                 Backups, iMazing, adb, scrcpy,  + Cellebrite UFED, GrayKey, Magnet
                        carving, board/screen repair      AXIOM, MSAB XRY, Oxygen, exploits
  Output                The user's files, returned      Verified extraction + analysis
  Acceptable result     "Recovered" or "unrecoverable"  "Insufficient evidence" is valid too

The deepest point is that the artifacts are the same — a backup, an SD card, a Manifest.db, a carved JPEG, the contents of /sdcard — and only your posture differs. That is precisely why the signature callout of this book is "Recovery vs. Forensics": you must be able to flip from one mode to the other the moment a job changes character, because the day a routine recovery turns up evidence of a crime (and it will — see Chapter 28), you need to already be working in a way that does not destroy its value as evidence.

Common mistakes

  • Powering on a wet phone "just to check." The single most destructive instinct. A live board in contact with conductive liquid corrodes and shorts in real time. Power off, keep it off, clean it, then test. Every second of power on a wet board lowers your odds.
  • Trusting rice. It does not pull meaningful moisture from a sealed device, it introduces debris, and worst of all it persuades the owner to wait while corrosion advances. Recommend high-purity isopropyl cleaning and proper drying, never the rice bowl.
  • Letting a recovered/seized AFU iPhone reboot or its battery die. AFU (unlocked since boot) means the keys are live and the data is reachable; a reboot drops it to BFU and re-locks everything. Keep it powered, keep it from locking, and pull the data before anything resets it.
  • Assuming chip-off beats encryption. It does not. On any encrypted device, ISP/JTAG/chip-off/EDL return ciphertext. Spending a client's money desoldering a modern locked phone to "get the raw data" yields a flawless copy of an unbreakable safe.
  • Trying to transplant an iPhone's NAND to a donor board. The NAND is cryptographically paired to the original Secure Enclave's UID. A donor SEP cannot produce the original device's keys. Repair the original board or stop.
  • Reaching for the soldering iron before solving the I/O problem. Most "dead" phones with broken screens are alive and reachable via a pairing record (iPhone, AFU) or scrcpy/OTG (Android). Exhaust the input/output options before you assume an encryption or hardware-storage problem.
  • Confusing a portable SD card with an adopted one. A portable (FAT32/exFAT) card is recoverable anywhere; an adopted card is encrypted and bound to its origin phone. Check before you promise the photos back.
  • Promising what encryption forbids. Telling a desperate client you can recover a locked, backup-less modern phone is at best a misunderstanding and at worst fraud. Know the wall; explain it plainly; offer the legitimate avenues that remain.
  • Parsing a potential-evidence backup in place. If the backup might be contested, image and hash the host first and work a verified copy. Opening it directly updates timestamps and forfeits the integrity you may later have to defend.

Limitations: knowing when to stop

Mobile is the chapter where theme #5 bites hardest, so be unsentimental about the ceiling. Encryption without the key is final. When a modern phone is encrypted, the passcode is unknown, there is no backup, and no trusted computer or cloud account survives, the user data is unrecoverable by any legitimate means available to you — full stop. No bench, no budget, no skill changes that. Crypto erase is final. A reset of an encrypted device destroyed the key; the ciphertext that remains will never decrypt. iPhone chip-off is essentially never the answer. The SEP pairing and hardware-bound keys mean a removed NAND is unreadable; only reviving the original board helps, and only with the passcode. Adopted SD cards and ADP-protected cloud data inherit the same wall. And board-level revival has physical limits — some water-damaged or impact-damaged boards are simply destroyed, taking the only readable copy of the key with them.

Knowing when to stop is not defeat; it is professionalism, and it protects three things at once: the client's money (no charging for impossible attempts), your credibility (no overpromising), and the client's emotional well-being (a clear "it cannot be recovered" lets a person grieve a loss instead of clinging to false hope through a string of failed "attempts"). The most senior recovery techs are distinguished not by the impossible saves they pull off but by how quickly and kindly they recognize the cases where the honest answer is "no" — and how reliably they squeeze every legitimate avenue (backup, cloud, card, screen swap, AFU pairing, board repair) before they say it.

Progressive project: the phone evidence enters through the computer

Your Forensic Case File (the running project from Chapter 5 onward) does not get a physical phone until the forensic mobile chapter (Chapter 24) — but mobile data very often enters a case through the computer, and you can add that thread now. In the disk image you have already acquired and hashed for the case, search for the iTunes/Finder backup paths from this chapter (MobileSync\Backup\ on Windows, Library/Application Support/MobileSync/Backup/ on macOS). If a backup is present:

  1. Treat it forensically: it is already inside your verified image, so parse a copy, never the original.
  2. Read Info.plist to document the device — serial, IMEI, phone number, product type, last-backup date — tying the backup to a specific handset for your report.
  3. Use the Manifest.db technique from this chapter to extract the artifacts that will matter later (messages sms.db, contacts, photos with their EXIF) and note their fileID storage names so you can prove, on the stand, how 3d0d7e5f… maps to "the text messages."
  4. Record the find in your evidence log as derived data, with its source hash, ready to correlate against other artifacts when you build the timeline in Chapter 21.

The lesson for the case file is the same as the lesson for the bench: you frequently recover a phone's contents without ever touching the phone, because the phone left a copy somewhere you can lawfully reach. Always look for the backup first.

Summary

Mobile recovery inverts the cheerful premise of the earlier recovery chapters. On hard drives and even SSDs, the operating principle is deleted is not destroyed: the data outlives the pointer and you can chase it down. On modern phones, the operating principle becomes encrypted is not accessible: the data is intact but locked behind hardware-bound keys you cannot extract. The competent practitioner therefore works a decision tree, not a single technique. First the easy, high-yield wins that are not really phone recovery at all — restoring or parsing an iTunes/Finder local backup (whose Manifest.db/SHA-1 structure you can read by hand), pulling from iCloud or a Google account with the owner's credentials and second factor, and imaging a portable SD card to carve photos exactly as in earlier chapters. Then the physical jobs — using an iPhone pairing record on a trusted computer to back up a broken-screen device in its AFU state, scrcpy or a screen swap for Android, and proper water-damage cleaning (isopropyl and ultrasonics, never rice, never power-on) aimed at reviving the original board, because an iPhone's NAND is cryptographically paired to its Secure Enclave and cannot be transplanted. And finally the wall: on a modern, passcode-protected, encrypted phone with no backup and no passcode, recovery is effectively impossible by legitimate means, and factory reset is crypto erase — the key is destroyed, the ciphertext is permanent. Throughout, the same artifacts serve two disciplines: a backup or a carved JPEG is recovery when the owner asks for their data and forensics when it might land in court, and the only difference is your authority, goal, and rigor. Recognizing the wall — and saying "it cannot be recovered" clearly, quickly, and kindly — is not a failure of skill. It is the skill.

You can now: - Triage a mobile recovery job by ownership, backup availability, device state, and encryption status — and know which branch ends in success and which ends in an honest "no." - Locate, read, and parse iTunes/Finder backups by hand, translating Manifest.db and the domain-relativePath SHA-1 rule into recovered messages, contacts, and photos. - Choose the right Android path — adb/scrcpy for cooperative, screen-impaired, or live devices; ISP/JTAG/chip-off only for unencrypted or no-barrier cases — and explain why chip-off yields ciphertext on encrypted storage. - Recover photos from a portable SD card with carving, while distinguishing it from an encrypted adopted card you cannot read off-device. - Handle broken-screen and water-damaged phones with pairing records, mirroring, and board-level cleaning instead of doomed chip transplants. - Explain the encryption wall, crypto erase, and the AFU/BFU and Secure Enclave model to a client in plain language — and tell the difference between owner-cooperative recovery and warrant-authorized forensic extraction.

What's next. Chapter 12 — Ransomware Recovery — moves from a single locked phone to a whole locked business: the third anchor case, where there is no current backup, the shadow copies are gone, and you must recover what you can from unencrypted slack, a stale external backup, and hard choices — proving once more that the cheapest recovery is the backup you made before you needed it.

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.