Disk and File System Forensics

Disk and file system forensics is the analytical phase that the acquisition phase exists to support. Once a bit-for-bit image has been produced and verified, the work that follows happens against the image: parsing partition tables, walking file system structures, recovering deleted content, extracting timestamps and ownership metadata, reconstructing what a user or process did on the system over time. The discipline is the oldest branch of digital forensics, the largest in operational volume, and the most artifact-dense by some margin. A modern Windows or macOS system carries hundreds of distinct artifact types that establish what happened on the machine; the file system structures that index them are themselves several layers of artifact in their own right.

This page covers the substrate: the disk layout that sits below the file system, the major file system families (NTFS, ext, APFS, FAT/exFAT) and what each preserves, the mechanics of file carving and slack-space recovery, the timestamp model that holds the whole reconstruction together, and the operating-system-specific artifact catalogs that the file system underlies. Several adjacent topics have their own subpages: Forensic Acquisition and Imaging covers how the image got produced, Timeline Analysis covers the cross-artifact reconstruction that the file-system timestamps feed into, Anti-Forensics covers the adversary techniques that complicate disk analysis, and Memory Forensics covers the volatile-data analysis that disk forensics is increasingly paired with.

The implicit assumption throughout this page is that the image has already been acquired with proper integrity controls, that the chain of custody is intact, and that the methodology supports the legal framework the case will live or die under. Those topics live in Evidence Handling and Chain of Custody.

The disk layout below the file system

Before the file system is visible, the disk has structure of its own. The forensic examiner has to understand both layers because the lower layer often holds evidence that the upper layer does not.

Partition tables describe how the disk is divided into addressable regions. The two formats in active use are MBR (Master Boot Record), dating to the early 1980s and limited to 2 TB disks and four primary partitions, and GPT (GUID Partition Table), the successor format that ships with UEFI systems and supports larger disks and more partitions. Modern systems with disks over 2 TB use GPT exclusively; smaller disks may still use MBR, particularly on legacy Windows installations and on removable media.

The forensic interest in partition tables is twofold. First, deleted partitions often leave their entries in the table for some time, and tools like mmls (from The Sleuth Kit) or commercial equivalents can recover the layout of partitions that have been removed and reused. Second, the unpartitioned space between partitions, before the first partition, and after the last partition can contain forensically interesting data: boot loaders, recovery images, hidden partitions used by manufacturers, and occasionally data deliberately hidden by users or adversaries.

Boot sectors sit at the start of bootable partitions and contain the boot code plus file system metadata. The Volume Boot Record (VBR) on NTFS partitions, the superblock on ext partitions, and the corresponding structures on FAT and APFS partitions describe the file system’s basic parameters (cluster size, total clusters, root directory location, and so on). Forensic tools parse these structures automatically; the examiner rarely has to read them by hand.

Host Protected Areas (HPA) and Device Configuration Overlays (DCO) are areas of the disk that the operating system normally cannot see, originally intended for vendor-shipped recovery images. Adversaries occasionally use them to hide data. Forensic acquisition tools can be configured to capture HPA and DCO areas; the methodology has to record whether they were captured and whether anything was found.

SSDs and TRIM. Solid-state drives present a special case. The TRIM command lets the file system tell the SSD that a block is no longer in use, allowing the SSD’s garbage collector to erase it ahead of the next write. This is a performance win for the user; it is a forensic problem. Deleted data on a TRIM-enabled SSD is typically gone within seconds to minutes of deletion, rather than persisting indefinitely as it would on a traditional hard drive. The implication for disk forensics is that the deleted-content recovery techniques that work on spinning media are substantially less reliable on SSDs. The mitigation, where possible, is to acquire the SSD as quickly as possible after the suspected deletion and to be honest in the report about what TRIM has likely destroyed.

NTFS: the dominant Windows file system

NTFS is the file system on every Windows installation from XP onward and is the single most analyzed file system in forensic practice. The structure rewards detailed understanding because the artifacts it preserves are among the richest in the file system family.

