Case Study 2 — Ten Years in the Cache: Recovering a Browser Profile From a Dying Drive

A self-employed photographer's laptop is failing, she never backed up to the cloud, and what she needs back is a decade of bookmarks, a list of the sites where she had saved logins, and a paid receipt she only ever viewed inside webmail and never downloaded. No court, no suspect — pure recovery. The lesson is the chapter's signature dual lens: this is the same History, Cache, and Login Data the examiner in Case Study 1 froze, read here for the opposite purpose.

Background

The client runs a one-person portrait and wedding studio. Her four-year-old laptop has begun freezing and throwing SMART warnings; its SSD's reallocated-sector count is climbing and the controller is starting to drop offline under load. She has no cloud backup — her business contacts, vendor lists, and client-gallery links live in her browser, and that is all. She walks in with a shoebox of the symptoms and one priority list: the bookmarks she has built over ten years, the list of which sites she had saved passwords for (so she can reset them safely on a new machine), and — the part she is most upset about — a set of product photos and a paid receipt for a large print order that she had only ever opened inside Gmail in the browser and never saved to disk. She needs to re-place that order and cannot find it.

This is a data-recovery engagement, not a forensic one, and the difference shapes every decision. There is no adverse party, no chain-of-custody requirement, no question of admissibility — only the human service of getting an irreplaceable digital life back, the spirit of the book's first anchor case. But the second theme still governs, and for a second reason: the original is sacred here not because a court demands it, but because the drive is dying, and every avoidable read risks the data you are trying to save.

The recovery

Image first, even with no court in sight. You do not browse the failing SSD live. Following the failing-media approach from Chapter 9 — SSD and Flash Recovery, you clone the drive with ddrescue, which reads the good regions first and retries the weak ones last, producing an image and a map of any unreadable sectors. The SSD drops offline twice during the clone and is re-seated; the second pass fills most of the gaps. From here you work only on the image — if the drive dies mid-recovery, the client's data is already safe.

Bookmarks — straight out of JSON. You extract the Chromium profile from the image and find Bookmarks, a plain JSON file, intact, plus its Bookmarks.bak. Ten years of vendor contacts, venue links, and client galleries parse out immediately, each with a date_added you convert from WebKit for her own reference. One detail matters even in recovery: her three most recent bookmarks were missing from Bookmarks but present once you accounted for recent activity — copying the whole profile, WAL companions included, is good practice no matter which discipline you are in.

Saved-login site list — without decrypting a thing. She does not need her passwords back; she needs to know which sites to reset. The Login Data logins table gives you exactly that — origin_url and username_value for every saved credential — with no decryption required:

Login Data → logins (metadata, no decryption needed)
origin_url                          username_value
https://www.theknot.com/...         studio@her-domain.com
https://vendor-prints.com/login     studio@her-domain.com
https://accounts.google.com/...     studio@her-domain.com
... (61 sites total)

Because this is her machine and her account, the encrypted v10/v11 values would in fact re-decrypt under her own Windows logon and DPAPI key if she ever needed them — the very dependency that makes them a Chapter 29 problem for an examiner facing a locked account is a non-issue for the owner. But the clean, safe deliverable is the reset list, and that is what you hand her.

The receipt she never saved — carved from the cache. The painful item is the print receipt and product photos she viewed in Gmail but never downloaded. They were never "saved," so there is no document to recover — except that the browser saved them for her, automatically, in the cache. You carve Default\Cache\Cache_Data and the standalone f_###### files by signature — FF D8 FF for JPEG, 89 50 4E 47 for PNG (Chapter 7 — File Carving, table in Appendix A) — and recover the product images and the receipt JPEG. Better still, each cache entry's metadata carries the source URL and fetch time, so the recovered receipt is not an anonymous picture: it points straight back to the order page, and she re-places the order that afternoon.

Restore, and let the engine rebuild. You copy the recovered profile onto her new laptop and let Chrome open it normally — checkpointing the WAL, rebuilding indexes, optimizing the databases. This is the precise opposite of the examiner's discipline in Case Study 1, and deliberately so: there, the goal was a pristine, byte-identical evidentiary copy that must never change; here, the goal is a working browser, and a rebuilt, healthy profile is the success criterion. Same History, same Cache, same Login Data files; opposite jobs.

A limitation lands honestly. Two cached images came back truncated — half-rendered JPEGs — because the failing drive had partially overwritten their cache blocks during the laptop's final, struggling weeks of ongoing browsing. The recovery window for cache and deleted rows is real but finite (theme five), and continued use on a dying drive is exactly what closes it. You set that expectation plainly, and you note the flip side of Case Study 1's lesson: anything she had viewed in a private window would never have entered the cache at all, and so could not have been recovered — for a small-business owner with no backups, incognito is a quiet way to lose your own receipts.

The analysis

  1. Recovery and forensics read the same files for opposite ends. The examiner freezes the profile to prove; the technician rebuilds it to restore. History, Cache, Bookmarks, and Login Data serve both — the discipline is in the goal, not the file.
  2. Image the failing original first — even with no court involved. Irreplaceable plus dying equals clone-before-you-touch. Theme two applies to recovery for the data's sake, not only to forensics for admissibility's sake.
  3. The cache is a second chance at never-saved content. Files the user only viewed — webmail attachments, product photos, a receipt — persist as ordinary JPEG/PNG data and carve by signature, with entry metadata supplying a source URL.
  4. Copy the WAL trio even in recovery. Her newest bookmarks were not yet in the main file; the same WAL discipline that protects an examiner protects a client.
  5. The recovery window is finite, so set expectations. Ongoing writes on a failing drive truncate cached files and overwrite freed pages; act early, and tell the client honestly what the window did and did not allow.

Discussion questions

  1. The technician let Chrome checkpoint and rebuild the restored profile, something the examiner in Case Study 1 would never do. Explain the divergence in terms of each job's success criterion, and why neither choice is "more correct" than the other.
  2. Why image a failing SSD before extracting the profile, even when no court is involved? Tie your answer to themes two (the original is sacred) and five (know your limitations).
  3. She viewed the receipt only inside webmail and never downloaded it, yet you recovered the image. From which artifact, and what made the recovered file more than an anonymous blob?
  4. ⭐ Suppose the same drive later becomes evidence in a billing dispute over that print order. List exactly what the technician should have done differently from step one to keep this recovery forensically defensible, and identify what is now unrecoverably compromised by the recovery-first workflow.
  5. Which of her three priority items would have been unrecoverable if she had done everything in a private window, and why does that make incognito a poor default habit for a backup-less small business?