Mistranslation of NTFS timestamps

[andersthulin]

Product Version: Autopsy 3.0.4 (RELEASE) Sleuth Kit Version: 4.0.1 Netbeans RCP Build: 201301102100 Java: 1.7.0_11; Java HotSpot(TM) Client VM 23.6-b04 System: Windows 7 version 6.1 running on x86; Cp1252; en_US (autopsy) Userdir: C:\Users\ath\AppData\Roaming.autopsy\dev

The range of NTFS timestamps that are correctly converted to text form appears to be 1970-01-01 00:00:01 -- 2106-02-07 06:28:00 (or reasonably close). (The 1970-01-01 00:00:00 timestamp is translated as '0000-00-00' etc.)

Timestamps outside that range, however, get translated as timestamps inside it: a timestamp corresponding to 1601-01-01 00:00:00.0000001 is translated as '2076-11-29 08:54:34'.

This means that there is a many-to-one correspondance: many timestamps have the same translation (in the range mentioned). This seems like a bad idea: the analyst can't decide if '2076-11-29 08:54:34' is from that timestamp or from another one, and it appears possible and perhaps even easy to raise doubts as to the validity of just about any analysis done with this version of Autopsy, unless it has been cross-checked with other tools.

Suggested simplest fix: translate everything outside supported range as '?' or 'not supported' or perhaps as the corresponding hex string. Best fix: support for full range of FILETIME.

I have a sample image file, but not witin the 5 Mbyte limit required. I've added a screenshot of the autopsy view: each file identifies a millenium, and has been timestamped with the earliest and latest 'tick' of that millenium that can be set by Windows system calls. That is, the file '02000' should have timestamps translations '2000-01-01 00:00:00' and '2999-12-31 23:59:59', and so on.

The test image has been verified with other tools -- the only one that covered every file was Windows Explorer, file properties dialog box.