13. Hook原理介绍

13.1 Objective-C消息传递(Messaging)

对于C/C++这类静态语言,调用一个方法其实就是跳到内存中的某一点并开始执行一段代码。没有任何动态的特性,因为这在编译时就决定好了。

而在 Objective-C 中,[object foo] 语法并不会立即执行 foo 这个方法的代码。它是在运行时给 object 发送一条叫 foo 的消息。这个消息,也许会由 object 来处理,也许会被转发给另一个对象,或者不予理睬假装没收到这个消息。多条不同的消息也可以对应同一个方法实现。这些都是在程序运行的时候动态决定的。

事实上,在编译时你写的 Objective-C 函数调用的语法都会被翻译成一个 C 的函数调用 objc_msgSend() 。比如,下面两行代码就是等价的:

[people TailName:@"Luz" Age:18];

objc_msgSend(people, @selector(TailName:Age:), "Luz", 18);

在 Objective-C 中,类、对象和方法都是一个C的结构体,从 objc/objc.h 和 objc/runtime.h 头文件中,我们可以找到他们的定义:

  typedef struct objc_class *Class;
  struct objc_object {
      Class isa  OBJC_ISA_AVAILABILITY;
  };
  typedef struct objc_object *id;
  
//Class 是一个 objc_class 结构类型的指针, id是一个 objc_object 结构类型的指针.

struct objc_class {
  Class isa  OBJC_ISA_AVAILABILITY;

  #if !__OBJC2__
      Class super_class                                        
      const char *name                                         
      long version                                             
      long info                                                
      long instance_size                                       
      struct objc_ivar_list *ivars                             
      struct objc_method_list **methodLists                    
      struct objc_cache *cache                                 
      struct objc_protocol_list *protocols                     
  #endif
} OBJC2_UNAVAILABLE;
  • isa
    是一个 objective-c Class 类型的指针. 实例对象有个isa的属性,指向Class, 而Class里也有个isa的属性, 指向meteClass. 这里就有个点, 在Objective-C中任何的类定义都是对象.

  • super_class
    指向该类的父类, 如果该类已经是最顶层的根类(如 NSObject 或 NSProxy),那么 super_class 就为 NULL.

objective-c.png
  • name
    类的名字

  • version
    类的版本信息,默认为0

  • info
    供运行期使用的一些位标识。

  • instance_size
    该类的实例变量大小

  • ivars
    成员变量的链表

struct objc_ivar_list {
    int ivar_count                                          
    /* variable length structure */
    struct objc_ivar ivar_list[1]                           
}       
  • methodLists
    方法定义的链表
     struct objc_method_list {  
          struct objc_method_list *obsolete;
          int method_count;
    
          struct objc_method method_list[1];
     };
     
     struct objc_method {  
      SEL method_name;
      char *method_types;   
      IMP method_imp;
    

};


- objc_cache
指向最近使用的方法.用于方法调用的优化  

struct objc_cache {
unsigned int mask /* total = mask + 1 */;
unsigned int occupied;
Method buckets[1];
};


- protocols
    协议的链表

struct objc_protocol_list {
struct objc_protocol_list *next;
long count;
Protocol *list[1];
};


objc_method_list 本质是一个有 objc_method 元素的可变长度的数组。一个 objc_method 结构体中:
- 函数名,也就是SEL
- 表示函数原型的字符串 (见 Type Encoding) 
- 函数的实现IMP

#### 13.2 Method Swizzling示例
  以上面可知方法的名字(SEL)跟方法的实现(IMP,指向 C 函数的指针)一一对应。Swizzle 一个方法其实就是在程序运行时对 objc_method_list 里做点改动,让这个方法的名字(SEL)对应到另个IMP。 
  
   Method Swizzling(方法调配技术),仅针对Objective-C方法有效。Method Swizzling 利用 Runtime 特性把一个方法的实现与另一个方法的实现进行替换。
  //涉及到的主要方法
  class_addMethod
  class_replaceMethod
  method_exchangeImplementations
- 为什么在load里面调用?
   一般情况下,类别里的方法会重写掉主类里相同命名的方法。如果有两个类别实现了相同命名的方法,只有一个方法会被调用。
但 +load是个特例,当一个类被读到内存的时候, runtime 会给这个类及它的每一个类别都发送一个 +load: 消息。(多个类别时需要防止多次执行)

