13. Reconstruction and recovery

18. Analysis

Filesystem reconstruction

With a readable (or decrypted) volume in hand, the next task is to understand the filesystem as it is, damage included, and to recover as much of its structure as the surviving metadata allows. Metadata reconstruction comes before carving because the filesystem's own records are the only source of file names, paths, timestamps, ownership and, above all, the allocation information that says which clusters belong to which file and in what order. Carving throws all of that away; it should be the fallback, not the first move.

What to examine, in order

• Partition tables. Parse the MBR or GPT and compare it with what is actually on the disk. A GPT keeps a backup header and table at the end of the disk; a damaged primary can be reconstructed from it. Where the table is missing or describes a layout the disk no longer has, search for filesystem boot sectors and superblocks at their expected alignments to locate volumes the table does not mention. Every volume found this way is reported as an observed fact (a valid boot sector at a stated offset) with the interpretation kept separate.
• Filesystem metadata. The boot sector or superblock, and the master structures it points to: the master file table on NTFS, inode tables and group descriptors on ext4, the object map and container superblock on APFS. NTFS keeps a mirror of the first MFT records; ext4 keeps backup superblocks in several block groups. Damage to a primary structure is often recoverable from these copies, and the fact of the damage is recorded.
• Directory structures. Walk the directory tree from the root, noting where it breaks. Directory entries that survive without a parent (orphans) are recovered by scanning metadata records directly rather than walking the tree.
• Allocation information. The bitmap or allocation table says which clusters are in use. Compare it with the sum of the allocations claimed by file records: clusters marked in use but claimed by no surviving file, and clusters claimed by a file but marked free, both point to damage or deletion and both are worth listing.
• Journals. The NTFS log file and change journal, the ext4 journal and the APFS object history record recent metadata operations, including creations, renames and deletions of files whose entries no longer exist. A journal can show that a file existed, its name, its size and when it was deleted, when nothing else does.
• Deleted entries. A deleted file's metadata record commonly survives, marked unused, until it is reused. It still holds the name, timestamps and the list of clusters the data occupied. If those clusters have not been reallocated, the file is recoverable in full and in order, with its metadata, which is a far stronger result than a carve.
• Slack space. The space between the end of a file's data and the end of its last cluster holds whatever was there before. It is small but can contain fragments of earlier files and, on some systems, the remains of memory.
• Unallocated space. Everything the filesystem no longer claims. This is where carving operates, and it is examined last, informed by everything learned above about where deleted files used to be.

Tools

• The Sleuth Kit and Autopsy (open source) parse partition tables and filesystems, list allocated, deleted and orphaned entries, extract files by metadata address, report cluster runs, and extract unallocated space for carving. Their command-line tools are well suited to producing the exact, reproducible offsets a report needs.
• X-Ways Forensics is strong on damaged filesystems, with the ability to locate and interpret lost metadata records, and on hex-level work.
• EnCase and FTK are established commercial platforms with validated filesystem support and case management.
• Equivalent validated tools are acceptable. For a damaged filesystem, use more than one: parsers differ in how they handle corruption, and a structure one tool rejects another may interpret. Disagreement between tools is itself a finding to record.

Recording the reconstruction

Every reconstructed structure is a derived artefact. Record the offset and content of the surviving copies used, the tool and version that interpreted them, and each decision you made (for instance, choosing the backup GPT over a primary that was partially valid). Keep the damaged originals in the image untouched, and never write your reconstruction back into the working copy; keep it as a separate description or a separate derived image with its own hash.

Example. A decrypted data volume has an NTFS boot sector whose MFT pointer refers to clusters that contain zeros. The MFT mirror is intact and locates the real MFT, which is largely present. Parsing it recovers 41,000 active records and 3,200 deleted records; the change journal shows a bulk deletion of a folder of image files on a stated date, and a wiping utility's own log on the system volume records a run at the same time. The report gives the offsets, the record numbers and the journal entries as observed facts; the wiping run as recovered evidence; and "the folder was deliberately deleted using the wiping tool at that time" as a conclusion, strongly supported, with the supporting artefacts listed.

19. Analysis

Fragmented file recovery

Files are fragmented when their data is stored in non-contiguous clusters. Normal use produces some fragmentation; deliberate fragmentation, where a file has been split and its pieces scattered or interleaved with other data to defeat recovery, is an anti-forensic technique that turns up in cases involving images in particular. This section deals with recovering such files, with photographs and other JPEG images as the running example because they are the most common subject and have the most usable internal structure.

When allocation metadata survives

If the file's metadata record survives, deleted or not, it lists the cluster runs in order. Extract the clusters in that order and the file is reconstructed directly, with its name and timestamps, regardless of how badly fragmented it is. Check each run against the allocation bitmap and against other files' runs: if a cluster has since been reallocated to another file, that part of the recovered file is overwritten and the result is partial. Record which clusters were intact and which were not. A file recovered this way from an intact record is recovered evidence; one recovered from a deleted record whose clusters were all still free is also recovered evidence, with the note that it was deleted. Only when clusters have been reused does reconstruction begin.

When allocation metadata is gone

Without a metadata record, the only sources of information are the file's own content and the content around it. Conventional carvers work by finding a file's header signature and copying a contiguous block from it to a footer signature or a maximum size:

• PhotoRec recognises a large number of formats, is aware of some internal structure, and can be run against a raw image, a partition or an unallocated-space extract.
• Scalpel and Foremost carve on header and footer signatures defined in a configuration file, quickly and reproducibly.
• bulk_extractor scans an image for features (email addresses, URLs, EXIF data, embedded JPEGs including thumbnails) without regard to filesystem structure, and its carved JPEGs and EXIF records are a useful independent source.
• X-Ways and the commercial suites carve by signature and, for some formats, by structure.

