Mach-O文件格式和程序从载入到运行过程

Posted clnchanpin

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Mach-O文件格式和程序从载入到运行过程相关的知识,希望对你有一定的参考价值。

>
之前深入了解过。过去了一年多的时间。如今花些时间好好总结下,毕竟好记性不如烂笔头。

其次另一个目的,对于mach-o文件结构。关于动态载入信息那个数据区中,命令含义没有深刻掰扯清除,希望有同学能够指点下。

摘要:对于mach-o是Mac和ios能够运行文件的格式。进程就是系统依据该格式将运行文件载入到内存后得到的结果。系统通过解析文件,建立依赖(动态库),初始化运行时环境,才干真正開始运行该App(进程)

Start from Hello World

通过分析以下这个最熟悉的可运行文件。来好好总结和了解下Mach-O这样的文件格式,而且也总结下系统在运行可运行文件几个过程:
+ 解析文件
+ 依赖建立
+ 初始化运行环境
+ 运行进程

代码1.0

#include <stdio.h>  
int  main( int  argc,  char  *argv[]) 
{ 
    printf( "Hello World!\n" ); 
     return  0; 
} 

浏览可运行文件格式

小工具介绍下:烂苹果MachOView。通过改工具能够直接review mach-o可运行文件的几个基本的组成部分:
编译下main.c文件(使用gcc -g main.c)
简单看下可运行文件格式:

技术分享

简单浏览mach-o可运行文件,详细能够分为几个部分

  • 文件头 mach64 Header
  • 载入命令 Load Commands
  • 文本段 __TEXT
  • 数据段 __TEXT
  • 动态库载入信息 Dynamic Loader Info
  • 入口函数 Function Starts
  • 符号表 Symbol Table
  • 动态库符号表 Dynamic Symbol Table
  • 字符串表 String Table

详细介绍下各个区域的作用。以及载入时系统是怎样使用该可运行文件。

Mach Header - 可运行文件文件头

使用下mac的otool工具

代码3.0

yingfang:mach-o文件结构-src fangying$ otool -h a.out
a.out:
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
 0xfeedfacf 16777223          3  0x80           2    15       1200 0x00200085

上面是mach-o标准的文件头格式。其相关的数据结构在

/*
 * The 32-bit mach header appears at the very beginning of the object file for
 * 32-bit architectures.
 */
struct mach_header {
    uint32_t    magic;      /* mach magic number identifier */
    cpu_type_t  cputype;    /* cpu specifier */
    cpu_subtype_t   cpusubtype; /* machine specifier */
    uint32_t    filetype;   /* type of file */
    uint32_t    ncmds;      /* number of load commands */
    uint32_t    sizeofcmds; /* the size of all the load commands */
    uint32_t    flags;      /* flags */
};

/* Constant for the magic field of the mach_header (32-bit architectures) */
#define MH_MAGIC    0xfeedface  /* the mach magic number */
#define MH_CIGAM    0xcefaedfe  /* NXSwapInt(MH_MAGIC) */

/*
 * The 64-bit mach header appears at the very beginning of object files for
 * 64-bit architectures.
 */
struct mach_header_64 {
    uint32_t    magic;      /* mach magic number identifier */
    cpu_type_t  cputype;    /* cpu specifier */
    cpu_subtype_t   cpusubtype; /* machine specifier */
    uint32_t    filetype;   /* type of file */
    uint32_t    ncmds;      /* number of load commands */
    uint32_t    sizeofcmds; /* the size of all the load commands */
    uint32_t    flags;      /* flags */
    uint32_t    reserved;   /* reserved */
};

/* Constant for the magic field of the mach_header_64 (64-bit architectures) */
#define MH_MAGIC_64 0xfeedfacf /* the 64-bit mach magic number */
#define MH_CIGAM_64 0xcffaedfe /* NXSwapInt(MH_MAGIC_64) */

对比命令结果和详细的数据结构,下表介绍各个字段的详细意义:

字段 说明 举例
magic 魔数,系统载入器通过改字段高速,推断该文件是用于32位or64位。

32位-0xfeedface 64位-0xfeedfacf

