iOS/MacOS lazy bind

iOS由MacOS系统修改而来，所以很多机制是相同的，与Android-Linux相比相似性更高。iOS符号分为自动non-lazy和lazy绑定符号，non-lazy符号位于Mach-O文件__DATA Segment 的__nl_symbol_ptr section，lazy符号位于__DATA Segment 的__la_symbol_ptr section。对于non-lazy的符号绑定时机为动态库加载（load），lazy符号的绑定时机则与Linux相同即函数第一次被调用。

测试代码

#include 

int main(int argc, const char * argv[]) {
    // insert code here...
    printf("Hello, World!\n");
    printf("Hello World Again!\n");
    return 0;
}

lldb 调试

反汇编main函数

+34为调用第一个printf函数，+51第二次调用printf函数。
二进制文件DATA段有两个section

DATA Segment

不用展开也应该能猜到是哪两个sction，section[0]为__nl_symbol_ptr section[1]为__la_symbol_ptr 。回到汇编代码，printf函数的地址无论第一次还是第二次都是0x100000f66，这个地址来自哪呢？

add.PNG

由上图可知，0x100000f66值为__TEXT Segment中的__stub section。
该section的作用解释如下

• section (__TEXT,__stubs) - section contains stubs with prefix imp___stubs__. That stubs are used in the code of __text section to compile procedures with external dependencies, such as system NSLog. dyld (dynamic linker) will replace such stubs on runtime with actual place in dynamic library.
  大意就是该section保存的是编译过程中的外部依赖，在运行时动态链接器dyld将其替换为实际位置 PS:灵魂翻译

call下断，si进去

程序jmpq 0x0000000100000f7c，在__la_symbol_ptr section address中符号的地址为0x0000000100001010

ladd.PNG

值相等

继续调试

Screen Shot 2017-05-09 at 1.22.04 PM.png

0x0000000100000f7c仅将0x0压栈后就jmp回0x100000f6c，printf函数的地址查询最终是通过 dyld_stub_binder函数实现。dyld_stub_binder中符号查找原理可以参考 fishhook

看了以上汇编是否觉得与 Linux PLT颇有几分相似?
0x0同样为索引

调用dyld_stub_binder前堆栈信息

第二次调用printf

Screen Shot 2017-05-09 at 1.37.54 PM.png

绑定结束，从此可以直接调用相应函数

返汇编

参考：

• https://skyylex.github.io/exploring_mach-o_binaries
• https://opensource.apple.com/source/xnu/xnu-2050.7.9/EXTERNAL_HEADERS/mach-o/loader.h.auto.html
• http://turingh.github.io/2016/03/10/Mach-O%E7%9A%84%E5%8A%A8%E6%80%81%E9%93%BE%E6%8E%A5/
• https://github.com/facebook/fishhook