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理解。

时间： 2024-08-26 23:50:51

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

程序的载入和运行（五）——《x86汇编语言：从实模式到保护模式》读书笔记25

程序的载入和运行(五)--<x86汇编语言:从实模式到保护模式>读书笔记25 前面几篇博文最终把代码分析完了.这篇就来说说代码的编译.运行和调试. 1.代码的编译及写入镜像文件 之前我们都是在命令行输入命令进行编译和写入.源文件少的时候还不认为麻烦,当源文件多了,就会认为特别麻烦.有没有简单的方法呢? 当然有,就是用make工具. 1.1.什么是make工具 make是一个命令工具,它解释Makefile中的指令.在Makefile文件里描写叙述了整个project全部文件的编译顺序.编译规则

1.3—一个典型的JAVA程序的编写和运行过程

JAVA语言应用范围 桌面应用编程 WEB客户端编程 WEB服务器编程 手机编程 机器人编程 第一个JAVA程序 JAVA开发环境搭建 下载:Download J2SDK (Java  2 Software  Development Kit) from http://java.sun.com 安装:run the executable(跟普通软件安装一样,点击下一步就OK!)  环境变量配置: 环境变量(就是为相关命令提供一个路径信息,告诉他到哪里去找相关文件信息): 设置: 新增系统环境变量J

Android程序能够构建和运行，但是报以下报错，为什么？

安卓程序写完之后能够构建和运行,但是会报以下的错误.不知道原因为何?求大神解答. 网上说的是混淆编译的原因,不过程序没有开启混淆编译. Error:warning: Ignoring InnerClasses attribute for an anonymous inner class Error:(com.alipay.android.phone.mrpc.core.c) that doesn't come with an Error:associated EnclosingMethod at

c#通过app.manifest使程序以管理员身份运行

通常我们使用c#编写的程序不会弹出这个提示,也就无法以管理员身分运行.微软的操作系统使用微软的产品方法当然是有的,通过app.manifest配置可以使程序打开的时候,弹出UAC提示需要得到允许才可以继续,这样就获得了管理员的权限来执行程序 微软在Windows Vista开始引入了UAC(用户帐户控制)新技术(点击这儿了解什么是UAC).当程序执行时需要权限的话,UAC会弹出警告消息:让用户确认是否同意允许这个程序改变你的计算机配置,windows需要得到你的许可才可以让程序继续执行下去. 通

一起C语言中程序时序问题的排查过程

[文章摘要] 对于由多个模块协同工作的软件来说,程序处理的时序是很重要的.当消息处理的顺序出现混乱时,程序就会出现异常. 本文基于作者的实际项目经验.对软件模块之间的时序问题进行了具体的分析,为相关软件问题的分析及解决提供了故意的參考. [关键词] C语言  时序  模块  开发  消息 一.问题描写叙述 在某软件版本号中,有两个模块(模块A与模块B)之间要进行通信. 通信链路建立起来之后.模块A向模块B发消息,消息中携带了用户号码及序列号.在消息发送成功之后,模块A依照序列号将用户号码存放到一

程序启动和运行过程

摘抄自:http://www.cnblogs.com/kenshincui/p/3890880.html#runProcess 程序的运行过程 在几乎所有的程序开发中程序一般都是从main函数开始运行的,那么IOS程序也不例外,在上图中我们可以看到Xcode为我们生成了一个main.m文件: // // main.m // FirstIOS // // Created by Kenshin Cui on 14-2-23. // Copyright (c) 2014年 Kenshin Cui. A

从内存中分析程序的运行过程

我觉得图形是最可以直观一种解释方法,所以先把程序运行过程的图形解析流程给大家,通过图形来一步一步的理解才是最让人清楚,直观的: 流程图懂了,好多事情也就懂了!

VS2010的MFC对话框程序中添加菜单栏的过程

VS2010的MFC对话框程序中添加菜单栏的过程 最近在看一个用MFC写的界面的项目的代码,在代码和界面中一直没有看到关于菜单控件是如何添加进对话框的,于是就百度了下.结果,与其它控件(Button等)添加的方式不一样: VS2010的MFC对话框程序中添加菜单栏的过程大致分了这五步. 一.将Menu加入Resource视图中 在WorkSpace中的Resource视图下,在左边目录的任意位置上,先右键-->选择Insert Resource(插入资源)选项,在弹出的对话框中选择Menu以后,

DOS环境下含包并引用第三方jar的java程序的编译及运行

DOS环境下含包并引用第三方jar的java程序的编译及运行 1.程序目录机构 bin:class文件生成目录 lib:第三方jar包目录 src:源程序文件目录 2.程序代码: 3.程序编译 javac –classpath .;..\lib\commons-lang-2.3.jar -d ..\bin com\Test.java 4.编译后的程序目录: 5.运行程序及结果显示 java -classpath .;..\lib\commons-lang-2.3.jar com.Test