Mac Address

This is a very old thread, but I have some information to share about the topic

1. When a kernel is generating a UUID, it generates a version 1 UUID (the version 1 is used even in Windows 10), see RFC 4122. Such UUIDs can be found in NTFS (in the object ID), in LNK files (copied from the object ID), in registry files (there are three UUIDs in the base block, most likely not generated on the target machine).
2. A version 1 UUID contains two artifacts the node ID and the timestamp.
3. The node ID (6 bytes) contains a MAC address of the machine used to generate that UUID. When a MAC address isn't available, random bytes or fixed bytes are used instead (see below).
4. The timestamp refers to the moment when the UUID was stored in the cache (when a kernel is generating a UUID, it pulls the next available UUID from the cache, and if the cache is empty, it generates a new bunch of UUIDs for the cache).
5. The node ID is set when the system is booting up and when a new network interface is seen. During the early stage of boot, the following fixed bytes are used (in Windows 10, other versions of Windows may have different values) 0x80 + "nonic" (ASCII). Later, this value is replaced with the node ID generated according to RFC 4122 (either a MAC address or random bytes). If a node ID contains random bytes, the first byte of the node ID has the bit 0x80 set (and a valid MAC address can't have this bit set).

5. The node ID is set when the system is booting up and when a new network interface is seen. During the early stage of boot, the following fixed bytes are used (in Windows 10, other versions of Windows may have different values) 0x80 + "nonic" (ASCII). Later, this value is replaced with the node ID generated according to RFC 4122 (either a MAC address or random bytes). If a node ID contains random bytes, the first byte of the node ID has the bit 0x80 set (and a valid MAC address can't have this bit set).

Interesting. )
Can you post a practical example?
If I get this right for *some time* at boot time the UUID's are different from what they are later?
To which UUID's (devices or *whatever*) does this apply?

Side note, I was looking for a Win32 port of Linux UUID (or a win32 tool with the same capabilities of decoding a UUID), and it wasn't easy-peasy to find one (I expected to find tens of them).
Anyway, here it is
http//winpg.jp/~saito/pg_work/OSSP_win32/

Seems like it does what it is supposed to do

C\UUID>uuid -d 83092730-6bfc-11df-b90c-806d6172696f
encode STR 83092730-6bfc-11df-b90c-806d6172696f
SIV 174176392969896765663505357727385938287
decode variant DCE 1.1, ISO/IEC 115781996
version 1 (time and node based)
content time 2010-05-30 150331.875000.0 UTC
clock 14604 (usually random)
node 806d6172696f (global unicast)
jaclaz

Can you post a practical example?

Let's look at the istat output for the file created using the latest Insider Preview version of Windows 10 on a NTFS volume

MFT Entry Header Values
Entry 41 Sequence 1
$LogFile Sequence Number 2126355
Allocated File
Links 1

Attributes
Type $STANDARD_INFORMATION (16-0) Name N/A Resident size 72
Type $FILE_NAME (48-4) Name N/A Resident size 76
Type $OBJECT_ID (64-5) Name N/A Resident size 16
Type $DATA (128-1) Name N/A Resident size 0
The UUID is 56341200-5452-99a6-11e6-7d80a6a0cf8f. The MAC address is 52-54-00-12-34-56 (this is from a QEMU VM), the bit 0x80 isn't set in the first byte (0x52).

The timestamp is 0x01e67d80a6a0cf8f (the bit 0x10 was unset in the first byte, 0x11, because it isn't a part of the timestamp, it refers to the UUID version 1). And the timestamp is 2016-09-18 091658.622145 UTC. This is two minutes before the file was created.

If I get this right for *some time* at boot time the UUID's are different from what they are later?

Yes, the node ID is different, and UUIDs will have different node IDs.

To which UUID's (devices or *whatever*) does this apply?

To all UUIDs created with the ExUuidCreate() routine. This is the default way for the kernel and drivers to generate UUIDs.

This is incredibly useful information in many ways, thank you.

If the machine has multiple MAC addresses (such as ethernet and wifi), how does ExUuidCreate() determine the MAC address to use? Or is it the "currently active/connected" one?

This is incredibly useful information in many ways, thank you.

If the machine has multiple MAC addresses (such as ethernet and wifi), how does ExUuidCreate() determine the MAC address to use? Or is it the "currently active/connected" one?

A userspace library is selecting the first network interface with a valid MAC address, then this address is used by the kernel in the ExUuidCreate() routine. I don't know the exact order of network interfaces (as seen by the kernel), so it's hard to tell what is the first network interface with a valid MAC address.

Thank you ) , but something is "queer" here. (surely I am missing something) but you seem like having the UUID "reversed".

C\>uuid -d 56341200-5452-99a6-11e6-7d80a6a0cf8f
encode STR 56341200-5452-99a6-11e6-7d80a6a0cf8f
SIV 114583972183616040164201261035256074127
decode variant reserved (NCS backward compatible)
version 9 (unknown)
content 56341200545209A611E67D80A6A0CF8F
(not decipherable unknown UUID version)


Acoording to this
http//stackoverflow.com/questions/1709600/what-kind-of-data-can-you-extract-from-a-uuid
the form is
AAAAAAAA-BBBB-CCCC-DDDD-FFFFFFFFFFFF
Where C is the version and D the variant.

I have to "invert" CCCC and DDDD to obtain a valid result

C\>uuid -d 56341200-5452-11e6-99a6-7d80a6a0cf8f
encode STR 56341200-5452-11e6-99a6-7d80a6a0cf8f
SIV 114583972183615399112733029871567032207
decode variant DCE 1.1, ISO/IEC 115781996
version 1 (time and node based)
content time 2016-07-27 233209.168332.8 UTC
clock 6566 (usually random)
node 7d80a6a0cf8f (global multicast)
but of course MAC and date are way off your results… 😯
A visual representation of the algorithm is here
http//rpbouman.blogspot.it/2014/06/mysql-extracting-timstamp-and-mac.html

To obtain your results I have to "invert" wholly the UUID
C\>uuid -d a6a0cf8f-7d80-11e6-99a6-525400123456
encode STR a6a0cf8f-7d80-11e6-99a6-525400123456
SIV 221486824624917256024806663493807912022
decode variant DCE 1.1, ISO/IEC 115781996
version 1 (time and node based)
content time 2016-09-18 091658.622145.5 UTC
clock 6566 (usually random)
node 525400123456 (local unicast)
jaclaz

Thank you ) , but something is "queer" here. (surely I am missing something) but you seem like having the UUID "reversed".

