GUIDs and Endianness: {Endi-an-ne-ssInGUID} OR idnE-na-en-ssInGUID?

I have recently received a couple inquiries regarding theway in which GUIDs are represented, how they are stored, how they aretransferred over the wire and how endianness impacts on them so I decided topost a little blog entry to share a couple details and examples.

GUIDs are described in [MS-DTYP] Section2.3.4 and that’s where the 3 representations for GUIDs are explained asfollows:

RPC IDL Representation:

typedef struct {

unsigned long Data1;

unsigned short Data2;

unsigned short Data3;

byte Data4[8];

} GUID,

UUID,

*PGUID;

Data1: This member is generally treated as an opaque value. This member isequivalent to the time_low field of a DCE UUID ([C706] section A.1).

Data2: This member is generally treated as an opaque value. This member isequivalent to the time_mid field of a DCE UUID ([C706] section A.1).

Data3: This member is generally treated as an opaque value. This member isequivalent to the time_hi_and_version field of a DCE UUID ([C706] section A.1).

Data4: This array is generally treated as a sequence of opaque values. Thismember is equivalent to the following sequence of fields of a DCE UUID ([C706] section A.1) inthis order: clock_seq_hi_and_reserved, clock_seq_low, and the sequence of bytesin the node field.

Packet Representation:

Data1(4 bytes): The value of the Data1 member (section 2.3.4), in little-endian byte order.

Data2(2 bytes): The value of the Data2 member (section 2.3.4), in little-endian byte order.

Data3(2 bytes): The value of the Data3 member (section 2.3.4), in little-endian byte order.

Data4(8 bytes): The value of the Data4 member (section 2.3.4), in little-endian byte order.

Curly Braced String Representation:

{f81d4fae-7dec-11d0-a765-00a0c91e6bf6}

If you are using GUIDs for your own client/serverapplication development, you can transfer/store them in any way, shape or formsince you are in charge of the encoding/decoding at both ends and you canmanipulate the data with your own rules.

It is always a good idea to follow standards but that’s apersonal call that you, as the developer, have to make.

However, if you are planning to interoperate with othersystems, you need to be aware of the representation that different protocolsand implementations are using when dealing with GUIDs.

Because of that, things may get a little confusing whenstoring those GUIDs into a file or transferring them through the network sincethe endianness varies depending on the GUID representation being used.

These examples should help you out in representing the GUIDsin the right way:

When using “Curly Braced String Representation”:

Strings are notaffected by endianness since they are represented as an array of individualbytes.

Big endian: {f81d4fae-7dec-11d0-a765-00a0c91e6bf6}

Little endian: {f81d4fae-7dec-11d0-a765-00a0c91e6bf6}

When using “RPC IDL Representation” OR “PacketRepresentation”:

As GUIDs in theserepresentations are composed of 4 different data elements, we need to becareful and treat each one accordingly.

Data1 (4 bytes)

Data2 (2 bytes)

Data3 (2 bytes)

Data4 (array of [8]one byte elements)

Big endian: f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Little endian: ae4f1df8-ec7d-d011-a765-00a0c91ebf6

Note that each data element is treated individually.

Data1 being 4 bytes long goes from Byte1Byte2Byte3Byte4 toByte4Byte3Byte2Byte1.

Data2 being 2 bytes long goes from Byte1Byte2 to Byte2Byte1.

Data3 being 2 bytes, is treated in the same way as Data2.

Data4 stays unaltered as it is represented as an array of 8individual bytes.

I hope that these examples can save you some time and debuggingefforts!