address sanitizer(内存清洁剂)是很实用的一个debug工具，用来检测潜在的内存问题，iOS环境下关于address sanitizer的原理可以看看WWDC的视频，简而言之就是标记出很多中毒内存(poisoned memory)在访问内存的时候check这片内存是否是中毒内存，本文不做过多介绍。
项目背景
项目需要，工程中使用了 fishhook hook了一些socket相关函数。
问题
一开始相安无事，但是在xcode开启address sanitizer的情况下，怪异的事情发生了，具体可以看我在fishhook底下的issue。
循坏调用
MAM_getaddrinfo是我hook的get_addrinfo函数，可以发现我的hook函数个一个名为wrap_getaddrinfo的函数陷入了循坏调用。wrap_getaddrinfo从名字来看像是一个getaddrinfo的包装函数。
探索
WWDC的视频里面提到了:
address_sanitizer_hook.jpg
address sanitizer会hook一些C的基础函数来执行一些内存检查，我们这里遇到的wrap_getaddrinfo应该就是address sanitizer插入的函数。那么这里为什么会导致循环调用呢？
我先用一句话概括下fishhook的原理：fishhook通过dyld遍历所有的可执行文件(image)的符号表，替换我们需要hook的符号结构中的value值(即函数地址)达到hook的目的。
具体原理看fishhook主页的介绍吧。按照fishhook的原理，我们重复hook一个函数的话，hook的函数会根据hook的先后顺序执行，并不会陷入循环调用。所以推测address sanitizer的hook原理和fishhook的并不相同。遗憾的是address sanitizer并没有说明是如何hook这些函数的。
dyld开放的源码中有一个dyld-interposing.h介绍了dyld中hook的方式。我们有理由推测address sanitizer就是使用的这种方式。
dyld-interposing.jpg
但是需要验证一下（此处一把辛酸泪...
这个宏并不是简单的放在源码中就行的，它需要通过注入动态库的方式才能生效，省略各种折腾1W字...
直接说最后怎么搞定的吧:)
最后新建了一个只包含这个hook代码的动态库然后通过embeded binary的方式使hook生效了。
embedded.jpg
模拟了下同时使用这个宏和fishhook的情况，发现果然陷入了循环调用！图就不贴了和第一个图一样。
but还是无可奈何啊，关于这个宏，网上所有的信息只有：使用这个宏的情况下，dyld的函数拦截功能提供了一个新的__DATA区，名为__interpose,在这个区中依次列出了替换函数和被替换的函数，其他事情就交由dyld处理了。但是dyld怎么处理的还是不知道，仍然没办法查明为什么会陷入循环调用。
解决方案
退而求其次，如果我们能在runtime通过代码检测到项目开启了address sanitizer，则关闭fishhook也是一种避免error的方案。clang关于address sanitizer的介绍页说明了通过宏的方式来判断的方案：
macro.jpg
这种方案在主工程的源码里面的确能生效，但是博主的项目是一个提供给别人使用的SDK，通过宏的方式并不可行。
Update: clang这个条件编译的宏在预处理(preprocessing)阶段被编译器处理，SDK在这个阶段并不能判断接入方是否开启address sanitizer，所以只能在运行时(runtime)通过代码判断。
这个时候就要祭出大杀器dyld了(apple 的动态链接器，本篇文章不做过多解释)。wwdc的视频里面说明了开启address sanitizer的情况下会注入一个asan dylib，那么我们可以在代码中检测是否存在asan相关动态库来在runtime判断address sanitizer是否开启。下面是dyld.h的接口。_dyld_get_image_name可以用来获取image的名字。
dyld.h
extern uint32_t _dyld_image_count(void) __OSX_AVAILABLE_STARTING(__MAC_10_1, __IPHONE_2_0);
extern const struct mach_header* _dyld_get_image_header(uint32_t image_index) __OSX_AVAILABLE_STARTING(__MAC_10_1, __IPHONE_2_0);
extern intptr_t _dyld_get_image_vmaddr_slide(uint32_t image_index) __OSX_AVAILABLE_STARTING(__MAC_10_1, __IPHONE_2_0);
extern const char* _dyld_get_image_name(uint32_t image_index) __OSX_AVAILABLE_STARTING(__MAC_10_1, __IPHONE_2_0);
通过dyld可以获取到asan dylib这个动态库的路径。在获取到这个动态库后我们可以进一步验证__DATA区的__interpose段。这里使用MachOView来查看这个dylib。
__interpose.jpg
果然，的确在__DATA区存在__interpose，进一步确认address sanitizer使用了DYLD_INTERPOSE这个宏来做hook。
关键代码不贴啦，项目敏感代码:)
已经提供了思路，感兴趣的读者自己去验证。
总结
这个问题困恼了博主两三天，，探索过程涉及到很多未知的知识点。iOS逆向方面的知识还是太薄弱，很多时候需要懂一些逆向的知识，比如dyld提供的这个宏在逆向中就用处很大。
最后感叹一句，学无止境啊。
网友评论