Runtime —— Method Swizzle

0x01.runtime和Method Swizzle

runtime是Objective C 语言的特殊机制。总的来说，OC通过runtime联系上c和c++，其底层由c语言编写

根据OC语言的特性，有很多类和成员变量在编译时是系统不知道的，而在运行时，我们所编写的代码才会转换成完整的确定的代码去运行（运行时链接）。因此，仅仅只有一套编译器是不够的，还需要一套运行时系统（Runtime System）来处理编译后的工作，runtime就是这样一个系统。根据这个原理，在运行时交换原有方法和我们自己编写的新方法的imp指针，可以达到hook函数的目的，是为Method Swizzle。

---

0x02.简单实现

下面简单实现一个普普通通的demo

一个button按钮，会调用很多方法

这些调用的方法都是简单的输出log，反正是拿来凑数的代码。不重要

编写一下Method Swizzle的代码。

代码

这里把trycheck6函数和自己编写的gogo函数做了交换，关键的交换函数就是method_exchangeImplementations函数，用于方法指针的交换。

运行效果就不看了，就是该执行trycheck6时打印了gogogogo

这样方法交换就完成了。相当于实现了对old函数也就是trycheck6这个函数的hook，改变了它的功能和逻辑。但其实它的名字和外皮并没有改变。

---

0x03.观察

以runtime的特性，我们在它运行的时候获取一个类下所有方法的imp指针。达到遍历所有方法的目的。

之前没接触过Objective C，就随便写写。代码如下：

+(NSArray*)getAllmethods

{

    unsigned int methodCount =0;

    const char* lastname;

    Method* methodList =class_copyMethodList([self class], &methodCount);

    NSMutableArray*methodsArray = [NSMutableArrayarrayWithCapacity:methodCount];

    Methodtemp = methodList[i];

    IMP imp = method_getImplementation(temp);

    const  char* name_s =sel_getName(method_getName(temp));

    //SEL name_f = method_getName(temp);

    lastname = name_s;

    //int arguments = method_getNumberOfArguments(temp);

    //const char* encoding = method_getTypeEncoding(temp);

    //NSLog(@"方法名:%@,参数个数:%d,编码方式:%@",[NSString stringWithUTF8String:name_s],arguments,[NSString stringWithUTF8String:encoding]);

        [methods ArrayaddObject:[NSString stringWithUTF8String:name_s]];

    }

    free(methodList);

    return methodsArray;

}

随便复制一手，最后返回的函数列表

返回的函数列表

这只是某一个类中所获取到的函数。要获取所有的函数需要遍历类。

可以看到，就算是方法交换之后返回的函数列表，trycheck6也还是trycheck6。他的名字并没有变成gogo。可见这还是有点欺骗性的。

---

0x04.天马行空的想象

我们如何去检测一个函数是否被hook呢？

其实在调试中是可以看见不一样的

imp指针的蛛丝马迹

这里imp指针的值可以看见，就算我把我的new方法改成了trycheck6同名，前面也会带上MSHook。人工一眼就能看见是被hook了。

那从antihook的角度来讲，是不是获取imp里面的值做比较就行了呢？有两个问题：

第一，imp是指针，指向的是函数的地址。Xcode只是便于让开发者具体的看才转化成了这个样子，其实imp的值只是一串十六进制数而已

第二，就算第一条能实现。要检测同名的替换函数，势必要检测类名，一个真正的工程有很多类名，要遍历类还要遍历每个类下的函数，太耗时了。

综上直接去比较imp指针是行不通的。但是要检测一个函数是否被hook也肯定离不开imp指针的。

我们来看一下，old和new在内存上的位置

上面的是old，下面的是new

用于方法交换的new的地址是比old的地址高的。这里只是我的demo的情况。在真正的项目中，注入动态库来进行方法交换的话，动态库会被注入到Load_command段末尾而不是像我一样直接写在项目中，可能会有old和new地址偏移量大的情况，这个留待后面验证。

基于这个思路，既然是交换了指向方法的imp指针，imp指针的值肯定有变化。同一个类中函数的地址是由低到高线性变化的。

这里

从没实现Method Swizzle时上面打印的log可以发现，同一个类中函数的地址是由低到高线性变化的，而且若函数体一样大偏移也是一样的。

那么我们实现了Method Swizzle之后呢，我们可以看看

出现了

很惊讶，trycheck7的地址要比trycheck6的地址低，所以偏移出现了负数。这很好理解，因为new的地址比old的地址高，交换过来trycheck6的地址也变高了。

那么这样可以不可以作为一个判断trycheck6被hook的依据呢？我觉得是可以的，但是我自己写的demo只有几十kb大小，函数调用也并不够复杂。

我弄了几个更大的app工程，发现machO文件越大，new和old的距离是越大的，单个函数体越复杂越大，函数直接的偏移也是越大的，在实际工程中应该可以取一个阀值，当两个在内存中线性的函数偏移量绝对值大于了这个阈值，那么一般是可以认定为有问题的。或者对于小的工程，也可以按比例取阈值，这个就有点天马行空的想象了。