Chapter 11 — Exercises

A mix of concept checks, hands-on labs (locate a backup, prove a hash, carve an image, sketch a timeline, write the client communication), and judgment calls — because mobile recovery is more decision tree than technique. (answer in Appendix) = worked solution in Answers. ⭐ = stretch. Where a lab references a practice image, see Appendix J — Practice Images and Lab Setup. Do every hardware-adjacent exercise only on devices and media you own or are clearly authorized to access — the same authority rule that opens the chapter's triage tree applies to your practice bench.

Group A — Triage: is this even a recovery job?

11.1 List, in the order you would ask them, the five intake questions that sort almost any mobile recovery job. For each, state in one phrase what the answer rules in or rules out. Then explain, in two sentences, why "Is there a backup?" comes before any question about the device's physical state or chipset — and why getting this order wrong costs you time and the client money. (answer in Appendix)

11.2 A grieving brother sets his late sister's Android phone on your bench. It is a 2023 flagship, powered off, passcode unknown, no computer was ever paired, and he does not have her Google credentials. He wants her photos. Walk the triage tree out loud, naming the exact branch the job lands on and the realistic ceiling. Then identify the one legitimate avenue you would still suggest he pursue, who must authorize it (executor of the estate; Google's Inactive Account Manager), and why "the brother is family" is not, by itself, sufficient authority to proceed — name two laws or legal regimes from the chapter's Legal Note that make unauthorized access risky.

11.3 ⭐ For each of the four intake snapshots below, name the triage branch, the realistic outcome, and the single fact that decides it — in one sentence each: (a) a 2012 Android handset, encryption never enabled, screen cracked, owner present with the PIN; (b) a current iPhone that "just won't turn on," owner present and knows the passcode, last synced to her MacBook two weeks ago; (c) a current Pixel, factory-reset by the owner yesterday "to sell it," now they want the photos back; (d) a microSD card pulled from a Samsung that was used as adoptable storage, the source phone now dead. Rank the four from most to least recoverable and defend the ranking in two sentences.

11.4 A walk-in says only "my phone is broken, can you get my stuff off it?" Write the five-to-seven questions you ask at the counter, in order, that let you quote a realistic outcome before the device ever leaves the front desk. For each question, note what a "bad" answer (from a recoverability standpoint) sounds like.

Group B — The iPhone encryption model

11.5 Describe the iOS Data-Protection key hierarchy from the user's passcode down to a file's bytes in NAND, naming each layer (passcode-derived key, UID key, class keys, keybag, file key) and how each wraps the next. State precisely where the UID lives, that it is a 256-bit AES key, and explain — in one sentence — why that single fact makes copying the encrypted blocks to a fast machine and brute-forcing the passcode offline impossible. (answer in Appendix)

11.6 Define AFU and BFU precisely. A colleague has a powered, unlocked-once iPhone connected to your bench machine for a cooperative recovery. List the two things you must not let happen to it before the pull completes, explain what each would cost you, and describe one concrete bench practice (cable, power, settings) that protects the AFU state.

11.7 Name the four Data-Protection classes (A–D) in one phrase each, and state which kind of data tends to live in each. Which class is the default for most app data? Explain the single most important operational consequence of that default for someone trying to read the data, and connect it directly to the AFU/BFU distinction from 11.6. As a check on your understanding, classify each of the following by the most likely protection class and say whether it is readable on a locked-but-AFU device: (a) a banking app's authentication token, (b) most photos and message databases, (c) the small amount of data the OS needs before first unlock, (d) an in-progress large download that must keep writing while the screen locks.

11.8 ⭐ Explain what Effaceable Storage is, where it sits, and how Erase All Content and Settings can finish in well under a second on a 256 GB iPhone without overwriting 256 GB of NAND. Then connect your answer to two downstream facts from the chapter: why a factory-reset modern iPhone is unrecoverable, and why "wipe before you sell" is sound security advice today in a way it was not in 2013.

Group C — Backups and the cloud

11.9 (Calculate and verify a hash.) Using any tool or a few lines of code, compute the SHA-1 of the ASCII string HomeDomain-Library/SMS/sms.db and confirm it equals the well-known fileID for the iMessage/SMS database. State the value you got. Then state the exact subfolder (iOS 10 and later) the file is stored in inside the backup directory, and explain in one sentence why Apple shards the files into 256 subfolders rather than dumping them all in one directory. (answer in Appendix)

11.10 (Hands-on.) Write the commands to locate iPhone backups on (a) a Windows host with iTunes installed both ways — Apple-downloaded and Microsoft Store — and (b) a macOS host. Give all three full paths, expanding the %APPDATA% / %USERPROFILE% variables to their literal C:\Users\<user>\... forms. You do not need a real backup present; the point is to know the paths cold and test each. As a bonus, write the one-line PowerShell that also reports each backup folder's last-write time so you can tell the client how current it is, and name the four .plist/.db files at the root of a <device-id> folder and what each one is for.

