Android Arm Inline Hook
本文将结合本项目的源代码,详细阐述Android Arm Inline Hook的原理与实现过程。
什么是Inline Hook
Inline Hook即内部跳转Hook,通过替换函数开始处的指令为跳转指令,使得原函数跳转到自己的函数,通常还会保留原函数的调用接口。与GOT表Hook相比,Inline Hook具有更广泛的适用性,几乎可以Hook任何函数,不过其实现更为复杂,考虑的情况更多,并且无法对一些太短的函数Hook。
其基本原理请参阅网上其他资料。
需要解决的问题
- Arm模式与Thumb模式的区别
- 跳转指令的构造
- PC相关指令的修正
- 线程处理
- 其他一些细节
下面我将结合源码对这几个问题进行解决。
Arm模式与Thumb模式的区别
本文讨论的对象为基于32位的Arm架构的Inline Hook,在Arm版本7及以上的体系中,其指令集分为Arm指令集和Thumb指令集。Arm指令为4字节对齐,每条指令长度均为32位;Thumb指令为2字节对齐,又分为Thumb16、Thumb32,其中Thumb16指令长度为16位,Thumb32指令长度为32位。
在对一个函数进行Inline Hook时,首先需要判断当前函数指令是Arm指令还是Thumb指令,指令使用目标地址值的bit[0]来确定目标地址的指令类型。bit[0]的值为1时,目标程序为Thumb指令;bit[0]值为0时,目标程序为ARM指令。其相关实现代码为以下宏:
跳转指令的构造
跳转指令主要分为以下两种:
- B系列指令:B、BL、BX、BLX
- 直接写PC寄存器
Arm的B系列指令跳转范围只有4M,Thumb的B系列指令跳转范围只有256字节,然而大多数情况下跳转范围都会大于4M,故我们采用LDR PC, [PC, ?]
构造跳转指令。另外Thumb16指令中并没有合适的跳转指令,如果单独使用Thumb16指令构造跳转指令,需要使用更多的指令完成,并且在后续对PC相关指令的修正也更加繁琐,故综合考虑下,决定放弃对ARMv5的支持。
另外,Arm处理器采用3级流水线来增加处理器指令流的速度,也就是说程序计数器R15(PC)总是指向“正在取指”的指令,而不是指向“正在执行”的,即PC总是指向当前正在执行的指令地址再加2条指令的地址。比如当前指令地址是0×8000, 那么当前pc的值,在thumb下面是0×8000 + 2 2, 在arm下面是0×8000 + 4 2。
对于Arm指令集,跳转指令为:
LDR PC, [PC, #-4]
对应的机器码为:0xE51FF004,addr
为要跳转的地址。该跳转指令范围为32位,对于32位系统来说即为全地址跳转。
对于Thumb32指令集,跳转指令为:
LDR.W PC, [PC, #0]
对应的机器码为:0x00F0DFF8,addr
为要跳转的地址。同样支持任意地址跳转。
其相关实现代码为:
首先通过TEST_BIT0宏判断目标函数的指令集类型,其中若为Thumb指令集,多了下面一个额外处理:
对bit[0]的值清零,若其值4字节不对齐,则添加一个2字节的NOP
指令,使得后续的指令4字节对齐。这是因为在Thumb32指令中,若该指令对PC寄存器的值进行了修改,则该指令必须是4字节对齐的,否则为非法指令。
PC相关指令的修正
不论是Arm指令集还是Thumb指令集,都存在很多的与PC值相关的指令,例如:B系列指令、literal系列指令等。原有函数的前几个被跳转指令替换的指令将会被搬移到trampoline_instructions中,此时PC值已经变动,所以需要对PC相关指令进行修正(所谓修正即为计算出实际地址,并使用其他指令完成同样的功能)。相关修正代码位于relocate.c文件中。其中INSTRUCTION_TYPE
描述了需要修正的指令,限于篇幅,这里仅阐述Arm指令的修正过程,对应的代码为relocateInstructionInArm
函数。
函数原型如下:
具体实现中,首先通过函数getTypeInArm
判断当前指令的类型,本函数通过类型,共分为4个处理分支:
- BLX_ARM、BL_ARM、B_ARM、BX_ARM
- ADD_ARM
- ADR1_ARM、ADR2_ARM、LDR_ARM、MOV_ARM
- 其他指令
BLX_ARM、BL_ARM、B_ARM、BX_ARM指令的修正
即为B系列指令(BLX <label>
、BL <label>
、B <label>
、BX PC
)的修正,其中BLX_ARM
和BL_ARM
需要修正LR寄存器的值,相关代码为:
接下来构造相应的跳转指令,即为:
最后解析指令,计算实际跳转地址value
,并将其写入trampoline_instructions
,相关代码为:
如此便完成了B系列指令的修正,关于指令的字节结构请参考Arm指令手册。
ADD_ARM指令的修正
ADD_ARM
指的是ADR Rd, <label>
格式的指令,其中<label>
与PC相关。
首先通过循环遍历,得到Rd寄存器,代码如下:
接下来是构造修正指令:
ADR1_ARM、ADR2_ARM、LDR_ARM、MOV_ARM
分别为ADR Rd, <label>
、ADR Rd, <label>
、LDR Rt, <label>
、MOV Rd, PC
。
同样首先解析指令,得到value
,相关代码如下:
最后构造修正指令,代码如下:
其他指令
事实上,还有些指令格式需要修正,例如:PUSH {PC}
、PUSH {SP}
等,虽然这些指令被Arm指令手册标记为deprecated,但是仍然为合法指令,不过在实际汇编中并未发现此类指令,故未做处理,相关代码如下:
处理完所有待处理指令后,最后加入返回指令:
Thumb指令的修正,大家可以参考这里的思路,自行阅读源码。
线程处理
一个完善的Inline Hook方案必须要考虑多线程环境,即要考虑线程恰好执行到被修改指令的位置。在Window下,使用GetThreadContext
和SetThreadContext
枚举所有线程,迁移context到搬迁后的指令中。然而在Linux+Arm环境下,并没有直接提供相同功能的API,不过可以使用ptrace
完成,主要流程如下:
- 解析/proc/self/task目录,获取所有线程id
- 创建子进程,父进程等待。子进程枚举所有线程,PTRACE_ATTACH线程,迁移线程PC寄存器,枚举完毕后,子进程给自己发SIGSTOP信号,等待父进程唤醒
- 父进程检测到子进程已经SIGSTOP,完成Inline Hook工作,向子进程发送SIGCONT信号,同时等待子进程退出
- 子进程枚举所有线程,PTRACE_DETACH线程,枚举完毕后,子进程退出
- 父进程继续其他工作
这里使用子进程完成线程处理工作,实际上是迫不得已的。因为,如果直接使用本进程PTRACE_ATTACH
线程,会出现operation not permitted,即使赋予root权限也是同样的错误,具体原因不得而知。
具体代码请参考freeze
与unFreeze
两个函数。
其他一些细节
- 页保护
页面大小为4096字节,使用mprotect
函数修改页面属性,修改为PROT_READ | PROT_WRITE | PROT_EXEC
。 - 刷新缓存
对于ARM处理器来说,缓存机制作用明显,内存中的指令已经改变,但是cache中的指令可能仍为原有指令,所以需要手动刷新cache中的内容。采用cacheflush
即可实现。 - 一个已知的BUG
虽然本库已经把大部分工作放在了registerInlineHook
函数中,但是在inlineHook
、inlineUnHook
函数中还是不可避免的使用了部分libc库的API函数,例如:mprotect
、memcpy
、munmap
、free
、cacheflush
等。如果使用本库对上述API函数进行Hook,可能会失败甚至崩溃,这是因为此时原函数的指令已经被破坏,或者其逻辑已经改变。解决这个Bug有两个方案,第一是采用其他Hook技术;第二将本库中的这些API函数全部采用内部实现,即不依赖于libc库,可采用静态链接libc库,或者使用汇编直接调相应的系统调用号。