20. Analysis, documentation
Validation of reconstructed files
A reconstruction is worth only as much as its validation. This section applies to every derived artefact: a carved file, a manually reassembled file, a file extracted from a deleted record whose clusters were partly reused, a decrypted volume produced with a reconstructed header, and a timeline built from several sources.
Required documentation for every reconstruction
- Every source location used: each sector, cluster or byte range in the working image, with the image identified by its hash. For a fragment, both its start and its end. For a metadata-based recovery, the metadata record's address and the cluster runs it listed.
- The order in which fragments were assembled, the method used to decide it (metadata, sequence markers, content), and, where the order was not given by metadata, why that order was chosen over the alternatives.
- The reconstruction method: metadata extraction, contiguous carving, gap carving, manual assembly, header repair, decryption, and the parameters used.
- Tool names and versions for every step, including the decoder used to test candidates.
- Manual decisions: every point where the examiner chose between candidates or corrected something by hand, with the reason. A reconstruction with no manual decisions is reproducible by the tool alone; one with manual decisions is reproducible only if they are written down.
- Assumptions: for instance that restart markers were used, that the file was written in one operation, that the EXIF dimensions are correct.
- Confidence level on the scale in section 23, with the reasons.
- The SHA-256 hash of the resulting file, and the hashes of each fragment as extracted before assembly.
Structural validation of every recovered or reconstructed artefact
Before corroboration, test the artefact against its own format. For every significant recovered or reconstructed file:
- Calculate and record its hash, and the hash of each fragment or source range.
- Parse its internal structure with a tool that reports errors and their positions, not one that tolerates them: every marker, chunk, record or packet the format defines should be present, in order, with valid lengths and checksums where the format has them.
- Compare the header and footer with the format specification, and check that nothing follows the footer that the format does not explain.
- Validate embedded metadata against the content: EXIF or document properties against the decoded dimensions, page count, duration or codec; internal timestamps against each other.
- Confirm the expected dimensions, codecs, formats or record structures decode completely: the number of image rows, audio samples or database records the header promises is the number the content delivers.
- Where proportionate, produce the same artefact with a second tool or method and compare the hashes (below).
- Identify and record any missing or uncertain regions: unread sectors from the imaging map, clusters that had been reused, joins chosen on content rather than metadata. A file with such regions is reported with them marked, never as complete.
Corroborate with independent evidence
The purpose of corroboration is to find evidence, independent of the reconstruction itself, that the assembled file is what the examiner says it is. Sources include:
- Filesystem metadata: a surviving or journalled record with a matching size, name or timestamps.
- EXIF information: dimensions, camera and timestamps consistent with the decoded image and with other images on the system.
- Embedded thumbnails: a decoded thumbnail that matches the reconstructed image.
- Timestamps from the filesystem, the journal, EXIF, and any application that handled the file, forming a coherent sequence.
- Backups, shadow copies and synchronised copies of the same file, on the same system or elsewhere, which may provide the original for direct comparison.
- Duplicate files: the same image elsewhere on the system, in a cache, in a mail attachment or on another seized device.
- Known hashes: a match against a hash set, whether an organisation's own file inventory or a reference database, is the strongest corroboration available, because it shows the reconstructed byte sequence existed independently of the examiner.
- Adjacent allocation information: the reconstruction is consistent with which clusters were free at the time the file was written.
- Other artefacts: a link file, a viewer's recent-files list, a browser cache entry or a log referring to the file by name, size or path.
Use a second independent method
Where practical, reconstruct the file a second time by a different route: a different tool, a different carving approach, or a second examiner working from the documented cluster list without sight of the first result. Two independently derived reconstructions that produce the same byte sequence, and therefore the same hash, are far stronger evidence than a single reconstruction that renders correctly, because the agreement is unlikely to arise from a shared mistake. Two reconstructions that differ are a finding too: locate the difference, and report it.
Rendering is not validation
Image viewers, document readers and media players are designed to tolerate damage and to show something rather than nothing. A file that opens may be truncated, may contain data from another file after a fragment boundary, or may have been silently repaired by the viewer. A file that does not open may be almost entirely correct. Rendering is a quick screening test, useful for rejecting candidates, and nothing more. Validation is structural decoding, corroboration and independent reproduction.
Retain the fragments
Keep every fragment used in a reconstruction as a separate extracted file with its own hash and its source location, alongside the assembled result. Keep the candidates that were rejected, with the reason. Another examiner must be able to take the fragments and the documented order and produce the same hash, and must be able to see what else was considered.
Example. A reconstructed JPEG has hash H1. A second examiner, given only the working image, the two cluster ranges and the assembly order, produces a file with hash H1. The embedded thumbnail decodes to a visually matching image. The EXIF timestamp falls between two journal entries for the folder the image is believed to have lived in. A synchronised copy of the same image is found in a cloud export with hash H1. The report grades the reconstruction confirmed: an independently existing byte sequence matches it. Had the cloud copy not existed, the same evidence would support strongly supported, and the report would say what further evidence would raise it.