我正在尝试为dSYM文件中包含的mach-o文件编写一个简单的解析器。当我在十六进制编辑器上打开文件时（TextWrangler上的Hex Fiend或Hex dump）。我看到这样的事情。
CEFAEDFE 0C000000 0B000000 0A000000 07000000 3C0D0000
00000000 1B000000 18000000 A04EF320 E8603B93 AB88123C
06AC3E9B ...
第一个值CEFAEDFE仅向后FEEDFACE，即MH_MAGIC个数字。实际上，它是MH_CIGMA，因为它是向后的。这使我的信息的其余部分是小端：首先是最不重要的字节。在0xFEEDFACE的情况下，最低有效字节为0xCE，这是我上面的示例中的第一个，然后是其余的字节。
所以我继续检查其余的整数（4个字节）。重新排列它们以使它们格式正确（即0C000000变为0000000C）后，我们有：
<00> 0000000C是CPU类型，即CPU_TYPE_ARM <00> 0000000B是CPU子类型，即CPU_SUBTYPE_ARM_V7S0000000A是MH_DSYM
的文件类型00000007是加载命令的数量
00000D3C是加载命令占用的字节数
00000000是标志（无标志）
<00> 0000001B是加载命令LC_UUID，表示该LC包含UUID00000018加载命令的大小，即0x18 = 24字节（命令[4字节] +大小[4字节] + UUID [16字节]）
现在，这就是它变得奇怪的地方以及我的问题所在。
由于信息是小端，我认为UUID（后面的16个字节）应该“向后”重新排列，如下所示：9B3EAC06-3C1288AB-933B60E8-20F34EA0。但是，当我使用dwarfdump获取UUID（dwarfdump --uuid TestApp.app.dSYM/）时，我得到了这个：
UUID: A04EF320-E860-3B93-AB88-123C06AC3E9B (armv7s) TestApp.app.dSYM/Contents/Resources/DWARF/TestApp
为什么这是大端序？为什么它以dwarfdump打印的顺序与我在Hex Fiend中看到的字节相同？
我错过了什么？
提前感谢您的帮助或建议。