- object_getClass(obj)与[obj class]的区别?
参考资料:http://www.jianshu.com/p/ae5c32708bc6

13.3 Fishhook

fishhook苹果系统下的一种C函数的hook方案,是facebook提供的一个动态修改链接Mach-O符号表的开源工具。Mach-O为Mach Object文件格式的缩写,也是用于iOS可执行文件,目标代码,动态库,内核转储的文件格式。Mach-O有自己的dylib规范(/usr/include/mach-o/loader.h文件里面)。

官网:https://github.com/facebook/fishhook

  • Hook示例
#import <Foundation/Foundation.h>
#import <dlfcn.h>
#import "fishhook.h"

static int (*orig_close)(int);
static int (*orig_open)(const char *, int, ...);

int my_close(int fd) {
    printf("Calling real close(%d)\n", fd);
    return orig_close(fd);
}

int my_open(const char *path, int oflag, ...) {
    va_list ap = {0};
    mode_t mode = 0;
    
    if ((oflag & O_CREAT) != 0) {
        // mode only applies to O_CREAT
        va_start(ap, oflag);
        mode = va_arg(ap, int);
        va_end(ap);
        printf("Calling real open('%s', %d, %d)\n", path, oflag, mode);
        return orig_open(path, oflag, mode);
    } else {
        printf("Calling real open('%s', %d)\n", path, oflag);
        return orig_open(path, oflag, mode);
    }
}


int main(int argc, const char * argv[]) {
    @autoreleasepool {
        // insert code here...
        //NSLog(@"Hello, World!");
        struct rebinding rbd[2];
        rbd[0].name = "close";
        rbd[0].replacement = my_close;
        rbd[0].replaced = (void*)&orig_close;
        
        rbd[1].name = "open";
        rbd[1].replacement = my_open;
        rbd[1].replaced = (void*)&orig_open;
        
        rebind_symbols(rbd, 2);
        
        // Open our own binary and print out first 4 bytes (which is the same
        // for all Mach-O binaries on a given architecture)
        int fd = open(argv[0], O_RDONLY);
        uint32_t magic_number = 0;
        read(fd, &magic_number, 4);
        printf("Mach-O Magic Number: 0x%x \n", magic_number);
        close(fd);
    }
    return 0;
}

  • 使用fishHook监听微信文件读写
    Makefile 文件
THEOS_DEVICE_IP = 192.168.1.113
DEBUG = 1
ARCHS = armv7 arm64 
TARGET = iphone:latest:8.0  
include $(THEOS)/makefiles/common.mk

TWEAK_NAME = WeChatReProject
WeChatReProject_FILES = Tweak.xm fishhook.c
WeChatReProject_FRAMEWORKS = UIKit Foundation CoreLocation
WeChatReProject_CFLAGS = -fobjc-arc
include $(THEOS_MAKE_PATH)/tweak.mk

after-install::
    install.exec "killall -9 WeChat"

