关于Mach-O类型文件那点事

Mach-O文件简介

 

Mach-O是一种文件格式，是Mach Object文件格式的缩写。

它通常应用于可执行文件，目标代码，动态库，内核转储等中。

 

Mach-O作为大部分基于Mach核心的操作系统所使用。

如：NeXTSTEP，Darwin和Mac OS X等系统使用这种格式作为其原生可执行文件，库和目标代码的格式。

 

在NeXTSTEP和Mac OS X中，可以将多个Mach-O文件组合进一个多重架构二进制文件中，以用一个单独的二进制文件支持多种架构的指令集。这种称为胖二进制文件(即：Fat binary文件)。

 

Mach-O文件类型众多，常见的一些Mach-O文件类型如下：

MH_OBJECT    目标文件，平时.o结尾的文件

MH_EXECUTE    可执行文件，我们平时编译后的包中的执行文件

MH_DYLIB    一些动态库，该文件夹下很多/usr/lib/xxx.dylib

MH_DSYM        符号文件，编译成功后XXX.app.dSYM

 

---

 

Mach-O文件结构布局

Mach-O主要有三部分组成：

Header部分主要描述当前Mach-O文件什么架构，是否Fat二进制文件，CUP类型等等；

Load commands部分主要描述：

1.Mach-O文件中在虚拟内存中空间是如何分配的，从哪个内存地址开始到哪个内存地址结束。

2.不同段在Mach-O文件中的位置，大小分布。

Data部分是描述内存如何被分配的内容。包括__TEXT, __DATA等。

Header结构描述

Fat_Arch的header结构图如下：

如果只有一种架构，那么Fat Header的地方直接就是mac_header

Load command结构描述 

为了方便管理，程序被添加到内存后是分段管理的，而每个段是如何从本地加载到内存是在LC_Type中进行描述的。

Segment的加载命令描述结构如下：

struct segment_command { /* for 32-bit architectures */
    uint32_t    cmd;        /* LC_SEGMENT */
    uint32_t    cmdsize;    /* includes sizeof section structs */
    char        segname[16];    /* segment name */
    uint32_t    vmaddr;     /* memory address of this segment */
    uint32_t    vmsize;     /* memory size of this segment */
    uint32_t    fileoff;    /* file offset of this segment */
    uint32_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 */
};

Mach-O文件中不同的内容段__TEXT, __DATA等在虚拟内存中的内存分布是用VM Address和VM Size来描述的；

在Mach-O本地文件中的空间分布是用File Offset和File Size来描述的；

而同一个Segment信息在这两个维度中的空间分配策略，是不完全相同的。

如：

__PAGEZERO段：在arm64架构size时0x100000000，在armv7架构size时0x4000。它会在虚拟内存中隔离出一大块

低地址区的内存空间。而在Mach-O文件中占据的大小为0，并没有实际的内容。当设置一个指针变量的值为NULL时，其实就是将指针指向了__PAGEZERO段这块区域。

__DATA段：在虚拟内存中的分配的空间要大于Mach-O文件中占据的大小。原因是在内存中需要预留一部分多余的空间给可以修改的全局变量或者所占空间可以变化的对象或容器使用。

 

常见的SEG类型

#define SEG_PAGEZERO    "__PAGEZERO"
#define SEG_TEXT    "__TEXT"    /* the tradition UNIX text segment */
#define SEG_DATA    "__DATA"    /* the tradition UNIX data segment */

SEG_PAGEZERO：

是一个不可读、不可写、不可执行的段。能够在空指针访问时抛异常。

SEG_TEXT：

代码段，可读、可执行。

SEG_DATA：

数据段，可读、可写。

 

__PAGEZERO段描述

__TEXT段加载描述

 __DATA段加载描述

根据__TEXT段的加载描述， 得到__DATA段内容的偏移地址如下：

---

 

ASLR：内存空间布局随机化

Mach-O文件利用两种空间描述，来表达自己在Mach-O文件和虚拟内存中不同空间的分配方式

每个app都有自己独立的虚拟内存，这个虚拟内存只存在与自己的Mach-O文件的load commands的描述中。

当app执行时，会被系统映射到实际的物理内存中。

 

程序一旦编译完成，函数就安静的放在了__TEXT段， 全局变量就安静的放在了__DATA段上。等用户点击后，才被加载到内存。

在iOS逆向中，通过Hopper工具反汇编可以看到函数的虚拟内存地址，但是Hopper中展示的内存地址是没有ASLR的。

想要得到函数的真正函数地址，还需要得到当前Mach-O文件在内存中的ASLR偏移值。

 

当app被加载到内时，系统会自动进行ASLR,在__PAGEZERO端的上面随机多出一段空间作为偏移，使得Mach-O文件的整个虚拟内存向下整体(包括堆，栈，共享库映射等线性布局)偏移。从而可以让生成的函数内存地址不断变动。这样可以提高黑客的破解难道。

那如何得到当前Mach-O文件的ASLR偏移值呢？

通过lldb调试器可以查到。

