Case Study 1 — The Photographs No USB Cable Explained

A departing engineer's laptop forensics came back clean — no USB device history, no cloud uploads, no smoking gun. The theft had simply migrated to the one device the examiner had nearly overlooked: the personal phone in his pocket. This is the forensic win the chapter promises, and it turns on a file-system extraction, a write-ahead log, and the discipline to acquire at the highest sound level.

Background

This is the mobile chapter of the book's second anchor case — the employee who covered their tracks. A mid-size aerospace-components firm noticed that a senior design engineer had given two weeks' notice to join a direct competitor, and that in his final month he had spent unusual evening hours at his workstation. Counsel opened an internal trade-secret investigation and issued a litigation hold. The engineer used a company laptop and, under the firm's written BYOD acceptable-use policy, a personal phone enrolled in the company's MDM for email — a policy he had signed, and which consented to forensic examination of company data on the device upon separation. That signed consent, scoped by counsel to company-data categories only, was the authority for everything that followed; there was no criminal warrant, and the examiner stayed rigorously inside the civil scope.

The laptop examination — the Windows-forensics and timeline work of Chapter 16 and Chapter 21 — came back frustratingly clean. The USBSTOR registry keys showed no unfamiliar mass-storage devices; the engineer had plugged in nothing. Browser history and email showed no large uploads to personal cloud. $FILE_NAME MFT timestamps showed late-night access to CAD project directories, which established opportunity but not exfiltration. On the laptop alone, the case stalled: he had clearly looked at the drawings, but there was no evidence any bytes had left the building.

The breakthrough was a question the examiner almost did not ask: if no USB device was ever attached and nothing went to the cloud from the laptop, how would a careful person actually remove a drawing? The simplest answer in the modern workplace is also the one that leaves no trace on the computer at all — you photograph the monitor with the phone in your pocket. The investigation moved to the handset.

The acquisition and analysis

The phone — a Pixel running a current Android, enrolled in MDM, unlocked by the engineer at the start of the session under the consent terms — was acquired at the highest sound level available. With the device unlocked and a temporary, documented elevation to reach /data, the examiner took a file-system extraction, hashed the resulting archive immediately, recorded the device identity for the report, and worked only on copies:

  Extraction: Full File System (Google Pixel, Android 13)   Method: agent (temp elevation)
  Device: model redfin, IMEI 35xxxxxxxxxxxxx, build .../security_patch 2024-02-05
  Archive: pixel_ffs.zip   SHA-256: 4f2a9c... (verified against tool-reported hash)
  Modification disclosed: temporary elevation for /data read; nothing written to persistent partitions; state reverts on reboot.

Two artifact categories broke the case open, and a third sealed it.

First, the photo library and EXIF metadata (Chapter 20). Among ordinary personal photos sat a cluster of images whose content was a computer monitor — screenshots-by-camera of CAD assembly drawings. Their EXIF blocks were the headline: Make="Google" Model="Pixel", capture timestamps falling on exactly the late evenings the laptop's MFT timestamps showed CAD access, and — because location services were on — GPS coordinates resolving to the company's building. A photograph of a monitor leaves the device's fingerprints all over it, and here they placed a personal phone in front of a company workstation, after hours, capturing proprietary drawings.

