File Carving: Recovering Files That No Longer Have a Name
I worked through a lab using Autopsy to perform file carving against a forensic image of an SSD running a Linux file system, recovering image files purely from their recognizable internal structure, with no file system metadata to rely on at all.
Every recovery technique I'd worked through earlier in this forensics series depended on the file system still knowing something about the file in question, a deleted entry that could be found, a hash that could be compared against a record. File carving solves a harder, more fundamental problem: recovering a file when the file system's own records about it are completely gone. No file name, no metadata, no directory entry pointing to it, nothing but raw, unallocated space on the disk and whatever bytes happen to still be sitting there.
I worked through a lab using Autopsy to perform file carving against a forensic image of an SSD running a Linux file system, recovering image files purely from their recognizable internal structure, with no file system metadata to rely on at all.
Why File Carving Is a Fundamentally Different Technique
Earlier labs in this series dealt with files that the file system still had some record of, even a deleted file typically still has a metadata trace pointing to where its data used to live, which is exactly what standard recovery tools search for. File carving exists for the case where even that's gone: metadata has been wiped, overwritten, or was never reliable to begin with, and all that's left is a block of unallocated space with no index describing what it used to contain.
The technique works by scanning raw disk space directly for recognizable file signatures, specific byte patterns that mark the beginning and end of known file types, a JPEG has a distinctive header structure, for instance, regardless of what file name or folder it once belonged to. Carving tools look for those recognizable patterns directly in the raw bytes and reconstruct files based purely on their internal structure, with zero reliance on the file system's own bookkeeping.
The lab's framing specifically noted this matters even more on SSDs, where a feature called TRIM, when enabled, proactively erases blocks the file system has marked as deleted, specifically to maintain the drive's performance over time. When TRIM is active, deleted data can be gone almost immediately, which is precisely why this lab's premise depended on TRIM being disabled: carving assumes the underlying bytes are still physically present on the disk, even though every higher-level record of them is gone. If TRIM had already erased that space, there'd be nothing left to carve.
Setting Up the Case
The setup mirrored the documented-case discipline from an earlier Autopsy lab: a new case (named specifically for this task), a dedicated base directory for case data, and examiner details and a case number recorded in the optional fields, the same chain-of-custody documentation that matters for any real forensic analysis.
I added the evidence as a Disk Image or VM File data source, this time a raw
.dd image ( Linux_Evidence_SSD.dd ) rather than the .img format used previously, a different but equally standard raw disk image format. After configuring the ingest modules and letting Autopsy begin its analysis, the lab noted something worth taking seriously: Autopsy consumes substantial system resources while scanning an image for carved content, and the lab specifically recommended not interacting with the machine until scanning completed. That's a genuinely practical operational detail, carving isn't a quick metadata lookup, it's an exhaustive scan of every block of unallocated space on the disk, and that kind of exhaustive search is inherently resource- and time-intensive.Waiting for Carved Files to Actually Appear
After selecting the evidence file in the left pane, I had to wait, specifically 10 to 15 minutes in this case, for a Carved Files folder to populate in the right pane. That wait is the scan itself happening: Autopsy working through unallocated space, byte by byte, looking for file signatures it recognizes, and only surfacing a given carved file once it's identified a complete, recognizable structure.
Once populated, the Carved Files folder contained a set of recovered image files, reconstructed purely from their internal byte patterns, with generic, auto-generated names (things like
f0203056.jpg ) rather than whatever name the file might have originally had. That naming detail is itself informative: carving has no access to the original file name at all, since that information lived in file system metadata that's gone. All carving can recover is the file's content and structure, never its original identity within the file system.Inspecting and Extracting a Carved File
Selecting one of the recovered image files displayed its actual visual content directly in Autopsy's Application tab, confirming the carved data really did reconstruct into a viewable, legitimate image rather than a corrupted fragment. The same multiple-view pattern from the full disk image lab applied here too, Hex, Text, File Metadata, and other tabs available for deeper inspection of the same recovered file from different angles.
To actually recover the file as a usable artifact outside of Autopsy's case environment, I right-clicked it and selected Extract File(s), saving it into the case's
Export subfolder, a location automatically organized under the case's own base directory rather than some arbitrary location on the analysis machine. After extraction, I navigated directly to that export folder and confirmed the recovered image file was genuinely present and usable as a standalone file.What File Carving Actually Demonstrates
A few things stood out about why this technique matters, and why it's meaningfully different from every other recovery method covered earlier in the same series.
Metadata and content are two separate things, and losing one doesn't necessarily mean losing the other. A file's name, its folder location, its timestamps, all of that lives in file system metadata, separate from the actual byte content of the file itself. File carving is proof that losing all of the former doesn't mean the latter is gone too, as long as the raw bytes are still physically present somewhere on the disk.
TRIM is specifically relevant to SSDs in a way it isn't for traditional spinning disks. Understanding that a modern SSD can proactively and permanently erase deleted data far faster than older storage media, specifically because of a performance-oriented feature like TRIM, is a real, practical piece of knowledge that shapes what's even possible to recover depending on the storage medium and its configuration.
Carving recovers content, not identity. A carved file like
f0203056.jpg has real, viewable image content, but no original name, no original folder path, no creation timestamp tying it to when it actually existed in the live file system. That's a meaningfully incomplete recovery compared to a deleted file recovered through standard means, which often does retain at least some of that original metadata. Carving is a last resort precisely because of what it can't bring back alongside the content itself.This is computationally different from every other technique in the series, and that has real operational consequences. Hashing a file, comparing two hashes, or even browsing a fully intact file system are all comparatively lightweight operations. Scanning every block of unallocated space on an entire disk image for recognizable byte patterns is a fundamentally heavier task, which is exactly why the lab flagged resource usage and wait times as something to actually plan around, not just a minor inconvenience.
File carving is the forensic technique for the situation where everything else has already failed, no file system record, no metadata, nothing pointing to where a file used to be. What's left is raw unallocated space and the possibility that the actual bytes are still physically sitting there, recoverable only by recognizing a file's own internal structure directly, with zero help from the file system's own bookkeeping.
That's a genuinely different kind of recovery than anything else covered in this series. Hashing and comparison assume a trusted record to check against. Standard deleted-file recovery assumes at least some surviving metadata pointing to the data. Carving assumes nothing except that, somewhere in a sea of unallocated bytes, a recognizable file structure might still be sitting there, waiting to be found purely by what it looks like on the inside, not by anything it was ever called.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article