Case Study 2 — Preserved to Death: The Plug-Pull and the FTL

DataField.Dev

Case Study 2 — Preserved to Death: The Plug-Pull and the FTL

A well-meaning IT manager "preserves" a suspect's running workstation the way he was taught a decade ago — by yanking the power cord — and bricks the very evidence he meant to protect. The drive was a cheap consumer SSD with no power-loss protection, and it was mid-write. The data was never destroyed; it was walled off behind a corrupted Flash Translation Layer. The lesson contrasts Case Study 1 from the opposite end: there, a recovery error; here, a forensic one, and both flow from not understanding the medium.

Background

A mid-size manufacturer suspected an engineer of funneling proprietary designs to a competitor before resigning — the familiar shape of the "employee who covered their tracks" investigation that threads later chapters of this book (Ch.16, Ch.21). When the engineer stepped out for lunch on his last day, the company's IT manager was sent to "grab his computer before he wipes it." The IT manager was competent and conscientious. He was also working from a rule he had learned years earlier, in a training built entirely around spinning hard drives: to preserve a running machine, pull the plug — don't shut it down, because a clean shutdown runs scripts that can alter the disk.

So he pulled the plug. He reached behind the tower and yanked the power cord out of the back of a machine that was, at that exact moment, in the middle of writing — a large cloud-sync was flushing files to disk and the OS was updating the file system. The workstation had a budget DRAM-less consumer SSD with no power-loss-protection capacitors. When the power vanished mid-write, the controller was partway through updating the FTL's logical-to-physical mapping table, and it never finished.

Recovery vs. Forensics. On a hard drive, the abrupt plug-pull is essentially harmless to the data and was, for years, sound 🔍 forensic doctrine — it froze the disk and avoided shutdown-time writes. On a PLP-less SSD caught mid-write, the same act risks corrupting the FTL and bricking the drive. The reflex didn't change; the medium did. Understanding that difference is the entire case.

The investigation

The workstation reached a forensic examiner two days later. The examiner did everything correctly from that point on — but the damage was already done. Attached through a hardware write-blocker, the SSD would not present a coherent volume. It identified intermittently, reported the wrong capacity, and then hung:

  Bench triage (illustrative)
  $ lsblk -d -o NAME,ROTA,SIZE,TRAN,MODEL
  NAME    ROTA  SIZE TRAN  MODEL
  sda        0    0B sata  (generic / unknown)     <- 0 bytes, no real identity

  $ sudo smartctl -i /dev/sda
  Read Device Identity failed: scsi error medium or hardware error (serious)

  -> Controller in a "panic"/safe-mode identity. The NAND is almost
     certainly intact and full of data, but the FTL map that locates
     it was left inconsistent by the interrupted write. The one
     component that knows where the data lives can no longer assemble it.

This is the consumer SSD's signature failure — sudden power-loss corruption — exactly as the chapter describes it. The flash pages holding the engineer's files were, in all likelihood, sitting intact in the NAND. But the mapping table that translates "the file system's view" into "this physical page on that die" had been corrupted mid-update, and without a coherent FTL the raw NAND is a jigsaw with no picture on the box. The data was not destroyed. It was inaccessible — which, to an investigation that needs to read it, is nearly the same thing, and is a far harder thing to explain.

The examiner laid out the options honestly. A normal forensic image was impossible: there was no coherent logical drive to image. The only paths forward were specialized and uncertain — a vendor-specific controller-level recovery in a flash lab, or a chip-off of the NAND followed by an attempt to reconstruct the proprietary FTL from the raw dump. Both are expensive, neither is guaranteed, and both are complicated by the at-rest encryption many controllers apply by default, which can render a raw NAND dump into ciphertext that is useless without the controller's key (Chapter 9; Chapter 29).

There was a second injury, subtler than the first. The plug-pull had not been documented. No one had photographed the running screen, noted what was on it, recorded that a write was in progress, or write-blocked anything before the cord came out. So even if a flash lab eventually coaxed data out of the NAND, the chain of custody now contained an undocumented, evidence-altering act performed by an untrained responder. The very step meant to preserve the evidence had become a question the examiner would have to answer under oath: what was done to this drive between seizure and analysis, and can you prove it didn't change the data?

Chain of Custody. "Preserve the evidence" is not one fixed action — it is an action chosen for the medium and then documented. Pulling the plug on an SSD-equipped machine, with no photographs, no notes, and no write-blocker, is not preservation; it is an undocumented alteration. Had the responder simply recorded what he saw, noted the active write, and called the examiner before touching anything, even a bad outcome would have been defensible. The undocumented act is what turns a data problem into a credibility problem.

The case did not collapse — investigators turned to evidence outside the bricked drive: the cloud-sync provider's server-side logs (the very sync that had been running), email, and badge records. But the workstation itself, the richest potential source, was effectively lost, and the reason was not the suspect's cleverness. It was a first responder applying a hard-drive reflex to a solid-state world.

The analysis

The medium changed the rules. The plug-pull was correct doctrine for hard drives and remains defensible for them. On a PLP-less consumer SSD caught mid-write, it risks corrupting the FTL and bricking the device. Acquisition technique must follow the medium; a reflex learned on one technology can destroy another.
Power loss corrupts the map, not (necessarily) the data. The NAND pages survived; the FTL mapping table did not. The difference between "data destroyed" and "data walled off behind a broken controller" is the whole story — and it is why the SSD's tiny, opaque computer is its greatest vulnerability.
An untrained first responder is a chain-of-custody risk. The most consequential act in this case was performed by someone with no forensic training and no documentation habit. The first sixty seconds of a seizure — by whoever happens to be there — can decide whether the evidence survives.
Acquisition strategy is a decision, not a reflex. Live acquisition, careful shutdown, or plug-pull are choices with tradeoffs that depend on the medium, on whether full-disk encryption is in play, and on what volatile data is at stake (developed in Chapter 14 and Chapter 15). It should never be muscle memory.
Report what is true: inaccessible is not the same as destroyed. The honest finding — "data is likely intact in NAND but inaccessible via the corrupted FTL; recovery requires specialized, uncertain controller-level techniques" — is precise and defensible. Overstating ("the data is gone") or understating ("we can definitely get it") would both be wrong.

Discussion questions

Both this case and Case Study 1 ended in avoidable loss, and both errors share a single root cause. Name the error in each case and state the common principle that, understood, would have prevented both.
The "pull the plug" rule was genuinely good forensic practice in the hard-drive era. Explain why it was sound then (what shutdown-time risk it avoided) and what specifically about SSDs makes it risky now. Is it ever still the right call?
The NAND was intact but the data was inaccessible. Explain the difference between "destroyed" and "walled off," why it matters to a client and a court, and how you would phrase the finding in a report so that neither word overstates the truth.
⭐ The damage was done by an IT manager, not a trained examiner. Design a one-page first-responder card for seizing a running computer that accounts for both HDDs and SSDs. What would it say about photographing the screen, documenting an in-progress write, power, write-blocking, and when to stop and call an examiner?
On cross-examination, opposing counsel asks: "What did your side do to this drive that made it impossible to analyze?" Explain why the undocumented plug-pull is now both a data problem and a credibility problem, and connect it to chain of custody (Chapter 5) and expert testimony (Chapter 27).