demo中magic值为0xfeedfacf。表明该文件支持64位
cputype CPU类型以及子类型字段。该字段确保系统能够将适合的二进制文件在当前架构下运行 demo值为0x1000007, 依据#define CPU_TYPE_X86_64 (CPU_TYPE_X86
cpusubtype CPU指定子类型。对于inter。arm。powerpc等CPU架构,其都有各个阶段和等级的CPU芯片。该字段就是详细描写叙述其支持CPU子类型 对于Demo,能够查看
#define CPU_SUBTYPE_X86_ALL ((cpu_subtype_t)3)
#define CPU_SUBTYPE_X86_64_ALL ((cpu_subtype_t)3)
#define CPU_SUBTYPE_X86_ARCH1 ((cpu_subtype_t)4)
#define CPU_SUBTYPE_X86_64_H ((cpu_subtype_t)8)
filetype 说明该mach-o文件类型(可运行文件,库文件。核心转储文件。内核扩展,DYSM文件,动态库)。详细能够看 demo中该值为2,表示该文件为二进制文件
ncmds 说明载入命令条数 demo中表示该文件载入命令条数为15,通过machoview工具。看到也是15条载入命令
sizeofcmds 表示载入命令大小 demo表示该文件载入命令大小为1200字节
flags 标志位,该字段用位表示二进制文件支持的功能,主要是和系统载入,链接相关。详细能够看 demo中值为0x00200085,分别表示三个功能:
1. MH_PRELOAD
2. MH_TWOLEVEL 动态库载入二级名称空间
3. MH_PIE 对可运行文件类型启用地址空间随机布局化
reserved 保留字段

系统解释,先解释文件头,获得文件支持位数(64位 or 32位),获得CPU类型。获得文件类型。获得载入命令条数和大小,获得文件标识。

Load Commands - 载入命令

Mach-O文件包括非常详细的载入指令,这些指令非常清晰地指示载入器怎样设置而且载入二进制数据。Load Commands紧紧跟着二进制文件头。
先使用工具review demo中二进制文件Load Commands

技术分享

也能够使用otool命令读取二进制文件载入命令:(之前分析bitcode是否支持,也是通过otool -l进行分析的)

代码4.0

yingfang:mach-o文件结构-src fangying$ otool -l a.out
a.out:
Load command 0
      cmd LC_SEGMENT_64
  cmdsize 72
  segname __PAGEZERO
   vmaddr 0x0000000000000000
   vmsize 0x0000000100000000
  fileoff 0
 filesize 0
  maxprot 0x00000000
 initprot 0x00000000
   nsects 0
    flags 0x0
Load command 1
      cmd LC_SEGMENT_64
  cmdsize 472
  segname __TEXT
   vmaddr 0x0000000100000000
   vmsize 0x0000000000001000
  fileoff 0
 filesize 4096
  maxprot 0x00000007
 initprot 0x00000005
   nsects 5
    flags 0x0
Section
  sectname __text
   segname __TEXT
      addr 0x0000000100000f50
      size 0x0000000000000034
    offset 3920
     align 2^4 (16)
    reloff 0
    nreloc 0
     flags 0x80000400
 reserved1 0
 reserved2 0
Section
  sectname __stubs
   segname __TEXT
      addr 0x0000000100000f84
      size 0x0000000000000006
    offset 3972
     align 2^1 (2)
    reloff 0
    nreloc 0
     flags 0x80000408
 reserved1 0 (index into indirect symbol table)
 reserved2 6 (size of stubs)
Section
  sectname __stub_helper
   segname __TEXT
      addr 0x0000000100000f8c
      size 0x000000000000001a
    offset 3980
     align 2^2 (4)
    reloff 0
    nreloc 0
     flags 0x80000400
 reserved1 0
 reserved2 0
Section
  sectname __cstring
   segname __TEXT
      addr 0x0000000100000fa6
      size 0x000000000000000e
    offset 4006
     align 2^0 (1)
    reloff 0
    nreloc 0
     flags 0x00000002
 reserved1 0
 reserved2 0