通过lldb调试器的mach-o文件列表查询命令，-o查询所有使用的mach-o文件包括dyld链接编辑器、app的mach-o文件、dylib库。

可以查询到app文件对应Mach-O的所包含的所有Mach-O文件。

//lldb调试器命令，打印app文件对应Mach-O文件的所包含的所有Mach-O文件。

image list -o -f

结果如下：

(lldb) image list -o -f
[  0] 0x0000000000558000 /Users/zhoufei/Library/Developer/Xcode/DerivedData/SorterAndFilter-gcqrjckyrquurscwtbwpiaeebgzj/Build/Products/Release-iphoneos/SorterAndFilter.app/SorterAndFilter
[  1] 0x0000000100800000 /Users/zhoufei/Library/Developer/Xcode/iOS DeviceSupport/11.4 (15F79)/Symbols/usr/lib/dyld
[  2] 0x0000000001190000 /Users/zhoufei/Library/Developer/Xcode/iOS DeviceSupport/11.4 (15F79)/Symbols/System/Library/Frameworks/Foundation.framework/Foundation
[  3] 0x0000000001190000 /Users/zhoufei/Library/Developer/Xcode/iOS DeviceSupport/11.4 (15F79)/Symbols/System/Library/Frameworks/UIKit.framework/UIKit
[  4] 0x0000000001190000 /Users/zhoufei/Library/Developer/Xcode/iOS DeviceSupport/11.4 (15F79)/Symbols/usr/lib/libobjc.A.dylib
[  5] 0x0000000001190000 /Users/zhoufei/Library/Developer/Xcode/iOS DeviceSupport/11.4 (15F79)/Symbols/usr/lib/libSystem.B.dylib
[  6] 0x0000000001190000 /Users/zhoufei/Library/Developer/Xcode/iOS DeviceSupport/11.4 (15F79)/Symbols/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation
[  7] 0x0000000001190000 /Users/zhoufei/Library/Developer/Xcode/iOS DeviceSupport/11.4 (15F79)/Symbols/System/Library/Frameworks/CoreGraphics.framework/CoreGraphics
[  8] 0x0000000001190000 /Users/zhoufei/Library/Developer/Xcode/iOS DeviceSupport/11.4 (15F79)/Symbols/System/Library/Frameworks/QuartzCore.framework/QuartzCore
[  9] 0x0000000001190000 /Users/zhoufei/Library/Developer/Xcode/iOS DeviceSupport/11.4 (15F79)/Symbols/usr/lib/libarchive.2.dylib

第0个结果0x0000000000558000 就是要找的ASLR值

 

如何证明全部变量在Mach-O中，局部变量在栈中，对象在堆空间中？

根据打印的内存地址可以进行说明

通过log的内容，拿到app的Mach-O文件路径：

[  0] 0x0000000000558000 /Users/zhoufei/Library/Developer/Xcode/DerivedData/SorterAndFilter-gcqrjckyrquurscwtbwpiaeebgzj/Build/Products/Release-iphoneos/SorterAndFilter.app/SorterAndFilter

其对应的偏移地址0x0000000000558000 就是Mach-O文件从本地添加到内存时，系统自动添加的ASLR：内存空间布局随机化值。

那Mach-O文件SorterAndFilter.app/SorterAndFilter的大小是多少呢？

通过终端，进行查询

1.cd /Users/zhoufei/Library/Developer/Xcode/DerivedData/SorterAndFilter-gcqrjckyrquurscwtbwpiaeebgzj/Build/Products/Release-iphoneos/SorterAndFilter.app/

2.size -l -m -x SorterAndFilter

的到结果如下：

SorterAndFilter (for architecture arm64):
Segment __PAGEZERO: 0x100000000 (vmaddr 0x0 fileoff 0)
Segment __TEXT: 0x1c000 (vmaddr 0x100000000 fileoff 0)
     Section __text: 0xfde0 (addr 0x100005740 offset 22336)
     Section __stubs: 0x1bc (addr 0x100015520 offset 87328)
     Section __stub_helper: 0x1d4 (addr 0x1000156dc offset 87772)
     Section __const: 0x64 (addr 0x1000158b0 offset 88240)
     Section __objc_methname: 0x36b4 (addr 0x100015914 offset 88340)
     Section __ustring: 0x134 (addr 0x100018fc8 offset 102344)
     Section __cstring: 0xd06 (addr 0x1000190fc offset 102652)
     Section __objc_classname: 0x28c (addr 0x100019e02 offset 105986)
     Section __objc_methtype: 0x19f2 (addr 0x10001a08e offset 106638)
     Section __gcc_except_tab: 0xd8 (addr 0x10001ba80 offset 113280)
     Section __unwind_info: 0x4a4 (addr 0x10001bb58 offset 113496)
     total 0x168bc
