iOS逆向(6)-从fishhook看runtime，hook系统C函数

在上篇文章不知MachO怎敢说自己懂DYLD中已经详细介绍了MachO，并且由MachO引出了dyld，再由dyld讲述了App的启动流程，而在App的启动流程中又说到了一些关键的名称如：LC_LOAD_DYLINKER、LC_LOAD_DYLIB以及objc的回调函数_dyld_objc_notify_register等等。并且在末尾提出了MachO中还有一些符号表，而有哪些符号表，这些符号表又有些什么用呢？笔者在这篇文章就将一一道来。

老规矩，片头先上福利：点击下载demo，demo中有笔者给fishhook每句代码加的详细注释！！！
这篇文章会用到的工具有：

• fishhook

在开始正文之前，假设面试官问了一个问题：
都知道Objective-C最大的特性就是runtime，大家可以用使用runtime对OC的方法进行hook，那么C函数能不能hook？

有兴趣回答的朋友可以先行在评论区回答，答完之后再继续阅读或者预先偷窥一下文末的答案，看看这被炒了无数次冷饭的runtime自己是否真的了然于胸。

本将从以下几方面回答上面所提的问题:

• Runtime的Hook原理
• 为什么C不能hook
• 如何利用MachO“玩坏”系统C函数
• fishhook源码分析
• 绑定系统C函数过程验证

一、Runtime的Hook原理

Runtime，从名称上就知道是运行时，也是它造就了OC运行时的特性，而要想彻底明白什么是运行时，那么就需要将之与C语言有相比较。
今天咱们就从汇编的角度看一看OC和C在调用方法（函数）上有什么区别。

注：笔者使用的是iPhone 7征集调试，所有一下汇编都是基于arm64，所以以下所有汇编默认为基于arm64。

新建一个工程取名为：FishhookDemo
敲入两个OC方法mylog和mylog2，挂上断点，如图：

OC方法.png

开启汇编断点，如图：

设置汇编断点.png

运行工程，会跳转到如下图的汇编断点：

OC汇编断点.png

从上图可以看的出来调用了两个objc_msgSend，这两个很像是
我们的mylog和mylog2，但现在还不能确定。
想一想objc_msgSend的定义：

OBJC_EXPORT void
objc_msgSend(void /* id self, SEL op, ... */ )
    OBJC_AVAILABLE(10.0, 2.0, 9.0, 1.0, 2.0);

第一个参数是self，第二个参数是SEL，所以可以知道SEL是放在x1的寄存器里面（什么是x1？继续关注作者，之后的文章会有相关的汇编的专门篇章）。

马不停蹄，挂上两个汇编断点，查看一下两个x1中存放的到底是什么，如图：

mylog1.png

mylog2.png

这也就验证了咱们OC方法都是消息转发（objc_msgSend）。而同一个C函数的地址又都是一样的（笔者这次运行的地址就是0x1026ce130） 。

所以在每次调用OC方法的时候就让我们有了一次改变消息转发「目标」的机会。

这里稍微提一下runtime的源码分析流程：
Step 1、方法查找
① 汇编快速查找缓存
② C/C++慢速查找：self->super->NSObject->找到换缓存起来
Step 2、动态方法解析: _class_resolveMethod
① _class_resolveInstanceMethod
② _class_resolveClassMethod
Step 3、消息转发
① _forwardingTargetForSelector
② _methodSignatureForSelector
③ _forwardInvocation
④ _doesNotRecognizeSelector

二、为什么C不能hook

同样我们从汇编的角度切入。
敲入代码一些C函数，挂上断点，如图：

C函数.png

运行工程：
会看到断点断到如下汇编：

汇编断点.png

可以看到每个NSLog对应跳转的地址都是0x10000a010，每个printf对应跳转的地址都是0x10000a184，也就是说每个C的函数都是一一对应着一个真实的地址空间。每次在调用一个C函数的时候都是执行一句汇编bl 0xXXXXXXXX。

所以上面讲述到的消息转发的机会没有了，也就是没有了利用runtime来Hook的机会了。

三、如何利用MachO“玩坏”系统C函数

既然如此，那么是否C函数就真的那么牢不可破，无法对他进行Hook呢？
答案肯定是否定的！
想要从根上理解这个问题，首先要了解：我们的C函数分为系统C函数和我们自定义的C函数。

1、自定义的C函数

