iOS逆向-Mach-O(Ⅴ)

Mach-O文件

Mach-O其实是Mach Object文件格式的缩写，是mac以及iOS上可执行文件的格式，类似于windows的PE格式 (Portable Executable ), linux上的elf格式 (Executable and Linking Format)

Mach-O文件格式

目标文件.o
库文件(.a/.dylib/Framework)
可执行文件
dyld
.dsym

查看动态库的头文件，在. Framework生成的Mach-O文件，静态库的头文件在最外层的.app生成的Mach-O文件

File指令

通过$ file 文件路径查看文件类型

Command+N新建一个test.c的文件，添加如下代码

#include 
int main() {
    printf("test\n");
    return 0;
}

命令行执行如下指令

$ clang -c test.c
$ ls
test.c  test.o
$ file test.o      //目标文件
test.o: Mach-O 64-bit object x86_64
$ clang test.o
$ ls
a.out   test.c  test.o
$ ./a.out 
test
$ file a.out         //可执行文件
a.out: Mach-O 64-bit executable x86_64

查看系统的.dylib文件,随便file一个

$ find /usr/lib -name "*.dylib"
$ file /usr/lib/libcupscgi.1.dylib      
/usr/lib/libcupscgi.1.dylib: Mach-O universal binary with 2 architectures: [i386:Mach-O dynamically linked shared library i386] [x86_64:Mach-O 64-bit dynamically linked shared library x86_64]
/usr/lib/libcupscgi.1.dylib (for architecture i386):    Mach-O dynamically linked shared library i386
/usr/lib/libcupscgi.1.dylib (for architecture x86_64):  Mach-O 64-bit dynamically linked shared library x86_64


$ cd /usr/lib
$ ls dyld
dyld
$ file dyld
dyld: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamic linker x86_64] [i386:Mach-O dynamic linker i386]
dyld (for architecture x86_64): Mach-O 64-bit dynamic linker x86_64
dyld (for architecture i386):   Mach-O dynamic linker i386

新建一个项目，运行在release模式下，可以看到生成的.dsym文件

$ cd /Users/xxxx/Library/Developer/Xcode/DerivedData/MachO-Demo-apcjwlbdqqvywufaqhxzubbpdtqn/Build/Products/Release-iphoneos/MachO-Demo.app.dSYM/Contents/Resources/DWARF 
$ ls
MachO-Demo
$ file MachO-Demo 
MachO-Demo: Mach-O 64-bit dSYM companion file arm64

在Xcode的Build Settings中可以看到Mach-o支持的类型

Architectures代表支持的架构

通用二进制文件（Universal binary）

苹果公司提出的一种程序代码。能同时适用多种架构的二进制文件。
同一个程序包中同时为多种架构提供最理想的性能。
因为需要储存多种代码，通用二进制应用程序通常比单一平台二进制的程序要大。
但是由于两种架构有共通的非执行资源，所以并不会达到单一版本的两倍之多。
而且由于执行中只调用一部分代码，运行起来也不需要额外的内存。

lipo命令

使用lifo -info可以查看MachO文件包含的架构

$ lipo -info MachO文件

使用lifo –thin 拆分某种架构

$ lipo MachO文件 –thin 架构 –output  输出文件路径

使用lipo -create 合并多种架构

$ lipo -create MachO1   MachO2  -output  输出文件路径

MachO文件结构

Mach-O 的组成结构如图所示包括了

Header 包含该二进制文件的一般信息
字节顺序、架构类型、加载指令的数量等。
使得可以快速确认一些信息，比如当前文件用于32位还是64位，对应的处理器是什么、文件类型是什么

在MachOView工具中查看一个只支持arm64架构的可执行文件，如下

其中Mach64 Header的信息都可以在Xcode里面找到,Xcode中Command+shift+O，搜索loader.h
可以看到Mach64 Header的头文件信息

struct mach_header_64 {
    uint32_t    magic;        /* 魔数，快速定位属于64还是32位 */
    cpu_type_t    cputype;    /* CPU类型，比如ARM */
    cpu_subtype_t    cpusubtype;    /* CPU的具体类型 arm64\armv7 */
    uint32_t    filetype;    /* 文件类型，比如可执行文件 */
    uint32_t    ncmds;        /* loadCommands条数 */
    uint32_t    sizeofcmds;    /* LoadCommands的大小 */
    uint32_t    flags;        /* 标志位标识二进制文件支持的功能。主要是和系统加载、链接有关 */
    uint32_t    reserved;    /* reserved */
};