The Master File Table (MFT) is the central index. Every file, every directory, every system structure on the volume has an entry in the MFT, a fixed-size record (1024 bytes by default) that describes the file’s attributes and either contains the file’s data directly (for very small files) or points to where the data lives on disk. The MFT is itself a file (MFT file record number 0), and the first 16 entries are reserved for system metadata files: $MFT itself, $MFTMirr (a backup of the first few MFT entries), $LogFile (the transaction journal), $Volume, $AttrDef, the root directory (.), $Bitmap (which clusters are in use), $Boot, $BadClus, $Secure, $UpCase, and $Extend (which contains additional metadata files).

Each MFT record contains a sequence of attributes. The forensically critical attributes are $STANDARD_INFORMATION (which holds the timestamps the user sees and that most tools display), $FILE_NAME (which holds an additional set of timestamps that get updated under different rules), $DATA (which holds the file’s content or pointers to it), $INDEX_ROOT and $INDEX_ALLOCATION (for directories), and $ATTRIBUTE_LIST (when a file’s attributes don’t fit in a single MFT record). The dual timestamp sets in $STANDARD_INFORMATION and $FILE_NAME are the basis for one of the most useful anti-anti-forensics techniques on NTFS: timestomping typically modifies only the $STANDARD_INFORMATION timestamps, leaving the $FILE_NAME timestamps intact, and a discrepancy between the two indicates that the timestamps have been manipulated.

Resident versus non-resident data. Files whose content fits inside the MFT record (typically under about 700 bytes after the metadata overhead) are stored resident, meaning the data lives inside the MFT record itself. Larger files are non-resident and the MFT record stores pointers (called “run lists” or “data runs”) to the disk regions that hold the data. The forensic implication is that small files (most LNK files, many configuration files, small registry values, much of the data forensic examiners care about) live inside the MFT and are recovered as a side effect of acquiring the MFT, even if the file has been deleted.

The $LogFile is NTFS’s transaction journal, used to recover from crashes. The journal records pending transactions before they are applied, which means it captures a rolling window of recent file system operations. Forensic tools (LogFileParser, NTFSLogTracker, the LogFile2csv tool) extract these transaction records and convert them into timeline events. The window depends on the file system’s activity. On a quiet system the $LogFile may cover days; on a busy system it may cover hours.

The $UsnJrnl (Update Sequence Number journal) is a separate, larger journal that records changes to files and directories. Unlike $LogFile, it is intended for application use (search indexers, backup software, antivirus) rather than for crash recovery. The $UsnJrnl typically preserves a much longer history (weeks to months on a typical system) and is one of the most useful artifacts for reconstructing file activity over time. The standard tools are MFTECmd for the MFT and UsnJrnl2Csv for the USN journal (both from Eric Zimmerman’s toolset), which parse these structures into formats that timeline analysis tools can consume.

Alternate Data Streams (ADS) allow multiple data streams to be attached to a single file. The mechanism exists to support legacy Macintosh file attributes; the operational use is to hide data. ADS content is invisible to standard directory listings. dir on the command line doesn’t show them by default, and Explorer doesn’t show them at all. Forensic tools list ADS as part of standard file enumeration, and any file with non-default ADS content is worth investigating. The “Zone.Identifier” ADS, attached by Internet Explorer and other browsers to indicate that a file was downloaded from the internet, is one of the more useful default ADSs because it carries the source URL of the download.

The Volume Shadow Copy Service (VSS) creates point-in-time snapshots of the volume that allow recovery of earlier states. Multiple shadow copies typically exist on a Windows system; each one is essentially a previous version of the entire file system that can be mounted and examined separately. Shadow copies are the single most useful Windows-specific forensic artifact for reconstructing past file content, and ignoring them is a methodology gap that occasionally undermines findings (“the file did not exist at the time” is a different claim from “the file did not exist at the time as far as we examined”).

The ext family on Linux and embedded systems

The ext family (ext2, ext3, ext4) is the dominant Linux file system and shows up on the majority of Linux servers, many embedded systems (including most Android internal storage until recently), and a non-trivial fraction of IoT devices. The internals differ from NTFS in ways that change the forensic methodology.

The superblock is the equivalent of the boot sector — it describes the file system parameters and is replicated across the volume for resilience. Ext maintains multiple superblock backups at predictable offsets, which means a corrupted or deliberately damaged primary superblock can usually be recovered.