All of these assume, in their default operation, that a file's data is contiguous from header to footer. Against a deliberately fragmented image they produce one of three things: a file that ends at the first fragment boundary (truncated), a file that runs across the boundary into unrelated data (corrupt from that point), or a file that happens to run into the correct next fragment (correct by luck, and indistinguishable from the other two without validation). A carver's output opening in an image viewer proves only that the viewer is tolerant.

Reconstructing a fragmented JPEG

JPEG reconstruction is possible because the format is highly structured and its decoding is deterministic. The examiner works at hex level, with a decoder, using the following sources of evidence:

• Filesystem allocation evidence. Even without the file's own record, the allocation bitmap, the runs of neighbouring files and the journal narrow the candidate clusters: a fragment cannot be in a cluster that another file has occupied continuously since before the image was written.
• File signatures and markers. A JPEG begins with a start-of-image marker and ends with an end-of-image marker. Between them are marker segments, each with a two-byte code and a length: application segments (EXIF lives in one), quantisation tables, Huffman tables, the frame header (which gives the image dimensions and component layout) and the start-of-scan marker, after which the entropy-coded scan data runs until the end marker. Every marker is a fixed point that can be identified in a fragment.
• Quantisation and Huffman tables. The scan data cannot be decoded without the tables from the header. A scan fragment found on its own can be tested against a candidate header by decoding: with the right tables it decodes cleanly, with the wrong ones it fails or produces noise. This is the principal method for matching headers to scans.
• Scan data structure. Within the scan, any byte of value 0xFF is followed by 0x00 (byte stuffing) or by a marker. A fragment of scan data can be recognised by that property, and a fragment that violates it is not JPEG scan data. If the encoder used restart intervals, restart markers appear at regular intervals in the scan with a cycling index, which gives both an ordering constraint (the indices must cycle in sequence) and a way to decode from the middle of a scan.
• Structural decoding. Decode the candidate assembly and examine the result. A fragment boundary in the wrong place shows as a horizontal band where the image content shifts, changes colour or becomes noise, because the decoder loses its place in the block sequence. A correct join decodes without error through the boundary and the image content is continuous. The number of blocks decoded before failure locates the boundary to within a few blocks, which converts to a byte range in the scan and hence to a cluster.
• Neighbouring sectors and clusters. The next fragment of a file is very often nearby: immediately after a gap occupied by another file, or the next free cluster at the time of writing. Bifragment gap carving tests candidate second fragments at increasing gaps from the first, validating each by decoding. For more than two fragments the search grows, and the allocation evidence above is what keeps it tractable.
• EXIF metadata. The EXIF segment carries the camera make and model, timestamps, dimensions and often the software that last saved the file. Dimensions in EXIF should match the frame header. Timestamps and camera identity link the file to other images on the system and to the filesystem timeline.
• Embedded thumbnails. Most camera JPEGs carry a small thumbnail inside the EXIF segment. It is a complete, independently decodable image of the same picture. Decoding it and comparing it with the reconstructed main image is a strong check on whether the assembly is correct, and the thumbnail is often recoverable when the main image is not.
• Candidate fragment comparison. Where several fragments could plausibly follow a given one, decode each candidate assembly and compare: image continuity across the join (content similarity of the rows either side of it), absence of decoder errors, restart marker sequence and any other sequence information the format carries, and agreement with the thumbnail and EXIF dimensions. Record every candidate considered and why each was accepted or rejected.

Tools

• The carvers above (PhotoRec, Scalpel, Foremost, bulk_extractor) to locate headers, scan fragments, EXIF segments and thumbnails, and to produce the contiguous candidates that are the starting point.
• X-Ways or an equivalent for hex-level examination with filesystem awareness, so that a byte offset in the image can be translated to a cluster and back.
• A hex editor with template support for inspecting JPEG marker structure by hand.
• A JPEG decoder that reports errors and their positions rather than silently tolerating them, and a scriptable image library for decoding candidate assemblies in bulk.
• Specialist fragmented-file carving tools, where available, that implement bifragment gap carving or structure-aware reassembly. Their output is subject to the same validation as any manual reconstruction; they do not remove the need for it.

Other formats

The same approach applies, with less internal structure to work with, to other formats. PNG is a sequence of length-prefixed chunks each with a CRC, which gives strong validation at chunk boundaries. Compressed archives and office documents are containers with directories and checksums. Video is a sequence of independently identifiable packets. Plain text and raw data have almost no internal structure and can only be reassembled on filesystem evidence and content plausibility, with correspondingly lower confidence.

What a reconstruction is and is not

A reconstructed file is a derived artefact assembled by the examiner from selected fragments in an order the examiner chose. It is not the original file, even if it is byte-identical to what the original file was, because that identity cannot be observed; it can only be inferred from validation (section 20). A reconstructed file that opens, renders and looks right is a hypothesis that has survived one weak test. The report says how it was made, from which clusters, and how confident the examiner is, and it never describes the file as simply "recovered".

Example. Unallocated space contains a JPEG header with EXIF and a thumbnail at cluster 118,204, but the scan data terminates at the cluster boundary 12 clusters later without an end marker. Decoding the truncated scan produces the top third of an image consistent with the thumbnail. The allocation bitmap shows the next 40 clusters occupied by an intact document written before the image's EXIF timestamp, so the second fragment cannot be there. Candidate scan fragments (identified by byte-stuffing structure and by restart marker sequence continuing from index 3) are found at three locations within the following 2,000 clusters. Only the candidate at cluster 118,301 decodes without error through the join and continues the image content; it runs to an end marker 9 clusters later. The reconstruction, the two cluster ranges, the rejected candidates and the decoded comparison with the thumbnail are all recorded.