File System Timeline from a Disk Image

About the File System Timeline from a Disk Image

A timeline of a disk is where most examinations start: when each file was created, modified, accessed and had its metadata changed, and when it was deleted where the file system records it, all in one list in time order. This page builds it from a disk image in your browser, from each file system’s own records: every record of an NTFS master file table with the four times of $STANDARD_INFORMATION and the four of $FILE_NAME to 100 nanoseconds; ext2, ext3 and ext4 inodes with their creation and deletion times; HFS+ catalog records; APFS inode records in nanoseconds; FAT and exFAT directory entries.

Deleted files are listed while their records are still there, and two signs of changed times are flagged on NTFS: a $STANDARD_INFORMATION creation time earlier than $FILE_NAME’s, and times with no fraction of a second. They are signs to check, not proof. The image (raw, E01 with its segments, DMG, VHD, VHDX, VMDK, QCOW2 or VDI) is read in pieces and never uploaded or changed.

Without a pass the whole image is read and the whole timeline built: you see every count by volume, file system and kind of time, the deleted entries counted, and the first rows of the timeline. The full timeline, the filters and their exports (CSV, a Sleuth Kit body file, a workbook) and the PDF summary with the image’s hashes need an Ultimate pass.

Common uses

• An incident: what was written to a server or a laptop in the hours around an alert.
• An HR or IP-theft case: which files were created, opened and deleted on a company computer, and when.
• Checking for back-dated documents: files whose visible creation time differs from the one NTFS keeps for itself.
• Handing a timeline to a colleague who works in mactime or a spreadsheet: the body file and the CSV hold every event.

Where the times come from

• NTFS: each record of the master file table, in use or not, with the four times of $STANDARD_INFORMATION (the ones Windows shows) and the four of each $FILE_NAME (which Windows writes itself when a file is made or moved), each a FILETIME of 100-nanosecond steps (MS-DTYP).
• ext2, ext3, ext4: the folder tree from the root, each name’s inode with its access, change, modification and creation times, in nanoseconds on inodes larger than 128 bytes, and the deletion time of a deleted name’s inode (the kernel’s documentation).
• HFS+: the catalog’s folder and file records with their creation, content, attribute and access dates, whole seconds in GMT (TN1150); deleted records from the journal, unused catalog nodes and the space at the end of a node.
• APFS: inode records with their four times in nanoseconds; records that only a snapshot or an older checkpoint keeps are listed as deleted.
• FAT and exFAT: each directory entry, deleted ones too: creation (to 10 ms), last write (2-second steps on FAT, 10 ms on exFAT) and the last access (the date alone on FAT, 2-second steps on exFAT); exFAT records a UTC offset where the writer gave one (exFAT specification).

One event per moment, as mactime makes it

The timeline follows The Sleuth Kit’s mactime: a file’s times that fall on the same moment are one row, marked m (content modified), a (accessed), c (metadata changed) and b (created, “born”), with a dot for each time that falls on another moment. NTFS’s $FILE_NAME times are rows of their own, so the two sets line up in the list. Every time is in UTC; FAT’s local times say so in their row, or how they were converted.

Signs of changed times

Two patterns are flagged on NTFS files, as signs that a program may have changed the times Windows shows:

• $SI created before $FN created: a program that sets times (SetFileTime) changes $STANDARD_INFORMATION but not $FILE_NAME, so a visible creation time earlier than the one NTFS wrote itself stands out. Copy and extract programs that restore an original’s creation time leave the same pattern.
• No fraction of a second: Windows writes times to 100 ns, while many time-changing tools write whole seconds. Files from archives that keep whole seconds, and files copied from FAT drives, look the same.

Neither proves anything on its own: compare it with the other records of the disk.

The files you get

• CSV: one row per event, in the columns the Windows Artifact Report writes too (time, time base, event, MACB, source, volume, path, size, deleted, flags, record, detail), so both open side by side or merge into one case timeline.
• Body file: The Sleuth Kit’s format (Body file), one line per file and set of times, times in whole Unix seconds: NTFS’s $FILE_NAME times are a second line whose name is followed by “($FILE_NAME)”, a deleted file’s name by “(deleted)” (after “($FILE_NAME)” on its second line), and an NTFS file’s inode field holds its record number and sequence number (“1234-5”); each volume is a top folder (/vol1, /vol2 … in the order of the list).
• Workbook: the counts, the whole timeline (in sheets of up to 1,048,575 rows each) and the files with signs.
• PDF summary: the image, the disk’s MD5, SHA-1 and SHA-256 with the hashes an E01 stores, every count, the files with signs, the method and its limits.

What the device needs

The image is read in pieces of a few megabytes, so its own size does not matter; the timeline is kept in memory in the page’s background worker. In our tests, the timeline of a volume of a million files laid out like a Windows system volume (about 3.1 million events) took about 300 MB of memory and was sorted within seconds of the last record being read. Its CSV was about 650 MB, the body file about 300 MB and the workbook about 230 MB (about a minute and a half to write); the browser holds each file until it is saved. Use a computer with at least 8 GB of memory for an image with a million files or more, and keep the tab open while it works.

Limitations

• A deleted file is listed only while its record is still there: NTFS, ext4 and the others reuse records, so older deletions may have left no trace.
• Inodes on ext2/3/4 whose names are gone, deleted folders’ contents and the ext journal’s older copies are not listed; NTFS’s $LogFile and $UsnJrnl are not read as events.
• Alternate data streams are not rows of their own, and each hard link is a row of its own. A name NTFS keeps in an extension record instead of the file’s own record (a file with very many hard links) is not listed.
• Windows updates last access times lazily or not at all, depending on its settings, so an access time may be much older than the last access.
• Encrypted volumes (BitLocker, FileVault, LUKS) cannot be read without their key: image the unlocked volume instead.
• Use these tools only on devices and data you own or may examine; no password cracking and no device unlocking. The page reads the image you hold; it does not connect to any device or account.

Privacy

On this device: nothing is sent

The disk image is read by your browser on your device; nothing from it is sent anywhere, and the page works offline once it has loaded. A file system timeline is personal data: keep the exports with the same care as the image.

How to check that nothing is uploaded