Inodes are the per-file metadata structures. Each inode is a fixed-size record (typically 256 bytes on ext4) that holds the file’s attributes, timestamps, ownership (uid, gid, permission bits), and pointers to the file’s data blocks. Unlike NTFS, the inode does not hold the file name — names live in directory entries that reference inodes by number. The implication for deleted-file recovery is that ext4 zeros out the inode block pointers when a file is deleted, which makes recovery harder than on NTFS (where the MFT record’s data runs survive deletion intact until the record is reused).

The journal (jbd2) is ext3 and ext4’s transaction log. Like NTFS’s $LogFile, the journal captures pending file system operations before they are applied. The standard journal mode (ordered) records only metadata changes; the optional journal mode records data as well, at a substantial performance cost. Forensic recovery from the journal is possible but less developed than the equivalent NTFS techniques — the tooling ecosystem around ext journal recovery is thinner.

Extents versus indirect blocks. ext4 introduced extents — contiguous ranges of disk blocks represented as (start, length) pairs — replacing the indirect-block scheme of ext2 and ext3. Extents are more efficient for large files but require different parsing logic. The Sleuth Kit handles both; the open-source ext4fuse and debugfs tools also work, but with thinner forensic instrumentation.

Timestamps on ext4 include atime (access), mtime (modification), ctime (inode change), and crtime (creation, added in ext4). The granularity is nanoseconds. The crtime is the equivalent of the Windows creation time and is critical for timeline analysis; older ext versions lack it, and the forensic methodology has to acknowledge what’s missing.

Deleted file recovery on ext is more limited than on NTFS. The ext3/4 journal sometimes preserves enough metadata to reconstruct recently-deleted files, but the standard tools (extundelete, ext4magic) are best-effort. File carving (covered below) is usually the more reliable recovery approach on ext.

ext on Android. Until Android 12, the internal storage on most Android devices was ext4 (sometimes wrapped in dm-crypt or fscrypt encryption). Newer Android versions use F2FS (Flash-Friendly File System) on the data partition, which is structurally different and has its own forensic tooling story (less mature than ext4).

APFS on modern macOS

APFS (Apple File System) replaced HFS+ on macOS in 2017 and is now the file system on every modern Mac. The design is structurally different from NTFS and ext in ways that change both what’s preserved and how it’s recovered.

The container/volume model. APFS introduces a layer above traditional volumes — a “container” that can hold multiple volumes sharing the same underlying storage pool. The container has its own metadata structures; the volumes within it are independent file systems. Forensic acquisition has to handle the container layer separately from the per-volume file systems.

Copy-on-write semantics. APFS does not overwrite blocks in place. When a file is modified, the new content is written to fresh blocks and the metadata is updated to point to the new location, leaving the original blocks intact until the garbage collector reclaims them. The forensic implication is that recently-modified files may have multiple historical versions accessible on disk, even after the file system would normally have considered them obsolete.

Snapshots. APFS supports volume-level snapshots — a frozen view of the file system at a point in time. Time Machine uses these for backups; macOS itself uses them for system updates. Snapshots are first-class file system citizens and can be mounted and examined like any other volume. The forensic toolset for APFS snapshots is still maturing; fsapfsinfo (libfsapfs) and apfs-fuse are the open-source standards, but the commercial tools (X-Ways, EnCase, Magnet AXIOM) have more complete APFS support.

Encryption. APFS supports per-volume encryption that is on by default for FileVault-enabled systems and for the data volume on Apple Silicon Macs (even when FileVault is “off” in the user-facing sense — the data is still encrypted with a key that the Secure Enclave holds). Dead acquisition of an APFS volume produces encrypted ciphertext unless the key can be recovered. The Memory Forensics subpage covers in-memory key recovery; for cold-acquired APFS images, the methodology often depends on user cooperation or legal process to obtain the key.

The Object Map. APFS maintains a per-volume object map that tracks all the file system objects (inodes, extents, snapshots) and their relationships. Forensic tools parse this structure to enumerate files; the structure is the rough equivalent of NTFS’s MFT but with different semantics.

FAT and exFAT on removable media

FAT (File Allocation Table) in its various versions (FAT12, FAT16, FAT32) and the successor exFAT are still the dominant file systems on removable media: USB flash drives, SD cards, the SD slots on consumer cameras and devices. The structure is much simpler than NTFS, ext, or APFS, which makes both the forensic tooling and the recovery techniques more constrained.

