Case Study 2 — The Server That Reconstructed the Same Way Twice

A seized file server holds the evidence in a corporate intellectual-property theft. The array must be rebuilt without its controller — but here the goal is not speed, it is reproducibility: a reconstruction so well documented that the opposing expert rebuilds the identical volume from the same images and gets the same hashes. This is the forensic counterpoint to Case Study 1 — same XOR math, entirely different discipline.

Background

This is the corporate IP-theft matter introduced as the book's running anchor case (Chapter 1). A departing senior engineer was suspected of copying proprietary design files to personal storage before resigning to join a competitor. Most of the analysis would center on his workstation, but the files he was accused of taking lived on the department's file server — a four-disk RAID 5 running under a hardware controller in a small rack. Counsel placed a litigation hold and had the server preserved. The controller was older and the firm could not guarantee a compatible spare, so the examiner's task was to reconstruct the volume virtually, from the bare drives, and to do it in a way that would withstand a Daubert challenge (Chapter 25) and cross-examination (Chapter 27).

The recovery question — "can we get the data back?" — was easy. The forensic question — "can we prove this is the data, unaltered, and reconstruct it identically on demand?" — set the entire workflow.

The investigation

Document before you touch. Before any drive left the chassis, the examiner photographed the rack, the server, the open bays, and the cabling, then recorded each drive's make, model, and serial against the bay it occupied. Identical drives become anonymous within minutes in a pile; the physical record is what lets the report later say which physical object produced which image.

Exhibit  Bay   Model            Serial          CoC label
  E-21    0    HGST 4TB SAS     WMC4N0H8K3P2    E21-bay0
  E-22    1    HGST 4TB SAS     WMC4N0H9L0Q7    E22-bay1
  E-23    2    HGST 4TB SAS     WMC4N0J1M4R3    E23-bay2
  E-24    3    HGST 4TB SAS     WMC4N0J2N8S9    E24-bay3

Each drive was labeled physically with its exhibit ID and bay before leaving the chassis, and the serials were recorded on the chain-of-custody form.

Image behind a write-blocker; hash immediately. Each member was imaged through a hardware write-blocker (Ch.14) and hashed the moment imaging finished, so the hash anchors the evidence at acquisition:

E21-bay0.dd   sha256: 9a1f4c…77be   acquired 09:14, verified read-back OK
E22-bay1.dd   sha256: 2d6e08…41ac   acquired 10:02, verified read-back OK
E23-bay2.dd   sha256: c4b7f3…90d1   acquired 10:58, verified read-back OK
E24-bay3.dd   sha256: 7e3a55…b2f6   acquired 11:49, verified read-back OK

All four imaged cleanly — consistent with the array having been preserved healthy rather than mid-failure. Crucially, no analysis or reconstruction would ever touch the originals again; everything that followed ran on the verified images.

Read the metadata, derive the parameters. The controller used SNIA DDF (anchor signature 0xDE11DE11) in a reserved area at the end of each member. Parsing it answered five of the six unknowns, and the per-disk role fields gave the order; the examiner cross-checked by confirming the reconstructed offset 0 was a clean NTFS boot sector:

00000000  EB 52 90 4E 54 46 53 20  20 20 20 00 02 08 00 00  |..NTFS    .....|
000001F0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 AA  |..............U.|

Reconstruction parameters (derived)
  Array level ......... RAID 5
  Members / order ..... E21-bay0, E22-bay1, E23-bay2, E24-bay3
  Strip size .......... 64 KB
  Parity layout ....... left-symmetric (synchronous)
  Data offset ......... 1,048,576 bytes (sector 2048)
  Source of params .... DDF metadata (order, strip, layout, offset);
                        confirmed empirically by boot-sector + $MFT alignment
  Stale member ........ none (all DDF sequence counters equal)

Verify, don't celebrate. The examiner assembled the virtual volume from the four images, mounted it read-only, ran a non-writing consistency check, and opened a dozen large files from deep in the tree — design files, a multi-hundred-megabyte CAD archive, a deeply nested PDF. All opened cleanly; the geometry was correct. Only then was the reconstructed volume itself imaged and hashed, becoming a derived exhibit with its own documented lineage from the four member images.

Scope what you examine, even when you can read everything. The reconstructed volume exposed the entire department's data — roughly sixty people's files, nearly all of it irrelevant and none of it the examiner's to read. The engagement and the litigation hold covered one custodian and one matter. So the examiner reconstructed the whole volume (you must, to access anything), then restricted the examination to the suspect engineer's directories and the disputed project folders, logged the keyword and path filters used, and documented what was excluded and why. The capacity to read all sixty employees' files was never authorization to do so — a distinction the report stated explicitly, both to protect uninvolved staff and to keep the examination defensible (Ch.28).

Reproducibility is the deliverable. The report stated the parameters and how each was derived, so that any competent examiner could rebuild the identical volume from the same four images. Months later the opposing expert did exactly that — and produced a volume whose hash matched the examiner's derived exhibit. That match did not weaken the case; it confirmed the method. A reconstruction another expert can reproduce byte-for-byte is the opposite of a guess.

Against that reconstructed volume the rest of the investigation ran as it would against any single image: the timeline (Ch.21) and Windows artifacts (Ch.16) placed the engineer's account accessing the disputed project folders in the days before his resignation, and the server's records corroborated the USB-copy artifacts found on his workstation. The array reconstruction did not prove the theft; it provided an admissible surface on which the proof could be built.

The analysis

1. Forensic reconstruction means reproducible reconstruction. The recovery tech is done when files open; the examiner is done only when the parameters, their derivation, the hashes, and the verification are documented well enough for an independent expert to rebuild the identical volume. Reproducibility — not the files themselves — is the forensic product.

2. Image every member behind a write-blocker and hash at acquisition. The originals were never touched after imaging, and each image's hash anchors it to the moment of acquisition. The reconstructed volume is a derived exhibit whose chain runs back through those four hashed images to four labeled physical disks.

3. Document the physical configuration before pulling a drive. Serial-to-bay-to-exhibit mapping and photographs turn four identical disks into four distinguishable pieces of evidence, satisfying chain of custody and supporting the order determination.

4. Capacity to read is not authorization to read. The server held every department member's files, but the engagement covered one custodian and one matter. The examiner reconstructed the whole volume to access anything, then scoped the examination to the authorized custodian and documented what was excluded (Theme: ethics; Ch.28).

5. The XOR is identical; the rigor is the whole difference. Bit for bit, the parity math here is the same operation Brightline's recovery used in Case Study 1. What separates "I got the data" from "I can prove this is the data and it is unaltered" is the hashing, documentation, scoping, and reproducibility wrapped around the identical technical act.

Discussion questions

1. The examiner could have simply produced the recovered files. Explain why "here are the files I pulled off the array" is insufficient in litigation, and what specifically the reproducible-reconstruction approach adds.

2. The opposing expert independently rebuilt the same volume and got matching hashes. Why is that a strength of the examiner's method rather than a threat to the case?

3. ⭐ The array held the files of roughly sixty employees, but the authorization covered a single custodian. Describe precisely how you would scope your examination, what you would document about the exclusion, and how you would explain to the court that you could read everything but did not.

4. Write the two-to-three-sentence passage you would put in the report describing the reconstruction parameters and their derivation, pitched so a lay jury understands that combining the disks was a defined, repeatable method and not an act of interpretation.

5. Suppose the seized array had been RAID 10 built with Linux mdadm using the far layout rather than classic nested 1+0. What additional determination must you make before reconstructing, why would a "find the mirror pairs" assumption fail, and how would you document the layout so your result remains reproducible?