Anti-ForensicsRendering Digital Investigations Irrelevant
Reference Library · Investigation notes

Review metadata inconsistencies across a file’s transformations

Compare filesystem, embedded, service, and collection metadata without assuming every difference is tampering.

Materially reviewed · Original editorial guide

2 minute read · Source-based editorial synthesis
On this page
  1. Preserve the object and field representation
  2. Build a transformation history
  3. Compare fields by meaning
  4. Find a discriminating observation

A metadata inconsistency is a question to explain. The first task is to identify which system wrote each field and what event it claims to describe. A filesystem creation time, an embedded capture time, a server upload time, and an export time can all differ without contradiction because they refer to different events.

Preserve the object and field representation

Keep the received bytes and their hash, original path or source identifier, collection method, and any available associated manifest. Export metadata with the parser version and field names, retaining raw values where possible. A normalized report can collapse fields that have similar labels but different definitions. Preserve enough detail to reverse the conversion.

Microsoft’s file-time documentation explains Windows file-time representation and filesystem differences. It also describes update behavior that complicates a simple equation between a file time and a user's action. Apply the reference to the relevant filesystem and Windows build; do not transfer one platform's semantics to another filesystem or to an embedded media field.

Build a transformation history

List each known stage: original receipt, download, copy, archive extraction, conversion, synchronization, editing, and export. Give each resulting object its own identifier and hash. Record which stages are documented and which are merely possible. A filename surviving a transformation does not establish identical content, and a changed hash is expected when the object changes.

For each stage, ask which system could preserve, generate, omit, or reinterpret a field. Use the applicable application documentation or a bounded validation exercise before claiming the transformation's actual behavior. Do not replace missing evidence with a general belief that a tool “usually preserves metadata.”

Compare fields by meaning

Metadata layerQuestion to resolve
FilesystemWhich volume, operation, and update semantics produced the time?
Embedded objectWhich application or device wrote the field and what time basis applies?
ServiceIs this creation, upload, receipt, indexing, or modification?
CollectionDoes the value describe export or examination rather than source activity?

Compare precision and known clock uncertainty before calling two values inconsistent. A missing time zone cannot responsibly acquire one merely because it produces a neat sequence. Preserve unresolved alternatives and show how each affects the proposed chronology.

Find a discriminating observation

If ordinary copying and deliberate modification could both explain a difference, identify a source that can distinguish them: an earlier preserved copy, an application activity record, a server transaction, or documented transformation settings. Two tools reading the same field offer a parser cross-check, not independent proof of the history.

A report should describe the difference before assigning cause: “The embedded value predates the destination filesystem creation value; a documented export intervened.” If the intervening workflow is unknown, say so. A plausible explanation remains an interpretation until supported.