How to check all timestamps of file

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)

Thank you very much for this thread )

The http//www.ietf.org/rfc/rfc4122.txt has some really valuable details )

I know some of my tools will get nice updates soon )

Good. )

In the meantime found out that UUID is a "common" command under Linux and uuid -d can decode V1 UUID's (I expected to find tens of windows32 ports of equivalent programs, but couldn't find easily one).

Anyway, there is one here
http//soft.rubypdf.com/software/guidgen-ossp-uuid
There is also the source.

that seemingly works fine
uuid -d 37D54FD4-D1EB-11E6-B0C6-001FC6BB76CE
encode STR 37d54fd4-d1eb-11e6-b0c6-001fc6bb76ce
SIV 74215118170733981956579217386954782414
decode variant DCE 1.1, ISO/IEC 115781996
version 1 (time and node based)
content time 2017-01-03 193126.562504.4 UTC
clock 12486 (usually random)
node 001fc6bb76ce (global unicast)

jaclaz

You can work out the timestamp part on Windows with powershell like;
(Get-Date 15/10/1582).AddDays(137021739104999239/864000000000)

The 137021739104999239 is the 60 bit timestamp off the guid, output presented in UTC.

You can work out the timestamp part on Windows with powershell like;
(Get-Date 15/10/1582).AddDays(137021739104999239/864000000000)

The 137021739104999239 is the 60 bit timestamp off the guid, output presented in UTC.

Sure ) .

And without Powershell, you can use a "normal" NT time decoder such as Decode
http//www.digital-detective.net/digital-forensic-software/free-tools/
or - better - Timelord
http//computerforensics.parsonage.co.uk/timelord/timelord.htm
together with "plain" calculator.

Get the relevant part from
37D54FD4-D1EB-11E6-B0C6-001FC6BB76CE
37D54FD4-D1EB-11E6
make it a BIG Endian hex number
11E6D1EB37D54FD4
remove the leading 1
01E6D1EB37D54FD4
subtract from it
146BF33E42C000<- this is (17+30+31+365*18+5)=6653 days expressed in 100 nanoseconds, i.e. multiplied by (60 * 60 * 24) and by (1000*1000*10) per RFC 4122
obtain
01D265F7F9928FD4
use either Timelord or Decode to obtain
2017-01-03 19.31.26.5625044
or
mar, 03 gennaio 2017 19.31.26 UTC

As a side-side note, and JFYI 😉 , not all RFC's are to be taken seriously 😯 , RFC 2324
https://tools.ietf.org/html/rfc2324
and its extension RFC 7168
https://tools.ietf.org/html/rfc7168
must be taken with a grain of salt …
More here, including the evil bit experiment
https://blog.benjojo.co.uk/post/evil-bit-RFC3514-real-world-usage

jaclaz