A forensic timeline is an index, not the disk

Two digital-forensics examiners at work in a laboratory in 2013. The room makes the ecosystem's human boundary visible: software can preserve addresses, extract events and organize searches, but an examiner still has to document the source and defend each inference. Photograph by ViktorDFC, CC BY-SA 4.0.[12]

At first glance, a forensic timeline looks more authoritative than the disk it came from. The disk is billions of opaque bytes. The timeline offers neat rows: a file modified at 09:41, a browser record written at 09:42, a log entry at 09:43. Sort the rows and a story seems to assemble itself.

But those three times may describe three different things. One could be a file-system metadata field, one a timestamp stored by an application, and one a parser's interpretation of a log record. They may have different precision, time-zone assumptions and relationships to human action. Plaso's event model preserves this distinction with fields for the event time, what that time represents, the source, parser and contextual data.[5] Chronological proximity is therefore an investigative lead, not proof of causality.

The open-source timeline stack is most useful when its layers remain visible. libewf reads or writes an Expert Witness Format container such as an .E01; dfVFS addresses the volumes, file systems and nested objects inside storage; Plaso extracts source-level events into a .plaso storage file; Timesketch indexes those events so investigators can search, tag, compare and narrate them. Each layer makes a new kind of question possible. None inherits all the authority of the layer below it.

That is the central boundary: a searchable timeline is a derived index over selected interpretations of acquired data. It can help an investigator find the decisive artifact. It is not a replacement for the evidence image, the acquisition record or the reasoning that connects an artifact to a claim.

Image context: the cover photograph shows two examiners in a digital-forensics laboratory in 2013. Monitors dominate the frame, but the exposed drives, controlled workspace and second operator matter just as much. The open stack mapped here produces inspectable transformations; the people and procedures around it establish what those transformations may support.[12]

Four layers, four different claims

Layer	Open component	What it can establish	What it cannot establish alone
Container access	libewf	Which media bytes and acquisition metadata an EWF file exposes, and whether its stored media data verifies	That the right device was acquired completely, under a documented process
Storage addressing	dfVFS	Which nested image, volume, file system and file entry a reader is accessing	That every encrypted, damaged or unsupported object became readable
Event extraction	Plaso	Which parser produced an event, from which source, with what time meaning and context	That the event represents the action an investigator suspects
Collaborative analysis	Timesketch	Which imported events match a query, view, tag or story	That absent events never existed, or that nearby events caused one another

The value of the ecosystem is not that it dissolves these seams. It gives each seam an inspectable implementation and a record that can be preserved.

libewf opens a container; provenance starts outside it

An EWF image is more than a filename ending in .E01. It is a container through which tools can access captured storage-media data and associated metadata. The libewf project supports common EWF families and ships separate utilities for their lifecycle: ewfacquire writes media data to EWF, ewfinfo reports container information, ewfexport converts or exports it, ewfmount exposes it through FUSE, and ewfverify verifies the stored media data.[1]

Those verbs are intentionally narrower than “prove.” A successful ewfverify result can support the claim that the media data in the container still matches the verification values expected by the format. It cannot tell an investigator whether the acquisition began after a live system changed, whether unreadable sectors were handled appropriately, whether a write blocker was used when one was required, or whether the labeled device is the device described in the case record.

NIST's preservation guidance keeps the surrounding responsibilities explicit: document the original source and how the image was created or transferred, hash digital images close to collection, keep the resulting hash separately in a secure location, retain backups, and record transfers.[10] A hash is powerful evidence of byte-level continuity between two observations. It does not reach backward in time to validate everything that happened before the first trustworthy hash.

That makes the EWF container the first technical boundary, not the beginning of truth. A defensible run keeps the source identifier, acquisition notes, tool and version, operator, start and end times, read-error record, container segment set and cryptographic hashes together. The original image then remains preserved while downstream tools work from a verified copy or controlled read-only access path.

dfVFS preserves the address through nested storage

A path inside forensic media is rarely just C:\Users\.... Reaching that file may require opening an EWF segment set, reading a partition table, selecting a partition, interpreting NTFS and then resolving a file entry or alternate data stream. A conventional operating-system path hides most of that chain.

The Digital Forensics Virtual File System provides a generic, read-only interface over storage-media formats, volume systems and file systems, with back ends doing the format-specific work.[2] Its path specifications make the nesting explicit. An EWF path specification can be the parent of a partition path specification; that partition can parent a Sleuth Kit file-system path; the file-system object can in turn identify a particular entry. The same model covers raw, QCOW, VHD and VMDK images, APFS and LVM containers, BitLocker or LUKS-encrypted volumes, Volume Shadow Copies and even files nested in ZIP, TAR or SQLite objects.[3]

This is an evidentiary advantage because “where did this object come from?” remains answerable after several abstraction layers. Plaso output can retain a serialized path specification alongside parser and event fields, allowing a reviewer to trace a row back toward its storage location rather than accepting only a friendly display path.[3][6]

Read-only access, however, is not synonymous with complete access. An encrypted volume still needs the right credential. A damaged file system can defeat a resolver. A format may be unsupported or only partly implemented. Selecting one snapshot can omit a state visible in another. The failure should stay in the run record: source-scan messages, credentials supplied, partitions selected, snapshots included and objects that could not be opened. An empty result from an unreadable layer is not evidence of absence.

