How to check all timestamps of file

The four timestamps that are actually eight? ?

http//reboot.pro/topic/15960-setmace/
http//reboot.pro/files/file/216-ntfs-tools-collection/

On github
https://github.com/jschicht?tab=repositories

Particularly
https://github.com/jschicht/MftRcrd

See
http//superuser.com/questions/973547/how-can-i-display-all-8-ntfs-timestamps

jaclaz

Between the $STANDARD_INFORMATION and $FILE_NAME attributes, I've seen a total of 12 (and in some cases, 16) time stamps. I use a Perl script to parse through and display these values. The Perl script can be 'compiled' into a standalone .exe file for Windows systems.

I have seen 9 timestamps D

I think we can agree on "double or more" than the original 4. wink

The actual number should be 4+4 or 4+8 for a "normal" file, depending on filename length, as explained by Joakim on the given links.

jaclaz

I think we can agree on "double or more" than the original 4. wink

The actual number should be 4+4 or 4+8 for a "normal" file, depending on filename length, as explained by Joakim on the given links.

jaclaz

Don't forget about hard links and Object IDs.

Don't forget about hard links and Object IDs.

Sure ) , that's why I expressly specified "normal" files. roll

But we could go for "at least eight" wink .

jaclaz

Don't forget about hard links and Object IDs.

Sure ) , that's why I expressly specified "normal" files. roll

But we could go for "at least eight" wink .

jaclaz

"Normal" files on internal drives are expected to have Object IDs )

"Normal" files on internal drives are expected to have Object IDs )

But strictly speaking an Object ID is not a timestamp, it is a GUID.
https://0cch.com/ntfsdoc/attributes/object_id.html

And it seems like there are cases where no Obiect_ID is associated to files
https://digital-forensics.sans.org/blog/2009/12/24/ntfs-attributes-part-one

jaclaz

"Normal" files on internal drives are expected to have Object IDs )

But strictly speaking an Object ID is not a timestamp, it is a GUID.
https://0cch.com/ntfsdoc/attributes/object_id.html

And it seems like there are cases where no Obiect_ID is associated to files
https://digital-forensics.sans.org/blog/2009/12/24/ntfs-attributes-part-one

jaclaz

But this GUID includes a timestamp.

But this GUID includes a timestamp.

Maybe, or maybe not.
http//blog.stephencleary.com/2010/11/few-words-on-guids.html

jaclaz

But this GUID includes a timestamp.

Maybe, or maybe not.
http//blog.stephencleary.com/2010/11/few-words-on-guids.html

jaclaz

This link has nothing to do with the NTFS driver and the kernel. Version 1 GUIDs are generated even in Windows 10.

This link has nothing to do with the NTFS driver and the kernel. Version 1 GUIDs are generated even in Windows 10.

Good to know. )

Do you have a decoder handy?

Just created a new volume in XP (IMDISK), formatted it NTFS and made a test.txt file in it, then MFTRCRD
MFTRCRD N\test.txt -d indxdump=off 1024 -s
…
$STANDARD_INFORMATION 1
File Create Time (CTime) 2017-01-13 1853586205000
File Modified Time (ATime) 2017-01-13 1854196361250
MFT Entry modified Time (MTime) 2017-01-13 1854281361250
File Last Access Time (RTime) 2017-01-13 1854237767500
…
$FILE_NAME 1
Parent MFTReference 5
ParentSequenceNo 5
File Create Time (CTime) 2017-01-13 1853586205000
File Modified Time (ATime) 2017-01-13 1854196361250
MFT Entry modified Time (MTime) 2017-01-13 1854196361250
File Last Access Time (RTime) 2017-01-13 1854196361250
…
$OBJECT_ID 1
GUID Object Id {37D54FD4-D1EB-11E6-B0C6-001FC6BB76CE}

Can you check this one?
37D54FD4-D1EB-11E6-B0C6-001FC6BB76CE

The online thingy
https://www.famkruithof.net/uuid/uuidgen

gets

The UUID 37D54FD4-D1EB-11E6-B0C6-001FC6BB76CE contains a timestamp taken at
Tuesday, January 3, 2017 73126 PM GMT

that makes little sense.

Maybe there is an issue in MFTRCRD or in the online decoder (or in both). 😯

jaclaz

P.S. Tested in another decoder, same result
http//www.mahonri.info/cgi/uuid.cgi

This link has nothing to do with the NTFS driver and the kernel. Version 1 GUIDs are generated even in Windows 10.

Good to know. )

Do you have a decoder handy?

Just created a new volume in XP (IMDISK), formatted it NTFS and made a test.txt file in it, then MFTRCRD
MFTRCRD N\test.txt -d indxdump=off 1024 -s
…
$STANDARD_INFORMATION 1
File Create Time (CTime) 2017-01-13 1853586205000
File Modified Time (ATime) 2017-01-13 1854196361250
MFT Entry modified Time (MTime) 2017-01-13 1854281361250
File Last Access Time (RTime) 2017-01-13 1854237767500
…
$FILE_NAME 1
Parent MFTReference 5
ParentSequenceNo 5
File Create Time (CTime) 2017-01-13 1853586205000
File Modified Time (ATime) 2017-01-13 1854196361250
MFT Entry modified Time (MTime) 2017-01-13 1854196361250
File Last Access Time (RTime) 2017-01-13 1854196361250
…
$OBJECT_ID 1
GUID Object Id {37D54FD4-D1EB-11E6-B0C6-001FC6BB76CE}

Can you check this one?
37D54FD4-D1EB-11E6-B0C6-001FC6BB76CE

The online thingy
https://www.famkruithof.net/uuid/uuidgen

gets

The UUID 37D54FD4-D1EB-11E6-B0C6-001FC6BB76CE contains a timestamp taken at
Tuesday, January 3, 2017 73126 PM GMT

that makes little sense.

Maybe there is an issue in MFTRCRD or in the online decoder (or in both). 😯

jaclaz

P.S. Tested in another decoder, same result
http//www.mahonri.info/cgi/uuid.cgi

The kernel is pulling GUIDs from a cache. Can you reboot the operating system and repeat your actions?

The kernel is pulling GUIDs from a cache.

Another good thing to know. )

The 3rd of january might well be the date of last boot.

The last 6005 and 6009 events in System Events are dated 03/01/2017 2022,43 (and since I am GMT+1 it would make more or less sense).

Can you reboot the operating system and repeat your actions?

No, I cannot reboot right now (this system is usually on 24/7), but I will repeat the test next time I reboot.

In any case the Object_ID continues to be not a "time stamp", but more like a "data point".

jaclaz

P.S. If you know of a decoder for these values, I would still be interested in it as the two mentioned online ones provide a different time
https://www.famkruithof.net/uuid/uuidgen
Tuesday, January 3, 2017 73126 PM GMT
vs
http//www.mahonri.info/cgi/uuid.cgi
Tue Jan 3 143126 2017 (+0.562504 seconds)