符号绑定的另一种打开方式
懒加载和非懒加载
iOS对于引用的外部符号,分为Lazy Symbol
和Non-Lazy Symbol
,分别存储在__DATA,__got
节和__DATA,__la_symbol_ptr
节。
Non-Lazy Symbol
符号在dyld加载模块的时候,就会将真实的函数地址写入到对应的地址中,实现绑定。而Non-Lazy Symbol
则会在第一次调用该函数的时候,为其动态寻找真实函数地址并进行绑定。
facebook基于符号绑定机制,写出了hook神器fishhook
,通过查找符号指针并替换,从而达到hook效果!!!
然而,基于模块检测反hook,却甚是烦人。你可能会有反反hook来应付,但是它也有可能会有反反反hook来对付你~~~
那么,怎么才能终结这场hook与反hook的心理战呢?
Mach-O View 分析动态符号绑定过程
简单分析一下Lazy Symbol
的绑定过程:
这里以NSLog
为例:
可以看出,符号NSLog
所指向的地址为:0x0000000100006474。
转化为文件偏移为:0x0000000100006474 - 0x100008078 + 32888 = 0x6474;
到文件偏移为0x6474
的位置查看:
这是一段可执行代码,地址0x6474处的意思是:读取0x647c位置处的四个字节的数据(0x1d),保存到w16寄存器。然后无条件跳转到0x645c(这里的地址,全部都是指文件偏移)。
这段代码,光这么看其实看不出什么,但是如果去调试的话,就会发现,这段代码实际上是在调用dyld_stub_binder
为懒加载符号绑定真实地址。而刚刚在0x6474处的代码获取到的四字节的数据,实际上是符号绑定信息的偏移:
0xc428+0x1d = 0xc445
也就是说,动态绑定NSLog所需要的数据,就存储在0xc445处。
那么,理论上来说,如果我们尝试着修改这里的数据,是不是就会改变符号的查找的过程呢?
实践
想的再多,都不如动手操作!!!
新建一个工程,书写如下代码(main.m):
__attribute__((constructor)) static void entry(int argc,char *argv[],char **apple,char **executablepath,struct mach_header_64 **mh_ptr){
if (!strncmp(argv[0], "aaa", 3)) {
printf("the same!!");
}
}
并按照如上方式,查找到函数strncmp
的Lazy Binding Info,做如下修改:
修改后:
编写动态库并注入到可执行文件:
__attribute__((visibility("default"))) int strncmq(const char *__s1, const char *__s2, size_t __n);
int strncmq(const char *__s1, const char *__s2, size_t __n){
printf("hook:%s\nhook:%s",__s1,__s2);
return strncmp(__s1, __s2, __n);
}
重签名运行!!
发现已经替换成功了!!!
但是,用ida或者hopper分析一下二进制文件,会发现调用的还是原来的strncmp符号:
说明如果进行模块检测的话,还是可以检测出来的~因为虽然符号查找替换了,但是实际上"外套"还是strncmp。所以,继续把外套也修改了!!!
修改这两个处:
修改后:
总结
对于动态绑定的外部引用符号,能动手脚的地方确实很多!!!