(potentially) wrong timestamps?

[thinrope]

I have been testing some "random" NTFS images and I see that sometimes most timestamps are off by years...

I looked in the code, but am still not sure how images containing both $STANDARD_INFORMATION and (multiple) $FILE_NAME attributes are present?

The relevant code is in https://github.com/Lazza/RecuperaBit/blob/323bef99cf29065e94371385ebd119b833ac90a9/recuperabit/fs/ntfs.py#L303-L312 but I cannot understand what takes priority. Or is the $STANDARD_INFORMATION simply ignored?

It looks like they are known at least: https://github.com/Lazza/RecuperaBit/blob/323bef99cf29065e94371385ebd119b833ac90a9/recuperabit/fs/ntfs_fmt.py#L241-L247 but are they used?

Here one reference on when these change:

• Win10: https://cyberforensicator.com/2018/03/25/windows-10-time-rules/
• Forensics|Exchange: https://forensixchange.com/posts/19_04_22_win10_ntfs_time_rules/

It will be good to dump all found attributes for inode somehow. May be even reconstruct the $MFT as a file? In addition, when providing bodyfile (it can only have single MACB) apply some logic which attribute to use (latest for mtime?).

[Lazza]

Or is the $STANDARD_INFORMATION simply ignored?

I need to check to be fair, but IIRC that's correct.

dump all found attributes for inode somehow

Do you mean like in a CSV file?

[thinrope]

For "dump all found attributes" - yup, CSV might work; also a binary (the MFT fragment itself).

Some time ago I was toying with a self-made carver (in Perl) that just searches for FILE0 signatures at 1024 bytes apart and dumps the result to disk. Then that was parsed by the log2timeline_legacy -f mft ( https://github.com/thinrope/log2timeline/blob/master/lib/Log2t/input/mft.pm ). I never quite finished it, but may be I can dust it off and do it one of these days. Or at least I'll try to compare results with RecuperaBit to see what is going on.

[Lazza]

You can usually extract the $MFT file itself, unless the metadata is heavily damaged.

[thinrope]

I worked a bit more on debugging this and here is a script to test it: test.sh

Just including directly the test results / findings:

• Finding 1:

  RecuperaBit outputs wrong unixtime in bodyfile, offset by the local machine timezone; it should be in UTC. Additionally unixtime is output wrongly truncated, yet with a .0 ending. CSV output can be considered correct (if interpreted in UTC), but it should instead depend on TZ and include %Z.

• Finding 2:

  RecuperaBit ignores $SI attribute and only accounts for $FN attribute, which is wrong in most circumstances.

[Lazza]

Thank you for the detailed test and the script you provided. I will check it out.

Just one thing, what do you mean by this?

Additionally unixtime is output wrongly truncated, yet with a .0 ending

[thinrope]

RecuperaBit outputs timestamps as float, but always ending with .0, e.g. 1617001874.622692040 will be 1617001874.0 which is wrong. It can be 1617001874.6 or 1617001874 (or even 1617001875).

[slavanap]

https://github.com/Lazza/RecuperaBit/pull/104

[Lazza]

I verified the issue on a real world example (a full 1 TB disk image) and went back to read literature again. Here's what Carrier has to say about the timestamps in $STANDARD_INFORMATION:

The four time values are stored as the number of one hundred nanoseconds since January 1, 1601 UTC. The same time fields also exist in the $FILE_NAME attribute, but these are the ones that Windows displays when you View the properties of a file, and these are the ones that are updated.

[Source]

For this reason, I am going to merge #104 (with a slight modification). RecuperaBit will use timestamps stored in $STANDARD_INFORMATION and not $FILE_NAME.