The MFT: file identity & metadata
Trace file records, names, and timestamp families without assuming metadata reveals behavior.
Question & scope
The NTFS Master File Table describes files and directories on a volume. In a gaming investigation, it can help establish that an object existed at a recorded path, identify related metadata, and connect a removed client to surviving filesystem records. An MFT record is filesystem evidence, not a direct observation of what a program did.
Collect the relevant volume context and use a parser appropriate to the acquisition. Keep the original record identifiers and sequence information where available. After deletion, a record can become available for reuse; a matching record number alone may therefore be insufficient to identify the same historical object.
What to collect
| Source | Retain and examine |
|---|---|
| Filesystem source | Collected MFT or disk image with volume identity and acquisition notes. |
| Record identity | Entry number, sequence information, parent reference, and allocation state. |
| Names and attributes | Parsed filename attributes, data descriptions, and relevant timestamp families. |
| Related sources | USN journal, transaction log, actual file copies, and execution-related evidence. |
Examination workflow
- Identify the volume and acquire its metadata through a method suited to the task.
- Parse a copy with a documented tool such as MFTECmd, recording the version and input format.
- Search full path context and follow parent references instead of assigning identity from a filename alone.
- Keep each timestamp family and source field separate. Describe any discrepancy before interpreting it.
- Correlate file creation, rename, or deletion leads with journal and execution records; retain raw identifiers in your working notes.
Interpretation & false positives
File metadata can change for legitimate reasons such as copying, extracting archives, updates, and normal application activity. Timestamp differences do not automatically establish deliberate tampering. A date printed by a parser is meaningful only with its attribute, field, and conversion rules.
Microsoft describes deleted records as reusable. Old metadata may survive temporarily, but it is not a guaranteed history or a guarantee of recoverable content. Do not assume a freed record still describes the file currently carrying a similar name. Execution and user attribution require additional sources.
Worked scenario
An archive was extracted into a game instance immediately before a session. Several files have older modification dates but recent filesystem creation context. That pattern may reflect preserved archive metadata rather than clock manipulation. Compare the archive, extraction behavior, and journal records before describing a cause.
Report checklist
- Volume and record identity are retained.
- Sequence or reuse context is considered.
- Timestamp fields are not merged into one date.
- Filesystem changes and execution are reported separately.
Sources & further reading
The workflow and scenario are authored investigation guidance. Confirm source-system and parser support for the build you examine.