No journaling. FAT and exFAT do not maintain transaction journals. Recent file system activity leaves fewer artifacts than on the journaled file systems. Deleted files are recovered by walking the directory entries (which mark deletions by zeroing the first byte of the file name) and following the cluster chain that the FAT still records — provided the clusters have not been overwritten.

Long file names in FAT32 are stored as a chain of directory entries that precedes the standard 8.3 entry. The chain includes a checksum that links back to the short entry. Most forensic tools handle this transparently; the underlying structure occasionally matters when names have been partially overwritten.

exFAT addresses FAT32’s size limitations (4 GB maximum file size, 2 TB maximum volume size) without adding journaling. The structure is similar but with larger fields. exFAT is the standard format for SDXC cards and large USB drives. The forensic analysis is similar to FAT but with the parsing adjusted for the extended structures.

Carving as the recovery strategy. Because FAT/exFAT do not preserve as much deletion metadata as the journaled file systems, file carving (covered below) is the primary recovery technique. The simplicity of the file system structure means there are fewer artifacts to mine, but what’s there is straightforward.

File carving

File carving is the practice of recovering files from raw disk data without reference to the file system structures. The technique exists because file systems treat deleted files in ways that destroy the metadata even when the content remains; carving works directly on the bytes.

Signature-based carving identifies file types by their magic bytes (the file format-specific identifier at the start of the file) and, where the format supports it, by their end-of-file markers or length fields. The tool reads the disk image sequentially, finds signatures, and extracts what looks like a file from each match. The output is files of approximate-but-imperfect fidelity — a carved JPEG might be truncated, or might include trailing data from a different file, or might be the wrong size altogether.

Structure-based carving uses the file format’s internal structure to extract files more reliably. Carving an MP4 video requires understanding the box structure; carving a SQLite database requires parsing the page format; carving an Office document (which is a ZIP container with specific internal structure) requires understanding the container.

The major carving tools:

• Foremost is the original signature-based carver, simple and reliable for the file types it supports.
• Scalpel extends Foremost with better performance and a more flexible configuration model.
• PhotoRec is the most widely-deployed carver, particularly for image and document recovery on consumer storage media. The tool comes packaged with TestDisk, which is also useful for partition recovery.
• bulk_extractor takes a different approach — instead of carving complete files, it scans the disk for specific patterns (email addresses, URLs, phone numbers, credit card numbers, search terms) and produces a structured catalog of what was found. The tool is fast (parallel, no file system parsing) and surfaces artifacts that signature-based carving misses.

Carving’s limitations are real. Fragmented files (files whose content is split across non-contiguous regions of the disk) are difficult to reassemble — signature-based carving will recover the first fragment and may miss or misattribute subsequent fragments. Compressed or encrypted content is uncarvable in raw form; the original ciphertext can be recovered but cannot be interpreted without the key. Modern file systems with extensive metadata (NTFS, APFS) reduce the need for carving when the file system structures are intact; carving comes back into play when the file system is damaged, the deletion is recent and unrecoverable through metadata, or the source is FAT/exFAT.

Slack space and unallocated space

The terminology around the unused regions of a disk is worth getting right because the regions have different forensic properties.

Unallocated space is the disk regions that the file system marks as free. These regions may contain remnants of previously-deleted files (full deleted files, partial files where some clusters have been overwritten, file system structures that referenced files no longer in the active directory tree). Carving operates against unallocated space.

File slack is the difference between a file’s actual size and the storage allocated to it. File systems allocate storage in fixed-size units (clusters on FAT/NTFS, blocks on ext, allocated bytes on APFS); a file that is 10 KB on a 4 KB cluster file system occupies three clusters totaling 12 KB. The unused 2 KB at the end of the third cluster — file slack — may contain remnants of whatever was in that cluster before the current file claimed it.

RAM slack is the specific portion of file slack between the file’s actual end and the next sector boundary, which the operating system pads with zero or with whatever was in memory at the time of write. Modern operating systems zero RAM slack, but historical Windows behavior was to copy memory contents, which occasionally surfaces interesting data.

