Case Study 2 — The Backup She Locked Herself Out Of

A wedding photographer encrypted her only archive drive after a break-in scare — then lost both the password and the recovery key. Eight years of client galleries became a wall of ciphertext that no lab, budget, or tool could open. This is the recovery mirror of Case Study 1: there, a corporate key sat in a directory the whole time; here, there was no key anywhere, and the math that protected her from a thief protected the data from her too. It is the gentlest and most final form of the chapter's central wall.

Background

A self-employed wedding photographer ran her entire business off one workflow: shoot, cull, edit, deliver — then archive each wedding to a single 4 TB external SSD that held eight years of client galleries, the raw files included. After a studio break-in in which a laptop was stolen, she did the responsible thing and encrypted that archive drive with BitLocker To Go, choosing a password and (the wizard insisted) saving a 48-digit recovery key. A year later, prompted by a security article, she changed the password to something new and "more memorable." She printed the original recovery key and put it "somewhere safe." When a controller cable failure made the drive briefly inaccessible, she went to unlock it and discovered she could remember neither the new password nor where the printout was. The drive was a personal device on a local account — no organization, no Active Directory, no Microsoft-account escrow. She brought it to your recovery shop with the sentence every technician dreads: "This is the only copy."

This is the book's first anchor case — irreplaceable images, the recovery technician as both engineer and human service — in its darkest variant. In Chapter 1 the deleted wedding photos came back, because deletion only removes the pointer. Here the same theme meets its one true exception.

The recovery attempt

You did what the second theme demands even when the data is unreadable: you protected the original. You imaged the SSD through a write-blocker, verified hashes, and worked only on the copy. The drive was mechanically and logically sound — this was not a failure of the media. An entropy scan and a header read told the whole story in two lines:

$ xxd -l 16 GALLERY-ARCHIVE.dd
00000000: eb58 902d 4656 452d 4653 2d00 0200 0800   .X.-FVE-FS-  (BitLocker)

$ manage-bde -status (working copy)
  Conversion Status:  Fully Encrypted
  Encryption Method:  XTS-AES-128
  Protection Status:  Protection On
  Lock Status:        Locked
  Key Protectors:     Numerical Password ; Password

Two protectors, both useless to you: a Numerical Password (the 48-digit recovery key she had lost) and a Password (the one she had forgotten). You walked the key-source playbook honestly, branch by branch, and watched every door close:

  • Escrow? None. A personal device, local account — nothing in AD, Entra, or a Microsoft account. The recovery key existed only on a printout no one could find.
  • Key in memory? None. An external data drive with no operating system, powered off for weeks. There was never a running, unlocked host to capture, no hiberfil.sys, no page file, no crash dump — nothing that had ever held the FVEK.
  • Suspended / clear key? No. Protection status was On; this was genuine encryption, not a suspended volume with a clear key sitting in the metadata.
  • Weak passphrase + the KDF reality? The only remaining avenue. You extracted a crackable representation and ran a GPU attack:
$ bitlocker2john -i GALLERY-ARCHIVE.dd > bl.hash
$ hashcat -m 22100 bl.hash wordlists/ + rules/   (BitLocker user-password attack)
  Speed.#1.........:  ~ a few hundred H/s   (deliberately slow KDF)

You built a targeted wordlist from everything she could recall — pet names, wedding dates, studio slogans, character substitutions — and ran dictionary-plus-rules and then mask attacks for weeks of GPU time. The 48-digit recovery key was never a target: with its built-in checksum structure it has cryptographic-grade entropy and would never fall. The user password was the only hope, and she had chosen a long, made-up phrase she simply could no longer reconstruct. After the candidate space her hints defined was exhausted, the honest assessment was that an unbounded brute force against a strong passphrase, throttled by BitLocker's KDF, would not finish in any timeframe that mattered. You stopped.

The hard conversation

The professional product here was not data; it was the truth, delivered with care. You explained that the drive was perfectly intact, that every byte she had ever written was still physically present, and that without the password or the recovery key those bytes could not be made to mean anything — by you or by anyone, regardless of price. You told her plainly that a competitor advertising "we crack any drive, no questions asked" was selling either a fabrication or, when applied to someone else's locked drive, an unauthorized-access service no reputable lab provides. You did not bill her for a miracle. You did give her the one constructive path that remained: a thorough search for the printed recovery key, since a single 48-digit string would open everything in seconds — and, going forward, a real 3-2-1 backup so that no single lost secret could ever erase her life's work again.

The analysis

  1. Strong, correctly used encryption is unbreakable — including by its rightful owner. The four conditions of the wall all held: sound AES-XTS, a strong memorized password through a real KDF, no escrow, no key in memory. This was not a skills gap or a budget gap; it was encryption working exactly as designed.

  2. Encryption protects everyone equally — including from themselves. She encrypted the drive to defeat a thief, and it did. The same wall that would have stopped the burglar stopped her. The technology does not know whose hand is on the keyboard; it only knows whether the right secret was supplied.

  3. The honest finding is the complete finding. "Acquired, verified, and inaccessible — no recoverable key" is a professional result, not a confession of incompetence. Refusing to sell false hope is part of the job, and saying so kindly is the harder, better skill. The mature technician internalizes this rather than chasing a brute force everyone knows will fail.

  4. The recovery key is the backup of the backup — treat it accordingly. Her one survivable mistake was losing the 48-digit recovery key; a single secure copy of it would have made this a five-second fix. Escrow, a password manager entry, a printout in a known place — the recovery key is the most valuable forty-eight digits a user owns, and most people file it like junk mail.

  5. The deepest lesson is prevention, exactly as in ransomware. Chapter 12 teaches that ransomware is hostile encryption and that backups, not decryption, are the answer. This case is the friendly-fire version of the same lesson: a current, tested, separately recoverable backup would have turned a catastrophe into an inconvenience. Encryption raises the stakes of the backup discipline, it does not replace it.

Discussion questions

  1. Compare this case directly with Case Study 1. Both drives were BitLocker, XTS-AES-128, with a TPM-or-password and a numerical-password protector. Identify the single difference that made one openable in an hour and the other permanently closed, and state the general principle it illustrates.

  2. You spent weeks on a brute-force attack you suspected would fail. Argue both sides: when is continuing a low-odds password attack a reasonable service to a desperate client, and when does it cross into billing for false hope? Where would you draw the line, and how would you document the decision?

  3. The 48-digit recovery key was never a viable crack target, but the user password was. Explain why — what is different about the entropy and structure of the two — and why a user who "made the password more memorable" may have unknowingly weakened or, by losing the recovery key, orphaned their own drive.

  4. ⭐ Reframe this exact scenario as a forensic matter: the same locked personal drive is now evidence seized from a suspect, powered off, with no escrow and a strong password. Walk the key-sources again and show they close identically — then explain what avenue exists in the forensic case that does not exist in the recovery case (hint: it is not technical), and why even that avenue might fail.

  5. Write the three-sentence honesty script you would use with this client — acknowledging the loss, explaining without jargon why no one can open the drive, and warning her about "we crack anything" services — in keeping with Chapter 28 — Ethics's duty not to overstate capability to win or keep business.