11.11 (Hands-on lab.) You have an unencrypted backup's Manifest.db open in a SQLite browser. Write the SQL that lists every photo and video file under the camera roll. Explain what the flags column value 1 filters for (versus 2 and 4), why you want it, and what would go wrong if you copied every row instead. Then write the two or three lines that would copy each matching file out under its real name, given that storage names are sharded by the first two hex characters.

11.12 (Judgment.) A client's Manifest.plist shows IsEncrypted = true and the client has forgotten the backup password. Explain, in plain language you could actually say to the client, why you cannot simply "crack it" on their dime — reference the PBKDF2-SHA256 iteration count Apple uses on modern iOS (and the much weaker count before iOS 10.2). State the only practical recovery path, and describe how you would document this dead end in your service notes so the client understands they were not shortchanged.

11.13 ⭐ It is counterintuitive, but an encrypted local backup is usually the richer recovery source than an unencrypted one. Name three categories of data the encrypted backup preserves that the unencrypted backup omits, explain in one sentence why Apple drew the line there, and then state the cloud analogue of "encrypted means even we cannot help" — naming the specific 2022 iCloud feature and what happens to the data when the user has lost every trusted device.

Group D — Android recovery

11.14 List the three prerequisites that must all be true before adb can read a non-rooted device's user data, and state what each one protects against. Then explain why adb pull /sdcard/DCIM succeeds but adb pull /data/data fails on the same non-rooted phone — naming the storage distinction (shared vs. app-private) that draws that line. (answer in Appendix)

11.15 (Hands-on, verify the hash.) Write the adb commands to (a) confirm the device is attached and authorized (and name what the three states device, unauthorized, and offline each mean), (b) read the model and Android release, (c) pull the camera folder and the Downloads folder, and (d) produce a SHA-256 hash of everything you pulled. Explain why step (d) matters even in a pure recovery job, and what specifically it lets you prove later.

11.16 In one line each, distinguish ISP, JTAG, and chip-off by method and destructiveness, including the approximate reflow temperature chip-off requires and, for ISP, which signal lines (CLK/CMD/DATA) you solder to. Then explain why a chip-off of an eMMC/UFS package yields a logical image you can parse directly, whereas a raw-NAND dump would force you to reconstruct page/spare layout, ECC, and descrambling by hand. Finish with the one sentence that explains why all three techniques return ciphertext on a modern encrypted device — and state, in a second sentence, the three legitimate situations in which chip-level work on Android is still worth doing despite that.

11.17 ⭐ A vendor's web page claims its Qualcomm "EDL 9008" service "recovers data from any locked Android phone," and a forum post claims the 2016 iPhone 5c "NAND mirroring" attack proves any phone can be beaten with enough cleverness. Dismantle both claims. For EDL, name the two things that defeat it on a modern device; for NAND mirroring, explain in two sentences why the same attack that beat the 5c is dead on any Secure Enclave iPhone, and what general principle that contrast teaches.

Group E — SD cards, carving, and a mini-timeline

11.18 Distinguish portable from adoptable SD-card storage on Android, including the file system each uses and whether it is encrypted. How do you tell which you are holding before you promise the client anything, and what does each mean for recoverability in another machine? Why have iPhones never been part of this conversation? (answer in Appendix)

11.19 (Recover from this image.) A hex view of a recovered cluster on a portable card begins:

00000000  FF D8 FF E1 14 22 45 78  69 66 00 00 4D 4D 00 2A   ......Exif..MM.*

(a) Identify the file type and what the FF D8 FF E1 and Exif / MM bytes each tell you. (b) Give the two-byte marker that ends such a file. (c) Outline, in three steps, a minimal carve that extracts this one file from a raw card image, and name the failure mode of a pure header-to-footer carve when two photos are adjacent or one is fragmented. Run it against your own carved test image from 11.21 if you have one.

11.20 (Build the timeline.) You carve six JPEGs off a portable card; their EXIF capture timestamps are 2024-06-01 14:02, 2024-06-01 14:05, 2024-05-30 09:11, 2024-06-02 18:44, 2024-06-01 14:03, and one file with no EXIF date at all. The owner's iTunes backup Info.plist shows a last-backup date of 2024-06-01 22:00. (a) Put the dated events in chronological order. (b) State which photos would and would not be present in that backup, and why. (c) Explain what the EXIF-less file's missing timestamp does and does not tell you about when the photo was taken, and name one other artifact (filesystem timestamp, filename counter) you might use to place it.

11.21 ⭐ (Hands-on lab — your own card.) Take a spare microSD card, copy a dozen JPEGs onto it, delete them, then quick-format the card. Image it with dd or dcfldd, run photorec against the image, and also run a manual SOI/EOI JPEG carve (the script pattern from the chapter). Report, as a short table: how many photos came back intact, how many truncated, how many duplicate thumbnails the carve pulled out of DCIM/.thumbnails/, and whether the quick format cost you any actual photo data. Explain the result in one paragraph in terms of "deleted is not destroyed," and note one thing a full (not quick) format would have changed.

