一、什么是Mach-O文件？
Mach-O是Mach Object文件格式的缩写，是mac以及iOS上可执行文件的格式。Mach-O文件对应有多种格式：
- 目标文件
.o- 库文件：
.a静态库文件
.dylib动态库文件
.framework系统级为动态库文件，自己创建的为静态库文件- 可执行文件及
MDW.app内部的MDW文件（通用二进制文件）dyld动态链接器将依赖的动态库加载到内存.dsym符号表
在Xcode中我们可以直接创建.c文件，通过终端clang命令来对.c文件进行编译或生成可执行文件，下面看一下clang怎样使用的。
1、创建一个main.c文件如下：
#include <stdio.h>
int main(){
printf("打印：yahibo\n");
return 0;
}
2、编译文件
clang -c main.c
会生成main.o文件，该文件即为mach-o文件，通过命令file main.o查看文件信息如下：
main.o: Mach-O 64-bit object x86_64
是一个object类型的文件称为目标文件，并不是可执行文件
3、生成可执行文件
- 命令
clang main.o会生成a.out文件，即可执行文件，通过ls查看 - 命令
clang -o main main.o也会生成可执行文件main - 命令
clang -o main main.c直接根据源文件生成可执行文件main - 命令
size -x -l -m a.out查看文件信息，如下：
Segment __PAGEZERO: 0x100000000 (vmaddr 0x0 fileoff 0)
Segment __TEXT: 0x1000 (vmaddr 0x100000000 fileoff 0)
Section __text: 0x2a (addr 0x100000f50 offset 3920)
Section __stubs: 0x6 (addr 0x100000f7a offset 3962)
Section __stub_helper: 0x1a (addr 0x100000f80 offset 3968)
Section __cstring: 0x11 (addr 0x100000f9a offset 3994)
Section __unwind_info: 0x48 (addr 0x100000fac offset 4012)
total 0xa3
Segment __DATA: 0x1000 (vmaddr 0x100001000 fileoff 4096)
Section __nl_symbol_ptr: 0x10 (addr 0x100001000 offset 4096)
Section __la_symbol_ptr: 0x8 (addr 0x100001010 offset 4112)
total 0x18
Segment __LINKEDIT: 0x1000 (vmaddr 0x100002000 fileoff 8192)
total 0x100003000
4、执行文件
./a.out 或 ./main
输出：
打印：yahibo
以上步骤可以用来写c并编译执行。
多个文件是如何编译的呢？
开发中根据不同功能模块我们会分很多文件来实现，在clang中是可以对多个文件进行一次性打包，生成一个可执行文件。如下：
1、新建一个功能文件
people.c
#include <stdio.h>
void sleep(){
printf("正在睡觉\n");
}
2、在main.c中声明sleep方法并调用
void sleep();//声明方法
int main(){
printf("打印：yahibo\n");
sleep();//调用方法
return 0;
}
3、编译为可执行文件
clang -o main main.c people.c
4、执行可执行文件
./main
运行如下：
打印：yahibo
正在睡觉
二、通用二进制文件（Universal binary）
在iOS中不同手机对应着可能不同的架构，如arm64、armv7、armv7s。为了兼容不同架构的手机，苹果推出了通用二进制文件，包含了应用程序常用的这些架构，因此通用二进制文件，比单一架构二进制文件要大很多。
架构选择
arm.png
- 注意以上标记的两处取交集，来确认最终架构
-
1处默认架构为arm64、armv7 - 如果需要添加
armv7s还需要在1处添加armv7s字符
通过以上配置真实编译出来的是包含arm64、armv7架构，因为工程中使用了第三方静态库不包含armv7s因此这里配置为标准架构模式。
通用二进制文件在哪呢？
在xxx.app中的xxx黑色文件即是通用二进制文件，右键xxx.app显示包内容即可获得。
lipo命令
通过lipo命令可以查看、拆分及合并以上提出的架构，在做静态库时也会使用，来合并真机下和模拟器下的静态库，以适应不同的调试环境。
- 从
MDW.app中我获取可执行文件MDW
1、查看架构信息
lipo -info MDW
打印如下：
Architectures in the fat file: MDW are: armv7 arm64
2、拆分armv7、arm64架构
lipo MDW -thin armv7 -output MDW_armv7
lipo MDW -thin arm64 -output MDW_arm64
查看armv7信息：
lipo -info MDW_armv7
打印如下：
Non-fat file: MDW_armv7 is architecture: armv7
查看arm64信息：
lipo -info MDW_arm64
打印如下：
Non-fat file: MDW_arm64 is architecture: arm64
3、合并架构
lipo -create MDW_armv7 MDW_arm64 -output MDW_ALL
查看合并后的信息
lipo -info MDW_ALL
打印如下：
Architectures in the fat file: MDW_ALL are: armv7 arm64
产生的可执行文件如图：
mackos.png
三、Mach-O文件结构
官方图解：
structure.png
文件分为三个部分：
-
Header：包含Mach-O文件的基本信息，字节顺序、架构类型、加载指令的数量等 -
Load commands：包含区域位置、符号表、动态符号表，加载Mach-O文件时使用这里的数据确定内存分布 -
Data：数据段segement，包含具体代码、常量、类、方法等，有多个segment，每个segment有0到多个section，每个段有一个虚拟地址映射到进程的地址空间
直接使用MachOView打开MDW可执行文件，如下：
macho.png
- 胖二进制文件中包含了
armv7、arm64架构 - 通过MachOView即可查看可执行文件的所有信息
1、Header
除了以上直接查看header，还可以通过otool命令查看header信息：
otool -f MDW
打印如下：
Fat headers
fat_magic 0xcafebabe
nfat_arch 2
architecture 0
cputype 12
cpusubtype 9
capabilities 0x0
offset 16384
size 7587424
align 2^14 (16384)
architecture 1
cputype 16777228
cpusubtype 0
capabilities 0x0
offset 7618560
size 8748384
align 2^14 (16384)
或
otool -h MDW
打印：
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
0xfeedface 12 9 0x00 2 48 5080 0x00210085
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
0xfeedfacf 16777228 0 0x00 2 48 5752 0x00210085
- 以上打印的两段分别是
armv7、arm64架构下的header信息
在objc4源码loader.h文件中有mach_header的结构体定义，如下：
struct mach_header {
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 */
};
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 */
};
-
magic：魔数，确定是64位还是32位 -
cputype：cpu类型 -
cpusubtype：cpu子类型 -
filetype：Mach-O支持多种文件类型，使用filetype来标注具体文件类型 -
ncmds：加载命令的数量 -
sizeofcmds：命令区域（load commands）总的字节大小 -
flags：标识二进制文件所支持的功能，主要与系统的加载、链接有关
2、Load commands
Header之后是load commands段为加载命令段，在header结构体中有对加载命令段相关信息的描述，用于解析加载命令。在objc4源码loader.h中，有对loadcommand的定义：
struct load_command {
uint32_t cmd; /* type of load command */
uint32_t cmdsize; /* total size of command in bytes */
};
-
cmd：命令类型，针对不同架构有不同的结构（32位、64位） -
cmdsize：命令所占字节大小（32位size必须为4字节的倍数，64位size必须为8字节的倍数）
在文件中有两个结构体segment_command和segment_command_64针对不同架构的结构体，内部设置字段相同。以segment_command_64为例：
struct segment_command_64 { /* for 64-bit architectures */
uint32_t cmd; /* LC_SEGMENT_64 */
uint32_t cmdsize; /* includes sizeof section_64 structs */
char segname[16]; /* segment name */
uint64_t vmaddr; /* memory address of this segment */
uint64_t vmsize; /* memory size of this segment */
uint64_t fileoff; /* file offset of this segment */
uint64_t filesize; /* amount to map from the file */
vm_prot_t maxprot; /* maximum VM protection */
vm_prot_t initprot; /* initial VM protection */
uint32_t nsects; /* number of sections in segment */
uint32_t flags; /* flags */
};
-
cmd：加载命令类型 -
LC_SEGMENT：表示这好似一个段加载命令，需要将它加载到对应的进程空间上 -
LC_LOAD_DYLIB：这是一个需要动态加载的链接库，它使用dylib_command结构体表示 -
LC_MAIN：记录了可执行文件的主函数main()的位置，它使用entry_point_command结构体表示 -
LC_CODE_SIGNATURE：代码签名的加载命令，描述了Mach-O的代码签名信息，它属于链接信息，使用linkedit_data_command结构体表示 -
cmdsize：加载命令所占内存大小 -
segname：存放16字节大小的段名字，当前是__PAGEZERO。 -
vmaddr：段的虚拟内存起始地址 -
vmsize：段的虚拟内存大小 -
fileoff：段在文件中偏移量 -
filesize：段在文件大小 -
maxprot：段页面所需要的最高内存保护（4=r,2=w,1=x） -
initprot：段页面初始的内存保护 -
nsects：段中包含section的数量 -
flags：其他杂项标志位
在看MachOView中的loadcommands字段：
loadcommands.png
以上为是应用程序所有加载命令，通过上面流程能够看到对系统库的加载顺序。对比项目中引入的库文件，顺序是一致的，如下图：
xcode.png
以上加载命令含义如下：
-
LC_SEGMENT_64：将文件中的段映射到进程地址空间中 -
LC_DYLD_INFO_ONLY：动态链接相关信息 -
LC_SYMTAB：符号表信息，位置、偏移、数据个数，供dyld使用 -
LC_DYSYMTAB：动态符号表信息，供dyld使用 -
LC_LOAD_DYLINKER：链接器信息，记录使用那些链接器完成内核后序的加载工作 -
LC_UUID：Mach-O文件的唯一标识 -
LC_VERSION_MIN_MACOSX：支持最低操作系统版本 -
LC_SOURCE_VERSION：源代码的版本号 -
LC_MAIN：设置主线程的入口即栈大小 -
LC_LOAD_DYLIB：依赖库信息，dyld通过该命令去加载依赖库 -
LC_FUNCTION_STARTS：函数的起始地址表 -
LC_CODE_SIGNATURE：代码签名
3、Data
Data区域由Segment段和Section节组成：
segment.png
-
segment主要有__TEXT和__DATA组成 -
__text：是主程序代码 -
__stubs、__stub_helper：是动态链接的桩 -
__cstring：程序中c语言字符串 -
__const：常量
Section含义：
-
Section64(__TEXT,__objc_methname)：OC类名 -
Section64(__DATA,__objc_classlist)：OC类列表 -
Section64(__DATA,__objc_protollist)：OC原型列表 -
Section64(__DATA,__objc_imageinfo)：OC镜像信息 -
Section64(__DATA,__objc_selfrefs)：OC类自引用 -
Section64(__DATA,__objc_superrefs)：OC类超类的引用 -
Section64(__DATA,__ivar)：OC类成员变量
等等，都是通过section来对OC中的具体类别做加载的。segment段分32位和64位，字段相同，以64为例如下：
struct section_64 { /* for 64-bit architectures */
char sectname[16]; /* name of this section */
char segname[16]; /* segment this section goes in */
uint64_t addr; /* memory address of this section */
uint64_t size; /* size in bytes of this section */
uint32_t offset; /* file offset of this section */
uint32_t align; /* section alignment (power of 2) */
uint32_t reloff; /* file offset of relocation entries */
uint32_t nreloc; /* number of relocation entries */
uint32_t flags; /* flags (section type and attributes)*/
uint32_t reserved1; /* reserved (for offset or index) */
uint32_t reserved2; /* reserved (for count or sizeof) */
uint32_t reserved3; /* reserved */
};
-
sectname：是__text,就是主程序代码 -
segname：该section所属的segment名，第一个是__TEXT -
addr：当前section在内存中的起始位置 -
size：当前section所占内存大小 -
offset：当前section的文件偏移 -
align：字节大小对齐 -
reloff：重定位入口的文件偏移，0 -
nreloc：需要重定位的入口数量，0 -
flags：包含section的type和attributes -
reserved1、reserved2预留字段
四、总结
注意在Load Commands的最后一条的地址偏移，再看Data段的起始地址偏移：
loadcommands.jpg
data.jpg
-
Load Commands最后一条指令的地址偏移为：0000311C -
Data段的起始地址为：00004000
中间预留了一段空间，该处即是后面代码注入的地方，此处不是专门预留出来进行注入的，而是考虑内存对称提高代码执行效率。
