阅读 4659

静态插桩的方式来实现Hook Method

通过fishhook拦截方法的局限性

我之前写了一个开源库TimeProfiler监控所有的OC方法耗时。可以在开发App阶段,很方便的看到主线程所有OC方法的耗时。但是由于TimeProfiler是通过fishhook基于运行时hook,所以从原理上,它就有局限性:不能选择hook部分类的OC方法。这造成2个很难解决的问题:

  1. 不能选择hook一部分类的OC方法,全部hook会有性能问题,所以也不能线上使用。
  2. 个别同学反映,TimeProfiler hook某个类的方法,会crash。但是由于代码安全性,不能把代码给我看,因为这个类跟项目强相关,也不能造一个crash的demo给我排查问题。所以我只能盲猜哪里出问题,效率极低。而他们也会因为hook这个类crash,导致不能用到这么好的工具,多可惜~ 而KKMagicHook可以选择不hook这个类,不妨碍使用这个工具。

KKMagicHook通过静态插桩的方式来实现Hook,可以选择自己需要hook的模块。

既然大家有这样的痛点,我就来想办法解决。网上有facebook方案:通过 llvm 插桩;手淘提到的汇编插桩。好吧,对于只能工作之外时间做这个事情,我暂时没有时间去做这个(但确实挺感兴趣的,后面时间允许,我研究完,也会分享出来)。然后看到这篇文章:静态拦截iOS对象方法调用的简易实现,大佬只是大致说了原理,但是网上并没有找到任何关于它的实现。我只好自己动手,在做的过程中,感觉还是挺复杂的(至少你要非常熟悉静态库和目标文件的结构。大佬说的简易,应该是相对于llvm 插桩跟汇编插桩来说吧),有许多坑~ 所以也写这篇文章分享一下。

实现过程遇到的坑跟核心逻辑

我就不一行一行解读具体实现代码了,我挑遇到的坑跟核心逻辑说一下,然后大家结合代码KKMagicHook,就很容易理解了。

静态库是fat file

脚本只处理arm64架构的静态库,如果静态库是fat file,包含多种架构。我是先从fat file中提取出arm64架构的静态库,交给脚本处理;处理完之后,在replace fat file中的arm64架构。

def deal_fat_file():
    global staticLibPath, fatFilePath
    fatFilePath = staticLibPath
    (fatFileDir, fatFileName) = os.path.split(fatFilePath)
    fatFileName = 'tmp-arm64-'+fatFileName
    staticLibPath = os.path.join(fatFileDir, fatFileName)
    # 提取出arm64架构的静态库
    os.system('lipo ' + fatFilePath + ' -thin ' + 'arm64 -output '+ staticLibPath)

def replace_fat_file():
    # replace fat file中的arm64架构
    os.system('lipo '+fatFilePath+' -replace arm64 '+staticLibPath+' -output '+fatFilePath)
    os.remove(staticLibPath)
复制代码

特别说明,处理后,只有arm64里的objc_msgSend方法被替换成了hook_msgSend,所以在arm64平台的设备上运行时候,都是调用hook_msgSend;而在其它架构平台,依然是调用objc_msgSend方法,对其它架构平台没有任何影响。

目标文件头size的意义

//静态库本身的符号表头跟目标文件头数据结构一样的
struct object_header {  
    char        name[16];       /* 名称 */
    char        timestamp[12];  /* 生成的时间戳 */
    char        userid[6];        /* 用户id */
    char        groupid[6];  /* 组id */
    uint64_t    mode;            /* 文件访问模式 */
    uint64_t    size;            /* 目标文件的字节大小 */
    uint32_t    endheader;        /* 头结束标志 */
    char        longname[0];   /* 目标文件名(不定长) */
};
复制代码

网上所有文章都说size是目标文件的字节大小,但是我在解析过程中,发现咋算都对不上。最后看MachOView源码才知道,size表示目标文件的大小 + longname的大小。所以说只有longname长度为0时候,size才表示目标文件的大小。longname长度可以从name中获取,如果name是以"#1/"开头,那"#1/xx",xx就表示longname的长度。否则longname长度为0。

过滤需要处理的类

其实我们过滤的是需要处理的目标文件,但是目标文件名就是类名(类名是ClassA,目标文件名就是ClassA.o),并且一个类在一个文件中。所以说我们过滤需要处理的目标文件,就是过滤需要处理的类。

脚本中默认是替换静态库中所有类的objc_msgSend方法,当选择处理模式为:need_process_objFile,就只替换need_process_objFile集合里的类的objc_msgSend方法;当选择处理模式为:needless_process_objFile,表示除了needless_process_objFile集合里的类不替换,静态库中其余的类的objc_msgSend方法都替换。

need_process_objFile = set() # set('xx1', 'xx2') 表示静态库中,仅xx1跟xx2需要处理
needless_process_objFile = set() # set('xx1', 'xx2') 表示静态库中,xx1跟xx2不需要处理,剩下的都需要处理

