懒加载和非懒加载

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。所以，继续把外套也修改了！！！

修改这两个处：

修改后：

总结

对于动态绑定的外部引用符号，能动手脚的地方确实很多！！！

[培训]内核驱动高级班，冲击BAT一流互联网大厂工 作，每周日13:00-18:00直播授课