什么是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中的底层结构
网友评论