在上面的步骤中我们已经了解到所有C函数的调用都是跳转到一个「固定的地址」，那么就可以推断得出这个「固定的地址」其实是在编译期已经被生成好了，所以才能快速、直接的跳转到这个地址，实现函数调用。
C语言被称之为是静态语言也就是这么个理。

2、系统的C函数

在上篇文章不知MachO怎敢说自己懂DYLD已经提到了在dyld启动app的第二个步骤就是加载共享缓存库，共享缓存库包括Foundation框架，NSLog是被包含在Foundation框架的。那么就可以确定一件事情，在我们将自己工程打包出的MachO文件中是不可能预先确定NSLog的地址的。

但是又因为C语言是静态的特性，没法在运行的时候实时获取共享缓存库中NSLog的地址。而共享缓存库的存在好处太大，既能节省大量内存，又能加快启动速度提升性能，不能弃之而不用。

为了解决这个问题，Apple使用了PIC（Position-independent code）技术，在第一次使用对应函数(NSLog)的时候，从系统内存中将对函数(NSLog)的内存地址取出，绑定到APP中对应函数(NSLog)上，就可以实现正常的C函数(NSLog)调用了。

既然有这么个过程，iOS系统可以动态的绑定系统C函数的地址，那么咱们就也能。

四、fishhook源码分析

1、fishhook的总体思路

Facebook的开源库fishhook就可以完美的实现这个任务。
先上一张官网原理图：

fishhook原理图.png

总体来说，步骤是这样的：

• 先找到四张表Lazy Symbol Pointer Table、Indirect Symbol Table、Symbol Table、String Table。
• MachO有个规律：Lazy Symbol Pointer Table中第index行代表的函数和Indirect Symbol Table中第index行代表的函数是一样的。
• Indirect Symbol Table中value值表示Symbol Table的index。
• 找到Symbol Table的中对应index的对象，其data代表String Table的偏移值。
• 用String Table的基值，也就是第一行的pFile值，加上Symbol Table的中取到的偏移值，就能得到Indirect Symbol Table中value（这个value代表函数的偏移值）代表的函数名了。

2、验证NSLog地址

下面就来验证一下在NSLog的地址是不是真的就存在Indirect Symbol Table中。
同样在NSLog处下好断点，打开汇编断点，运行代码。会发现断点断在如下入位置：

NSLog断点.png

注：笔者的工程重新build了，MachO也重新生成，所以此处的截图和上文中断住NSLog的截图的地址不一样，这是正常情况。

可以发现NSLog的地址是0x104d36010，先记住这个值。

然后查看我们APP在内存中的偏移值。
利用image list命令列出所有image，第一个image就是我们APP的偏移值，也就是内存地址。

APP在内存中的偏移值.png

可以看到APP在内存中的偏移值为0x104d30000。
接着打开MachOView查看MachO中的Indirect Symbol Table中的value，如图：

函数偏移地址.png

其值为0x100006010，去除最高位得到的0x6010就是NSLog在MachO中的偏移值。
最后将NSLog在MachO中的偏移值于APP在内存中的偏移值相加就得到NSLog真实的内存地址:
0x6010+0x104d30000=0x104d36010

最终证明，在Indirect Symbol Table的value中的值就是其对应的函数的地址！！！

3、根据MachO的表查找对应的函数名和函数地址

咱们还是用NSLog来距离查找。

1、Indirect Symbol Table

取出其data值0000010A，用10进制表示，结果为266，如图：

Indirect Symbols Table.png

2、Symbol Table

在Symbol Table中找到下标(offset)为266的的对象，取出其data0x124，如图：

Symbols Table.png

3、String Table

将在Symbols中得到的偏移值0x124加上String Table的首个地址DC6C，得到值DD90，然后找到pFile为DD90的值，如下两图：

String Table 1.png

String Table 2.png

上述就是根据MachO的表查找对应的函数名和函数地址全过程了。

4、源码分析

fishhook的源码总共只有250行左右，所以结合MachO慢慢看，其实一点也不费劲，在笔者的demo中有对其每一句函数的详细注释。当然也有对fishhook使用的demo。

所以笔者就不在此处对fishhook做太过详细的介绍了。只对其中一些关键参数和关键函数做介绍。

• fishhook为维护一个链表，用来储存需要hook的所有函数

// 给需要rebinding的方法结构体开辟出对应的空间
// 生成对应的链表结构（rebindings_entry），并将新的entry插入头部
static int prepend_rebindings(struct rebindings_entry **rebindings_head,
                              struct rebinding rebindings[],
                              size_t nel)

• 根据linkedit的基值，找到对应的三张表：symbol_table、string_table和indirect_symtab ：

