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的距离是越大的,单个函数体越复杂越大,函数直接的偏移也是越大的,在实际工程中应该可以取一个阀值,当两个在内存中线性的函数偏移量绝对值大于了这个阈值,那么一般是可以认定为有问题的。或者对于小的工程,也可以按比例取阈值,这个就有点天马行空的想象了。

你可能感兴趣的:(Runtime —— Method Swizzle)