工作的需要可能要打包.bundle或者相关的MacOS的动态库,故做一个这样子的笔记。

一.mach-o文件介绍

Mach-O为Mach Object文件格式的缩写,是一种用于可执行文件,目标代码,动态库,内核转储的文件格式,是mac上可执行文件的格式,类似于windows上的PE格式 (Portable Executable ), linux上的elf格式 (Executable and Linking Format)。我们在macOS上编写的C、C++、swift、OC,最终编译链接生成Mach-O可执行文件。
作为a.out格式的替代,Mach-O提供了更强的扩展性,并提升了符号表中信息的访问速度。

二.文件结构

每个Mach-O文件包括一个Mach-O头,然后是一系列的载入命令,再是一个或多个,每个块包括0到255个。Mach-O使用REL再定位格式控制对符号的引用。Mach-O在两级命名空间中将每个符号编码成“对象-符号名”对,在查找符号时则采用线性搜索法。
Mach-O的基本结构,引用了文件中数据页的变长“加载命令”表,也用于Accent核心的可执行文件格式中,而这种格式则是基于来自Spice Lisp的理念。
文件类型可以分为:
  • Executable:应用的主要二进制
  • Dylib Library:动态链接库(又称DSO或DLL)
  • Static Library:静态链接库
  • Bundle:不能被链接的Dylib,只能在运行时使用dlopen( )加载,可当做macOS的插件
  • Relocatable Object File :可重定向文件类型
关于其文件头:有11种类的定义
主要的有:
  1. MH_OBJECT (0x1 )
  • 目标文件(.0)
  • 静态库文件(.a),静态库文件其实就是多个.o文件的合集.比如支持多种cpu建构的.a库文件.
  1. MH_EXECUTE (0x2) 可执行文件,
  • 比如.app文件
  1. MH_DYLIB 动态库文件
  • .dylib文件
  • .framework/xx文件
  1. MH_DYLINKER (0x7) 动态链接编辑器
  • usr/lib/dyld
  1. MH_DYSM 符号文件
  • dSYM/Content/Resources/DWARF/xx常用与app崩溃信息分析

三.Mach-O文件格式

Mach-O是一个以数据块分组的二进制字节流,这些数据块包含元信息,比如字节顺序、CPU类型、数据块大小等等。
典型的Mach-O文件包含三个区域:
1.Header:保存Mach-O的一些基本信息,包括平台、文件类型、指令数、指令总大小,dyld标记Flags等等。
2.Load Commands:紧跟Header,加载Mach-O文件时会使用这部分数据确定内存分布,对系统内核加载器和动态连接器起指导作用。
3.Data:每个segment的具体数据保存在这里,包含具体的代码、数据等等。

四.其数据结构

1.Header
/*
 * 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) */

从上面的代码可以得到如下的解释

我们可以使用MachOview查看具体的可执行文件的详细情况

MachOview

官方GITHUB地址:https://github.com/gdbinit/MachOView

国人做的改版(支持中文显示):https://github.com/zhongjianfeipqy/MachOView

可以直接运行的编译后版本:http://sourceforge.net/projects/machoview/

打开后在上方状态栏打开文件

2.Load Commands

/*
 * The load commands directly follow the mach_header.  The total size of all
 * of the commands is given by the sizeofcmds field in the mach_header.  All
 * load commands must have as their first two fields cmd and cmdsize.  The cmd
 * field is filled in with a constant for that command type.  Each command type
 * has a structure specifically for it.  The cmdsize field is the size in bytes
 * of the particular load command structure plus anything that follows it that
 * is a part of the load command (i.e. section structures, strings, etc.).  To
 * advance to the next load command the cmdsize can be added to the offset or
 * pointer of the current load command.  The cmdsize for 32-bit architectures
 * MUST be a multiple of 4 bytes and for 64-bit architectures MUST be a multiple
 * of 8 bytes (these are forever the maximum alignment of any load commands).
 * The padded bytes must be zero.  All tables in the object file must also
 * follow these rules so the file can be memory mapped.  Otherwise the pointers
 * to these tables will not work well or at all on some machines.  With all
 * padding zeroed like objects will compare byte for byte.
 */
struct load_command {
    uint32_t cmd;       /* type of load command */
    uint32_t cmdsize;   /* total size of command in bytes */
};

大致翻译:

load_commands紧跟mach_header,load_commands展开后的数目与总大小已经在mach_header有记录,所有加载指令都是以cmd、cmdsize起头。cmd字段用该命令类型的常量表示,有专门的结构;cmdsize字段以字节为单位,主要记录偏移量让load command指针进入下一条加载指令,32位架构的cmdsize是以4字节的倍数,64位结构的cmdsize是以8字节的倍数(加载指令永远是这样对齐),不够用0填充字节。文件中的所有表都遵循这样的规则,这样就可以被映射到内存,否则的话指针不能很好地指向。