Drive slack is the remaining slack between the RAM slack boundary and the cluster boundary. Drive slack contains data left over from previous use of the cluster.

The practical analysis pulls all three slack regions and unallocated space into the carving and pattern-matching workflows. The yield is variable; the cost is low (the data is already in the image); the discovery rate when it works can be significant.

Timestamp analysis

Timestamps are the connective tissue of any timeline reconstruction. Each file system preserves a different timestamp model, and each model carries its own quirks.

NTFS timestamps come from two attributes per file. $STANDARD_INFORMATION carries four timestamps: creation, last modification, MFT entry modification, and last access. $FILE_NAME carries the same four timestamps but updates them under different rules — typically only on file creation and rename, leaving them frozen for most of the file’s life. The dual model means that timestomping (which usually modifies only $STANDARD_INFORMATION) leaves $FILE_NAME intact, and a divergence between the two is a strong signal that the file has been touched. NTFS records timestamps with 100-nanosecond granularity stored as a 64-bit count of intervals since 1601-01-01 UTC.

ext4 timestamps include atime (access), mtime (modification), ctime (inode change), and crtime (creation). Nanosecond granularity. ext2 and ext3 lack crtime, and many older systems may not preserve atime at all (the noatime mount option, ubiquitous on performance-tuned systems, suppresses atime updates).

APFS timestamps include create, modify, change (the inode change time equivalent), and access. Nanosecond granularity. APFS additionally preserves snapshot creation times that allow point-in-time reconstruction across the snapshot history.

FAT/exFAT timestamps are sparser. FAT32 stores creation date+time, last access date (no time), and last modification date+time. exFAT improves on this with finer granularity but still has a less complete timestamp set than the journaled file systems. The two-second granularity on FAT32 modification times is a recurring source of timeline confusion when correlating with other artifacts.

The “MAC” or “MACE” mnemonic that some forensic literature uses (Modification, Access, Creation, Entry-modification on NTFS) is a useful shorthand but conflates the OS-specific differences. Each file system’s timestamps have their own update rules, and a timeline that treats timestamps as semantically equivalent across file systems will get the relative ordering wrong on cross-system reconstructions.

Timestamps lie. Anti-forensics tooling (timestomp, SetMACE, the Metasploit timestomp module) can rewrite timestamps to arbitrary values. Network time skew, system clock manipulation, and time-zone confusion all introduce artifacts that timeline analysis has to account for. The cross-corroboration of timestamps against artifact-internal evidence (a file claiming a creation date of 2010 that contains references to 2022 events) is the practical check on timestamp reliability.

The downstream consumption of timestamps is covered in the Timeline Analysis subpage.

Windows artifact catalog

Beyond the file system structures themselves, Windows preserves a rich catalog of artifacts that disk forensics extracts and interprets. A short tour of the major categories.

The registry is Windows’ configuration and state database. The hives — SOFTWARE, SYSTEM, SAM, SECURITY, DEFAULT, and per-user NTUSER.DAT and UsrClass.dat — preserve installed software, user accounts, network configuration, USB device history (USBSTOR), wireless network history, recently-opened documents, and a long list of forensically interesting state. The standard tools are RegRipper (open-source, plugin-based), Registry Explorer (Eric Zimmerman’s GUI tool), and YARP (Python parser for the underlying hive format). RegRipper plugins exist for hundreds of specific artifacts; the parsing of any given registry key is usually a question of choosing the right plugin or writing a custom one.

Prefetch files record program execution. Windows writes a .pf file to C:\Windows\Prefetch\ the first time a program is run and updates it on subsequent runs. The file records the program’s path, the number of times it has been run, the last eight run times (newer Windows versions), the files the program accessed during startup, and other launch metadata. Prefetch is one of the strongest artifacts for proving program execution. The standard tools are PECmd (Eric Zimmerman) and prefetch-parser. Some hardened systems disable prefetch; SSDs typically have prefetch disabled by default.

ShellBags record the folders a user has browsed in Windows Explorer, including folders that no longer exist, folders on disconnected drives, and folders on removable media. Stored in the user’s NTUSER.DAT and UsrClass.dat, ShellBags are recovered by ShellBagsExplorer (Eric Zimmerman) and similar tools. The artifact is particularly valuable for establishing user knowledge of folder structures that are no longer accessible.

