什么是Mach-O

Mach-O: Mach Object

布拉布拉.....，概念没意思，反正就是一可执行文件

ios中的常见的.o .a .dylib Framework dyld dsym 都是Mach-O

抽象概念

是一种可执行文件，用于目标代码，动态库，内核转储

每个Mach-O文件包括一个Mach-O头，一系列的载入命令，多个块

image.png

• Mach Header: 描述 Mach-O 的CPU架构、文件类型、加载命令等信息

  • Magic Number 32位/64位架构

  • File Type 文件类型 - 其实就是可执行文件

  • Number of Load Commands 加载的Commands有多少个命令

  • Size of Load Commands 加载命令的内存大小

  • Flags 标识 系统加载有没有关系/链接/两级命名空间（通过两级命名空间将符号编码成 对象:符号 的两级名字，这样不同的动态库就避免了符号冲突）....

• Load Commands: 描述文件中数据等具体组织结构，不同数据类型使用不同等加载命令表示

  • 其实就是一张包含很多内容的表，内容包括区域的位置、符号表、动态符号表等
  • LC_SEGMENT_64 将文件中(32位或64位)的段映射到进程地址空间中

    • 当然了，点开 LC_SEGMENT_64，还会看见更细节的内容，命令的执行需要依赖一些记录信息 代码 常量 其他数据类型等等 比如 LC_SEGMENT_64 类型的加载命令

    • VM Address 虚拟地址

    • VM Size 虚拟地址大小

    • File Offset 文件偏移

    • File size 文件大小

    • Maximum VM Protection 就是最大能使用的大小，因为不能操作物理内存，系统会分配一个最大的进程空间，只能通过虚拟空间 + offset的方式去映射物理内存，永远不会超过系统分配的边界

    • Number of Sections 加载进内存的section数量

- LC_DYLD_INFO_ONLY  动态链接相关信息
- LC_SYMTAB  符号地址
- LC_DYSYMTAB 动态符号表地址
- LC_LOAD_DYLINKER dyld加载
- LC_UUID 文件的UUID
- LC_VERSION_MIN_MACOSX 支持最低的操作系统版本
- LC_SOURCE_VERSION 源代码版本
- LC_MAIN 设置程序主线程的入口地址和栈大小
- LC_LOAD_DYLIB 依赖库的路径，包含三方库
- LC_FUNCTION_STARTS 函数起始地址表
- LC_CODE_SIGNATURE 代码签名

• Data: Data中每一个段(Segment)的数据保存在此，段用来存放数据和代码

  • Data 区主要就是负责代码和数据记录的

  • Mach-O 是以 Segment 这种结构来组织数据的, 一个 Segment 可以包含 0 个或多个 Section

  • Segment 中 section 就可以被解读为是代码，常量或者一些其他的数据类型

  • 在装载在内存中时，也是根据 Segment 做内存映射的

  • TEXT.text: 机器码

  • TEXT.cstring: 硬编码的字符串

  • TEXT.const: 初始化过的常量

  • DATA.data: 初始化过的可变的（静态/全局）数据

  • DATA.const: 没有初始化过的常量

  • DATA.bss: 没有初始化过的 (静态/全局)变量

  • DATA.common: 没有初始化过的符号声明

  • Section64(__TEXT,__text) 存放的就是代码的指令 汇编指令

  • Section64(__TEXT,cstring) 存放的就是硬编码的字符串

  • Section64(__DATA_CONST,__objc_classlist) OC中的类都记录在此section

  • Section64(__TEXT,__swift5_types) swift中的类都记录在此section 包含结构体 enumor 或者 类的descriptor(地址信息)

操作一番，稍微看下具体mach-o 与 实际代码中关系

目前操作的是swift代码，此篇博客重在初步感知下Mach-O，所以具体swift的类结构暂不涉及

此后会专门写博客探究源码层面的结构

image.png

拿出计算器，当前是arm架构，小端模式

image.png

得到一个地址 , 此时发现前缀是个 0x100000000 这样的地址

在ios中，这个地址是 常量数据的存放地址, 验证一下

image.png

通过lldb调试，image list，读取镜像，得到虚拟偏移首地址，这里跟 上面Mach-O PageZero中记录的虚拟内存首地址 不一样，只是此处恰好相等而已

image.png

现在用计算器中的值 减去Mach-O中读取的虚拟首地址， 得到0x3E0C，

上Mach-O Segments部分 常量Section里看下

image.png

这里读出的偏移地址 0x00AC 与 前面得到的 0x3E0C 相加，得到 0x3EB8

这个结果 加上 刚才app启动时，lldb - image list拿到的偏移地址 0x100000000

(再次注意 - 这个值跟Mach-O中 虚拟首地址不一样，只是恰好相等了而已，Mach-O中的那个值是固定的，而此处的之个虚拟首地址值每次启动app都会变,就是所谓的ASLR，随机偏移地址)

得到 0x100003EB8， 回到调试，打开汇编，读下寄存器

--- 失败，刚才调试，类没有定义方法，临时加了一个 test_func(), 只好复刻下上面的操作，有的时候，事情总出点纰漏，出错不怕，能补漏就好

复习一遍

__swift5_types 中的 基址 + 相对地址

image.png

减去 PageZero中记录的虚拟地址首地址 得到 0x3DFC

image.png

上面得到的 0x0012 的 (基址0x3E30 + ASLR(app启动内存随机偏移 0x100000000) + 4字节偏移 + 得到的0x0012) = 0x3E46

具体是不是这样呢，时间关系，下一篇博客我通过寄存器验证，然后紧接着从验证结果入手，分析swift中的底层结构