11.22 Where does Android keep gallery thumbnail caches, and why is a surviving postage-stamp thumbnail in DCIM/.thumbnails/ both emotionally meaningful to a client and forensically useful, even when the full-resolution original is gone forever? Name two limitations of relying on a thumbnail as the recovered artifact (consider resolution and what metadata the thumbnail may not carry), and explain why a carve of a card often produces more thumbnails than originals.

Group F — Physical damage and broken screens

11.23 A customer brings in a phone that fell in a sink three days ago; it has been sitting in a bag of rice ever since, and they admit they "turned it on once to check." State everything that went wrong (the power-on, the wait, the rice), what you do now in correct order (the actual cleaning and inspection sequence, naming the cleaning agent and tool), and what the owner should have done in the first five minutes. Then explain why reviving the original board matters more on an iPhone than on an old Android. (answer in Appendix)

11.24 A broken-screen iPhone arrives; the digitizer is dead but the phone is running, and the owner has their personal laptop with them. Outline the pairing-record (lockdown/trust) workflow that pulls the data without ever touching the screen, naming the open-source tool (libimobiledevice) you would use if the laptop were not available and a backup tool you would run on the laptop itself. Name the host paths where the pairing record lives on macOS and Windows, state the device state the phone must be in for the pairing record to be useful, and identify the one event that would instantly invalidate the whole approach and force a screen swap instead. Why is "mirror the screen to a TV with an AV adapter" not a solution to this particular problem — what can it do, and what can it not do, when the digitizer is dead?

11.25 ⭐ Put the four options for a broken-screen Android recovery in your preferred order — scrcpy, USB-OTG mouse / external display, display-assembly swap, chip-level work — and justify the ordering in terms of cost, certainty, and the encryption wall. For each option, state the precondition it quietly assumes (debugging already enabled? device already AFU? board alive?), and explain why chip-level work sits last even though it sounds the most "powerful."

Group G — The wall, ethics, and the report

11.26 (Write the report / client communication.) A client's modern iPhone is passcode-protected, the passcode is unknown, there is no computer backup, and the iCloud account is gone. Write the short, plain-language paragraph you give them: state the honest finding, explain why in one non-technical sentence (no jargon — no "Secure Enclave" unless you immediately define it), and list the legitimate avenues you checked before concluding. Be specific, be kind, and do not overpromise. Then write the one-line internal service note that records the same finding for your files. (answer in Appendix)

11.27 That same client tells you a competitor shop quoted $1,200 to "chip-off the phone and recover everything." Explain what is almost certainly happening technically, why the chip-off cannot deliver on a Secure Enclave iPhone (in one sentence a layperson would understand), and what your ethical obligation is when a client reports such an offer. Does your answer change if you cannot be sure whether the other shop is incompetent or dishonest? Finally, distinguish this fraudulent offer from the one legitimate context in which a locked iPhone's passcode is attacked — name that context, who operates in it, and why even there success is not guaranteed.

11.28 (Recovery vs. Forensics.) Midway through a routine, owner-authorized recovery of a client's tablet you encounter what appears to be evidence of a serious crime. (a) Explain why it matters that you were already working in a way that preserves the artifacts' evidentiary value. (b) State which posture you must flip into and the first three things you do (and do not do) next. (c) Name the chapter that owns this duty, and the one that owns the chain-of-custody rigor you now need.

11.29 ⭐ (Progressive project.) Working in the verified disk image you acquired for your Forensic Case File, search for an iTunes/Finder backup (MobileSync\Backup\ on Windows, Library/Application Support/MobileSync/Backup/ on macOS). If one exists: (a) read Info.plist and record the device serial, IMEI, product type, iOS version, and last-backup date; (b) use the Manifest.db SHA-1 rule to extract sms.db and the camera roll to a working copy, parsing the copy and never the original inside the image; (c) log the find in your evidence inventory as derived data, citing the source image's hash; and (d) note the fileID storage names so you can later explain, on the stand, how a name like 3d0d7e5f… maps to "the text messages." Write the two-sentence evidence-log entry exactly as it would appear in your case file.

Self-check. You have mastered this chapter when you can look at any phone on the bench and, within five questions, place it on the triage tree — backup, cloud, card, broken-screen, water, or wall — and when you can say "the data cannot be recovered" as confidently and as kindly as you say "I got it all back." Concretely: you should be able to prove the sms.db fileID by hand, carve a JPEG from a raw image, sketch a recovery timeline from EXIF and backup metadata, and explain to a non-technical client why a chip-off of their locked iPhone yields only ciphertext — without notes. If any of those four still feels shaky, re-read the matching chapter section before you try it on a client's device. Next, Chapter 12 — Ransomware Recovery takes the same honesty about limits and applies it to an entire locked business instead of a single locked phone.