A friend of mine she asked me how to check all timestamps of a file on an NTFS volume. She did not have EnCase or FTK in hand. So I gave her FTK Imager and showed her the creation time, access time and modified time of a file. All she need to do is to take a look at properties of file.
You guys could take a look at my blog to see the screenshots.
http//www.cnblogs.com/pieces0310/p/6280086.html
Second I showed her another option - Winhex. Check Options->Directory Browser to make sure all four timestamps will show up in file lists. Now she could see all four timestamps in local time format in file lists.
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.htmlAnd 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-onejaclaz
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.htmljaclaz
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-001FC6BB76CEThe online thingy
https://www.famkruithof.net/uuid/uuidgengets
The UUID 37D54FD4-D1EB-11E6-B0C6-001FC6BB76CE contains a timestamp taken at
Tuesday, January 3, 2017 73126 PM GMTthat 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)