Which of These Files Had Its Dates Rewritten TIMESTOMP
Every file carries its timestamps twice. One set any program can rewrite; the other the kernel writes. Most of the value is in knowing when that comparison lies to you.
The table
MFTECmd and analyzeMFT both produce these columns. Keep the sub-second digits. An export truncated to whole seconds loses the strongest test on this page entirely, and the page will tell you when that has happened rather than quietly scoring everything lower. A master file table is a complete index of a machine; this one is read here and goes nowhere.
What the tests found
The four tests, and what each is worth
- Dates flattened to exactly the secondNTFS keeps time in hundred-nanosecond ticks, so there are ten million of them in a second and a genuine timestamp essentially never lands on zero. The usual tooling sets times from a value accurate only to the second, which leaves the remainder at precisely nought. This is the strongest signal here, it does not depend on $FILE_NAME at all, and it is the one most tools never look at.
- $STANDARD_INFORMATION earlier than $FILE_NAMEThe kernel writes $FILE_NAME when the file arrives, and nothing that happened to the file afterwards can have happened before it got there. $SI can be rewritten by any user-mode program with one documented call; $FILE_NAME cannot.
- A file modified or read before it was createdImpossible, and the arithmetic does not care which tool made it so. Rare, but when it appears it is unambiguous.
- A date far from its neighbours in the tableMFT records are handed out in order, so files created close together sit close together. This one is soft on purpose — records get reused when files are deleted — and is never a finding on its own.
The analysis
Questions people ask about TIMESTOMP