Parsing dSYM (Mach-O) File. Issue with Endianness

Question

I'm trying to write a simple parser for the mach-o file that is included inside the dSYM file. When I open the file on a hex editor (Hex Fiend or Hex dump on TextWrangler). I see something like this.

CEFAEDFE 0C000000 0B000000 0A000000 07000000 3C0D0000 
00000000 1B000000 18000000 A04EF320 E8603B93 AB88123C 
06AC3E9B ...

The first value CEFAEDFE is just FEEDFACE backwards which is the MH_MAGIC number. Actually, it is MH_CIGMA since it is backwards. This makes me thing that the rest of the info is little endian: the least significant byte first. In the case of 0xFEEDFACE, the least significant byte is 0xCE, which is first in my sample above, then the rest of the bytes.

So I carry on inspecting the rest of the integers (4 bytes). After rearranging them so they are properly formatted (i.e. 0C000000 becomes 0000000C), we have:

0000000C is the CPU type which is CPU_TYPE_ARM

0000000B is the CPU subtype which is CPU_SUBTYPE_ARM_V7S

0000000A is the filetype wich is MH_DSYM

00000007 is the number of load commands

00000D3C is the number of bytes occupied by the load commands

00000000 are the flags (no flags)

0000001B is the load command LC_UUID indicating that this LC contains the UUID

00000018 size of the load command which is 0x18 = 24 bytes (command [4 bytes] + size [4 bytes] + UUID [16 bytes])

Now this is where it gets weird and where my questions come.

Since the info is little endian, I thought the UUID (the following 16 bytes) should be rearranged "backwards" like this: 9B3EAC06-3C1288AB-933B60E8-20F34EA0. However, when I use dwarfdump to get the UUID (dwarfdump --uuid TestApp.app.dSYM/) I get this:

UUID: A04EF320-E860-3B93-AB88-123C06AC3E9B (armv7s) TestApp.app.dSYM/Contents/Resources/DWARF/TestApp

Why is this in big endian order? Why is it printed by dwarfdump in the same order that I see the bytes in Hex Fiend?

What am I missing?

Thanks in advance for your help or suggestions.

Answer 1

UUIDs are defined by rfc4122 to be in "network byte order", also known as big-endian.

So, yes you need to read/write them that way even in otherwise little-endian structures.