The original text comes from [Tingyun Technology Blog]: http://blog.tingyun.com/web/article/detail/1 34 1
0x01 A brief introduction to the Mach-O format
The Mach-O file format is an executable file format on OS X and iOS systems, similar to Windows PE files and Linux (other Unix like) ELF files. If you don't fully understand the Mach-O format and related content, then Digging into the xnu kernel doesn't help.
The format of the Mach-O file is shown in the following figure:
It consists of the following parts:
1. Header: Saves some basic information of Mach-O, including platform, file type, number of LoadCommands, etc.
2. LoadCommands: This section follows the Header, and the data here is used to determine the memory distribution when loading the Mach-O file.
3. Data: The specific data of each segment is stored here, which contains specific codes, data, and so on.
0x02 FAT binary data, the data structure is defined in \<mach-o/fat.h\>
1. The first segment is the magic number. Pay attention to the big and small ends here. After reading it, you need to see whether it is 0xCAFEBABE or 0xBEBAFECA (otherwise, it is thin). You need to convert the byte order of the subsequent read bytes according to this. It can be seen that the first 4 bytes are 0xBEBAFECA, which means fat.
2. The second segment is the arch count, that is, which CPU architectures are included in the App or dSYM, such as armv7, arm64, etc. In this example, it is 2 (the last 4byte 0x 00 00 00 02), indicating that two CPU architectures are included.
`sizeof(struct fat-header) = 8byte`
3. 后续段中包含cputype（0x 0C 00 00 01）、cpusubtype (0x 00 00 00 00)、offset (0x 00 10 00 00)、size(0x 00 F0 27 00)等数据，根据fat中的结构定义，依次读取，这里需要说明的是，如果只包含一种CPU架构的话，是没有这段fat头定义的，可以跳过这部分，直接读取Arch数据。
`sizeof(struct fat-arch) = 20byte`
4. 根据fat头中读取的offset数据，我们可以跳到文件对应的arch数据的位置，当然如果只有一种架构的话就不需要计算偏移量了。 下图给出解析的函数
0x03 Mach Header二进制数据
通过magic我们可以区分出是32-bit还是64-bit，64-bit多了4个字节的保留字段，这里同样需要注意字节序的问题，也就是判断magic，来确定是否需要转换字节序。
`sizeof(struct mach-header-64) = 32byte` ; `sizeof(struct mach-header) = 28byte`
根据mach-header与mach-header_64的定义，很明显可以看出，Headers的主要作用就是帮助系统迅速的定位Mach-O文件的运行环境，文件类型。
FileType
因为Mach-O文件不仅仅用来实现可执行文件，同时还用来实现了其他内容
1. 内核扩展
2. 库文件
3. CoreDump
4. 其它
下面是一些精彩用到的文件类型
1. MH-OBJECT 编译过程中产生的 obj文件 (gcc -c xxx.c 生成xxx.o文件)
2. MH-EXECUTABLE 可执行二进制文件 (/usr/bin/ls)
3. MH-CORE CoreDump (崩溃时的Dump文件)
4. MH-DYLIB 动态库(/usr/lib/里面的那些共享库文件)
5. MH-DYLINKER 连接器linker（/usr/lib/dyld文件）
6. MH-KEXT-BUNDLE 内核扩展文件 （自己开发的简单内核模块）
flags
Mach-O headers还包含了一些很重要的dyld的加载参数。
1. MH-NOUNDEFS 目标没有未定义的符号，不存在链接依赖
2. MH-DYLDLINK 该目标文件是dyld的输入文件，无法被再次的静态链接
3. MH-PIE 允许随机的地址空间（开启ASLR -\>Address Space Layout Randomization）
4. MH-ALLOW-STACK-EXECUTION 栈内存可执行代码，一般是默认关闭的。
5. MH-NO-HEAP-EXECUTION 堆内存无法执行代码
0x04 LoadCommands
Load Commands 直接就跟在Header后面，所有command占用内存的总和在Mach-O Header里面已经给出了。在加载过Header之后就是通过解析LoadCommand来加载接下来的数据了。定义如下：
cmd字段
根据cmd字段的类型不同，使用了不同的函数来加载。简单的列出一张表看一看在内核代码中不同的command类型都有哪些作用。
1. LC-SEGMENT；LC-SEGMENT-64 在内核中由load-segment 函数处理（将segment中的数据加载并映射到进程的内存空间去）
2. LC-LOAD-DYLINKER 在内核中由load-dylinker 函数处理（调用/usr/lib/dyld程序）
3. LC-UUID 在内核中由load-uuid 函数处理 （加载128-bit的唯一ID）
4. LC-THREAD 在内核中由load-thread 函数处理 （开启一个MACH线程，但是不分配栈空间）
5. LC-UNIXTHREAD 在内核中由load-unixthread 函数处理 （开启一个UNIX posix线程）
6. LC-CODE-SIGNATURE 在内核中由load-code-signature 函数处理 （进行数字签名）
7. LC-ENCRYPTION-INFO 在内核中由 set-code-unprotect 函数处理 （加密二进制文件）
UUID 二进制数据 128byte
UUID是16个字节（128bit）的一段数据，是文件的唯一标识，前面提到的符号化时，这个UUID必须要和App二进制文件中的UUID一致，才能被正确的符号化。dwarfdump查看的UUID就是这段数据。读取这部分数据时通过Command结构读取的，也就是第一段(0x0000001B)表示接下来的数据类型，第二段(0x00000018)数据的大小（包含Command数据）。
SymTab 二进制数据
1. 符号表数据块结构，前二段依然是Command数据。后边4段分别为符号在文件中的偏移量(0x001DF5E0)、符号个数(0x001DF5E0)、字符串在文件中的偏移量(0x0020C3A0)、字符串表大小(0x000729A8)。
2. 接下来就是读取Segment和Section数据块了，和上面读取数据块结构一样是根据Command结构读取，下图展示的Segment数据和Section数据，它们在二进制文件中它们是连续的，也就是每一条Segment数据后面会紧跟着多条对应的Section数据，Section的数据总数是通过Segment结构中的nsects决定的。
3. 这里我写了一个简单地Mach-O解析工具 [https://github.com/liutianshx2012/Tmacho](https://github.com/liutianshx2012/Tmacho)
Segment数据
加载数据时，主要加载的就是LC-SEGMET活着LC-SEGMENT_64。其他的Segment的用途在这里不做深究。
LCSEGMENT以及LC-SEGMENT-64 定义如下图。
可以看出，这里大部分的数据是用来帮助内核将Segment映射到虚拟内存的。
nsects 字段，标示了Segment中有多少secetion ，section是具体有用的数据存放的地方。
TEXT的vmaddr也就是程序的加载地址； —DWARF中表明了DWARF数据块的信息，表示dSYM是DWARF格式的数据结构。
` sizeof(struct segment-command) = 56byte ; sizeof(struct segment-command-64) = 72byte`
Section数据
从Section数据中，我们可以找到—debug-info、—debug-pubnames, —debug-line等调试信息，通过这些调试信息我们可以找到程序中符号的起始地址、变量类型等信息。如果我们要符号化的话，就可以通过解析这些数据得到我们想要的信息。
Symbol 数据
通过SymTab中的数据可以得到Symbol在文件中的位置和个数，Symbol块数据中包含了符号的起始地址、字符串的偏移量等数据，这部分数据结构可以参考\<nlist.h\> 和 \<stabl.h\>。在这部分数据全部读取后，就可以读取所有的符号数据了，也就是接下来的数据。
Symbol String 数据
1. 通过SymTab和Symbo中的数据可以得到每个符号字符串在文件中的偏移量和大小，每个符号数据是以0结尾的字符串。
2. 我们通过以上两部分数据的组合就可以得到每个symbo在程序中的加载地址了。这些数据对于以后做符号工作都非常的有帮助。
3. At this point, the reading of the header data in the dSYM file is completed. The header data has a corresponding data structure definition, which is relatively easy to read. Pay attention to the byte order when parsing the data, the difference between 32-bit and 64-bit data structure, the difference in byte length, DWARF Version differences are closely related to each data block, and a read deviation of one byte will cause subsequent data read errors.