Jump lists record recently-opened files in specific applications. Stored as .automaticDestinations-ms and .customDestinations-ms files in the user’s AppData\Roaming\Microsoft\Windows\Recent\ paths, they are parsed by JLECmd (Eric Zimmerman).

LNK files (Windows shortcut files) record the target file, the file’s MAC times, the volume serial number, and the network path if applicable. Even after the target file is deleted, the LNK file preserves the metadata. LECmd (Eric Zimmerman) is the standard parser.

The Recycle Bin preserves deleted files in a per-user $Recycle.Bin folder until the user empties it. The deleted files are renamed (the deletion entry records the original name), and the metadata is in $I files that pair with the $R content files. RBCmd (Eric Zimmerman) parses these.

Event logs in EVTX format record system events, security events, application events, and a long list of additional channels. The Security log records logon attempts (event ID 4624 for successful, 4625 for failed, 4648 for explicit-credential), process creation (4688 if audit is enabled), and many other events. The forensic analysis is normally done with EvtxECmd (Eric Zimmerman), plaso / log2timeline, or commercial tools that convert EVTX to searchable timelines.

Browser artifacts include history, cache, cookies, downloads, autofill, and saved credentials. Stored in browser-specific SQLite databases (Chrome’s History, Firefox’s places.sqlite, Edge’s WebCacheV01.dat). The analysis is normally done with Hindsight (Chrome), NirSoft tools, and Magnet AXIOM for integrated browser analysis.

Memory-derived artifacts on disk include the hibernation file (hiberfil.sys, an effective memory snapshot when the system was last hibernated), the page file (pagefile.sys, which contains paged-out memory contents that may include encryption keys and other sensitive data), and the crash dumps. These are disk artifacts that the Memory Forensics subpage covers from the analytical side.

The Windows artifact catalog is large enough that listing it exhaustively requires its own page. The above is the working subset for routine disk forensics.

macOS and Linux artifacts

The macOS and Linux artifact catalogs are smaller than the Windows catalog and less standardized, but the major categories are worth knowing.

On macOS, the central artifacts are Spotlight (.Spotlight-V100, the search index, which preserves metadata about indexed files even after deletion), FSEvents (.fseventsd, the file system change log used by Time Machine and Spotlight), Quarantine attributes (extended attributes attached to downloaded files that record the source application and URL), Unified Logging (the modern macOS log system, replacing the older system.log), launch agents and daemons (the plist files in LaunchAgents and LaunchDaemons directories that establish persistence), and the Keychain (encrypted credential storage). Time Machine snapshots preserve historical file system state.

On Linux, the central artifacts are bash history (~/.bash_history, sometimes obscured by unset HISTFILE but recovered from memory or from rotated copies), /var/log/ (system logs in syslog or journald format), /var/log/wtmp and /var/run/utmp (login records, parsed by last and who), the systemd journal (/var/log/journal/ in binary format, parsed by journalctl), cron logs (showing scheduled job execution), and the running-process logs that the operating system maintains. Persistence mechanisms include ~/.bashrc, /etc/rc.local, systemd unit files in ~/.config/systemd/user/, and cron tables.

The OS-specific tooling for these artifacts is thinner than the Windows ecosystem. Many examiners run grep, awk, and sqlite3 directly against the relevant files rather than using purpose-built parsers. The commercial forensic tools (X-Ways, EnCase, FTK, Magnet AXIOM) have macOS and Linux coverage but the depth varies — particularly on the macOS side, where the artifact landscape changes with each macOS release.

Tooling landscape

The tools the disk-forensics work depends on, separated from the acquisition tools that came earlier in the workflow.

The Sleuth Kit (TSK) and Autopsy. The open-source forensic suite. TSK provides the underlying parsers for the major file systems; Autopsy is the GUI front-end that orchestrates examinations. The tooling is mature for NTFS, FAT/exFAT, and ext; APFS support via libfsapfs is less complete than the commercial alternatives.

X-Ways Forensics. The German commercial tool that has a substantial following among examiners who prioritize technical depth. The file system support is broad and the carving capabilities are deep. The learning curve is steep.