Plaso turns artifacts into source-level events

log2timeline.py accepts a file, directory, storage device or storage-media image and writes extracted events plus collection metadata to a Plaso storage file. The documented basic shape is deliberately plain:

log2timeline.py --storage-file timeline.plaso /evidence/host.E01

Before and during extraction, Plaso scans the source through dfVFS, preprocesses context such as hostnames, local users and time-zone information, selects parsers, and stores the events they emit.[4] The .plaso file is an intermediate derived analysis artifact: pinfo.py can inspect it, while psort.py can filter or render it into other output formats.[4]

The word event needs discipline here. Plaso defines a source-level event as a time or duration, an indication of what that time means, the source from which it was learned, source-specific data and contextual information.[5] A file's creation time and modification time are separate events because they are separate claims. A browser database row may expose a visit time recorded by the application. A Windows event log record may carry a system-written timestamp. A parser can normalize these values for comparison while retaining fields such as timestamp_desc, parser chain and source path.[6]

Normalization enables correlation, but it cannot manufacture a common clock. A powered-off laptop may have had the wrong local time. A cloud service may write UTC while an application exports local time. Some formats store subsecond precision; others do not. File copying can preserve one metadata field and rewrite another. Parser coverage also sets a hard ceiling: unsupported artifacts, corrupted records or an excluded parser produce no event. Independent research on digital-forensic tool error treats inaccurate clocks and incorrect timestamp interpretation as distinct failure paths that a sorted result cannot erase.[11]

The operational record should therefore capture the exact Plaso release, command line, parser or filter selection, source time-zone decision, dependency checks, warnings and the hash of the resulting .plaso file. Re-running extraction after an upgrade is legitimate, but it creates a new derived dataset. Preserve the earlier storage file and record what changed instead of silently replacing the timeline beneath an existing conclusion.

Timesketch makes the derived set investigable

A .plaso file is rich but awkward for several people asking changing questions. Timesketch accepts Plaso storage files as well as appropriately structured CSV and JSONL. Its importer can apply a Plaso event filter, splits large uploads into pieces, and indexes the resulting event data for exploration.[7] A sketch can combine timelines and give investigators search, time-range filters, saved views, comments, tags, starred events and stories; sketches can also be shared with selected users or groups.[8]

This layer changes the unit of work. Instead of repeatedly exporting a complete timeline, an analyst can save a query such as data_type:"windows:registry:key_value", narrow a time range, tag relevant rows and place selected events into a written story.[9] A second investigator can inspect the same result set and challenge the query. That shared, reviewable state is Timesketch's real contribution.

It is also another transformation. An ingest filter can omit event classes. Index mappings decide how fields are searched. A saved view records a query, not the investigator's unspoken assumptions. Tags and stories are analytical annotations, not properties discovered on the disk. Access to a sketch may disclose highly sensitive source content even when users never receive the original image.

For a single responder examining one bounded host, psort.py output and a carefully documented notebook may be the smaller, safer system. Timesketch becomes compelling when multiple investigators need repeatable queries across large or numerous timelines—but then the team owns a secured service, storage capacity, case-level authorization, backups, audit expectations and an export strategy. The collaboration layer should be adopted because collaboration is the problem, not because a web interface makes the evidence look finished.

Preserve a chain of transformations, not one final screenshot

The fastest way to make this ecosystem indefensible is to preserve only the polished end state: a screenshot of ten rows in Timesketch with colored tags and a paragraph beneath it. The screenshot loses the query, filters, parser provenance, excluded sources and path back to the image.

A compact audit bundle should retain five linked records:

Acquisition: source identity, authority and scope, operator notes, errors, tool version, container segment inventory, timestamps and hashes stored independently of the image.
Access: the verified working copy, dfVFS source-selection decisions, credentials or snapshots used, and scan failures that constrained what was readable.
Extraction: the Plaso version, complete command, parser set, time-zone handling, warnings, processing statistics and hash of the .plaso output.
Ingest: the Timesketch importer version, target sketch and timeline, any --plaso-event-filter, index or mapping changes, and access-control decision.
Analysis: saved queries and time ranges, tags with authorship, story revisions, exports, and citations from each material claim back to the underlying event and source path.

These records do not make an inference correct. They make it possible to locate the layer where disagreement belongs. If two analysts see different rows, compare the ingest and query. If the event exists but its time meaning is disputed, inspect the Plaso event and parser. If the source path cannot be resolved, inspect dfVFS and the container. If the container itself is questioned, return to acquisition, hashes and custody.

That diagnostic direction—from story back to event, event back to object, object back to bytes—is the ecosystem's strongest design property. libewf, dfVFS, Plaso and Timesketch let teams replace or rerun a layer without pretending that every layer says the same thing.

A forensic timeline earns trust not by looking complete, but by keeping its incompleteness inspectable. It should show what was acquired, what could be opened, what was parsed, what was imported and what an analyst inferred. The timeline is where investigation becomes navigable. The disk image and its provenance remain where the claims must ultimately return.

cronfeed.work