clean::
    rm -rf ./packages/* 

Tweak.xm文件

#import<UIKit/UIKit.h>
#import<CoreLocation/CoreLocation.h>
#import<CoreLocation/CLLocation.h>
#import "fishhook.h"

@interface SeePeopleNearByLogicController
- (void)onRetrieveLocationOK:(id)arg1;
@end

static int (*orig_close)(int);
static int (*orig_open)(const char *, int, ...);

int my_close(int fd) {
    printf("Calling real close(%d)\n", fd);
    return orig_close(fd);
}

int my_open(const char *path, int oflag, ...) {
    va_list ap = {0};
    mode_t mode = 0;
    
    if ((oflag & O_CREAT) != 0) {
        // mode only applies to O_CREAT
        va_start(ap, oflag);
        mode = va_arg(ap, int);
        va_end(ap);
        NSLog(@"Calling real open('%s', %d, %d)", path, oflag, mode);
        return orig_open(path, oflag, mode);
    } else {
        NSLog(@"Calling real open('%s', %d)", path, oflag);
        return orig_open(path, oflag, mode);
    }
}

%hook MicroMessengerAppDelegate
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions 
{
    struct rebinding rbd[2];
    rbd[0].name = "close";
    rbd[0].replacement = (void*)my_close;
    rbd[0].replaced = (void**)&orig_close;
    
    rbd[1].name = "open";
    rbd[1].replacement = (void*)my_open;
    rbd[1].replaced = (void**)&orig_open;
    
    rebind_symbols(rbd, 2);
    NSLog(@"begin hook");
    return %orig;
}
%end

%hook SeePeopleNearByLogicController
- (void)onRetrieveLocationOK:(id)arg1
{
    CLLocation *location = [[CLLocation alloc] initWithLatitude:31.154352 longitude:121.42562];
    %orig(location);
    
    UIAlertView *alertView = [[UIAlertView alloc] 
    initWithTitle:[@"onRetrieveLocationOK" 
    stringByAppendingString:[[NSString alloc] 
    initWithFormat:@"location is %@", location]] 
    message:nil 
    delegate:self 
    cancelButtonTitle:@"ok" 
    otherButtonTitles:nil];
    
    [alertView show];

}
%end
 

13.4 Mach-o文件结构

Mach-o包含三个基本区域:

  • 头部(header structure)

  • 加载命令(load command)。

  • 段(segment)。可以拥有多个段(segment),每个段可以拥有零个或多个区域(section)。每一个段(segment)都拥有一段虚拟地址映射到进程的地址空间。

  • 链接信息。一个完整的用户级Mach-o文件的末端是链接信息。其中包含了动态加载器用来链接可执行文件或者依赖库所需 使用的符号表,字符串表等等。

mach-o.png
  • 使用MachOView查看
  • 文件头 mach64 Header
  • 加载命令 Load Commands
  • 文本段 __TEXT
  • 数据段 __DATA
  • 动态库加载信息 Dynamic Loader Info
  • 入口函数 Function Starts
  • 符号表 Symbol Table
  • 动态库符号表 Dynamic Symbol Table
  • 字符串表 String Table
13.4.1 Mach-o的header
  • otool工具来查看Mach-o的头部,看看都包含哪些信息:
➜ otool -hv WeChat.decrypted
WeChat.decrypted (architecture armv7):
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
   MH_MAGIC     ARM         V7  0x00     EXECUTE    76       7416   NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE
WeChat.decrypted (architecture arm64):
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64   ARM64        ALL  0x00     EXECUTE    76       8168   NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE
  • 使用hexdump或者UE编辑器查看
➜ hexdump -C WeChatReProject.dylib | more
00000000  ce fa ed fe 0c 00 00 00  09 00 00 00 06 00 00 00  |................|
00000010  15 00 00 00 fc 07 00 00  85 00 10 00 01 00 00 00  |................|
00000020  d0 01 00 00 5f 5f 54 45  58 54 00 00 00 00 00 00  |....__TEXT......|
00000030  00 00 00 00 00 00 00 00  00 80 00 00 00 00 00 00  |................|
00000040  00 80 00 00 05 00 00 00  05 00 00 00 06 00 00 00  |................|

头部的的结构如下:

  struct mach_header {
  uint32_t    magic;      
  cpu_type_t  cputype;    
  cpu_subtype_t   cpusubtype; 
  uint32_t    filetype;   
  uint32_t    ncmds;      
  uint32_t    sizeofcmds; 
  uint32_t    flags;      
  };

  struct mach_header_64 {
      uint32_t    magic;             
      cpu_type_t  cputype;           
      cpu_subtype_t   cpusubtype;    
      uint32_t    filetype;          
      uint32_t    ncmds;             
      uint32_t    sizeofcmds;       
      uint32_t    flags;            
      uint32_t    reserved;          
  };
  ```  
  • mach_header各个字段的具体意义:

    • magic
      魔数,系统加载器通过改字段快速,判断该文件是用于32位or64位。
     //32位魔数
     #define MH_MAGIC    0xfeedface  
     #define MH_CIGAM    0xcefaedfe  
    
     //64位魔数
     #define MH_MAGIC_64 0xfeedfacf 
     #define MH_CIGAM_64 0xcffaedfe 
    
  • cputype
    CPU类型以及子类型字段,该字段确保系统可以将适合的二进制文件在当前架构下运行。

    #define CPU_TYPE_ARM     ((cpu_type_t) 12)
    #define CPU_TYPE_ARM64   (CPU_TYPE_ARM | CPU_ARCH_ABI64)
    
  • cpusubtype
    CPU指定子类型,对于inter,arm,powerpc等CPU架构,其都有各个阶段和等级的CPU芯片,该字段就是详细描述其支持CPU子类型。

    #define CPU_SUBTYPE_ARM_V7       ((cpu_subtype_t) 9)
    #define CPU_SUBTYPE_ARM64_ALL    ((cpu_subtype_t) 0)
    #define CPU_SUBTYPE_ARM64_V8     ((cpu_subtype_t) 1)
    
  • filetype
    说明该mach-o文件类型(可执行文件,库文件,核心转储文件,内核扩展,DYSM文件,动态库等)

    #define  MH_OBJECT   0x1     //.o目录文件
    #define  MH_EXECUTE  0x2     //a.out可主动执行文件
    #define  MH_DYLIB    0x6     //.dylib文件
    #define  MH_DSYM     0xa     //.dSYM文件   
    #define  MH_KEXT_BUNDLE  0xb //.kext驱动文件     
    
  • ncmds
    说明加载命令条数

  • sizeofcmds
    表示加载命令大小

  • flags
    标志位,该字段用位表示二进制文件支持的功能,主要是和系统加载,链接相关。

    #define    MH_NOUNDEFS    0x1        // 目前没有未定义的符号,不存在链接依赖
    #define    MH_DYLDLINK    0x4        // 该文件是dyld的输入文件,无法被再次静态链接
    #define    MH_PIE 0x200000          // 加载程序在随机的地址空间,只在 MH_EXECUTE中使用
    #define    MH_TWOLEVEL    0x80      // 两级名称空间
    
    • 随机地址空间
      进程每一次启动,地址空间都会简单地随机化。
      如果采用传统的方式,程序的每一次启动的虚拟内存镜像都是一致的,黑客很容易采取重写内存的方式来破解程序。采用ASLR-地址空间配置随机加载(Address space layout randomization)将可执行程序随机装载到内存里,可以有效的避免缓冲区溢出攻击。

    • dyld(/usr/lib/dyld)
      动态链接器:当内核执行LC_DYLINK时,链接器会启动,查找进程所依赖的动态库,并加载到内存中。

    • 二级名称空间
      这是dyld的一个独有特性,符号空间中还包括所在库的信息,这样子就可以让两个不同的库导出相同的符号。

13.4.2 Load Commands - 加载命令

Mach-O文件包含非常详细的加载指令,这些指令非常清晰地指示加载器如何设置并且加载二进制数据。Load Commands信息紧紧跟着二进制文件头后面。加载命令的数目以及总的大小在header中已经给出。

  • load command的结构如下:
struct load_command {
    uint32_t cmd;        /* type of load command */
    uint32_t cmdsize;    /* total size of command in bytes */
};
  • 使用otool命令查看加载指令信息
