最近开始研究 iOS 逆向的相关知识,并且使用 MonkeyDev 对 WeChat 进行了实战。这里我放出后期会持续更新的个人项目 WeCheat。在逆向专题真正开始之前,需要系统的学习一些软件内幕知识。这篇文章将从二进制格式开始讲起,并探秘 Mach-O 文件格式内容。
进程与二进制格式
进程在众多操作系统中都有提及,它是作为一个正在执行的程序的实例,这是 UNIX 的一个基本概念。而进程的出现是特殊文件在内存中加载得到的结果,这种文件必须使用操作系统可以认知的格式,这样才对该文件引入依赖库,初始化运行环境以及顺利地执行创造条件。
Mach-O(Mach Object File Format)是 macOS 上的可执行文件格式,类似于 Linux 和大部分 UNIX 的原生格式 ELF(Extensible Firmware Interface)。为了更加全面的了解这块内容,我们看一下 macOS 支持的三种可执行格式:解释器脚本格式、通用二进制格式和 Mach-O 格式。
可执行格式 | magic | 用途 |
---|---|---|
脚本 | \x7FELF |
主要用于 shell 脚本,但是也常用语其他解释器,如 Perl, AWK 等。也就是我们常见的脚本文件中在 #! 标记后的字符串,即为执行命令的指令方式,以文件的 stdin 来传递命令 |
通用二进制格式 | 0xcafebabe 0xbebafeca |
包含多种架构支持的二进制格式,只在 macOS 上支持 |
Mach-O | 0xfeedface (32 位)0xfeedfacf (64 位) |
macOS 的原生二进制格式 |
通用二进制格式(Universal Binary)
这个格式在有些资料中也叫胖二进制格式(Fat Binary),Apple 提出这个概念是为了解决一些历史原因,macOS(更确切的应该说是 OS X)最早是构建于 PPC 架构之上,后来才移植到 Intel 架构(从 Mac OS X Tiger 10.4.7 开始),通用二进制格式的二进制文件可以在 PPC 和 x86 两种处理器上执行。
说到底,通用二进制格式只不过是对多架构的二进制文件的打包集合文件,而 macOS 中的多架构二进制文件也就是适配不同架构的 Mach-O 文件。
Fat Header 的数据结构在 <mach-o/fat.h>
头文件中有定义,可以参看 /usr/include/mach-o/fat.h
找到定义头:
对于 cputype
和 cpusubtype
两个字段这里不讲述,可以参看 /usr/include/mach/machine.h
头中对其的定义,另外 Apple 官方文档中也有简单的描述。
在 fat_header
中,magic
也就是我们之前在表中罗列的 magic 标识符,也可以类比成 UNIX 中 ELF 文件的 magic 标识。加载器会通过这个符号来判断这是什么文件,通用二进制的 magic 为 0xcafebabe
。nfat_arch
字段指明当前的通用二进制文件中包含了多少个不同架构的 Mach-O 文件。fat_header
后会跟着多个 fat_arch
,并与多个 Mach-O 文件及其描述信息(文件大小、CPU 架构、CPU 型号、内存对齐方式)相关联。
这里可以通过 file
命令来查看简要的架构信息,这里以 iOS 平台 WeChat 4.5.1 版本为例:
进一步,也可以使用 otool
工具来打印其 fat_header
详细信息:
之后我们用 Synalyze It! 来查看 WeChat 的 Mach64 Header 的效果:
- 从第一个段中得到
magic = 0xcafebabe
,说明是FAT_MAGIC
。 - 第二段中所存储的字段为
nfat_arch = 0x00000002
,说明该 App 中包含了两种 CPU 架构。 - 后续的则是
fat_arch
结构体中的内容,cputype(0x0000000c)
、cpusubtype(0x00000009)
、offset(0x00004000)
、size(0x03505C00)
等等。需要臧帅闯是如果只含有一种 CPU 架构,是没有 fat 头定义的,这部分则可跳过,从而直接过去arch
数据。
Mach-O 文件格式
由上所知一个通用二进制格式包含了很多个 Mach-O 文件格式,下面我们来具体说说这个格式。Mach-O 文件格式在官方文档中有一个描述图,是很多教程中都引用到的,我重新绘制了一版更清晰的:
可以看的出 Mach-O 主要由 3 部分组成:
- Mach-O 头(Mach Header):这里描述了 Mach-O 的 CPU 架构、文件类型以及加载命令等信息;
- 加载命令(Load Command):描述了文件中数据的具体组织结构,不同的数据类型使用不同的加载命令表示;
- 数据区(Data):Data 中每一个段(Segment)的数据都保存在此,段的概念和 ELF 文件中段的概念类似,都拥有一个或多个 Section ,用来存放数据和代码。
Mach-O 头
与 Mach-O 文件格式有关的结构体定义都可以从 /usr/include/mach-o/loader.h
中找到,也就是 <mach-o/loader.h>
头。以下只给出 64 位定义的代码,因为 32 位的区别是缺少了一个预留字段:
由于 Mach-O 支持多种类型文件,所以此处引入了 filetype
字段来标明,这些文件类型定义在 loader.h
文件中同样可以找到。
另外在 loader.h
中还可以找到 flags
中所取值的全部定义,这里只介绍常用的:
Mach-O 文件头主要目的是为加载命令提供信息。加载命令过程紧跟在头之后,并且 ncmds
和 sizeofcmds
来能个字段将会用在加载命令的过程中。
Mach-O Data
加载命令在 Mach-O 文件加载解析时,会被内核加载器或者动态链接器调用。这些指令都采用 Type-Size-Value
这种格式,即:32 位的 cmd
值(表示类型),32 位的 cmdsize
值(32 位二级制位 4 的倍数,64 位位 8 的倍数),以及命令本身(由 cmdsize
指定的长度)。内核加载器使用的命令可以参看 xnu 源码来学习,其他命令则是由动态链接器处理的。
在正式进入加载命令这一过程之前,先来学习一下 Mach-O 的 Data 区域,其中由 Segment 段和 Section 节组成。先来说 Segment 的组成,以下代码仍旧来自 loader.h
:
进而来看一下 Segment 的数据结构具体是什么样的(同样这里也只放出 64 位的代码,与 32 位的区别就是其中 uint64_t
类型的几个字段取代了原先 32 位类型字段):
部分的 Segment (主要指的 __TEXT
和 __DATA
)可以进一步分解为 Section。之所以按照 Segment -> Section 的结构组织方式,是因为在同一个 Segment 下的 Section,可以控制相同的权限,也可以不完全按照 Page 的大小进行内存对其,节省内存的空间。而 Segment 对外整体暴露,在程序载入阶段映射成一个完整的虚拟内存,更好的做到内存对齐(可以继续参考 OS X & iOS Kernel Programming 一书的第一章内容)。下面给出 Section 具体的数据结构:
下面列举一些常见的 Section。
Section | 用途 |
---|---|
__TEXT.__text |
主程序代码 |
__TEXT.__cstring |
C 语言字符串 |
__TEXT.__const |
const 关键字修饰的常量 |
__TEXT.__stubs |
用于 Stub 的占位代码,很多地方称之为桩代码。 |
__TEXT.__stubs_helper |
当 Stub 无法找到真正的符号地址后的最终指向 |
__TEXT.__objc_methname |
Objective-C 方法名称 |
__TEXT.__objc_methtype |
Objective-C 方法类型 |
__TEXT.__objc_classname |
Objective-C 类名称 |
__DATA.__data |
初始化过的可变数据 |
__DATA.__la_symbol_ptr |
lazy binding 的指针表,表中的指针一开始都指向 __stub_helper |
__DATA.nl_symbol_ptr |
非 lazy binding 的指针表,每个表项中的指针都指向一个在装载过程中,被动态链机器搜索完成的符号 |
__DATA.__const |
没有初始化过的常量 |
__DATA.__cfstring |
程序中使用的 Core Foundation 字符串(CFStringRefs ) |
__DATA.__bss |
BSS,存放为初始化的全局变量,即常说的静态内存分配 |
__DATA.__common |
没有初始化过的符号声明 |
__DATA.__objc_classlist |
Objective-C 类列表 |
__DATA.__objc_protolist |
Objective-C 原型 |
__DATA.__objc_imginfo |
Objective-C 镜像信息 |
__DATA.__objc_selfrefs |
Objective-C self 引用 |
__DATA.__objc_protorefs |
Objective-C 原型引用 |
__DATA.__objc_superrefs |
Objective-C 超类引用 |
验证实验
当了解了 Segment 和 Section 的定义之后,我们可以简单的探索一下 LC_SEGMENT
这个命令的过程。用 helloworld 来做个试验:
使用 clang -g main.cpp -o main
生成执行文件。然后拖入到 MachOView 中来查看一下加载 Segment 的结构(当然使用 Synalyze It! 也能捕捉到这些信息的,但是 MachOView 更对结构的分层更加一目了然):
在 LC_SEGMENT_64
中有四个元素,分别是 __PAGEZERO
、__TEXT
、__DATA
、__LINKEDIT
这四个 Segment。其中,__TEXT
的 __text
Section 的加载是可以验证到的,我们从 Section 的实例中取出其 addr
来对比汇编之后代码的起始地址即可。使用 otool -vt main
来获取其汇编代码:
对比 Synalyze It! 的分析结果中 SEG__TEXT.__text
中的 addr
观察:
其对应的物理地址均为 0x100000F60
,说明其 LC_SEGMENT
对于 Segment 和 Section 的加载与我们的预期完全一致。
对于 __TEXT.__stubs
的一些探究
这是对于五子棋大神的 深入剖析Macho (1) 中的过程进行再次验证。在查阅过关于 __stubs
的相关资料后还是不太理解到底是个什么东西。在知乎中有这么一个问题,其中的观点是 Stub 会根据不同的代码上下文表示的含义不同。在 wikipedia 也有一个关于 Method stub 的词条,其中的解释是这样的:
A method stub or simply stub in software development is a piece of code used to stand in for some other programming functionality. A stub may simulate the behavior of existing code (such as a procedure on a remote machine) or be a temporary substitute for yet-to-be-developed code. Stubs are therefore most useful in porting, distributed computing as well as general software development and testing.
大意就是:Stub 是指用来替换一部分功能的程序段。桩程序可以用来模拟已有程序的行为(比如一个远端机器的过程)或是对将要开发的代码的一种临时替代。
我们将 Calculator 应用拖入到 Synalyze It! 和 Hopper Disassembler 中。首先使用 Synalyze It! 来查找一个 __stubs
地址:
取出地址 0x100016450
并在 Hopper 中查找对应的代码,并以此双击进入:
到达第二幅图的位置的时候,我们发现无法继续进入,因为 _CFRelease
中的代码是没有意义的。我们拿出 0x100031000
这个首地址,在 MachOView 中查找:
发现其低 32 位的值为 0x00000010001663E
,将这个地址继续在 hopper 中搜索:
发现这一系列操作都会跳到 0x000000010001650c
这个位置,而这里就是 __TEXT.__stub_helper
的表头。
也就是说,__la_symbol_ptr
里面的所有表项的数据在开始时都会被 binding 成 __stub_helper
。而在之后的调用中,虽然依旧会跳到 __stub
区域,但是 __la_symbol_ptr
中由于在之前的调用中获取到了对应方法的真实地址,所以无需在进入 dyld_stub_binder 阶段,并直接调用函数。这样就完成了一次近似于 lazy 思想的延时 binding 过程。(这个过程可以用 lldb 来加以验证,在之后会补充。)
总结一下 Stub 机制。其实和 wikipedia
上的说法一致,设置函数占位符并采用 lazy 思想做成延迟 binding 的流程。在 macOS 中也是如此,外部函数引用在 __DATA
段的 __la_symbol_ptr
区域先生产一个占位符,当第一个调用启动时,就会进入符号的动态链接过程,一旦找到地址后,就将 __DATA
Segment 中的 __la_symbol_ptr
Section 中的占位符修改为方法的真实地址,这样就完成了只需要一个符号绑定的执行过程。