Section
  sectname __unwind_info
   segname __TEXT
      addr 0x0000000100000fb4
      size 0x0000000000000048
    offset 4020
     align 2^2 (4)
    reloff 0
    nreloc 0
     flags 0x00000000
 reserved1 0
 reserved2 0
Load command 2
      cmd LC_SEGMENT_64
  cmdsize 232
  segname __DATA
   vmaddr 0x0000000100001000
   vmsize 0x0000000000001000
  fileoff 4096
 filesize 4096
  maxprot 0x00000007
 initprot 0x00000003
   nsects 2
    flags 0x0
Section
  sectname __nl_symbol_ptr
   segname __DATA
      addr 0x0000000100001000
      size 0x0000000000000010
    offset 4096
     align 2^3 (8)
    reloff 0
    nreloc 0
     flags 0x00000006
 reserved1 1 (index into indirect symbol table)
 reserved2 0
Section
  sectname __la_symbol_ptr
   segname __DATA
      addr 0x0000000100001010
      size 0x0000000000000008
    offset 4112
     align 2^3 (8)
    reloff 0
    nreloc 0
     flags 0x00000007
 reserved1 3 (index into indirect symbol table)
 reserved2 0
Load command 3
      cmd LC_SEGMENT_64
  cmdsize 72
  segname __LINKEDIT
   vmaddr 0x0000000100002000
   vmsize 0x0000000000001000
  fileoff 8192
 filesize 552
  maxprot 0x00000007
 initprot 0x00000001
   nsects 0
    flags 0x0
Load command 4
            cmd LC_DYLD_INFO_ONLY
        cmdsize 48
     rebase_off 8192
    rebase_size 8
       bind_off 8200
      bind_size 24
  weak_bind_off 0
 weak_bind_size 0
  lazy_bind_off 8224
 lazy_bind_size 16
     export_off 8240
    export_size 48
Load command 5
     cmd LC_SYMTAB
 cmdsize 24
  symoff 8296
   nsyms 12
  stroff 8504
 strsize 240
Load command 6
            cmd LC_DYSYMTAB
        cmdsize 80
      ilocalsym 0
      nlocalsym 8
     iextdefsym 8
     nextdefsym 2
      iundefsym 10
      nundefsym 2
         tocoff 0
           ntoc 0
      modtaboff 0
        nmodtab 0
   extrefsymoff 0
    nextrefsyms 0
 indirectsymoff 8488
  nindirectsyms 4
      extreloff 0
        nextrel 0
      locreloff 0
        nlocrel 0
Load command 7
          cmd LC_LOAD_DYLINKER
      cmdsize 32
         name /usr/lib/dyld (offset 12)
Load command 8
     cmd LC_UUID
 cmdsize 24
    uuid A36ECE81-1426-3D1F-928C-62F6CC590A5D
Load command 9
      cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.11
      sdk 10.11
Load command 10
      cmd LC_SOURCE_VERSION
  cmdsize 16
  version 0.0
Load command 11
       cmd LC_MAIN
   cmdsize 24
  entryoff 3920
 stacksize 0
Load command 12
          cmd LC_LOAD_DYLIB
      cmdsize 56
         name /usr/lib/libSystem.B.dylib (offset 24)
   time stamp 2 Thu Jan  1 08:00:02 1970
      current version 1225.1.1
compatibility version 1.0.0
Load command 13
      cmd LC_FUNCTION_STARTS
  cmdsize 16
  dataoff 8288
 datasize 8
Load command 14
      cmd LC_DATA_IN_CODE
  cmdsize 16
  dataoff 8296
 datasize 0

从otool展现的载入命令,我们能够分析基本的载入命令(段命令,区命令。段命令中会分为几个区命令)
详细能够看看bsd/kern/mach_loader.c

