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

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

老规矩,片头先上福利:点击下载demo,demo中有笔者给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方法mylogmylog2,挂上断点,如图:

OC方法.png

开启汇编断点,如图:

设置汇编断点.png

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


OC汇编断点.png

从上图可以看的出来调用了两个objc_msgSend,这两个很像是
我们的mylogmylog2,但现在还不能确定。
想一想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 listregister 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;

推荐阅读更多精彩内容