Hook objc_msgSend（😁）

iOS运行时

函数调用 - 栈空间详解

如果你之前了解过函数调用时栈空间的栈分配情况，你应该见过类似下面的栈图：

在这里，我们需要明确两块内存空间：一块是“栈空间”，上图中蓝色框中的内存属于这里，fp、sp 之中存储的通常是这个空间的地址；一块是“代码空间”，是用于存放我们所编写的函数的汇编指令的，上图中的 IMP A/B/C 存放在这里。你可以这样理解他们之间的关系：我们写的代码被编译成汇编指令后，被 runtime 加载进“代码空间”并开始执行，汇编执行过程中，所产生的中间变量（函数传参、值类型局部变量等），被存储在“栈空间”。当然，为了实现函数跳转、返回、堆栈捕获等功能，栈空间还额外存储了 fp 值以及 lr 值（注意是值！）。

例子

@implementation AppDelegate
- (void)simple
{
    [self count:1];
}
- (int)count:(int)i
{
    return i;
}
@end

查看 -[AppDelegate simple] 的汇编：

w2 代表只用 2 号寄存器的 32 位。
bl、blr 指令在跳转的同时，会将 lr 寄存器的值设置为当前 pc+4byte。

从上面的汇编结合一点点思考，我们得出了一些 非常非常重要 的结论：

• “不给别人添麻烦”：每个函数都有自己的一块操作空间，我们称其为“栈帧(stack frame)”。寄存器 fp、sp 的值是栈帧范围的唯一标识，作为 simple 函数，为了保证自己 return 之后，调用者能继续正常执行，函数体需要自己负责维护 fp/sp 的状态，保证进出时一致。而正是因为大家都遵循这样的规则，在后续代码中，我们才能放心的在调用完 count: 之后，继续使用 fp/sp 寄存器。

• “自己的事情自己做”：一个函数有多少参数、多少局部变量，进而需要多大的栈空间，只有函数自己知道，所以函数内部需要自己“挪动” fp、sp 的指向，来“声明”自己所需要的空间。

• “一切行动听指挥”：我们知道，lr 寄存器存储着返回地址，当函数内部又有函数调用时，我们不可避免的需要改变 lr 寄存器的值，那么为了保证自己能成功回到上一级，函数自己需要将 lr 地址存好，并在执行结束之前重新设置给 lr 寄存器。

在上面的代码中，我们看到 simple 的汇编代码将参数值 1 放进了 2 号寄存器中，那 count: 如何知道我将参数放在了这里呢？我们再看看 count: 方法的汇编代码：

从 count: 的汇编，我们得出了另外一个重要结论：

函数参数的传递并不是口耳相传，而是依赖强类型约束和汇编规范的硬编码！不但寄存器的顺序有严格规定，实际的读写操作也和数据类型强相关（int 类型，寄存器选择用 w 而非 x，存储到栈空间偏移量也不是 8 的整数倍）。但是寄存器的数量终归是有限的，当函数内部需要调用多参方法的时候，调用者的会扩大其栈帧的大小，将寄存器塞不下的参数按一定顺序放置在栈帧中。而被调用方，同样是通过硬编码 offset 的方式，一个一个的从前一个函数的栈帧中读取出来。

hook代码

点击此文件查看完成代码

#define call(b, value) \
__asm volatile ("stp x8, x9, [sp, #-16]!\n"); \
__asm volatile ("mov x12, %0\n" :: "r"(value)); \
__asm volatile ("ldp x8, x9, [sp], #16\n"); \
__asm volatile (#b " x12\n");
#define save() \
__asm volatile ( \
"stp x8, x9, [sp, #-16]!\n" \
"stp x6, x7, [sp, #-16]!\n" \
"stp x4, x5, [sp, #-16]!\n" \
"stp x2, x3, [sp, #-16]!\n" \
"stp x0, x1, [sp, #-16]!\n");
#define load() \
__asm volatile ( \
"ldp x0, x1, [sp], #16\n" \
"ldp x2, x3, [sp], #16\n" \
"ldp x4, x5, [sp], #16\n" \
"ldp x6, x7, [sp], #16\n" \
"ldp x8, x9, [sp], #16\n" );
__attribute__((__naked__)) static void hook_Objc_msgSend() {
    // Save parameters.
    save()
    __asm volatile("mov x2, lr\n");
    __asm volatile("mov x3, x4\n");
    // Call our before_objc_msgSend.
    call(blr, &before_objc_msgSend)
    // Load parameters.
    load()
    // Call through to the original objc_msgSend.
    call(blr, orig_objc_msgSend)
    // Save original objc_msgSend return value.
    save()
    // Call our after_objc_msgSend.
    call(blr, &after_objc_msgSend)
    // restore lr
    __asm volatile("mov lr, x0\n");
    // Load original objc_msgSend return value.
    load()
    // return
    ret()
}

hook调用流程：
1. 和传统函数不同，函数起头没有声明属于自己的栈空间：fp、sp 和上一栈帧一致。
2. 把所有寄存器的值存在低址，并下移 sp，保证后续函数调用不会修改到这部分栈空间。
3. 把 lr 寄存器的值当做参数传递给 before_objc_msgSend，后者将其存至内存中（放到堆区的结构体里面了）
4. 在调用 orig_objc_msgSend 之前，恢复寄存器状态以及 sp 指向，使栈空间的状态恢复到与第一步一致，此时调用 orig_objc_msgSend，所有寄存器、栈帧内容均和原始调用方执行跳转时一致。
5. after_objc_msgSend 将原有 lr 的值作为返回值返回，并设置至 lr 寄存器之中，确保能正确返回。

整套方案最巧妙的点在于，“复用”了调用方的整个栈帧，站在栈空间的角度来看，hook 方法对于调用和被调用方都是透明的；而为了达到 100% 还原栈帧，lr 的值便只能传递出去存至堆区了。

在几个关键点，堆栈和寄存器状态如图：

可以看到，在调用原实现时，唯一的不同点就是 lr 寄存器指向了 hook 方法，使原方法执行完后回到 hook 方法中。在汇编指令执行时，位于当前 sp 寄存器下面(低址)的内存属于“无人认领”的内存，可以任意使用。这就是为什么第二步我们需要下移 sp，而第三步我们也不需要清理低址残留的寄存器值。

参考

Hook objc_msgSend -- 从 0.5 到 1