segname cmd 说明 举例
LC_SEGMENT_64 将文件里(32位或64位)的段映射到进程地址空间中
LC_DYLD_INFO_ONLY
LC_SYMTAB 符号表地址
LC_DYSYMTAB 动态符号表地址
LC_LOAD_DYLINKER 使用何种动态载入库 demo中表明使用/usr/lib/dyld
LC_UUID 文件的唯一标识,crash解析中也会有该仅仅。去确定dysm文件和crash文件是匹配的
LC_VERSION_MIN_MACOSX 二进制文件要求的最低操作系统版本号 demo二进制版本号。支持最低os版本号为10.11
LC_SOURCE_VERSION 构建该二进制文件使用的源码版本号
LC_MAIN 设置程序主线程的入口地址和栈大小 demo二进制的entryoff位OXF50,正式__TEXT段偏移地址,然后看看0XF50的汇编代码,正式熟悉的main函数调用地址。详细请看以下汇编代码
LC_LOAD_DYLIB 载入额外的动态库,细致看这个命令格式,动态库地址和名,当前版本号号,兼容版本号号。该设计比較合理。假设对于动态库有版本号管理能力
LC_FUNCTION_STARTS 函数起始地址表,怎样使用呢?
LC_DATA_IN_CODE /* table of non-instructions in __text */ 不是非常理解

代码4.1

yingfang:mach-o文件结构-src fangying$ otool -vt a.out
a.out:
(__TEXT,__text) section
_main:
0000000100000f50    pushq   %rbp
0000000100000f51    movq    %rsp, %rbp
0000000100000f54    subq    $0x20, %rsp
0000000100000f58    leaq    0x47(%rip), %rax
0000000100000f5f    movl    $0x0, -0x4(%rbp)
0000000100000f66    movl    %edi, -0x8(%rbp)
0000000100000f69    movq    %rsi, -0x10(%rbp)
0000000100000f6d    movq    %rax, %rdi
0000000100000f70    movb    $0x0, %al
0000000100000f72    callq   0x100000f84
0000000100000f77    xorl    %ecx, %ecx
0000000100000f79    movl    %eax, -0x14(%rbp)
0000000100000f7c    movl    %ecx, %eax
0000000100000f7e    addq    $0x20, %rsp
0000000100000f82    popq    %rbp
0000000100000f83    retq
section cmd 说明 举例
__text 主程序代码
__stubs 用于动态库链接的桩
__stub_helper 用于动态库链接的桩
__cstring 常亮字符串符号表描写叙述信息,通过该区信息,能够获得常亮字符串符号表地址
__unwind_info 这里字段不是太理解啥意思。希望大家指点下

动态库连接器–动态库链接信息

总结了mach-o文件的两个最重要的部分,那么动态库依据载入命令怎样动态链接到内存中的呢?以下总结这个动态过程。

  • 系统通过载入命令。获得动态载入器的地址/usr/lib/dyly(其解决的问题是。把代码段__TEXT中和动态库相关内容进行关联,比方代码中怎样调用到哪个动态库的相关代码段的偏移地址)
    (dyly是用户态进程。这个是开源的,不属于kern内核的部分)感兴趣能够看看这里

总结下:在载入命令中。和动态库和链接相关命令有例如以下几个:

  • 段命令
    • LC_DYLD_INFO_ONLY
    • LC_LOAD_DYLIB
    • LC_LOAD_DYLINKER
    • LC_SYMTAB
    • LC_DYSYMTAB
  • 区命令
    • __stubs
    • __stubs_helper

在进行动态链接器工作前,要先解析相关工作环境參数

  • LC_LOAD_DYLINKER 获得动态载入器地址
  • LC_LOAD_DYLIB 二进制文件依赖动态库信息
    能够使用otool工具。读取该部分信息

代码5.0

yingfang:mach-o文件结构-src fangying$ otool -L a.out
a.out:
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)
  • LC_DYLD_INFO_ONLY 动态库信息,依据该命令是真正动态库绑定,地址重定向重要的信息。
    结合之前otool -l的信息中的command 4命令,以下struct就是该命令相应的数据结构:

代码5.1

struct dyld_info_command {
    uint32_t   cmd;     /* LC_DYLD_INFO or LC_DYLD_INFO_ONLY */
    uint32_t   cmdsize;     /* sizeof(struct dyld_info_command) */
    uint32_t   rebase_off;
    uint32_t   rebase_size;
    uint32_t   bind_off;
    uint32_t   bind_size;
    uint32_t   weak_bind_off;
    uint32_t   weak_bind_size;
    uint32_t   lazy_bind_off;
    uint32_t   lazy_bind_size;
    uint32_t   export_off;
    uint32_t   export_size;
};

