通过fishhook拦截方法的局限性

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

不能选择hook一部分类的OC方法，全部hook会有性能问题，所以也不能线上使用。
个别同学反映，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 */
};

这块需要知道理论知识：

替换字符串表中的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

参考