打开区域显示内容为:

Load Commands下面常见的加载指令
Load Commands中 LC_SEGMENT_64段的数据结构如下(它将会和数据区中一一对应)
/*
 * The 64-bit segment load command indicates that a part of this file is to be
 * mapped into a 64-bit task's address space.  If the 64-bit segment has
 * sections then section_64 structures directly follow the 64-bit segment
 * command and their size is reflected in cmdsize.
 */
struct segment_command_64 { /* for 64-bit architectures */
    uint32_t    cmd;        /* Load Command类型 */
    uint32_t    cmdsize;    /*包含的所有section结构体的大小 */
    char        segname[16];    /* 段名 */
    uint64_t    vmaddr;     /* 映射到虚拟地址的偏移 */
    uint64_t    vmsize;     /* 映射到虚拟地址的大小 */
    uint64_t    fileoff;    /* 相对于当前架构文件的偏移 */
    uint64_t    filesize;   /* 文件大小 */
    vm_prot_t   maxprot;    /* 段页面的最高内存保护 */
    vm_prot_t   initprot;   /* 初始内存保护 */
    uint32_t    nsects;     /* 包含的section数 */
    uint32_t    flags;      /* 段页面标志 */
};

主要有一下四种

注:dylib过后补一篇文章做笔记

3.数据区(DATA)

除了Header和Commands外所有的原始数据。Commands是对数据的汇总提示,而数据区则是真实的数据。Commands与数据区的关系就像size和char*的关系。
Load Commands区域后的各个Section64就是数据区,如果展开Load Commands下的LC_SEGMENT_64可以看到多个Section64,各个Section的具体信息可以在Load Commands后面的部分查到
Section的数据结构为:
struct section_64 { /* for 64-bit architectures */
    char        sectname[16];   /* 节名 */
    char        segname[16];    /* 所属段名 */
    uint64_t    addr;       /* 映射到虚拟地址的偏移 */
    uint64_t    size;       /* 节的大小 */
    uint32_t    offset;     /* 节在当前架构文件中的偏移 */
    uint32_t    align;      /* 节的字节对齐大小n,2^n */
    uint32_t    reloff;     /* 重定位入口的文件偏移 */
    uint32_t    nreloc;     /* 重定位入口个数 */
    uint32_t    flags;      /* 节的类型和属性*/
    uint32_t    reserved1;  /* reserved (for offset or index) */
    uint32_t    reserved2;  /* reserved (for count or sizeof) */
    uint32_t    reserved3;  /* 保留位,以上两同理 */
};

大致有如下内容:

__TEXT:

__DATA:

挑选一些进行详细介绍

1). (__TEXT,__text)

这里存放的是汇编后的代码,当我们进行编译时,每个.m文件会经过预编译->编译->汇编形成.o文件,称之为目标文件。汇编后,所有的代码会形成汇编指令存储在.o文件的(__TEXT,__text)区((__DATA,__data)也是类似)。链接后,所有的.o文件会合并成一个文件,所有.o文件的(__TEXT,__text)数据都会按链接顺序存放到应用文件的(__TEXT,__text)中。

2). (__DATA,__data)

存储数据的section,static在进行非零赋值后会存储在这里,如果static 变量没有赋值或者赋值为0,那么它会存储在(__DATA,__bss)中。

3). Symbol Table

符号表,这个是重点中的重点,符号表是将地址符号联系起来的桥梁。符号表并不能直接存储符号,而是存储符号位于字符串表的位置。

4). String Table

字符串表所有的变量名、函数名等,都以字符串的形式存储在字符串表中。

5). Indirect Symbols (动态符号表)

动态符号表存储的是动态库函数位于符号表的偏移信息。(__DATA,__la_symbol_ptr) section 可以从动态符号表中获取到该section位于符号表的索引数组。

动态符号表

动态符号表并不存储符号信息,而是存储其位于符号表的偏移信息。Fishhook源码看起来比较复杂主要是因为hook的是动态链接的函数,索引和链接关系比较绕。但是我们自己编写的C函数不是动态链接的,而是在编译链接后代码指令就存储在文件内部的函数,因此不会用到动态符号表。接下来我们以static 函数为例,看看如何动态的查找自己编写的函数地址。

 

 

参考:

https://www.jianshu.com/p/5a44f69466cc

https://www.cnblogs.com/dengzhuli/p/9952202.html

https://baike.baidu.com/item/Mach-O/9608283?fr=aladdin

https://www.jianshu.com/p/c51a138c932f?open_source=weibo_search【优化MachOView】

分类: macOS

0 条评论

发表回复

Avatar placeholder

您的电子邮箱地址不会被公开。 必填项已用 * 标注