Native Hook 技术，天使还是魔鬼

Hook 的不同流派¶

对于 Hook 技术，比较常见的有 GOT/PLT Hook、Trap Hook 以及 Hook，下面逐个讲解这些 Hook 技术的实现原理和优劣比较。

1. GOT/PLT Hook¶

在-plus中，我们使用了 PLT Hook 技术来获取线程创建的堆栈。先来回顾一下它的整个流程，我们将 .so 中的外部函数 替换成自己的方法 。

你可以发现，GOT/PLT Hook 主要是用于替换某个 SO 的外部调用，通过将外部函数调用跳转成我们的目标函数。GOT/PLT Hook 可以说是一个非常经典的 Hook 方法，它非常稳定，可以达到部署到生产环境的标准。

那 GOT/PLT Hook 的实现原理究竟是什么呢？你需要先对 SO 库文件的 ELF 文件格式和动态链接过程有所了解。

ELF 格式¶

ELF（ ）是可执行和链接格式，它是一个开放标准，各种 UNIX 系统的可执行文件大多采用 ELF 格式。虽然 ELF 文件本身就支持三种不同的类型（重定位、执行、共享），不同的视图下格式稍微不同，不过它有一个统一的结构，这个结构如下图所示。

网上介绍 ELF 格式的文章非常多，你可以参考《ELF 文件格式解析》。顾名思义，对于 GOT/PLT Hook 来说，我们主要关心“.plt”和“.got”这两个节区：

我们也可以使用 -S来查看 ELF 文件的具体信息。

链接过程¶

接下来我们再来看看动态链接的过程，当需要使用一个 库（.so 文件）的时候，我们需要调用(".so")来加载这个库。

在我们调用了(".so")之后，系统首先会检查缓存中已加载的 ELF 文件列表。如果未加载则执行加载过程，如果已加载则计数加一，忽略该调用。然后系统会用从 .so 的节区中读取其所依赖的库，按照相同的加载逻辑，把未在缓存中的库加入加载列表。

你可以使用下面这个命令来查看一个库的依赖：

readelf -d  | grep NEEDED

下面我们大概了解一下系统是如何加载的 ELF 文件的。

但是这里有一个关键点，在 ELF 文件格式中我们只有函数的绝对地址。如果想在系统中运行，这里需要经过重定位。这其实是一个比较复杂的问题，因为不同机器的 CPU 架构、加载顺序不同，导致我们只能在运行时计算出这个值。不过还好动态加载器（//bin/）会帮助我们解决这个问题。

如果你理解了动态链接的过程，我们再回头来思考一下“.got”和“.plt”它们的具体含义。

PLT 和 GOT 记录是一一对应的，并且 GOT 表第一次解析后会包含调用函数的实际地址。既然这样，那 PLT 的意义究竟是什么呢？PLT 从某种意义上赋予我们一种懒加载的能力。当动态库首次被加载时，所有的函数地址并没有被解析。下面让我们结合图来具体分析一下首次函数调用，请注意图中黑色箭头为跳转，紫色为指针。

在解析前 GOT[n]会直接指向 jmp *GOT[n]的下一条指令。在解析完成后，我们就得到了 func 的实际地址，动态加载器会将这个地址填入 GOT[n]，然后调用 func。

如果对上面的这个调用流程还有疑问，你可以参考《GOT 表和 PLT 表》这篇文章，它里面有一张图非常清晰。

当第一次调用发生后，之后再调用函数 func 就高效简单很多。首先调用 PLT[n]，然后执行 jmp *GOT[n]。GOT[n]直接指向 func，这样就高效的完成了函数调用。

总结一下，因为很多函数可能在程序执行完时都不会被用到，比如错误处理函数或一些用户很少用到的功能模块等，那么一开始把所有函数都链接好实际就是一种浪费。为了提升动态链接的性能，我们可以使用 PLT 来实现延迟绑定的功能。

对于函数运行的实际地址，我们依然需要通过 GOT 表得到，整个简化过程如下：

看到这里，相信你已经有了如何 Hack 这一过程的初步想法。这里业界通常会根据修改 PLT 记录或者 GOT 记录区分为 GOT Hook 和 PLT Hook，但其本质原理十分接近。

GOT/PLT Hook 实践¶

GOT/PLT Hook 看似简单，但是实现起来也是有一些坑的，需要考虑兼容性的情况。一般来说，推荐使用业界的成熟方案。