EnCase Forensic. The OpenText commercial tool, still dominant in U.S. law enforcement and in environments with long EnCase histories. EnScript (the embedded scripting language) allows custom processing; the artifact coverage is broad.

FTK (Forensic Toolkit). The Exterro commercial tool, dominant in some commercial forensic practices, particularly those with FTK-trained staff. Historically strong on processing performance.

Magnet AXIOM. A newer commercial entrant that has gained ground particularly for its mobile and cloud forensic capabilities. Strong artifact coverage for modern Windows, macOS, and mobile platforms.

Eric Zimmerman’s tools (MFTECmd, PECmd, RBCmd, LECmd, JLECmd, EvtxECmd, Registry Explorer, ShellBagsExplorer, RECmd, AmcacheParser, and others) are the de facto standard open-source artifact parsers for Windows. The toolset is the result of one person’s focused work over a decade and is widely deployed in DFIR practices regardless of whether the rest of the toolchain is commercial or open-source.

plaso / log2timeline is the cross-artifact timeline tool that consumes outputs from many of the above and produces normalized timeline events. Covered in the Timeline Analysis subpage.

libfsntfs, libfsfat, libfsapfs, libewf (Joachim Metz’s libyal libraries) are the open-source low-level libraries that many of the above tools depend on. The libraries are also useful for custom parsing where the higher-level tools fall short.

Where the methodology breaks down

The structural problems disk forensics is currently working through:

SSDs and TRIM. As discussed earlier, TRIM destroys deleted content on modern SSDs in seconds to minutes. The deleted-file recovery techniques that work on spinning media have substantially reduced yield on SSDs. The methodology has to acknowledge this honestly in the report.

Full-disk encryption. BitLocker, FileVault, LUKS, and the per-volume APFS encryption are now the default on modern systems. Dead acquisition of an encrypted volume produces an examinable image only if the key can be recovered. The mitigations are partial; see the Memory Forensics subpage.

File system corruption. Real-world acquired images sometimes have corruption — bad sectors, partial overwrites, file system inconsistencies. The methodology has to handle this without invalidating the analysis. The standard approach is to document the corruption, work with the recoverable subset, and acknowledge the limitation.

Modern OS update patterns. The Windows feature-update model (twice-yearly major updates) and the macOS annual release cadence change artifact formats more rapidly than the forensic tooling can keep up. Each new OS release potentially breaks a subset of parsers; the toolset maintenance burden is substantial.

File system pace of change. New file systems (ReFS on Windows Server, btrfs in some Linux environments, ZFS on FreeBSD and Linux, the various Android and iOS file system layers) have less mature forensic tooling than NTFS, ext, and APFS. The analytical methodology often falls back to manual parsing or to commercial tools whose support is partial.

Anti-forensics. Timestomping, log clearing, file wiping, and the rest of the anti-forensics toolkit complicate examination. Each category has partial mitigations (the $FILE_NAME timestamps catch timestomping when the adversary doesn’t think to address them; the $LogFile journal catches many file system operations even after log clearing; carving recovers wiped content when the wipe was incomplete). The full coverage is in the Anti-Forensics subpage.

Scale. Modern enterprise environments produce more disk images than any examiner can fully examine. The methodology adjustments are working: targeted artifact extraction (KAPE), automated timeline construction (plaso), curated dashboards (Timesketch). They still leave a substantial gap between what is theoretically possible and what an examiner can complete within a case’s timeline.

Disk and file system forensics is the workhorse of the discipline. It is the part where the most evidence lives, the part where the longest-standing methodology has been built up, and the part where most forensic engagements spend the majority of their analytical effort. The structures are well-understood, the tooling is mature, and the artifacts are documented to a depth that makes the work systematic rather than improvisational. Until it doesn’t, at which point the work depends on the examiner’s ability to read raw file system structures and write custom parsers.

The connected pages cover the work that this work supports and that supports it: Forensic Acquisition and Imaging covers the methodology that produces the images; Memory Forensics covers the volatile-data analysis that disk forensics is paired with; Timeline Analysis covers the cross-artifact reconstruction that the file system timestamps feed into; Anti-Forensics covers the adversary techniques that complicate examination; and Evidence Handling and Chain of Custody covers the procedural framework that makes the findings defensible. The Digital Forensics hub covers the discipline as a whole.