C\>uuid -d 56341200-5452-99a6-11e6-7d80a6a0cf8f
encode STR 56341200-5452-99a6-11e6-7d80a6a0cf8f
SIV 114583972183616040164201261035256074127
decode variant reserved (NCS backward compatible)
version 9 (unknown)
content 56341200545209A611E67D80A6A0CF8F
(not decipherable unknown UUID version)


Acoording to this
http//stackoverflow.com/questions/1709600/what-kind-of-data-can-you-extract-from-a-uuid
the form is
AAAAAAAA-BBBB-CCCC-DDDD-FFFFFFFFFFFF
Where C is the version and D the variant.

I have to "invert" CCCC and DDDD to obtain a valid result

C\>uuid -d 56341200-5452-11e6-99a6-7d80a6a0cf8f
encode STR 56341200-5452-11e6-99a6-7d80a6a0cf8f
SIV 114583972183615399112733029871567032207
decode variant DCE 1.1, ISO/IEC 115781996
version 1 (time and node based)
content time 2016-07-27 233209.168332.8 UTC
clock 6566 (usually random)
node 7d80a6a0cf8f (global multicast)
but of course MAC and date are way off your results… 😯
A visual representation of the algorithm is here
http//rpbouman.blogspot.it/2014/06/mysql-extracting-timstamp-and-mac.html

To obtain your results I have to "invert" wholly the UUID
C\>uuid -d a6a0cf8f-7d80-11e6-99a6-525400123456
encode STR a6a0cf8f-7d80-11e6-99a6-525400123456
SIV 221486824624917256024806663493807912022
decode variant DCE 1.1, ISO/IEC 115781996
version 1 (time and node based)
content time 2016-09-18 091658.622145.5 UTC
clock 6566 (usually random)
node 525400123456 (local unicast)
jaclaz

This is a known issue with many tools displaying a UUID using different endianness assumptions.

This is a known issue with many tools displaying a UUID using different endianness assumptions.

But isn't there a "right" one (according to RFC4122)?

The istat tool you used is seemingly providing not a UUID but a "reversed" one, since it calls it "object ID" it may also be fine (but it makes little sense anyway) but when calling it a UUID one needs to "reverse" it.

I know I am picky, but you cannot really say
"The UUID is 56341200-5452-99a6-11e6-7d80a6a0cf8f."
as that is not a UUID, the UUID is (maybe) a6a0cf8f-7d80-11e6-99a6-525400123456, and the way it is "reversed" is (at least to me) not "immediate" or "obvious".

Some fields seem like being inverted due to the wrong endianness, but other ones are the same.

AAAAAAAA-BBBB-CCCC-DDDD-FFFFGGGGGGGG
a6a0cf8f-7d80-11e6-99a6-525400123456

RRRRRRRR RRRR SSSS-SSSS-SSSSRRRRRRRR
GGGGGGGG-FFFF-DDDD-CCCC-BBBBAAAAAAAA
56341200-5452-99a6-11e6-7d80a6a0cf8f

Maybe (since the tool is written by Brian Carrier) it could be possible to let him know and (maybe) he will add a line to the output with the actual UUID? ?
What would be the right way to contact him?

jaclaz

UUID is just a 16-byte value. Printing its bytes in the hexdump-like style (as is, without rotating the bytes) is okay. Rotating the bytes is okay too -)