Prove Your Boot Media Did Not Alter the Evidence

This document exists so an examiner can answer, on the stand, a two-part question: how do you know this tool did not alter the evidence and how do you know exactly what it was? It is deliberately modeled on the NIST Computer Forensics Tool Testing (CFTT) approach, a documented repeatable before/after test that measures whether the tool changes the source, with every deviation disclosed in advance.

WinFE-style boot media has a bad reputation in court for two specific reasons:

No integrity story on distribution

Tools are pulled from a web page with no published hash or code signature, so you cannot prove what you ran.

A fully customizable one-off build

Every examiner's WinFE is different, so there is no fixed testable artifact and no way to reproduce what happened.

The Sherlock Forensics Forensic Boot Media is WinFE-lineage but is engineered to close both holes. The sections below state exactly how and where the residual limitations are. The credibility here comes from transparency, not from a claim of perfection.

The mechanism is specific and independently verified after each build:

• SAN policy 3 (offline all) and NoAutoMount = 1 are written into every control set of the offline SYSTEM hive before first boot, so every disk is offline and unmounted when WinPE starts.
• The wizard sets every disk read-only at the disk level the moment it starts and brings only the chosen destination writable.
• Post-build verification independently re-reads the policy and confirms SanPolicy = 3 and NoAutoMount = 1 in the control set the boot loader selects.

Removable media caveat. SD cards in built-in readers and flash drives cannot be taken offline by SAN policy. They are protected only by no-automount, the read-only attribute where the stack supports it and examiner discipline. Treat removable media accordingly.

You must be able to name and verify the exact tool. The boot media closes the WinFE distribution-integrity gap with three anchors.

The WinFE one-off-build objection is answered by making the build reconstructable from named hashed inputs.

Base image, reproducible-first

The provisioner selects the WinPE base in this order: an examiner-supplied Windows ISO, then a fixed ADK WinPE package, then the host's harvested WinRE. The first two are reproducible bases, known artifacts you are licensed for and can hash, so they are preferred. The build manifest records which base was used, its SHA-256 and a reproducible flag.

Deterministic provisioning

The wipe, partition, inject, registry and BCD steps are generated by pinned code, not hand-typed, so the recipe is fixed and testable.

Harvested WinRE is the fallback

When no known base is available (offline, no ADK, no ISO), the host's own WinRE is harvested. This is convenient but not reproducible: it is machine-specific and patch-specific, so the manifest marks it reproducible false.

Run this against a test disk, never live evidence, before relying on the media and whenever the base image, drivers or imager version change. It measures whether booting the media alters an attached disk.

1. Prepare a test disk with a known non-blank partition table so the disclosed blank-MBR signature write does not apply. Populate it with representative data.
2. Baseline hash. On a trusted workstation with a hardware write blocker, compute the full-disk SHA-256 of the test disk. Record it.
3. Boot the media on the test machine with the test disk attached as the internal target disk. Confirm the machine was fully powered off first, not sleep or fast-startup.
4. Run the wizard's read-only pass up to and including source selection and the pre-scan, but do not acquire. The goal is to measure incidental writes from simply booting and enumerating.
5. Power off from the wizard's safe-to-power-off state. Never reboot.
6. Re-hash the test disk on the same trusted write-blocked workstation.
7. Compare. The before and after SHA-256 must be identical. Any difference is a failure unless it is exactly the disclosed blank-MBR signature write, which this protocol avoids by using a non-blank disk.
8. Repeat with a destination disk attached to confirm only the intended destination is brought writable.
9. Record the result in the table below and retain the build manifest.

Optionally, repeat the test over the platforms you deploy on (Intel VMD, AMD RAID, common firmware) to confirm the target disk is visible and the write block holds.

The build manifest lets you state, precisely: which imager (name, SHA-256, signer), which base image (source, SHA-256, reproducible flag), which drivers were injected, which Secure Boot CA the boot files use and that the write-block policy and injected-executable imports passed post-build verification. Pair it with your validation result below and the acquisition's own hash log.

Record one row per validated build on the bench. Attach the build manifest for each.

Prefer hardware write blocking

This is software write-blocking on the evidence machine's own hardware. When the drive can be removed and imaged behind a hardware write blocker on a lab machine, do that. Reach for this media when the drive cannot be pulled or hardware-blocked, which is most internal NVMe.

Not yet NIST CFTT validated

The imager is not yet on the NIST CFTT validated-tools list. This methodology does not substitute for third-party validation where your jurisdiction expects it.

x64 only

x64 targets only. ARM64 machines (Snapdragon, Copilot+) are refused at build time.

Encrypted volumes are captured as ciphertext

TPM-protected BitLocker and self-encrypting drives are captured as ciphertext.

Removable media

SD cards in built-in readers and flash drives cannot be taken offline by SAN policy. They are protected only by no-automount, the read-only attribute where the stack supports it and examiner discipline.