filetype对应Mach-O文件的类型，也可以在loader.h中看到

#define MH_OBJECT   0x1     /* Target 文件：编译器对源码编译后得到的中间结果 */
#define MH_EXECUTE  0x2     /* 可执行二进制文件 */
#define MH_FVMLIB   0x3     /* VM 共享库文件（还不清楚是什么东西） */
#define MH_CORE     0x4     /* Core 文件，一般在 App Crash 产生 */
#define MH_PRELOAD  0x5     /* preloaded executable file */
#define MH_DYLIB    0x6     /* 动态库 */
#define MH_DYLINKER 0x7     /* 动态连接器 /usr/lib/dyld */
#define MH_BUNDLE   0x8     /* 非独立的二进制文件，往往通过 gcc-bundle 生成 */
#define MH_DYLIB_STUB   0x9     /* 静态链接文件（还不清楚是什么东西） */
#define MH_DSYM     0xa     /* 符号文件以及调试信息，在解析堆栈符号中常用 */
#define MH_KEXT_BUNDLE  0xb     /* x86_64 内核扩展 */

Load commands 一张包含很多内容的表
内容包括区域的位置、符号表、动态符号表等。

在MachOView工具查看Load commands如下

LC_SEGMENT_64 //将文件中（32位或64位）的段映射到进程地址空间中
LC_DYLD_INFO_ONLY //动态链接器相关信息
LC_SYMTAB //符号表地址
LC_DYSYMTAB //动态符号表地址
LC_LOAD_DYLINKER //dyld加载
LC_UUID //Mach-O唯一标识符
LC_VERSION_MIN_MACOSX //该Mach-O运行的最低系统版本.
LC_SOURCE_VERSION //源代码版本
LC_MAIN //程序主线程的入口地址和栈大小
LC_LOAD_DYLIB //依赖库的路径，包含三方库
LC_FUNCTION_STARTS //函数起始地址表
LC_CODE_SIGNATURE //代码签名信息

Data 通常是对象文件中最大的部分
包含Segement的具体数据(代码、常量、字符串、类、方法等)

dyld

新建一个项目，添加一个load函数,打上断点，看一下堆栈信息

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x0000000102b9e760 MachO-Demo`+[ViewController load](self=ViewController, _cmd="load") at ViewController.m:19:5
    frame #1: 0x0000000206091ffc libobjc.A.dylib`call_load_methods + 184
    frame #2: 0x0000000206093e54 libobjc.A.dylib`load_images + 180
    frame #3: 0x0000000102d2e390 dyld`dyld::notifySingle(dyld_image_states, ImageLoader const*, ImageLoader::InitializerTimingList*) + 444
    frame #4: 0x0000000102d40380 dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 440
    frame #5: 0x0000000102d3f3dc dyld`ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 136
    frame #6: 0x0000000102d3f498 dyld`ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 84
    frame #7: 0x0000000102d2e6d8 dyld`dyld::initializeMainExecutable() + 220
    frame #8: 0x0000000102d332a0 dyld`dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 4304
    frame #9: 0x0000000102d2d044 dyld`_dyld_start + 68

这里从dyld的main函数环境配置-> 加载共享缓存->实例化主程序->动态库加载->初始化方法&启动main都可以在dyld和runtime的源码中看到过程,其中notifySingle方法里面回调了_objc_init方法(可以用符号断点_dyld_objc_notify_register查看)，这个要在runtime源码中看，里面调用了load_images方法, load_images里面执行call_load_methods方法, call_load_methods里面循环调用call_class_loads（各个类的load方法）,之后dyld源码中调用doModInitFunctions方法（内部会调用全局C++对象的构造函数：带__attribute__(constructor)的c函数）,之后返回主程序的入口函数，进入main函数!

void _objc_init(void)
{
    static bool initialized = false;
    if (initialized) return;
    initialized = true;
    
    // fixme defer initialization until an objc-using image is found?
    environ_init();
    tls_init();
    static_init();
    lock_init();
    exception_init();
    _dyld_objc_notify_register(&map_images, load_images, unmap_image);
}