如何从目标文件中读取Mach-O头？
我花了几天时间试验assembly，现在了解assembly和机器代码之间的关系（在OSX上通过NASM使用x86，阅读英特尔文档 ）。
现在我试图理解链接器如何工作的细节，特别是想要了解Mach-O目标文件的结构，从Mach-O头开始。
我的问题是，你能否将下面的Mach-O标头映射到otool命令输出（显示标题，但它们的格式不同）？
这个问题的一些原因包括：
- 它将帮助我看到“Mach-O头的结构”上的文档如何在真实世界的目标文件中查看。
- 它将简化理解的路径，因此我和其他新人不必花费很多时间或几天想知道“他们是指这个还是这个 ”类型的东西。 如果没有以前的经验，很难将一般的Mach-O文档精神翻译成现实世界中的实际目标文件。
下面我展示了我尝试从真实对象文件解码Mach-O头的示例和过程。 在下面的描述中，我试图显示出现的所有小/微问题的提示。 希望这将提供一种对新手如此混淆的感觉。
例
从名为example.c的基本C文件开始：
#include int main() { printf("hello world"); return 0; }
用gcc example.c -o example.out编译它，它给出：
cffa edfe 0700 0001 0300 0080 0200 0000 1000 0000 1005 0000 8500 2000 0000 0000 1900 0000 4800 0000 5f5f 5041 4745 5a45 524f 0000 0000 0000 0000 0000 0000 0000 0000 0000 0100 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1900 0000 2802 0000 5f5f 5445 5854 0000 0000 0000 0000 0000 0000 0000 0100 0000 0010 0000 0000 0000 0000 0000 0000 0000 0010 0000 0000 0000 0700 0000 0500 0000 0600 0000 0000 0000 5f5f 7465 7874 0000 0000 0000 0000 0000 5f5f 5445 5854 0000 0000 0000 0000 0000 400f 0000 0100 0000 2d00 0000 0000 0000 400f 0000 0400 0000 0000 0000 0000 0000 0004 0080 0000 0000 0000 0000 0000 0000 5f5f 7374 7562 7300 0000 0000 0000 0000 5f5f 5445 5854 0000 0000 0000 0000 0000 6e0f 0000 0100 0000 0600 0000 0000 0000 6e0f 0000 0100 0000 0000 0000 0000 0000 0804 0080 0000 0000 0600 0000 0000 0000 5f5f 7374 7562 5f68 656c 7065 7200 0000 ... 531 total lines of this
运行otool -h example.out ，它打印：
example.out: Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags 0xfeedfacf 16777223 3 0x80 2 16 1296 0x00200085
研究
为了理解Mach-O文件格式，我发现这些资源很有帮助：
- https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachORuntime/index.html#//apple_ref/doc/uid/TP40000895
- https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachORuntime/index.html
- https://www.mikeash.com/pyblog/friday-qa-2012-11-30-lets-build-a-mach-o-executable.html
- http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/EXTERNAL_HEADERS/mach-o/loader.h
- http://www.opensource.apple.com/source/dtrace/dtrace-78/head/arch.h
- http://www.opensource.apple.com/source/xnu/xnu-792.13.8/osfmk/mach/machine.h
来自opensource.apple.com的最后3个包含所有常量，例如：
#define MH_MAGIC_64 0xfeedfacf /* the 64-bit mach magic number */ #define MH_CIGAM_64 0xcffaedfe /* NXSwapInt(MH_MAGIC_64) */ ... #define CPU_TYPE_MC680x0 ((cpu_type_t) 6) #define CPU_TYPE_X86 ((cpu_type_t) 7) #define CPU_TYPE_I386 CPU_TYPE_X86 /* compatibility */ #define CPU_TYPE_X86_64 (CPU_TYPE_X86 | CPU_ARCH_ABI64)
Mach-O头的结构如下所示：
struct mach_header_64 { uint32_t magic; /* mach magic number identifier */ cpu_type_t cputype; /* cpu specifier */ cpu_subtype_t cpusubtype; /* machine specifier */ uint32_t filetype; /* type of file */ uint32_t ncmds; /* number of load commands */ uint32_t sizeofcmds; /* the size of all the load commands */ uint32_t flags; /* flags */ uint32_t reserved; /* reserved */ };
鉴于此信息，目标是在example.out对象文件中找到Mach-O标头的每个部分。
第一：找到“神奇”的数字
鉴于这个例子和研究，我能够确定Mach-O标题的第一部分，即“神奇数字”。 那很酷。
但这不是一个简单的过程。 以下是为了弄清楚这一点而必须收集的信息。
-
otool输出的第一列显示“魔法”为0xfeedfacf。 - Apple Mach-O文档说标题应该是
MH_MAGIC或MH_CIGAM（相反的“魔术”）。 所以通过google在mach-o / loader.h中找到了那些。 由于我使用的是64位架构而不是32位，因此使用了MH_MAGIC_64（0xfeedfacf）和MH_CIGAM_64（0xcffaedfe）。 - 查看
example.out文件，前8个hex代码是cffa edfe，匹配MH_CIGAM_64！ 它有一种不同的格式会让你失望，但是它们是两种不同的hex格式，足以让我们看到连接。 它们也是相反的。
这里有3个数字，足以弄清楚幻数是多少：
0xcffaedfe // value from MH_CIGAM_64 0xfeedfacf // value from otool cffa edfe // value in example.out
所以这很令人兴奋！ 仍然不能完全确定我是否能就这些数字得出正确的结论，但希望如此。
下一页：查找cputype
现在它开始变得混乱。 以下是需要将它们组合在一起以便几乎理解它的部分，但这是我到目前为止所处的位置：
-
otool显示16777223。 这个苹果堆栈交换问题提供了一些如何理解这一点的提示。 - 在mach / machine.h中找到
CPU_TYPE_X86_64，并且必须进行多次计算才能计算出它的值。
以下是计算CPU_TYPE_X86_64值的相关常量：
#define CPU_ARCH_ABI64 0x01000000 /* 64 bit ABI */ #define CPU_TYPE_X86 ((cpu_type_t) 7) #define CPU_TYPE_I386 CPU_TYPE_X86 /* compatibility */ #define CPU_TYPE_X86_64 (CPU_TYPE_X86 | CPU_ARCH_ABI64)
所以基本上：
CPU_TYPE_X86_64 = 7 BITWISEOR 0x01000000 // 16777223
这个数字16777223与16777223相匹配，很好！
接下来，尝试在example.out找到该数字，但它不存在，因为这是一个十进制数。 我刚刚在JavaScript中将其转换为hex，其中
> (16777223).toString(16) '1000007'
所以不确定这是否是生成hex数的正确方法，尤其是与Mach-O目标文件中的hex数相匹配的数字。 1000007也只有7个数字 ，所以不知道你是否应该“填充”它或什么的。
无论如何，你看到这个数字example.out ，就在幻数之后：
0700 0001
嗯，他们似乎有点相关：
0700 0001 1000007
看起来在1000007的末尾添加了0 ，并且它被颠倒了。
题
在这一点上，我想问这个问题，已经花了几个小时来达到这一点。 Mach-O头的结构如何映射到实际的Mach-O目标文件？ 您能否在上面的example.out文件中显示标题的每个部分，并简要说明原因？
令你困惑的部分原因是字节序 。 在这种情况下，标头以平台的本机格式存储。 与Intel兼容的平台是little-endian系统，这意味着多字节值的最低有效字节首先在字节序列中。
因此，字节序列07 00 00 01 ，当被解释为小端32位值时，对应于0x01000007 。
解释结构时需要了解的另一件事是每个字段的大小。 所有uint32_t字段都非常简单。 它们是32位无符号整数。
cpu_subtype_t和cpu_subtype_t都在您链接的machine.h中定义，等同于integer_t 。 integer_t被定义为等于/usr/include/mach/i386/vm_types.h中的int 。 OS X是一个LP64平台，这意味着long s和指针对架构敏感（32-与64位），但int不是。 它总是32位。
因此，所有字段的大小都是32位或4字节。 由于有8个字段，因此总共32个字节。
从您的原始hexdump，这是与标题对应的部分：
cffa edfe 0700 0001 0300 0080 0200 0000 1000 0000 1005 0000 8500 2000 0000 0000
按字段划分：
struct mach_header_64 { uint32_t magic; cf fa ed fe -> 0xfeedfacf cpu_type_t cputype; 07 00 00 01 -> 0x01000007 cpu_subtype_t cpusubtype; 03 00 00 80 -> 0x80000003 uint32_t filetype; 02 00 00 00 -> 0x00000002 uint32_t ncmds; 10 00 00 00 -> 0x00000010 uint32_t sizeofcmds; 10 05 00 00 -> 0x00000510 uint32_t flags; 85 00 20 00 -> 0x00200085 uint32_t reserved; 00 00 00 00 -> 0x00000000 };
MAGIC或CIGAM为您提供文件中使用的字节顺序的提示。 当您将前四个字节读为cffaedfe这意味着您应该解释小端的任何4个字节。 意味着你首先用单位，然后是第十，等等来编写数字。所以，当你读到07000001它代表数字01000007，这正是你所等待的（1000007），除了前导0.我建议你阅读有关字节排序的内容？