如果不想深入它内部的原理，我们只需要直接使用这些开源的优秀方案就可以了。因为这种 Hook 方式非常成熟稳定，除了 Hook 线程的创建，我们还有很多其他的使用范例。

这种 Hook 方法也不是万能的，因为它只能替换导入函数的方式。有时候我们不一定可以找到这样的外部调用函数。如果想 Hook 函数的内部调用，这个时候就需要用到我们的 Trap Hook 或者 Hook 了。

2. Trap Hook¶

对于函数内部的 Hook，你可以先从头想一下，会发现调试器就具备一切 Hook 框架具有的能力，可以在目标函数前断住程序，修改内存、程序段，继续执行。相信很多同学都会使用调试器，但是对调试器如何工作却知之甚少。下面让我们先了解一下软件调试器是如何工作的。

¶

一般软件调试器都是通过 系统调用和 配合来进行断点调试，首先我们来了解一下什么是 ，它又是如何断住程序运行，然后修改相关执行步骤的。

所谓合格的底层程序员，对于未知知识的了解，第一步就是使用man命令来查看系统文档。

The () call a means by which one (the “”) may and the of (the “”), and and the ’s and . It is used to and call .

这段话直译过来就是， 提供了一种让一个程序（）观察或者控制另一个程序（）执行流程，以及修改被控制程序内存和寄存器的方法，主要用于实现调试断点和系统调用跟踪。

我们再来简单了解一下调试器（GDB/LLDB）是如何使用 的。首先调试器会基于要调试进程是否已启动，来决定是使用 fork 或者 到目标进程。当调试器与目标程序绑定后，目标程序的任何 （除 ）都会被调试器做先拦截，调试器会有机会对相关信号进行处理，然后再把执行权限交由目标程序继续执行。可以你已经想到了，这其实已经达到了 Hook 的目的。

如何 Hook¶

但更进一步思考，如果我们不需要修改内存或者做类似调试器一样复杂的交互，我们完全可以不依赖 ，只需要接收相关 即可。这时我们就想到了句柄（ ）。对！我们完全可以主动 raise ，然后使用 来实现类似的 Hook 效果。

业界也有不少人将 Trap Hook 叫作断点 Hook，它的原理就是在需要 Hook 的地方想办法触发断点，并捕获异常。一般我们会利用 或者 （非法指令异常）这两种信号。下面以 信号为例，具体的实现步骤如下。

Trap Hook 实践¶

Trap Hook 实践Trap Hook 兼容性非常好，它也可以在生产环境中大规模使用。但是它最大的问题是效率比较低，不适合 Hook 非常频繁调用的函数。

对于 Trap Hook 的实践方案，在“卡顿优化（下）”中，我提到过 的，它就是通过定期发送 信号来实现卡顿监控的。

3. Hook¶

跟 Trap Hook 一样， Hook 也是函数内部调用的 Hook。它直接将函数开始（）处的指令更替为跳转指令，使得原函数直接跳转到 Hook 的目标函数函数，并保留原函数的调用接口以完成后续再调用回来的目的。

与 GOT/PLT Hook 相比， Hook 可以不受 GOT/PLT 表的限制，几乎可以 Hook 任何函数。不过其实现十分复杂，我至今没有见过可以用在生产环境的实现。并且在 ARM 体系结构下，无法对叶子函数和很短的函数进行 Hook。

在深入“邪恶的”细节前，我们需要先对 Hook 的大体流程有一个简单的了解。

如图所示， Hook 的基本思路就是在已有的代码段中插入跳转指令，把代码的执行流程转向我们实现的 Hook 函数中，然后再进行指令修复，并跳转回原函数继续执行。这段描述看起来是不是十分简单而且清晰？

对于 Trap Hook，我们只需要在目标地址前插入特殊指令，并且在执行结束后把原始指令写回去就可以了。但是对 Hook 来说，它是直接进行指令级的复写与修复。怎么理解呢？就相当于我们在运行过程中要去做 ASM 的字节码修改。

当然 Hook 远远比 ASM 操作更加复杂，因为它还涉及不同 CPU 架构带来的指令集适配问题，我们需要根据不同指令集来分别进行指令复写与跳转。

下面我先来简单说明一下 常见的 CPU 架构和指令集：

ARM64 目前我还没有适配，不过 Play 要求所有应用在 2019 年 8 月 1 日之前需要支持 64 位，所以今年上半年也要折腾一下。但它们的原理基本类似，下面我以最主流的 ARMv7 架构为例，为你庖丁解牛 Hook。