依据该载入命令的字段偏移,系统能够得到压缩动态数据信息区(dymanic load info)。

依据上述数据,dymanic load info数据区,主要包括了5种数据:
(以下的一些内容,我的理解可能不是太正确。希望和大家一起讨论)dyld_info_command详细定义地址

dymanic load info 说明 举例
重定向数据 rebase demo中该段数据位 11 22 10 51 11: 高位0x10表示设置马上数类型,低位0x01表示马上数类型为指针
22: 表示REBASE_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB + 2 重定向到数据段2。

结合上面的信息。就是重定向到数据段2。该段数据信息为一个指针
结合数据段2的数据,获得一个重定向符号指针[0x100001010 -> _printf]

绑定数据 bind 在demo中进行动态绑定依赖的dyld的函数 U dyld_stub_binder
弱绑定数据 weak bind 用于弱绑定动态库,就像weak_framework一样
懒绑定数据 lazy bind 对于须要从动态库载入的函数符号 demo中有两个:
U _printf
U _scanf
export数据 用于对外开放的函数 demo中仅仅有两个
0000000100000000 T __mh_execute_header
0000000100000f50 T _main

对于相关的绑定函数查找。能够使用nm命令

代码5.2

yingfang:mach-o文件结构-src fangying$ nm a.out
0000000100000000 T __mh_execute_header
0000000100000f50 T _main
                 U _printf
                 U dyld_stub_binder

>
标注:dymanic load info数据是以命令码(命令码就是一个字节码)的形式,传递详细内容。

高四位表示真正命令名。低四位表示一个马上数。

00表示该类型命令结束

能够使用dylyinfo获得这部分信息读取

代码5.3

yingfang:mach-o文件结构-src fangying$ xcrun dyldinfo -opcodes a.out
rebase opcodes:
0x0000 REBASE_OPCODE_SET_TYPE_IMM(1)
0x0001 REBASE_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB(2, 0x00000010)
0x0003 REBASE_OPCODE_DO_REBASE_IMM_TIMES(1)
0x0004 REBASE_OPCODE_DONE()
binding opcodes:
0x0000 BIND_OPCODE_SET_DYLIB_ORDINAL_IMM(1)
0x0001 BIND_OPCODE_SET_SYMBOL_TRAILING_FLAGS_IMM(0x00, dyld_stub_binder)
0x0013 BIND_OPCODE_SET_TYPE_IMM(1)
0x0014 BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB(0x02, 0x00000000)
0x0016 BIND_OPCODE_DO_BIND()
0x0017 BIND_OPCODE_DONE
no compressed weak binding info
lazy binding opcodes:
0x0000 BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB(0x02, 0x00000010)
0x0002 BIND_OPCODE_SET_DYLIB_ORDINAL_IMM(1)
0x0003 BIND_OPCODE_SET_SYMBOL_TRAILING_FLAGS_IMM(0x00, _printf)
0x000C BIND_OPCODE_DO_BIND()
0x000D BIND_OPCODE_DONE
0x000E BIND_OPCODE_DONE
0x000F BIND_OPCODE_DONE

动态库链接器运行结果

上面总结,动态链接器相关信息(载入命令信息,载入命令偏移地址相关信息)。

如今总结下动态链接器运行的结果是什么?怎样使用相关动态链接信息,完毕相关过程的?

从字面上,之前我理解,链接器就是把文本段原来动态库函数相关地址,用真实的动态库地址替换。生成一个真实的完整的可运行文本。比方demo中printf是其他动态库的,可是其真实地址对于可运行文件是不知道,仅仅有这个运行文件运行时,通过动态链接器完好其原来文本段地址。

在总结之前两个问题前。先总结下__stubs(桩)的区概念:该区存放的是二进制文件里没有定义符号的占位符。编译器生成代码时会创建对符号桩区的调用。链接器在运行时解决对桩的这些调用。链接器解决方式是在被调用的地址处。放置一条JMP指令。JMP指令将控制权转交给真实的函数体。