MachDemo 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
 ...
  • CMD字段的解释

    • LC_SEGMENT_64
      将文件中(32位或64位)的段映射到进程地址空间中。

    • LC_SYMTAB
      符号表地址。

    • LC_DYSYMTAB
      动态符号表地址

    • LC_DYLD_INFO_ONLY
      动态链接相关信息

    • LC_LOAD_DYLINKER
      加载一个动态链接器(动态库加载器),通常路径是“/usr/lib/dyld”。

    • LC_LOAD_DYLIB:
      加载一个动态链接共享库。如“/usr/lib/libSystem.B.dylib”,这是C标准库。每个库由动态链接器加载并包含一个符号表。

    • LC_UUID
      文件的唯一标识,crash解析中也会有该值,去确定dysm文件和crash文件是匹配的。

    • LC_VERSION_MIN_MACOSX
      二进制文件要求的最低操作系统版本

    • LC_MAIN
      设置程序主线程的入口地址和栈大小

    • LC_SOURCE_VERSION
      构建该二进制文件使用的源代码版本

    • LC_FUNCTION_STARTS
      定义一个函数起始地址表,使调试器和其他程序易于看到一个地址是否在函数内

    • LC_DATA_IN_CODE
      定义在代码段内的非指令数据

  • LC_SEGMENT_64和LC_SEGMENT是加载的主要命令,它负责指导内核来设置进程的内存空间。

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 */
};

struct segment_command_64 { /* for 64-bit architectures */
    uint32_t    cmd;        /* LC_SEGMENT_64 */
    uint32_t    cmdsize;    /* includes sizeof section_64 structs */
    char        segname[16];    /* segment name */
    uint64_t    vmaddr;     /* memory address of this segment */
    uint64_t    vmsize;     /* memory size of this segment */
    uint64_t    fileoff;    /* file offset of this segment */
    uint64_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 */
};

