文章目录
  1. 1. 通过fishhook拦截方法的局限性
  2. 2. 实现过程遇到的坑跟核心逻辑
    1. 2.1. 静态库是fat file
    2. 2.2. 目标文件头size的意义
    3. 2.3. 过滤需要处理的类
    4. 2.4. 寻找字符串表的location跟size
    5. 2.5. 替换字符串表中的objc_msgSend
    6. 2.6. _hook_msgSend的实现
  3. 3. KKMagicHook的适用场景
  4. 4. KKMagicHook的意义
  5. 5. 源码
  6. 6. 参考

通过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架构。

1
2
3
4
5
6
7
8
9
10
11
12
13
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的意义

1
2
3
4
5
6
7
8
9
10
11
//静态库本身的符号表头跟目标文件头数据结构一样的
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方法都替换。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
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。

1
2
3
4
5
6
7
8
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会被丢弃。最后发现二进制也可以替换😂。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
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的实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
.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方法的耗时:

1

KKMagicHook的意义

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

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

源码

KKMagicHook

参考

  1. https://juejin.im/post/5e1280fae51d4540e47ca450
  2. https://juejin.im/post/5d5275b251882505417927b5
  3. https://juejin.im/post/5d527867f265da03ed1946d2
文章目录
  1. 1. 通过fishhook拦截方法的局限性
  2. 2. 实现过程遇到的坑跟核心逻辑
    1. 2.1. 静态库是fat file
    2. 2.2. 目标文件头size的意义
    3. 2.3. 过滤需要处理的类
    4. 2.4. 寻找字符串表的location跟size
    5. 2.5. 替换字符串表中的objc_msgSend
    6. 2.6. _hook_msgSend的实现
  3. 3. KKMagicHook的适用场景
  4. 4. KKMagicHook的意义
  5. 5. 源码
  6. 6. 参考