Segment __DATA: 0xc000 (vmaddr 0x10001c000 fileoff 114688)
     Section __got: 0x60 (addr 0x10001c000 offset 114688)
     Section __la_symbol_ptr: 0x128 (addr 0x10001c060 offset 114784)
     Section __const: 0x9f0 (addr 0x10001c188 offset 115080)
     Section __cfstring: 0x9a0 (addr 0x10001cb78 offset 117624)
     Section __objc_classlist: 0x90 (addr 0x10001d518 offset 120088)
     Section __objc_catlist: 0x28 (addr 0x10001d5a8 offset 120232)
     Section __objc_protolist: 0x58 (addr 0x10001d5d0 offset 120272)
     Section __objc_imageinfo: 0x8 (addr 0x10001d628 offset 120360)
     Section __objc_const: 0x55d8 (addr 0x10001d630 offset 120368)
     Section __objc_selrefs: 0x9c0 (addr 0x100022c08 offset 142344)
     Section __objc_classrefs: 0x138 (addr 0x1000235c8 offset 144840)
     Section __objc_superrefs: 0x68 (addr 0x100023700 offset 145152)
     Section __objc_ivar: 0xd0 (addr 0x100023768 offset 145256)
     Section __objc_data: 0x5a0 (addr 0x100023838 offset 145464)
     Section __data: 0x430 (addr 0x100023dd8 offset 146904)
     Section __bss: 0x48 (addr 0x100024208 offset 0)
     total 0x8250
Segment __LINKEDIT: 0x24000 (vmaddr 0x100028000 fileoff 163840)
total 0x10004c000

在虚拟内存中，Mach-O文件SorterAndFilter的总大小是total 0x10004c000。

 

由于Mach-O文件在虚拟内存中的__PAGEZERO段的大小是0x100000000

所以在本地文件中Mach-O文件的大小是：0x10004c000 - 0x100000000 等于0x4c000

 

因为系统自动添加的ASLR值是0x558000,所以在虚拟内存中，Mach-O文件SorterAndFilter的空间分布是：

0x558000 -> 0x1005A4000 (0x10004c000 + 0x558000 )

 

根据上面内存地址信息log的值：

2020-01-12 16:47:32.388332+0800 SorterAndFilter[1717:366886] 全局变量:0x10057bf58, 局部变量:0x16f8a57fc, 局部变量—对象指针:0x16f8a57f0, 堆空间-对象地址：0x100aace30

动态链接器dyld的虚拟内存地址

[  1] 0x0000000100800000 /Users/zhoufei/Library/Developer/Xcode/iOS DeviceSupport/11.4 (15F79)/Symbols/usr/lib/dyld

Mach-O文件SorterAndFilter所有使用的到的image（image都是Mach-O类型文件）文件内存分布，得到虚拟内存中的内存分布如下：

这里有个很奇怪的地方，系统共享库的虚拟内存地址0x1190000,是在Mach-O文件SorterAndFilter的虚拟内存空间范围内

我感觉比较合理的解释是打印出来的0x1190000是app中stub代码区地址。

 

那何为stub代码区呢？

Stub代码区是本地源代码调用系统库代码的连接点，当app工程中有调用系统函数的代码时，在app编译后，那个调用系统函数的处的内存地址便指向了stub代码区 。

app从本地加载到内存时，使用的系统函数API在app的可执行文件文件中并没有函数实现，需要dyld动态链接器将系统API与系统函数地址进行绑定。

而根据绑定时机不同，绑定分为app加载时binding和函数调用时lazy_binding。

下面以lazy_binding绑定方式为例：

1.点击按钮，触发本地函数对系统函数的调用，此时被调用的系统函数指针是指向的stub代码区，

2. 在stub代码区的实现中，又将函数指针指向了懒动态符号表。

3.懒动态符号表又将函数指针指向了stub_helper代码区。

4.最后stub_helper代码区通过dyld_stub_binder函数将真实的系统函数内存地址更新到懒动态符号表中。

 

具体动态绑定流程图如下：

_nl_symbol_ptr列表在加载时绑定。

_la_symbol_ptr列表在第一次使用时进行函数绑定。

_la_symbol_ptr懒动态符号列表的绑定过程如下：

---

 

Mach-O类型文件工具

Mach-O类型文件工具有很多，常见的如下：

 

系统自带工具

file: 查看Mach-O的文件类型

nm:查看Mach-O文件的符号表

otool:查看Mach-O特定部分和段的内容

size -l -m -x： 查看Mach-O不同段的虚拟内存分布

lipo:常用用于多架构Mach-O文件的处理

查看通用二进制文件包含的架构
lipo -info test
瘦身通用二进制文件，到包含指定架构(armv7)的瘦二进制文件
lipo test -thin armv7 -output test_armv7
合并两个瘦二进制文件到一个通用二进制文件
lipo -create test_armv7 test_arm64 -output test2

 

Xcode自带工具

lldb调试器命令，打印所有app文件对应Mach-O的所包含的所有Mach-O文件。

image list -o -f

 

第三方工具

class-dump：可以把未经加密的app的头文件导出来。

//产生头文件 

class-dump -H test -o Headers

MachOView: GUI工具查看Mach-O文件

HopperDisassembler： 反汇编查看Mach-O文件中的函数和全局变量的信息。

 

有了工具的使用，在分析Mach-O文件时会变的轻松很多。