- cmd
  就是Load commands的类型,这里LC_SEGMENT_64代表将文件中64位的段映射到进程的地址空间。LC_SEGMENT_64和LC_SEGMENT的结构差别不大。

- cmdsize
  代表load command的大小

- segname 
  16字节的段名字

- vmaddr 
  段的虚拟内存起始地址

- vmsize 
  段的虚拟内存大小

- fileoff 
  段在文件中的偏移量

- filesize 
  段在文件中的大小

- maxprot 
   段页面所需要的最高内存保护(1=r,2=w,4=x)

- initprot 
  段页面初始的内存保护

- nsects 
  段中包含section的数量

- flags 
  其他杂项标志位
13.4.3 段(segment)和节(section)

“__TEXT"代表的是Segment,小写的”__text"代表 Section

  • __PAGEZERO
    一个全用0填充的段,用于抓取空指针引用(非法内存访问)。这通常不会占用物理内存空间。

  • __TEXT
    本段只有可执行代码和其他只读数据。

    __text           主程序代码  
    
    __stubs         用于动态库链接的桩   
    
    __stub_helper   用于动态库链接的桩的辅助    
    
    __cstring       常量字符串符号表描述信息,通过该区信息,可以获得常量字符串符号表地址  
        
    __unwind_info  存储堆栈展开信息供处理异常。
    
     __eh_frame:  提供堆栈展开信息,用于异常处理
     
    ➜ otool -tv a.out 
    a.out:
    (__TEXT,__text) section
    _main:
    0000000100000f30    pushq   %rbp
    0000000100000f31    movq    %rsp, %rbp
    0000000100000f34    subq    $0x20, %rsp
    0000000100000f38    leaq    0x47(%rip), %rax
    0000000100000f3f    movl    $0x0, -0x4(%rbp)
    0000000100000f46    movl    %edi, -0x8(%rbp)
    0000000100000f49    movq    %rsi, -0x10(%rbp)
    0000000100000f4d    movq    %rax, %rdi
    0000000100000f50    movb    $0x0, %al
    0000000100000f52    callq   0x100000f64
    0000000100000f57    xorl    %ecx, %ecx
    0000000100000f59    movl    %eax, -0x14(%rbp)
    0000000100000f5c    movl    %ecx, %eax
    0000000100000f5e    addq    $0x20, %rsp
    0000000100000f62    popq    %rbp
    0000000100000f63    retq
    
  • __DATA
    用于读取和写入数据的一个段。

    __nl_symbol_ptr:非延迟导入符号指针表。
    
    __la_symbol_ptr:延迟导入符号指针表。
    
  • __LINKEDIT
    包含给动态链接器的原始数据的段,包括符号和字符串表,压缩动态链接信息,以及动态符号表等。

  • Section的数据结构

    struct section { /* for 32-bit architectures */
        char        sectname[16];   /* name of this section */
        char        segname[16];    /* segment this section goes in */
        uint32_t    addr;       /* memory address of this section */
        uint32_t    size;       /* size in bytes of this section */
        uint32_t    offset;     /* file offset of this section */
        uint32_t    align;      /* section alignment (power of 2) */
        uint32_t    reloff;     /* file offset of relocation entries */
        uint32_t    nreloc;     /* number of relocation entries */
        uint32_t    flags;      /* flags (section type and attributes)*/
        uint32_t    reserved1;  /* reserved (for offset or index) */
        uint32_t    reserved2;  /* reserved (for count or sizeof) */
    };

    struct section_64 { /* for 64-bit architectures */
        char        sectname[16];   /* name of this section */
        char        segname[16];    /* segment this section goes in */
        uint64_t    addr;       /* memory address of this section */
        uint64_t    size;       /* size in bytes of this section */
        uint32_t    offset;     /* file offset of this section */
        uint32_t    align;      /* section alignment (power of 2) */
        uint32_t    reloff;     /* file offset of relocation entries */
        uint32_t    nreloc;     /* number of relocation entries */
        uint32_t    flags;      /* flags (section type and attributes)*/
        uint32_t    reserved1;  /* reserved (for offset or index) */
        uint32_t    reserved2;  /* reserved (for count or sizeof) */
        uint32_t    reserved3;  /* reserved */
    };
    
    
    sectname:比如__text、__stubs

    segname :该section所属的segment,比如__TEXT
    
    addr : 该section在内存的起始位置
    
    size: 该section的大小
    
    offset: 该section的文件偏移
    
    align : 字节大小对齐(以多少字节对齐,一般是2的乘幂)
    
    reloff :重定位入口的文件偏移
    
    nreloc: 需要重定位的入口数量
    
    flags:包含section的type和attributes
   
    reserved: 预留的字段