Second, deleted messages recovered from SQLite. The engineer had used WhatsApp to coordinate with a contact at the competitor and had deleted the thread — and a logical pull of msgstore.db would indeed have shown clean live tables. But the file-system extraction captured msgstore.db and its -wal side file, and the write-ahead log held the pre-deletion frames: the messages, their timestamps, the recipient, and references to "the drawings" and a meeting. Deleted is not destroyed, operating inside a database file. Because the firm's policy and counsel's scope covered company-related communications and the examiner could decrypt the WhatsApp store (the extraction captured both the database and the app's key file), the content was recoverable and in scope.

   msgstore.db (live tables)        →  thread DELETED, nothing visible
   msgstore.db-wal (write-ahead log) →  pre-delete frames:
        2024-02-19 21:47  -> [competitor contact]  "got the full assembly set tonight"
        2024-02-19 21:49  <- [competitor contact]  "perfect, bring them Monday"
   Recovered from: WAL frames 312–319 (not yet checkpointed into main file)

Third, the knowledgeC-equivalent usage traces and Wi-Fi history tied the timeline together. Android usage-stats and on-device traces showed the camera app and WhatsApp active in the same evening windows; the Wi-Fi configuration store showed the device joined to the corporate SSID, and the BSSIDs corroborated presence in the building independent of GPS. Every event converted to a single coherent timeline, each entry sourced to a specific database and location, and validated against a second tool — ALEAPP confirmed the same usage and message timestamps the commercial suite reported, so no single parser's bug could carry the conclusion.

The report (Chapter 26) separated findings from inferences with discipline: "image files X–Z carry EXIF GPS coordinates resolving to [the facility] and creation timestamps of [...]; their visual content is CAD drawings; deleted WhatsApp frames recovered from msgstore.db-wal reference 'the assembly set'" — findings, each sourced. "The engineer exfiltrated trade secrets to the competitor" was framed as the inference the findings support, with the explicit caveat that the phone proves device activity, and that attribution to the engineer rested additionally on the device being his personal handset, unlocked with his credential, holding his accounts. The matter settled before trial; the file-system extraction and the WAL recovery were the evidence that moved it.

The analysis

  1. Follow the data to where it actually went. A clean laptop is not a clean case. When USB and cloud paths show nothing but opportunity is established, ask how a careful person would remove data — and on a modern matter the answer is frequently "they photographed the screen with a phone." The evidence migrated to the handset, and so must the examiner.

  2. Acquire at the highest sound level, or you miss the case. A logical pull of this phone would have shown clean WhatsApp tables and reported "no relevant messages." Only the file-system extraction captured msgstore.db-wal, where the deleted thread survived. Stopping at logical when file-system was achievable would have lost the decisive evidence — the chapter's central acquisition lesson, with real stakes.

  3. Photographs of screens carry the camera's own testimony. EXIF Make/Model, capture timestamps, and (when location services are on) GPS turned a picture of a monitor into proof of which device captured what, when, and where. The act designed to leave no trace on the computer left an abundant trace on the phone.

  4. Deleted is not destroyed — inside a database, too. The recovered messages came from the write-ahead log, and the report stated exactly where (WAL frames not yet checkpointed) and why that location proves deletion rather than fabrication. That sourcing is what makes a recovered "deleted" message survive cross-examination rather than invite it.

  5. Authority and scope made the win admissible. The signed BYOD consent, counsel's scoping to company-data categories, the disclosed device modification, the immediate hashing, and the second-tool validation are why this extraction was evidence and not merely data. The cleverness recovered the messages; the paperwork made them count.

Discussion questions

  1. The laptop forensics were clean. Walk through the reasoning that took the examiner from "no USB, no cloud" to "examine the phone." What other modern exfiltration paths leave little or no trace on the computer but rich traces on a handset?

  2. The case turned on a file-system extraction reaching msgstore.db-wal. Explain to a non-technical decision-maker why a "complete backup" of the phone (a logical extraction) would have reported the messages as simply not present — and why that is not the same as their never having existed.

  3. The examiner could decrypt WhatsApp because the extraction captured both msgstore.db and the app's key file. How would the finding have changed if the engineer had used Signal instead, and what is the exact, defensible sentence the report would then contain?

  4. The phone proves device activity, not who held it. List the additional facts that strengthened attribution to the engineer here, and identify what a defense could still legitimately argue despite them.

  5. ⭐ Re-run this as a criminal matter rather than a civil one: the same phone is now seized under a warrant, the engineer is uncooperative, and the device is a locked A12+ iPhone instead of an unlocked Pixel. Explain how authority, acquisition options, and the realistic outcome all change — and why the very same evidence might be unreachable. Which chapter governs the authority questions, and which governs the encryption wall?