Case Study 1 — The Shattered Screen and the Laptop in the Drawer

A wedding's worth of photos lived only on a phone with a dead screen, and the panicked client was sure they were gone. They were never gone — they were one trusted laptop and one backup away. This is the easy win the chapter keeps promising: solve the input/output problem before you assume an encryption problem.

Background

A second shooter for a small wedding studio dropped her work iPhone on a stone patio the morning after a Saturday wedding. The phone still ran — it buzzed, it rang — but the display was a spiderweb of black, the digitizer dead. On it were roughly four hundred behind-the-scenes and candid shots she had taken to supplement the lead photographer's gallery: getting-ready moments, the toast, the dog in a bow tie. None of it had been delivered yet. None of it had been culled to the studio's cloud. The couple's gallery was due Friday, and the studio owner called you Monday morning in the particular flat voice of someone who has not slept.

This is the modern shape of the book's first anchor case. In Chapter 1 the lost photos were ten years of family memories on a reformatted hard drive, and the lesson was deleted is not destroyed — chase the data down on the platter. Here the photos were born on a phone, lived on a phone, and were one accident away from dying on a phone, with no drive to image. The instinct of a panicked owner — and, frankly, of an inexperienced tech — is to imagine the data trapped behind unbreakable encryption and start pricing exotic extractions. The discipline of this chapter is to slow down and run the triage tree first.

The recovery

The intake answered the five triage questions fast. The owner was present and clearly authorized (it was a studio device, she was an employee, the studio signed the work order). The device powered on and the board was alive — the problem was purely I/O, a dead screen on a living phone. And, critically, the phone had been used all weekend, so it was AFU: unlocked at least once since its last boot, which meant the Class C keys were live in memory and the data was decryptable in place. The only thing standing between you and four hundred photos was the broken glass.

The decisive question was backups, and the answer was the laptop in the studio drawer. The shooter occasionally plugged her phone into the studio's old MacBook to charge while editing, and months ago she had tapped Trust This Computer. That tap had created a pairing record — a lockdown/trust certificate pair — and it was still sitting on the MacBook:

  macOS pairing records:
     /var/db/lockdown/<UDID>.plist        ← present for this device's UDID
  (Windows equivalent, for reference:
     %ProgramData%\Apple\Lockdown\<UDID>.plist)

With a valid pairing record, a trusted computer can back up an AFU iPhone over the cable without ever touching the screen. You connected the phone to that same MacBook, confirmed it was visible, and ran a Finder backup. (On a different machine you would have reached for idevicebackup2 from the open-source libimobiledevice suite; here the studio's own already-trusted Mac was the cleanest path.) The first thing you did, before anything else, was protect the AFU state: the phone stayed on the charger, and you disabled anything that might reboot it. A reboot would have dropped it to BFU, and the pairing record alone cannot unlock a BFU device's data — that would have turned a thirty-minute job into a screen replacement.

The backup completed blind, in about forty minutes, landing in the standard location:

  ~/Library/Application Support/MobileSync/Backup/00008101-000A4D2E1E78001E/
   ├── Manifest.db        (SQLite index — human path  ->  storage hash)
   ├── Manifest.plist     IsEncrypted = false
   ├── Info.plist         device serial, IMEI, product type, last-backup date
   └── 00/ 01/ ... ff/    256 subfolders of hash-named files

Because the backup was unencrypted, the photos were immediately accessible — but not under their real names. Each file is stored as SHA1("domain-relativePath"), in a subfolder named by the first two hex characters of that hash. You walked the camera roll straight out of the Manifest.db:

import os, shutil, sqlite3
backup = "/.../MobileSync/Backup/00008101-000A4D2E1E78001E"
con = sqlite3.connect(os.path.join(backup, "Manifest.db"))
cur = con.cursor()
cur.execute(
    "SELECT fileID, relativePath FROM Files "
    "WHERE domain = 'CameraRollDomain' "
    "  AND relativePath LIKE 'Media/DCIM/%' "
    "  AND flags = 1")                 # 1 = regular file
os.makedirs("delivered", exist_ok=True)
n = 0
for file_id, rel in cur.fetchall():
    src = os.path.join(backup, file_id[:2], file_id)
    if os.path.exists(src):
        shutil.copy2(src, os.path.join("delivered", os.path.basename(rel)))
        n += 1
print(n, "media files recovered")     # 412 media files recovered

Four hundred twelve files came out — a mix of HEIC stills (header ftypheic) and a few .mov clips — every one openable, every EXIF block intact with capture timestamps that let the studio sort them back into the wedding-day timeline. You hashed the delivered set, handed the studio a drive and a manifest, and recommended the obvious prevention: turn on the studio's cloud sync so the next dropped phone is a hardware annoyance, not a near-disaster. Total bench time was under an hour, and not one component was desoldered.

The analysis

  1. Solve the I/O problem before you assume an encryption problem. A "dead" phone with a broken screen is usually a living, decryptable phone with an input problem. The owner imagined unbreakable encryption; the reality was broken glass on an AFU device. Reaching for chip-off here would have been an expensive way to manufacture ciphertext.

  2. AFU is a perishable asset — protect it. Because the phone had been unlocked since boot, its keys were live and the data was readable. That state survives only until a reboot or, on some configurations, a long lock. Keeping the device powered and preventing a reboot was the single most important technical decision in the case.

  3. The pairing record is the key that fits the lock you actually have. A previously trusted computer can back up an AFU iPhone without the screen. The studio's own MacBook held that trust from a months-old "Trust This Computer" tap — a reminder that the fastest path often already exists in the client's environment if you ask the right intake questions.

  4. Know the backup internals so you are never at the mercy of a GUI. The photos were stored under SHA-1 hash names, not filenames. Reading Manifest.db directly — and filtering CameraRollDomain with flags = 1 — pulled exactly the media, by hand, in a way you could later explain to anyone. A commercial tool would have worked too, but the structural knowledge is what rescues the partial or stubborn backups a GUI gives up on.

  5. The cheapest recovery is the one the owner could have prevented. The job ended with a prevention conversation, not just a delivery. Turning on cloud sync converts the next catastrophe into a non-event — the recurring lesson that the best recovery is the backup made before it was needed.

Discussion questions

  1. The phone was AFU when it arrived. Walk through exactly what would have changed about this recovery if it had rebooted to BFU on the drive over — and what your options would have been then.

  2. The pairing record made a screen-touch unnecessary. If no trusted computer had existed, rank the remaining options (screen-assembly swap, AV-adapter mirroring, declining) and justify your top choice on cost and certainty.

  3. Why did reading Manifest.db and filtering on flags = 1 and CameraRollDomain matter, rather than just copying every file in the backup folder? What would a naive "copy everything" approach have produced?

  4. The backup here was unencrypted. Suppose it had been encrypted and the shooter remembered the password. Would that have helped or hurt this particular recovery, and what additional data would the encrypted backup have contained?

  5. ⭐ Reframe this exact scenario as a forensic matter — say the studio later alleged the shooter deleted photos to sabotage a deadline. What would you have had to do differently from the very first minute (handling, imaging, hashing, chain of custody) for the recovered photos and their EXIF timestamps to be defensible in a dispute? Cite the chapter that owns that rigor.