Chapter 9 — Quiz

15 questions: 11 multiple choice, 2 true/false, 2 short answer. Answers and a scoring band are at the bottom. Commit to an answer before you look — this is the chapter where guessing on the stand, or to a client, costs you credibility.

Multiple choice

Q1. Why is an SSD described as "not a small hard drive" at the physical level? - A) It simply spins its platters faster than an HDD - B) A controller running a Flash Translation Layer maps logical addresses to physical NAND, decides where data lives and when old copies are erased — so you are negotiating with the controller, not reading the medium directly - C) It stores data magnetically but with more heads - D) It has no firmware, so reads are always literal

Q2. NAND flash is read and programmed (written) at one granularity but erased at another. Which is correct? - A) Read/program at block granularity; erase at page granularity - B) Read/program at page granularity; erase at block granularity - C) Both happen at the level of a single cell - D) Both happen at the level of an entire die

Q3. The single most important question in any SSD recovery job is: - A) What is the drive's total capacity? - B) Has TRIM been processed against the data you are trying to recover? - C) Is the drive SATA or NVMe? - D) Which file system formatted it?

Q4. On a Deterministic-Read-Zero-After-TRIM (RZAT) drive, when does a host-side read of a trimmed LBA begin returning zeros? - A) Only after garbage collection physically erases the underlying NAND - B) The instant the controller drops the mapping — before any physical erase occurs - C) Never; an RZAT drive always returns the old data until overwritten - D) Only after the next power cycle

Q5. Which situation makes recovery of deleted data on flash most likely to succeed? - A) A modern internal NVMe SSD under current Windows with TRIM enabled - B) An SD card that was reformatted in a camera - C) A volume on which Optimize-Volume -ReTrim was just run - D) An RZAT SSD whose target range was trimmed two days ago

Q6. A hardware write blocker attached to an evidence SSD on the bench prevents: - A) All changes to the drive, including its internal garbage collection - B) Host writes only — it does not stop the controller's autonomous GC and wear leveling - C) Nothing; write blockers do not function on solid-state drives - D) Only the drive's SMART counters from updating

Q7. The controller of a self-encrypting drive (SED) is dead and no recovery key exists. A flawless chip-off of the intact NAND will yield: - A) The user's plaintext files, once ECC is corrected - B) Ciphertext that is worthless without the controller's key - C) A blank dump — SEDs erase the NAND when the controller fails - D) Plaintext, because chip-off bypasses encryption

Q8. Turning a raw chip-off dump into a mountable image means reversing the controller's transformations in order. Which sequence is correct? - A) De-interleave → mount → apply ECC - B) ECC correction → de-scramble (de-randomize) → de-XOR → de-interleave → rebuild the translator (L2P) - C) Rebuild the translator → apply ECC → carve - D) Decrypt → reformat → carve

Q9. Two forensic images of the same SSD, taken minutes apart, produce different SHA-256 hashes, and nothing was tampered with. The professional interpretation is: - A) Someone altered the evidence and the chain of custody is broken - B) The imaging software is defective and the analysis is worthless - C) Autonomous SSD operations (garbage collection / wear leveling) changed unallocated areas — explainable, not tampering - D) One of the hashes was simply transcribed incorrectly

Q10. Most USB thumb drives and microSD cards are "monolithic," which means: - A) They contain one oversized NAND chip that is easy to desolder - B) The controller and the NAND die(s) are fused into a single package, so there is no separable NAND chip to remove - C) They can hold only a single file at a time - D) They are always self-encrypting by design

Q11. Which is a correct, professional finding after a suspect's RZAT SSD was trimmed following a deletion? - A) "No incriminating files ever existed on this device." - B) "The suspect deliberately destroyed the deleted files to conceal a crime." - C) "The evidence is insufficient to determine whether such files were present, because TRIM on this device renders deleted data unrecoverable." - D) "Chip-off will recover the deleted files given an adequate budget."

True/False

Q12. Mounting an evidence SSD read/write on a live, modern operating system "just to see if it works" is a safe first step. (True / False)

Q13. Once TRIM has been processed against a range on an RZAT SSD, chip-off recovery reliably brings that data back. (True / False)

Short answer

