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.
name
类的名字version
类的版本信息,默认为0info
供运行期使用的一些位标识。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文件的末端是链接信息。其中包含了动态加载器用来链接可执行文件或者依赖库所需 使用的符号表,字符串表等等。
- 使用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
- magic
-
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
解析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官方原理图