13.4.4 动态库链接信息
  • LC_DYLD_INFO_ONLY
    根据该加载命令的字段偏移,可以得到压缩动态数据信息区(动态库绑定,地址重定向等信息)。
    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;   /* file offset to rebase info  */
     uint32_t   rebase_size;  /* size of rebase info   */
     uint32_t   bind_off; /* file offset to binding info   */
     uint32_t   bind_size;    /* size of binding info  */      
     uint32_t   weak_bind_off;    /* file offset to weak binding info   */
     uint32_t   weak_bind_size;  /* size of weak binding info  */
     uint32_t   lazy_bind_off;    /* file offset to lazy binding info */
     uint32_t   lazy_bind_size;  /* size of lazy binding infs */ 
     uint32_t   export_off;   /* file offset to lazy binding info */
     uint32_t   export_size;  /* size of lazy binding infs */
    };
    
     重定向数据rebase(命令码:高四位 低四位)
     11:  高四位0x10 表示设置立即数类型   低四位0x01 表示立即数类型为指针
     22:  表示REBAE_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB + 2 重定向到数据段第2个section     
     意思就是:重定向到数据段第二个section,该数据段信息为一个指针。
     e.g: 在demo中是[0x100001010->_printf]
    
    绑定数据 bind:
    进行动态绑定依赖的dyld的函数(dyld_stub_binder)
    
    弱绑定数据 weak bind:
    用于弱绑定动态库,就像weak_framework一样
    
    延时绑定数据 lazy bind:
    对于需要从动态库加载的函数符号(_printf)
    
    export数据:
    用于对外开放的函数(_add、_main)
    
    ➜nm a.out       
      0000000100000000 T __mh_execute_header
      0000000100000f00 T _add
      0000000100000f20 T _main
                       U _printf
                       U dyld_stub_binder
                                        
    
13.4.5 动态库链接器运行方式
VA  : 虚拟地址,也就是程序被加载到内存空间中的地址
RVA : 以虚拟地址前边加上个“相对的”,也就是说它还是按虚拟地址来换算,只不过不是从0开始。
RAW :一般称文件偏移,你把一个文件看成一个连续的字节流,OFFSET就是这个字节流中的位置。
  • MachoDemo.m中main函数对printf调用的汇编代码:
callq   0x100000f84 ## symbol stub for: _printf

  汇编代码中0x100000f84,这个地址是 __TEXT段的section __stubs区的地址。即JMP到__stubs(桩区)
  • 0x100000f84地址,是一段汇编指令

    0x100000f84:FF2586000000
    等效于:jmpq *0x86(%rip) # 0x100001010
    跳转地址 = 当前地址+加指令长度+跳转偏移 = 0x100000f84 + 0x6 + 0x86
    
  • 0x100001010地址,是指向__DATA段__la_symbol_ptr区。

    0x100001010:0000000100000f9c
    
  • 0x100000f9c 这个地址是 __TEXT段的section __stub_helper区的地址

     0x100000f9c: pushq $0x0
     0x100000fa1: jmpq 0x100000f8c
    
  • 0x100000f8c 这个地址是__TEXT段section __stub_helper区的起始地址。

     0x100000f8c: lea    ["0x100001008->ABSOLUTE"](%rip),%r11        
     0x100000f93: push   %r11
     0x100000f95: jmpq   *[0x100001000->dyld_stub_binder](%rip)  
     0x100000f9c: pushq $0x0
     0x100000fa1: jmpq 0x100000f8c
    
  • 0x100001000地址,恰好是__DATA段section __nl_symbol_ptr区的起始地址。
    该地址指向的数据值位为:

    0x100001000:0x0000000000000000 
    0x100001008:0x0000000000000000 
    
  • 说明:

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

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

13.4.6 可执行文件的加载过程

参考资料:
https://opensource.apple.com/tarballs/dyld/dyld-360.18.tar.gz

https://opensource.apple.com/source/xnu/xnu-2422.1.72/bsd/kern/kern_exec.c