Q14. In one or two sentences, explain why "image fast" is a discipline on an SSD but not on a hard drive.

Q15. Name the two questions that decide nearly every SSD case, and state when you must answer them.

---

Answer key

Q1 — B. Underneath the logical-block interface, an SSD is a small computer running an FTL that maps LBAs to physical NAND pages and decides placement, relocation (wear leveling), and erase (garbage collection). The HDD assumption "logical N = physical N, read returns last written" is false; you reason about the controller's behavior, not the bare medium.

Q2 — B. You program a page (e.g., 16 KB) but can only erase a whole block (e.g., 256 pages, ~4 MB), and a page cannot be reprogrammed in place. That asymmetry forces the controller to write updates to fresh pages and remap — the root of wear leveling, GC, and everything that makes flash recovery hard.

Q3 — B. Recoverability hinges on whether TRIM reached the data. The second question is whether it can still run before you finish. Capacity, interface, and file system come after.

Q4 — B. On RZAT, the controller drops the mapping at TRIM time and any read of that LBA returns zeros immediately — the data is effectively unrecoverable by software the instant the mapping is dropped, well before the physical NAND erase that GC performs later.

Q5 — B. Cameras issue no TRIM and card controllers do little autonomous erase, so a reformatted card typically leaves the prior clusters fully carvable. A, C, and D are all situations where TRIM has (or just) ran on a TRIM-honoring drive.

Q6 — B. A write blocker stops host writes (and prevents auto-mount/auto-TRIM), but garbage collection and static wear leveling are internal to the drive and run on the controller's own schedule whenever it is powered — the blocker cannot stop them.

Q7 — B. Chip-off does not break encryption. You would reconstruct a perfect image of ciphertext, useless without the key the (dead) controller held. Always determine whether a drive is encrypted before desoldering.

Q8 — B. ECC correction first (using OOB bytes), then de-scramble the PRBS, then de-XOR any controller XOR layer, then de-interleave across dies/planes/channels, then rebuild the L2P translation from per-page metadata. Only then is the image mountable.

Q9 — C. Non-determinism: GC and static wear leveling autonomously rewrite stale/unallocated areas whenever the drive is powered (named in Bell & Boddington, 2010). The mismatch is explained, not disproven — you minimize powered time, write-block anyway, hash file-resident data separately, and document the behavior.

Q10 — B. In a monolith the controller and NAND share one package (sometimes one die), so there is no NAND chip to remove; recovery means reading the raw NAND through the package via its technological points — even more delicate than ordinary chip-off.

Q11 — C. The honest finding distinguishes "we did not find" from "cannot be recovered because the device erased it," and concedes that absence proves nothing about prior existence. A and B overclaim; D is false on an RZAT-trimmed range.

Q12 — False. This is the chapter's War Story: a modern OS auto-mounts, sees the file system's free space, and issues TRIM for the unallocated ranges — destroying exactly the data you came to recover. Always acquire read-only behind a write blocker; never let a live OS touch a writable evidence volume.

Q13 — False. Once GC has run, chip-off recovers zeros; in the narrow window before GC it might reach an unmapped physical copy, but you cannot know whether GC has run and you cannot stop it — so chip-off is not a reliable cure for TRIM-plus-GC. Quoting a client for it on a trimmed RZAT drive bills them for a drive full of zeros.

Q14. An SSD's controller runs garbage collection and static wear leveling autonomously whenever the drive is powered — even idle, even behind a write blocker — so every powered minute is a minute it can spend erasing the stale pages you are trying to save; a hard drive changes nothing on its own, so imaging can be unhurried.

Q15. Was TRIM issued/processed against the target data? and Is the drive encrypted (a self-encrypting drive)? Both are cheap to answer and must be answered before any quote and before any desoldering — diagnose first, promise second.

Scoring: 13–15 — you reason from the controller's behavior, not the file system, and you know when the answer is "the data is gone"; you're ready for RAID in Chapter 10. 10–12 — solid; re-read the TRIM-determinism and non-determinism sections. 7–9 — review the FTL/GC/TRIM mechanics and the "diagnose before you promise" workflow. Below 7 — re-read the chapter, focusing on why deletion can trigger destruction on flash and on the two diagnostic questions that decide every case.