http://www.cocoachina.com/mac/20150122/10988.html
http://www.reinterpretcast.com/hello-world-mach-o
很多朋友都知道，在Windows上exe是可直接执行的文件扩展名，而在Linux（以及很多版本的Unix）系统上ELF是可直接执行的文件格式，那么在苹果的操作系统上又是怎样的呢？在iOS（和Mac OS X）上，主要的可执行文件格式是Mach-O格式。本文就关于iOS上的可执行文件和Mach-O格式做一个简要整理。
Mach-O格式是iOS系统上应用程序运行的基础，了解Mach-O的格式，对于调试、自动化测试、安全都有意义。在了解二进制文件的数据结构以后，一切就都显得没有秘密。
0. Mach与Mach-O
这里先提醒大家一下，Mach不是Mac，Mac是苹果电脑Macintosh的简称，而Mach则是一种操作系统内核。Mach内核被NeXT公司的NeXTSTEP操作系统使用。在Mach上，一种可执行的文件格是就是Mach-O（Mach Object file format）。1996年，乔布斯将NeXTSTEP带回苹果，成为了OS X的内核基础。所以虽然Mac OS X是Unix的“后代”，但所主要支持的可执行文件格式是Mach-O。
iOS是从OS X演变而来，所以同样是支持Mach-O格式的可执行文件。
1. iOS可执行文件初探
作为iOS客户端开发者，我们比较熟悉的一种文件是ipa包（iPhone Application）。但实际上这只是一个变相的zip压缩包，我们可以把一个ipa文件直接通过unzip命令解压。
解压之后，会有一个Payload目录，而Payload里则是一个.app文件，而这个实际上又是一个目录，或者说是一个完整的App Bundle。
在这个目录中，里面体积最大的文件通常就是和ipa包同名的一个二进制文件。找到它，我们用file命令来看一下这个文件的类型：
|
1
2
3
|
XXX: Mach-O universal binary with 2 architecturesXXX (for architecture armv7): Mach-O executable armXXX (for architecture armv7s): Mach-O executable arm |
由此看来，这是一个支持armv7和armv7s两种处理器架构的通用程序包，里面包含的两部分都是Mach-O格式。
对于一个二进制文件来讲，每个类型都可以在文件最初几个字节来标识出来，即“魔数”。比如PNG图片的最初几个字节是211 P N G 32 （89 50 4E 47 0D 0A 1A 0A）。我们再来看下这个Mach-O universal binary的:
|
1
|
0000000 ca fe ba be 00 00 00 02 00 00 00 0c 00 00 00 09 |
没错，开始的4个字节是cafe babe，即“Cafe baby”。了解Java或者说class文件格式的同学可能会很熟悉，这也是.class文件开头的“魔数”，但貌似是Mach-O在更早的时候就是用了它。在OS X上，可执行文件的标识有这样几个魔数（也就是文件格式）：
cafebabe
feedface
feadfacf
还有一个格式，就是以#!开头的脚本
cafebabe就是跨处理器架构的通用格式，feedface和feedfacf则分别是某一处理器架构下的Mach-O格式，脚本的就很常见了，比如#!/bin/bash开头的shell脚本。
这里注意一点是，feedface和cafebabe的字节顺序不同，我们可以用lipo把上面cafebabe的文件拆出armv7架构的，看一下开头的几个字节：
0000000 ce fa ed fe 0c 00 00 00 09 00 00 00 02 00 00 00
2. Mach-O格式
接下来我们再来看看这个Mach-O格式到底是什么样的格式。我们可以通过二进制查看工具查看这个文件的数据，结果发现，不是所有数据都是相连的，而是被分成了几个段落。
在一位叫做JOE SAVAGE的老兄发布的图片上来看，Mach-O的文件数据显现出来是这个样子的：
(图形化的Mach-O文件数据)
大家可以对数据的分布感受下。
虽然被五颜六色的标记出来，可能这还不是特别直接。再来引用苹果官方文档的示意图：
(Mach-O文件格式基本结构)
从这张图上来看，Mach-O文件的数据主体可分为三大部分，分别是头部（Header）、加载命令（Load commands）、和最终的数据（Data）。
回过头来，我们再看上面那张图，也许就都明白了。黄色部分是头部、红色是加载命令、而其它部分则是被分割成Segments的数据。
3. Mach-O头部
这里，我们用otool来看下Mach-O的头部信息，得到：
|
1
2
|
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags 0xfeedface 12 9 0x00 2 45 4788 0x00218085 |
更详细的，我们可以通过otool的V参数得到翻译版：
|
1
2
3
|
Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags MH_MAGIC ARM V7 0x00 EXECUTE 45 4788 NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE |
前面几个字段的意义，上下对比就能看懂，我这里主要说下这样几个字段：
filetype，这个可以有很多类型，静态库（.a）、单个目标文件（.o）都可以通过这个类型标识来区分。
ncmds和sizeofcmds，这个cmd就是加载命令，ncmds就是加载命令的个数，而sizeofcmds就是所占的大小。
flags里包含的标记很多，比如TWOLEVEL是指符号都是两级格式的，符号自身+加上自己所在的单元，PIE标识是位置无关的。
4. 加载命令
上面头部中的数据已经说明了整个Mach-O文件的基本信息，但整个Mach-O中最重要的还要数加载命令。它说明了操作系统应当如何加载文件中的数据，对系统内核加载器和动态链接器起指导作用。一来它描述了文件中数据的具体组织结构，二来它也说明了进程启动后，对应的内存空间结构是如何组织的。
我们可以用otool -l xxx来看一个Mach-O文件的加载命令：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
Load command 0 cmd LC_SEGMENT cmdsize 56 segname __PAGEZERO vmaddr 0x00000000 vmsize 0x00004000 fileoff 0 filesize 0 maxprot --- initprot --- nsects 0 flags (none)Load command 1 cmd LC_SEGMENT cmdsize 736 segname __TEXT vmaddr 0x00004000 vmsize 0x00390000 fileoff 0 filesize 3735552 maxprot r-x initprot r-x nsects 10 flags (none)Section sectname __text segname __TEXT addr 0x0000b0d0 size 0x0030e7f4 |
上面这段是执行结果的一部分，是加载PAGE_ZERO和TEXT两个segment的load command。PAGE_ZERO是一段“空白”数据区，这段数据没有任何读写运行权限，方便捕捉总线错误（SIGBUS）。TEXT则是主体代码段，我们注意到其中的r-x，不包含w写权限，这是为了避免代码逻辑被肆意篡改。
我再提一个加载命令，LC_MAIN。这个加载指令，会声明整个程序的入口地址，保证进程启动后能够正常的开始整个应用程序的运行。
除此之外，Mach-O里还有LC_SYMTAB、LC_LOAD_DYLIB、LC_CODE_SIGNATURE等加载命令，大家可以去官方文档查找其含义。
至于Data部分，在了解了头部和加载命令后，就没什么特别可说的了。Data是最原始的编译数据，里面包含了Objective-C的类信息、常量等。
本文是对Mach-O文件格式的一个理解小结，希望能够抛砖引玉，帮助各位朋友把握可执行文件的主题脉络，进而解决各类问题。
参考：