// 找到linkedit的头地址
// linkedit_base其实就是MachO的头地址！！！可以通过查看linkedit_base值和image list命令查看验证！！！（文末附有验证图）
/**********************************************************
 Linkedit虚拟地址 = PAGEZERO(64位下1G) + FileOffset
 MachO地址 = PAGEZERO + ASLR
 上面两个公式是已知的 得到下面这个公式
 MachO文件地址 = Linkedit虚拟地址 - FileOffset + ASLR(slide)
**********************************************************/
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);
// Get indirect symbol table (array of uint32_t indices into symbol table)
// 获取indirect_symtab的真实地址
uint32_t *indirect_symtab = (uint32_t *)(linkedit_base + dysymtab_cmd->indirectsymoff);

• 最核心的一个步骤，查找并且替换目标函数：

// 在四张表(section,symtab,strtab,indirect_symtab)中循环查找
// 直到找到对应的rebindings->name,将原先的函数复制给新的地址，将新的函数地址赋值给原先的函数
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)

五、绑定系统C函数过程验证

上面说了这么多，那么咱们来验证一下系统C函数是不是真的会这样被绑定起来，并且看一看，是在什么时候绑定的。

同样，在第一次敲入NSLog函数的地方加上断点，在第二个NSLog处也加上断点：

两个NSLog断点.png

运行工程后，使用dis -s命令查看该函数的汇编代码，并且继续查看其中第一次b指令，也就是函数调用的汇编，如图：

第一次NSLog汇编断点+dis -s.png

从上图就可以看到，在我们第一次调用NSLog的时候，系统确实会默认的调用dyld_stub_binder函数对NSLog进行绑定。

继续跳过这个断点，进入下一个NSLog的汇编断点处，同样利用dis -s命令查看该汇编：

第二次NSLog汇编断点+dis -s.png

得到答案：
系统确实会在第一次调用系统C函数的时候对其进行绑定！

还记得正文开始的时候的那个问题吗？
那么是不是系统C函数可以hook，而自定义的C函数就绝对不能hook了呢？
很显然，国内外大神那么多，肯定是能做到的，有兴趣的读者可以自行查阅Cydia Substrate。

这篇文章利用了一些LLDB命令行看了许多我们想看的内容，如image list，register read还有dis -s，在我们正向开发中，LLDB就是一把利器，而在我们玩逆向的时候，LLDB就成为了我们某些是后的唯一途径了！所以，在下一篇文章中，笔者将会对LLDB进行更加详细的讲解，让大家看到LLBD的伟大。

---

• 关于道友AmazingYu的提问：

想问下 linkedit_base 地址与 Text 段的初始地址以及 Data 段的初始地址的关系，这三个段在内存中是挨着的吗，还有就是 linkedit_base 大概在进程内存分布中的哪个地方？

在咨询大佬请叫我Hank后，得到最终答案，在下面问回答中有一些问题，再此纠正一下！
linkedit地址(不是linkedit_base，末尾会介绍linkedit_base到底是什么) 与 Text 段的初始地址以及 Data 段确实是连续的，他们的顺序是：
先是Text 段，然后是Data 段，最后是linkedit_base 地址。从下面三幅图的File Offset和File Size可以看出来，两者相加就能得到下一段的地址：

TEXT段.png

DATA段.png

LINKEDIT.png

• 几个名词（pFile 、offset 、File Offset）之前解释的有点问题：
  1、首先，这三个都是表示相对于MachO的内存偏移，只不过其含义被细分了。
  2、pFile 和 offset含义相近，不过offset更详细，能够对应上具体某一个符号(DATA? TEXT?)。比如文件里面有许多类，类里面有许多的属性，pFile就代表各个类的偏移值，offset代表各个属性的偏移值
  3、File Offset 这个存在于Segment的字段中。用于从Segment快速找到其代表的「表」真正的偏移值。

最后说一下linkedit_base：
linkedit_base其实代表的就是MachO的真实内存地址！
可以从下图得到验证

linkedit_base==MachO.png

因为：

Linkedit虚拟地址 = PAGEZERO(64位下1G) + FileOffset 
MachO地址 = PAGEZERO + ASLR
// 上面两个公式是已知的 所以可以得到下面这个公式
MachO地址 = Linkedit虚拟地址 - FileOffset + ASLR(slide)

也就是fishhook中的：

uintptr_t linkedit_base = (uintptr_t)slide + linkedit_segment->vmaddr - linkedit_segment->fileoff;