回想下nm命令结果:U表示没有定义的符号

yingfang:mach-o文件结构-src fangying$ nm a.out
0000000100000000 T __mh_execute_header
0000000100000f50 T _main
                 U _printf
                 U dyld_stub_binder

看下demo中main函数汇编代码:

  • demo中真实的print函数调用,编译器,编译为callq 0x100000f84 ## symbol stub for: _printf
  • 汇编代码中。callq 0x100000f84 . 注意0x100000f84,这个地址是 __TEXT段的__stubs区的地址。换句话说,就是JMP到__stubs(桩区)– 段1 section位__stubs的起始地址
  • 0x100000f84地址。是一段汇编指令 0x100000f84: jmpq *0x86(%rip) # 0x100001010
  • 0x100001010地址,是指向(代码7.2)数据段__la_symbol_ptr区。因为这个数据都符号指针,查看下该地址指向的数据区域(代码7.3)
  • 0x100001010地址指针。指向地址为4294971292(数据段都在高位。所以相比__TEXT地址,这个地址是正常的)
  • 4294971292地址,运行汇编代码请看(代码7.4) 0x100000fa1: jmpq 0x100000f8c。请注意 0x100000f8c就是__TEXT段section __stub_helper区的起始地址。该地址是运行汇编代码详细请看(代码7.5)0x100000f95: jmpq *0x65(%rip) # 0x100001000
  • 0x100001000地址,恰好是__DATA段, __nl_symbol_ptr区的事实上地址,该地址指向的数据值位为 0x100001000: 0x0000000000000000 0x0000000000000000 (代码7.6)

>
总结:

+ __stubs区和__stub_helper区是帮助动态链接器找到指定数据段__nl_symbol_ptr区,二进制文件用0x0000000000000000进行占位,在运行时。系统依据dynamic loader info信息,把占位符换为调用dylib的dyld_stub_binder函数的汇编指令。

+ 当第一次调用完动态库中的符号后,动态链接器会依据dynamic loader info信息,把数据段__la_symbol_ptr指向正在的符号地址。而不是指向_nl_symbol_ptr区

代码7.0

yingfang:mach-o文件结构-src fangying$ otool -p _main -tV a1.out 
a1.out:
(__TEXT,__text) section
_main:
0000000100000f50    pushq   %rbp
0000000100000f51    movq    %rsp, %rbp
0000000100000f54    subq    $0x20, %rsp
0000000100000f58    leaq    0x47(%rip), %rax        ## literal pool for: "Hello World!\n"
0000000100000f5f    movl    $0x0, -0x4(%rbp)
0000000100000f66    movl    %edi, -0x8(%rbp)
0000000100000f69    movq    %rsi, -0x10(%rbp)
0000000100000f6d    movq    %rax, %rdi
0000000100000f70    movb    $0x0, %al
0000000100000f72    callq   0x100000f84             ## symbol stub for: _printf
0000000100000f77    xorl    %ecx, %ecx
0000000100000f79    movl    %eax, -0x14(%rbp)
0000000100000f7c    movl    %ecx, %eax
0000000100000f7e    addq    $0x20, %rsp
0000000100000f82    popq    %rbp
0000000100000f83    retq

代码7.1

Section
  sectname __stubs
   segname __TEXT
      addr 0x0000000100000f84
      size 0x0000000000000006
    offset 3972
     align 2^1 (2)
    reloff 0
    nreloc 0
     flags 0x80000408
 reserved1 0 (index into indirect symbol table)
 reserved2 6 (size of stubs)
Section
  sectname __stub_helper
   segname __TEXT
      addr 0x0000000100000f8c
      size 0x000000000000001a
    offset 3980
     align 2^2 (4)
    reloff 0
    nreloc 0
     flags 0x80000400
 reserved1 0
 reserved2 0

代码7.2

yingfang:mach-o文件结构-src fangying$ xcrun dyldinfo -lazy_bind a1.out 
lazy binding information (from lazy_bind part of dyld info):
segment section          address    index  dylib            symbol
__DATA  __la_symbol_ptr  0x100001010 0x0000 libSystem        _printf

