通过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的核心逻辑，来服务自己项目许多方面。

源码

参考