ARM32 指令集¶

ARMv7 中有一种广为流传的PC=��=PC+8的说法。这是指 ARMv7 中的三级流水线（取指、解码、执行），换句话说PC寄存器总是指向正在取指的指令，而不是指向正在执行的指令。取指总会比执行快2个指令，在ARM32指令集下2个指令的长度为8个字节，所以��寄存器总是指向正在取指的指令，而不是指向正在执行的指令。取指总会比执行快2个指令，在���32指令集下2个指令的长度为8个字节，所以PC寄存器的值总是比当前指令地址要大 8。

是不是感觉有些复杂，其实这是为了引出 ARM 指令集的常用跳转方法：LDR PC, [PC, #-4] ;$

LDR PC, [PC, #-4] ;0xE51FF004
$TRAMPOLIN_ADDR

在了解了三级流水线以后，就不会对这个 PC-4 有什么疑惑了。

按照我们前面描述的 Hook 的基本步骤，首先插入跳转指令，跳入我们的蹦床（），执行我们实现的 Hook 后函数。这里还有一个“邪恶的”细节，由于指令执行是依赖当前运行环境的，即所有寄存器的值，而我们插入新的指令是有可能更改寄存器的状态的，所以我们要保存当前全部的寄存器状态到栈中，使用 BLX 指令跳转执行 Hook 后函数，执行完成后，再从栈中恢复所有的寄存器，最后才能像未 Hook 一样继续执行原先函数。

在执行完 Hook 后的函数后，我们需要跳转回原先的函数继续执行。这里不要忘记我们在一开始覆盖的 LDR 指令，我们需要先执行被我们复写的指令，然后再使用如下指令，继续执行原先函数。

LDR PC, [PC, #-4]
HOOKED_ADDR+8

是不是有一种大功告成的感觉？其实这里还有一个巨大的坑在等着我们，那就是指令修复。前面我提到保存并恢复了寄存器原有的状态，已达到可以继续像原有程序一样的继续执行。但仅仅是恢复寄存器就足够么？显然答案是否定的，虽然寄存器被我们完美恢复了，但是 2 条备份的指令被移动到了新的地址。当执行它们的时候，PC寄存器的值是与原先不同的。这条指令的操作如果涉及��寄存器的值是与原先不同的。这条指令的操作如果涉及PC的值，那么它们将会执行出完全不同的结果。

到这里我就不对指令修复再深入解析了，感兴趣的同学可以在留言区进行讨论。

Hook 实践¶

对于 Hook，虽然它功能非常强大，而且执行效率也很高，但是业界目前还没有一套完全稳定可靠的开源方案。 Hook 一般会使用在自动化测试或者线上疑难问题的定位，例如“UI 优化”中说到 .so 崩溃问题的定位，我们就是利用 Hook 去收集系统信息。

业界也有一些不错的参考方案： -Cydia 。在中，我们就使用它来 Hook 系统的内存分配函数。 -adbi。支付宝在GC 抑制中使用的 Hook 框架，不过已经好几年没有更新了。

各个流派的优缺点比较¶

最后我们再来总结一下不同的 Hook 方式的优缺点：

GOT/PLT Hook 是一个比较中庸的方案，有较好的性能，中等的实现难度，但其只能 Hook 动态库之间的调用的函数，并且无法 Hook 未导出的私有函数，而且只存在安装与卸载 2 种状态，一旦安装就会 Hook 所有函数调用。

Trap Hook 最为稳定，但由于需要切换运行模式（R0/R3），且依赖内核的信号机制，导致性能很差。

Hook 是一个非常激进的方案，有很好的性能，并且也没有 PLT 作用域的限制，可以说是一个非常灵活、完美的方案。但其实现难度极高，我至今也没有看到可以部署在生产环境的 Hook 方案，因为涉及指令修复，需要编译器的各种优化。

但是需要注意，无论是哪一种 Hook 都只能 Hook 到应用自身的进程，我们无法替换系统或其他应用进程的函数执行。

总结¶

总的来说 Hook 是一门非常底层的技术，它会涉及库文件编译、加载、链接等方方面面的知识，而且很多底层知识是与 甚至移动平台无关的。在这一领域，做安全的同学可能会更有发言权，我来讲可能班门弄斧了。不过希望通过这篇文章，让你对看似黑科技的 Hook 有一个大体的了解，希望可以在自己的平时的工作中使用 Hook 来完成一些看似不可能的任务，比如修复系统 Bug、线上监控 内存分配等。