13. Reconstruction and recovery

18. Analysis

Filesystem reconstruction

In short: understand the filesystem as it is, damage included, and recover as much structure as the surviving metadata allows before any carving.

With a readable (or decrypted) volume in hand, metadata reconstruction comes before carving. 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 is the fallback, not the first move.

Work through the structures in order

1. 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 find volumes the table does not mention.
2. 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 is often recoverable from these copies; record the fact of the damage.
3. Directory structures. Walk the tree from the root, noting where it breaks. Entries that survive without a parent (orphans) are recovered by scanning metadata records directly rather than walking the tree.
4. 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 in use but claimed by no surviving file, and clusters claimed by a file but marked free, both point to damage or deletion; list both.
5. 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.
6. 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.
7. Slack space. The space between the end of a file's data and the end of its last cluster holds whatever was there before. Small, but it can contain fragments of earlier files and, on some systems, the remains of memory.
8. Unallocated space. Everything the filesystem no longer claims. This is where carving operates. Examine it last, informed by everything learned above about where deleted files used to be.

Choose the 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.

Record the reconstruction

Every reconstructed structure is a derived artefact. Record:

• The surviving copies used: their offset and content.
• The interpreter: the tool and version.
• Each decision you made, for instance choosing the backup GPT over a primary that was partially valid.

19. Analysis

Fragmented file recovery

In short: follow surviving cluster runs where you can; where you cannot, rebuild from the file's own structure and validate every join.

Files are fragmented when their data is stored in non-contiguous clusters. Normal use produces some fragmentation. Deliberate fragmentation, where a file is 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. JPEG photographs are the running example here: they are the most common subject and have the most usable internal structure.

When allocation metadata survives

1. Read the cluster runs from the file's metadata record, deleted or not. They are listed in order.
2. Extract the clusters in that order. The file is reconstructed directly, with its name and timestamps, however badly fragmented it is.
3. Check each run against the allocation bitmap and against other files' runs. If a cluster has since been reallocated to another file, that part is overwritten and the result is partial.
4. Record which clusters were intact and which were not.

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 find a file's header signature and copy 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. 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, by default, that a file's data is contiguous from header to footer. Against a deliberately fragmented image they produce one of three things:

• Truncated: the file ends at the first fragment boundary.
• Corrupt from the boundary: the file runs across it into unrelated data.
• Correct by luck: the file happens to run into the right next fragment, and is indistinguishable from the other two without validation.

Reconstruct a fragmented JPEG

JPEG reconstruction is possible because the format is highly structured and its decoding is deterministic. You work at hex level, with a decoder, using these 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 (image dimensions and component layout) and the start-of-scan marker, after which entropy-coded scan data runs until the end marker. Every marker is a fixed point you can identify in a fragment.
• Quantisation and Huffman tables. Scan data cannot be decoded without the tables from the header. Test a lone scan fragment 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. That property recognises a fragment of scan data, and a fragment that violates it is not JPEG scan data. If the encoder used restart intervals, restart markers appear at regular intervals with a cycling index: 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 wrong boundary shows as a horizontal band where the content shifts, changes colour or becomes noise, because the decoder loses its place in the block sequence. A correct join decodes without error and the 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 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. Camera make and model, timestamps, dimensions and often the software that last saved the file. EXIF dimensions 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, complete, independently decodable thumbnail of the same picture inside the EXIF segment. Comparing it with the reconstructed main image is a strong check on the assembly, 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), absence of decoder errors, restart marker sequence and any other sequence information the format carries, and agreement with the thumbnail and EXIF dimensions.

Assemble the toolkit

• 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 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.

Apply it to other formats

The same approach works with less internal structure to lean on:

Say what a reconstruction is and is not

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