https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/MachOTopics/1-Articles/executing_files.html

  • 解析mach-o文件,确定该文件是一个有效的Mach-O文件,所以内核为程序(fork)创建一个进程并开始程序执行过程(execve)

  • 加载命令。内核配合动态连接器,进入加载指令指定分配的地址空间。段的虚拟内存保护标志也按指示添加上(例如__TEXT是只读)

    • 动态库信息
    • 符号表地址信息
    • 动态符号表地址信息
    • 常量字符串表地址信息
    • 动态库加载信息
    • 符号函数地址
    • 依赖动态库信息
    • 动态链接器路径信息
  • 根据动态库加载信息,把__DATA段section __nl_symbol_ptr区占位符换为调用dylib的dyld_stub_binder函数的汇编指令。

  • 根据LC_MAIN的entry point调用指定entry offset偏移地址执行entry offset相关汇编指令。

  • 第一次运行到动态库函数时,进行一次懒加载动态绑定,并且动态链接器自动修改_la_symbol_ptr区的地址,指向动态库对应符号的地址。

  • 第二次运行到动态库函数时,直接jmp到指定的符号地址

总结:

 通过对Mach-O文件的分析,我们知道代码段(__TEXT)都是只读区,包含了程序逻辑处理。但是对于动态库的函数调用借助了数据段(__DATA)的_la_symbol_ptr区和_nl_symbol_pt区。用户可以去修改这两个区的数据,因此我们可以利用这个特性去替换相关函数的调用(如:fishhook)。