代码7.3

(gdb) x/2g 0x100001010
0x100001010:    4294971292

代码7.4

(gdb) x/3i 4294971292
   0x100000f9c: pushq  $0x0
   0x100000fa1: jmpq   0x100000f8c

代码7.5

(gdb) x/3i 0x100000f8c
   0x100000f8c: lea    0x75(%rip),%r11        # 0x100001008
   0x100000f93: push   %r11
   0x100000f95: jmpq   *0x65(%rip)        # 0x100001000

代码7.6

(gdb) x/3g 0x100001000
0x100001000:    0x0000000000000000  0x0000000000000000
0x100001010:    0x0000000100000f9c

可运行文件运行过程

依据上面总结。该段总结下可运行文件运行过程。
我总结例如以下:

  • 解析mach-o文件
  • 设置运行环境參数
    • 文本段VM映射參数
    • 载入命令
    • 动态库信息
    • 符号表地址信息
    • 动态符号表地址信息
    • 常亮字符串表地址信息
    • 动态库载入信息
    • 符号函数地址
    • 依赖动态库信息
    • 动态链接器地址信息
  • 依据动态库载入信息,把桩占位符,填写为指定调用_nl_symbol_ptr的汇编指令
  • 依据LC_MAIN的entry point调用指定entry offset偏移地址
  • 运行entry offset相关二进制(逻辑是依照汇编指令,进行运行)
  • 第一次运行到动态库函数时,进行一次懒载入动态绑定。而且动态链接器自己主动改动_la_symbol_ptr区的地址。指向动态库相应符号的地址
  • 第二次运行到动态库函数时,直接jmp到指定的符号地址

>
注意:系统非常多动态库都是共同拥有的,所以XOS做了共享库缓存优化,仅仅要有相关进程使用过相关动态库,在另一进程,动态链接器在填桩时。直接会把桩_la_symbol_ptr区的地址,指向动态库相应符号的地址。

详细看系统怎样载入文件。动态链接文件,以及进入入口函数,能够这里

parse_machfile(
    struct vnode        *vp,       
    vm_map_t        map,
    thread_t        thread,
    struct mach_header  *header,
    off_t           file_offset,
    off_t           macho_size,
    int         depth,
    int64_t         aslr_offset,
    int64_t         dyld_aslr_offset,
    load_result_t       *result
)

mach-o格式和载入方式 – 能够做啥呢

基础非常重要。mach-o格式理解和载入运行逻辑总结。能够帮助我们正确认识到mac os和ios app可运行文件启动过程。

基于该内容。能够做的事情列一下

  • category冲突分析
  • 非OC函数switch
  • bitcode分析
  • 包支持架构分析
  • 常量字符串分析,比方资源为无使用情况分析
  • crash符号化
  • 符号模块查找
  • 学习经典的数据格式,对于设计相关数据协议,网络协议等等。也有非常好启示和參考价值

反过来:假设二进制包越来越大。进程启动速度也会越来越慢。因为读取。解析文件格式会比較慢。

通过对于mach-o文件的分析,对于__TEXT系统都是仅仅读区。程序代码逻辑都在该区。可是也发现因为为了保持代码栈形式的运行。系统对于动态库的函数,不是直接调用动态库的函数地址,而是先调用到数据段的_nl_symbol_ptr区。通过_nl_symbol_ptr的信息调用到__DATA段_la_symbol_ptr区,因为__DATA内存区。用户态能够去改动。因此我们能够利用该特性去替换相关函数调用。详细代码我也在基于fishhook代码总结中。

了解mach-o详细的格式和载入,动态链接过程原理。比方mac上使用DYLD_INSERT_LIBRARIES进行代码注入。或者使用fishhook进行c函数hook。都能非常easy理解。






































以上是关于Mach-O文件格式和程序从载入到运行过程的主要内容,如果未能解决你的问题,请参考以下文章

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

优化 App 的启动时间

Android执行时ART载入类和方法的过程分析

iOS之深入解析插件化架构

iOS逆向之Mach-O文件(上)

mach-o文件格式