def process_object_file(name, location, size):
# 根据需要,下面三行中,只需打开一行,另外两行需要注释掉
process_mode = 'default' # 默认处理该静态库中的所有目标文件(类)
#process_mode = 'need_process_objFile' # 只处理need_process_objFile集合(上面的集合,需要赋值)中的类
#process_mode = 'needless_process_objFile' # 除了needless_process_objFile集合(上面的集合,需要赋值)中的类不处理,剩下的都需要处理

# 这里可以过滤不需要处理的目标文件,或者只选择需要处理的目标文件
# 默认处理该静态库中的所有目标文件
if process_mode == 'need_process_objFile':
    if name in need_process_objFile:
        find_symtab(location, size)
elif process_mode == 'needless_process_objFile':
    if not name in need_process_objFile:
        find_symtab(location, size)
else:
    find_symtab(location, size)
复制代码

寻找字符串表的location跟size

遍历目标文件的Load Commands,找到符号表,根据stroff算出location。

struct symtab_command {
	uint32_t	cmd;		/* LC_SYMTAB */
	uint32_t	cmdsize;	/* sizeof(struct symtab_command) */
	uint32_t	symoff;		/* symbol table offset */
	uint32_t	nsyms;		/* number of symbol table entries */
	uint32_t	stroff;		/* string table offset */
	uint32_t	strsize;	/* string table size in bytes */
};
复制代码

这块需要知道理论知识:

  1. iOS程序员的自我修养-MachO文件结构分析(二)
  2. iOS程序员的自我修养-MachO文件静态链接(三)

替换字符串表中的objc_msgSend

直接看我开源出来的代码,这块逻辑很好懂。但是我做这块时候,踩好多坑(反思了一下,主要是我不懂python),比如我不知道python不能在原文件中修改指定位置内容(确实查到可以通过os.system调用sed,然后回写等方式),但是静态库只能以二进制方式打开,而那些都是处理文本。
我原本是找到字符串表,然后decode成字符串,然后替换完成,再encode成二进制,但是这样会造成失真。原因decode过程,\x00会被丢弃。最后发现二进制也可以替换😂。

def replace_Objc_MsgSend(fileLen):
pos = 0
bytes = b''
(loc, size) = symtabList_loc_size[0]
listIndex = 1
with open(staticLibPath, 'rb') as fileobj:
    while pos < fileLen:
        if pos == loc:
            content = fileobj.read(size)
            content = content.replace(b'\x00_objc_msgSend\x00', b'\x00_hook_msgSend\x00')
            pos = pos + size
            if listIndex < len(symtabList_loc_size):
                (loc, size) = symtabList_loc_size[listIndex]
                listIndex = 1 + listIndex
        else:
            step = 4
            if loc > pos:
                step = loc - pos
            else:
                step = fileLen - pos
            content = fileobj.read(step)
            pos = pos + step
        bytes = bytes + content
with open(staticLibPath, 'wb+') as fileobj:
    fileobj.write(bytes)

复制代码

_hook_msgSend的实现

.macro CALL_HOOK_BEFORE
    BACKUP_REGISTERS
    mov x2, lr
    bl _hook_objc_msgSend_before
    RESTORE_REGISTERS
.endmacro

.macro CALL_HOOK_AFTER
    BACKUP_REGISTERS
    bl _hook_objc_msgSend_after
    mov lr, x0
    RESTORE_REGISTERS
.endmacro

# hookObjcMsgSend.py里定义了函数名为hook_msgSend,如果修改脚本里的函数名,这里的函数名,也需跟脚本保持一致
ENTRY _hook_msgSend

CALL_HOOK_BEFORE
bl _objc_msgSend
CALL_HOOK_AFTER
ret

END_ENTRY _hook_msgSend
复制代码

这个汇编代码详细解说,请见我之前博客监控所有的OC方法耗时。唯独需要注意的是,汇编里的函数名,要跟hookObjcMsgSend.py里定义的函数名一致。

KKMagicHook的适用场景

我觉得KKMagicHook算是TimeProfiler的进阶版本,虽然可以实现TimeProfiler全部的功能,但是认为如果你要hook所有的OC方法,那为啥不用TimeProfiler,使用更简单。所以能用TimeProfiler就用TimeProfiler吧。

KKMagicHook应该更适用于,你想监控某个模块的OC方法耗时,你把这个模块编译成静态库,然后用KKMagicHook中的脚本处理一下,就可以了。例如项目中使用了TalkingData这个第三方库,我们想监控/评估一下这个第三方库的性能问题,这个时候就不想监控项目中其它类了,以免干扰分析。如图,很清晰显示TalkingData这个库所有OC方法的耗时:

KKMagicHook的意义

这个库本身跟TimeProfiler一样,是可视化OC方法的耗时。但是绝不止于此,KKMagicHook的核心逻辑是静态插桩的方式来实现Hook Method,可以服务更广的场景。这个TimeProfiler和fishhook关系一样,TimeProfiler只能用来可视化方法耗时,但是fishhook可以服务更广的场景。

所以大家可以使用KKMagicHook的核心逻辑,来服务自己项目许多方面。

源码

KKMagicHook

参考

  1. juejin.im/post/684490…
  2. juejin.im/post/684490…
  3. juejin.im/post/684490…