注:通过DYLD_INSERT_LIBRARIES进行代码注入是dyld提供的功能。
13.4.7 fishhook工作原理
int rebind_symbols(struct rebinding rebindings[], size_t rebindings_nel) {
  //在钩子链表头增加新的钩子
  int retval = prepend_rebindings(&_rebindings_head, rebindings, rebindings_nel);
  if (retval < 0) {
    return retval;
  }
  if (!_rebindings_head->next) { //首次调用
    //注册系统回调
    _dyld_register_func_for_add_image(_rebind_symbols_for_image);
  } else {
    uint32_t c = _dyld_image_count();
    for (uint32_t i = 0; i < c; i++) {
      _rebind_symbols_for_image(_dyld_get_image_header(i), _dyld_get_image_vmaddr_slide(i));
    }
  }
  return retval;
}
//回调函数(参数1:mach_header的地址,参数2:slide 随机偏移量)
//由于ASLR的缘故,导致程序实际虚拟内存地址与对应的Mach-o结构中的地址不一致,有一个偏移量
//slide,slide是程序装在时随机生成的随机数。
static void _rebind_symbols_for_image(const struct mach_header *header,
                                      intptr_t slide) {                            
    rebind_symbols_for_image(_rebindings_head, header, slide);
}
static void rebind_symbols_for_image(struct rebindings_entry *rebindings,
                                     const struct mach_header *header,
                                     intptr_t slide) {
  Dl_info info;
  if (dladdr(header, &info) == 0) {
    return;
  }

  segment_command_t *cur_seg_cmd;
  segment_command_t *linkedit_segment = NULL;
  struct symtab_command* symtab_cmd = NULL;
  struct dysymtab_command* dysymtab_cmd = NULL;

  //计算load commands区域的位置(紧跟mach_header之后)
  uintptr_t cur = (uintptr_t)header + sizeof(mach_header_t);
  
  //遍历加载指令区域
  for (uint i = 0; i < header->ncmds; i++, cur += cur_seg_cmd->cmdsize) {
    cur_seg_cmd = (segment_command_t *)cur;
    //LC_SEGMENT指令
    if (cur_seg_cmd->cmd == LC_SEGMENT_ARCH_DEPENDENT) {  
      //__LINKEDIT段
      if (strcmp(cur_seg_cmd->segname, SEG_LINKEDIT) == 0) {
        linkedit_segment = cur_seg_cmd;
      }
    } else if (cur_seg_cmd->cmd == LC_SYMTAB) { //符号表
      symtab_cmd = (struct symtab_command*)cur_seg_cmd;
    } else if (cur_seg_cmd->cmd == LC_DYSYMTAB) {//动态符号表
      dysymtab_cmd = (struct dysymtab_command*)cur_seg_cmd;
    }
  }

  if (!symtab_cmd || !dysymtab_cmd || !linkedit_segment ||
      !dysymtab_cmd->nindirectsyms) {
    return;
  }

  //计算mach-o header在内存空间中的位置
  uintptr_t linkedit_base = (uintptr_t)slide + linkedit_segment->vmaddr - linkedit_segment->fileoff;
  
  //计算Symbol Table的位置
  nlist_t *symtab = (nlist_t *)(linkedit_base + symtab_cmd->symoff);
  
  //计算String Table的位置
  char *strtab = (char *)(linkedit_base + symtab_cmd->stroff);

  //计算Dynamic Symbol Table的位置 
  uint32_t *indirect_symtab = (uint32_t *)(linkedit_base + dysymtab_cmd->indirectsymoff);

  //计算load commands区域的位置(紧跟mach_header之后)
  cur = (uintptr_t)header + sizeof(mach_header_t);
  for (uint i = 0; i < header->ncmds; i++, cur += cur_seg_cmd->cmdsize) {//遍历
    cur_seg_cmd = (segment_command_t *)cur;
    //LC_SEGMENT
    if (cur_seg_cmd->cmd == LC_SEGMENT_ARCH_DEPENDENT) {
      //数据段(__DATA)
      if (strcmp(cur_seg_cmd->segname, SEG_DATA) != 0 &&
          strcmp(cur_seg_cmd->segname, SEG_DATA_CONST) != 0) {
        continue;
      }
      for (uint j = 0; j < cur_seg_cmd->nsects; j++) {
        section_t *sect =
          (section_t *)(cur + sizeof(segment_command_t)) + j;
          //__la_symbol_ptr区
        if ((sect->flags & SECTION_TYPE) == S_LAZY_SYMBOL_POINTERS) {
          perform_rebinding_with_section(rebindings, sect, slide, symtab, strtab, indirect_symtab);
        }
        //__nl_symbol_ptr区
        if ((sect->flags & SECTION_TYPE) == S_NON_LAZY_SYMBOL_POINTERS) {
          perform_rebinding_with_section(rebindings, sect, slide, symtab, strtab, indirect_symtab);
        }
      }
    }
  }
}
static void perform_rebinding_with_section(struct rebindings_entry *rebindings,
                                           section_t *section,
                                           intptr_t slide,
                                           nlist_t *symtab,
                                           char *strtab,
                                           uint32_t *indirect_symtab) {
  //计算(延时/非延时)加载区在indirect symtab表中的位置                                         
  uint32_t *indirect_symbol_indices = indirect_symtab + section->reserved1;
  
  //计算(延时/非延时)加载区的地址
  void **indirect_symbol_bindings = (void **)((uintptr_t)slide + section->addr);
  
  //计算(延时/非延时)加载区的大小,并遍历
  for (uint i = 0; i < section->size / sizeof(void *); i++) {
    uint32_t symtab_index = indirect_symbol_indices[i];
    if (symtab_index == INDIRECT_SYMBOL_ABS || symtab_index == INDIRECT_SYMBOL_LOCAL ||
        symtab_index == (INDIRECT_SYMBOL_LOCAL   | INDIRECT_SYMBOL_ABS)) {
      continue;
    }
    //获取符号在String Table中的偏移
    uint32_t strtab_offset = symtab[symtab_index].n_un.n_strx;
    //获取符号名字
    char *symbol_name = strtab + strtab_offset;
    if (strnlen(symbol_name, 2) < 2) {
      continue;
    }
    struct rebindings_entry *cur = rebindings;
    while (cur) {
     //遍历钩子链表,将替换成新实现,保存老实现 
      for (uint j = 0; j < cur->rebindings_nel; j++) {
        if (strcmp(&symbol_name[1], cur->rebindings[j].name) == 0) {
          if (cur->rebindings[j].replaced != NULL &&
              indirect_symbol_bindings[i] != cur->rebindings[j].replacement) {
            *(cur->rebindings[j].replaced) = indirect_symbol_bindings[i];
          }
          indirect_symbol_bindings[i] = cur->rebindings[j].replacement;
          goto symbol_loop;
        }
      }
      cur = cur->next;
    }
  symbol_loop:;
  }
}
  • fishhook官方原理图
fishhook.png
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,126评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,254评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,445评论 0 341
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,185评论 1 278
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,178评论 5 371
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,970评论 1 284
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,276评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,927评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,400评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,883评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,997评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,646评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,213评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,204评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,423评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,423评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,722评论 2 345

推荐阅读更多精彩内容