作 者:道哥,10+年嵌入式开发老兵,专注于:C/C++、嵌入式、Linux。
关注,回复【书籍】,获取 Linux、嵌入式领域经典书籍;回复【PDF】,获取所有原创文章( PDF 格式)。
目录
文章目录
- 理论与实践
- 开始
- 新的动态库
- 面临的问题
- 怎么做?
- ELF
- 概述
- ELF 文件头
- SHT(section header table)
- PHT(program header table)
- 连接视图(Linking View)和执行视图(Execution View)
- .dynamic section
- 动态链接器(linker)
- 追踪
- 内存
- 基地址
- 内存访问权限
- 指令缓存
- 验证
- 使用 xhook
- FAQ
- 可以直接从文件中读取 ELF 信息吗?
- 计算基地址的精确方法是什么?
- 目标 ELF 使用的编译选项对 hook 有什么影响?
- hook 时遇到偶发的段错误是什么原因?如何处理?
- ELF 内部函数之间的调用能 hook 吗?
别人的经验,我们的阶梯!
大家好,我是道哥,今天我为大伙儿解说的技术知识点是:【动态库的内存处理】。
在上周的一篇转载文章中,介绍了一种如何把一个动态库中的调用函数进行“掉包”的技术,从而达到一些特殊的目的。
这个技术是爱奇艺开源的 xHook,github
地址是:https://github.com/iqiyi/xHook。
在官方文档中,作者的描述场景是android
系统。因为底层都是基于Linux
的,因此这里介绍的hook
技术也同样适合其他Linux
系统的工作环境。
这篇文章,我们就一起向大神学习一下,如何一步一步找到目标(被调用函数的地址),然后偷换成其他的函数地址。
文章的内容比较长,但是绝对值得花半天的功夫、甚至几天的时间来研究其中的知识点。
也许它不能立竿见影的提高你的编程技术,但是对于内功的修炼、提升,绝对是一等一的好资料!
在学习的过程中,我会在一些重要的地方,用橙色字体加上自己的学习心得,或者说理解。如果理解有误,欢迎指出、一起讨论。
为了便于阅读,我在原文中比较关键的文字上,添加了字体颜色。
理论与实践
关于动态库的相关内容,市面上质量比较好的书籍可能就是:《程序员的自我修养-链接、装载和库》这本书了。
我手里的这一本,是 2019 年 6 月第 29 次印刷,足见这本书的生命力是多么的强悍!
如果您读过这本书,可能会有这样的感受:书中的内容理论性太强,即使自己明白了其中的道理,但是应该如何实践呢?或者说,能利用这些知识点来做什么呢?
爱奇艺的xHook
,就是对这些理论知识的完美实践!
《程序员的自我修养-链接、装载和库》是一本不可多得的好书,如果您对动态库很感兴趣,建议您入手一本纸质书,支持一下作者!
如果只是想浏览一下,我这里有一个 PDF 版本(忘记从哪里下载的了),已经放在网盘里。
如果您需要的话,在公众号【IOT物联网小镇】的后台留言:1031,即可获取下载链接。
开始
新的动态库
我们有一个新的动态库:libtest.so
。
头文件 test.h
源文件 test.c
say_hello
的功能是在终端打印出hello\n
这6个字符(包括结尾的\n
)。
我们需要一个测试程序:main
。
源文件 main.c
编译它们分别生成libtest.so
和main
。运行一下:
太棒了!libtest.so
的代码虽然看上去有些愚蠢,但是它居然可以正确的工作,那还有什么可抱怨的呢?
赶紧在新版APP
中开始使用它吧!
遗憾的是,正如你可能已经发现的,libtest.so
存在严重的内存泄露问题,每调用一次say_hello
函数,就会泄露1024
字节的内存。
新版APP
上线后崩溃率开始上升,各种诡异的崩溃信息和报障信息跌撞而至。
面临的问题
幸运的是,我们修复了libtest.so
的问题。可是以后怎么办呢?我们面临2
个问题:
- 当测试覆盖不足时,如何及时发现和准确定位线上 APP 的此类问题?
- 如果 libtest.so 是某些机型的系统库,或者第三方的闭源库,我们如何修复它?如果监控它的行为?
怎么做?
如果我们能对动态库中的函数调用做 hook
(替换,拦截,窃听,或者你觉得任何正确的描述方式),那就能够做到很多我们想做的事情。
比如hook malloc
,calloc
,realloc
和free
,我们就能统计出各个动态库分配了多少内存,哪些内存一直被占用没有释放。
这真的能做到吗?答案是:hook
我们自己的进程是完全可以的。
hook
其他进程需要root
权限(对于其他进程,没有root
权限就没法修改它的内存空间,也没法注入代码)。
幸运的是,我们只要hook
自己就够了。
道哥注解:
如果去 hook 不属于自己的进程,那就真的属于病毒了!
进程级别的隔离,一般由操作系统来处理!
ELF
道哥注解:
关于 ELF 的详细介绍,也可以看一下我之前写的一篇文章:Linux系统中编译、链接的基石-ELF文件:扒开它的层层外衣,从字节码的粒度来探索。
这篇文章的内容非常详细,就像剥洋葱一样,一层一层分析 ELF 文件的结构。
并且以图片的方式,把 ELF 文件中的二进制内容与相关的结构体成员变量一一对应起来,比较直观。
概述
ELF(Executable and Linkable Format)
是一种行业标准的二进制数据封装格式,主要用于封装可执行文件、动态库、object
文件和 core dumps
文件。
使用google NDK
对源代码进行编译和链接,生成的动态库或可执行文件都是ELF
格式的。
用readelf
可以查看ELF
文件的基本信息,用objdump
可以查看ELF
文件的反汇编输出。
ELF
格式的概述可以参考这里,完整定义可以参考这里。
其中最重要的部分是:ELF 文件头、SHT(section header table)、PHT(program header table)
。
ELF 文件头
ELF
文件的起始处,有一个固定格式的定长的文件头(32
位架构为52
字节,64
位架构为64
字节)。ELF
文件头以magic number 0x7F 0x45 0x4C 0x46
开始(其中后3
个字节分别对应可见字符E L F
)。
libtest.so
的ELF
文件头信息:
ELF
文件头中包含了SHT
和PHT
在当前ELF
文件中的起始位置和长度。
例如,libtest.so
的SHT
起始位置为12744
,长度40
字节;
PHT
起始位置52
,长度32
字节。
SHT(section header table)
ELF
以section
为单位来组织和管理各种信息。
ELF
使用SHT
来记录所有section
的基本信息。
主要包括:section
的类型、在文件中的偏移量、大小、加载到内存后的虚拟内存相对地址、内存中字节的对齐方式等。
libtest.so
的SHT
:
比较重要,且和hook
关系比较大的几个section
是:
dynstr:保存了所有的字符串常量信息。
dynsym:保存了符号(symbol)的信息(符号的类型、起始地址、大小、符号名称在 .dynstr 中的索引编号等)。函数也是一种符号。
text:程序代码经过编译后生成的机器指令。
dynamic:供动态链接器使用的各项信息,记录了当前 ELF 的外部依赖,以及其他各个重要 section 的起始位置等信息。
got:Global Offset Table。用于记录外部调用的入口地址。动态链接器(linker)执行重定位(relocate)操作时,这里会被填入真实的外部调用的绝对地址。
plt:Procedure Linkage Table。外部调用的跳板,主要用于支持 lazy binding 方式的外部调用重定位。(Android 目前只有 MIPS 架构支持 lazy binding)
rel.plt:对外部函数直接调用的重定位信息。
rel.dyn:除 .rel.plt 以外的重定位信息。(比如通过全局函数指针来调用外部函数)
道哥注解:
ELF
文件中,dynamic
这个section
是非常重要的!
当一个动态库被加载到内存中时,动态链接器就是读取这个section
的内容,比如:
依赖于其他哪些共享对象;
动态链接符号表的位置(.dynsym);
动态链接重定位表的位置;
初始化代码的位置;
…
使用指令: readelf -d xxx.so
,即可查看一个动态库中 .dynamic
的内容。
另外,got
和plt
这两个 section
,主要就是用来处理地址无关的功能。
如果您查询-fPIC
的相关内容,一定会讲解这两个知识点。
总的来说就是:Linux
下的动态库,把代码段中地址有关的部分,通过“增加一层”的原理,全部变成“地址无关”的。
这样的话,动态库的代码段在加载到物理内存中之后,就可以被多个不同的进程来共享了,只要把代码段的物理地址,映射到每个进程自己的虚拟地址即可。
而“地址相关”的部分,就放在got
(对变量的引用) 和plt
(对函数的引用) 中。
PHT(program header table)
·ELF 被加载到内存时,是以
segment 为单位的。一个
segment 包含了一个或多个
section`。
ELF
使用PHT
来记录所有segment
的基本信息。
主要包括:segment
的类型、在文件中的偏移量、大小、加载到内存后的虚拟内存相对地址、内存中字节的对齐方式等。
libtest.so
的PHT
:
所有类型为PT_LOAD
的segment
都会被动态链接器(linker
)映射(mmap
)到内存中。
连接视图(Linking View)和执行视图(Execution View)
连接视图:ELF 未被加载到内存执行前,以 section 为单位的数据组织形式。
执行视图:ELF 被加载到内存后,以 segment 为单位的数据组织形式。
我们关心的hook
操作,属于动态形式的内存操作,因此主要关心的是执行视图,即ELF
被加载到内存后,ELF
中的数据是如何组织和存放的。
.dynamic section
这是一个十分重要和特殊的section
,其中包含了ELF
中其他各个section
的内存位置等信息。
在执行视图中,总是会存在一个类型为PT_DYNAMIC
的segment
,这个segment
就包含了.dynamic section
的内容。
无论是执行hook
操作时,还是动态链接器执行动态链接时,都需要通过PT_DYNAMIC segment
来找到.dynamic section
的内存位置,再进一步读取其他各项section
的信息。
libtest.so
的.dynamic section
:
动态链接器(linker)
安卓中的动态链接器程序是linker
。源码在这里。
动态链接(比如执行dlopen
)的大致步骤是:
- 检查已加载的 ELF 列表。(如果 libtest.so 已经加载,就不再重复加载了,仅把 libtest.so 的引用计数加一,然后直接返回。)
- 从 libtest.so 的 .dynamic section 中读取 libtest.so 的外部依赖的 ELF 列表,从此列表中剔除已加载的 ELF,最后得到本次需要加载的 ELF 完整列表(包括 libtest.so 自身)。
- 逐个加载列表中的 ELF。加载步骤:
(1) 用 mmap 预留一块足够大的内存,用于后续映射 ELF。(MAP_PRIVATE 方式)
(2) 读 ELF 的 PHT,用 mmap 把所有类型为 PT_LOAD 的 segment 依次映射到内存中。
(3) 从 .dynamic segment 中读取各信息项,主要是各个 section 的虚拟内存相对地址,然后计算并保存各个 section 的虚拟内存绝对地址。
(4) 执行重定位操作(relocate),这是最关键的一步。重定位信息可能存在于下面的一个或多个 secion 中:.rel.plt, .rela.plt, .rel.dyn, .rela.dyn, .rel.android, .rela.android。动态链接器需要逐个处理这些 .relxxx section 中的重定位诉求。根据已加载的 ELF 的信息,动态链接器查找所需符号的地址(比如 libtest.so 的符号 malloc),找到后,将地址值填入 .relxxx 中指明的目标地址中,这些“目标地址”一般存在于.got 或 .data 中。
(5) ELF 的引用计数加一。
- 逐个调用列表中 ELF 的构造函数(constructor),这些构造函数的地址是之前从 .dynamic segment 中读取到的(类型为 DT_INIT 和 DT_INIT_ARRAY)。各 ELF 的构造函数是按照依赖关系逐层调用的,先调用被依赖 ELF 的构造函数,最后调用 libtest.so 自己的构造函数。(ELF 也可以定义自己的析构函数(destructor),在 ELF 被 unload 的时候会被自动调用)
等一下!我们似乎发现了什么!再看一遍重定位操作(relocate
)的部分。
难道我们只要从这些.relxxx
中获取到“目标地址”,然后在“目标地址”中重新填上一个新的函数地址,这样就完成hook
了吗?也许吧。
追踪
静态分析验证一下还是很容易的。以armeabi-v7a
架构的libtest.so
为例。
先看一下say_hello
函数对应的汇编代码吧。
找到了!say_hello
在地址f61
,对应的汇编指令体积为60
(10 进制)字节。
用objdump
查看say_hello
的反汇编输出。
对malloc
函数的调用对应于指令blx dd4
。跳转到了地址dd4
。
看看这个地址里有什么吧:
果然,跳转到了.plt
中,经过了几次地址计算,最后跳转到了地址3f90
中的值指向的地址处,3f90
是个函数指针。
稍微解释一下:因为arm
处理器使用3
级流水线,所以第一条指令取到的pc
的值是当前执行的指令地址+ 8
。
于是:dd4
+ 8
+ 3000
+ 1b4
= 3f90
。
地址3f90
在哪里呢:
果然,在.got
里。
顺便再看一下.rel.plt
:
malloc
的地址居然正好存放在3f90
里,这绝对不是巧合啊!
道哥注解:
.rel.plt
这个section
中,记录了重定位表的信息,也就是哪些函数地址需要被重定位。
链接器把所有被依赖的共享对象加载到内存中时,会把每个共享对象中的符号给汇总起来,得到全局符号表。
然后再检查每个共享对象中的.rel.plt
,是否需要对一些地址进行重定位。
如果需要的话,就从全局符号表中找到该符号的内存地址,然后填写到 .plt 中对应的位置。
还等什么,赶紧改代码吧。我们的main.c
应该改成这样:
编译运行一下:
思路是正确的。但之所以还是失败了,是因为这段代码存在下面的3
个问题:
- 3f90 是个相对内存地址,需要把它换算成绝对地址。
- 3f90 对应的绝对地址很可能没有写入权限,直接对这个地址赋值会引起段错误。
- 新的函数地址即使赋值成功了,my_malloc 也不会被执行,因为处理器有指令缓存(instruction cache)。
我们需要解决这些问题。
内存
基地址
在进程的内存空间中,各种ELF
的加载地址是随机的,只有在运行时才能拿到加载地址,也就是基地址。
道哥注解:
我们在查看一个动态链接库时,看到的入口地址都是0x0000_0000
。
动态库在被加载到内存中时,因为存在加载顺序的问题,所以加载地址不是固定的。
还有一种说法:对于某一个进程而言,它在被加载到内存中时,它所依赖的所有动态库的顺序是一定的。
因此,每个动态库的加载地址也是固定的,因此,理论上可以在第一次重定位之后,把重定位之后的代码段存储下来。
这样,以后再次启动这个进程时,就不需要重定位了,加快程序的启动速度。
我们需要知道ELF
的基地址,才能将相对地址换算成绝对地址。
没有错,熟悉Linux
开发的聪明的你一定知道,我们可以直接调用dl_iterate_phdr
。详细的定义见这里。
道哥注解:
dl_iterate_phdr
这个函数真的很有用,以回调函数的形式可到每一个动态链接库的加载地址等信息。
如果没有这个函数,很多信息就需要从 /proc/xxx/maps
中来获取,执行速度慢,因为要处理很多字符串信息。
嗯,先等等,多年的Android
开发被坑经历告诉我们,还是再看一眼NDK
里的linker.h
头文件吧:
为什么?!ARM
架构的Android 5.0
以下版本居然不支持dl_iterate_phdr
!
我们的APP
可是要支持Android 4.0
以上的所有版本啊。
特别是ARM
,怎么能不支持呢?!这还让不让人写代码啦!
幸运的是,我们想到了,我们还可以解析/proc/self/maps
:
maps
返回的是指定进程的内存空间中mmap
的映射信息,包括各种动态库、可执行文件(如:linker
),栈空间,堆空间,甚至还包括字体文件。
maps
格式的详细说明见这里。
我们的libtest.so
在maps
中有3
行记录。
offset
为0
的第一行的起始地址b6ec6000
在绝大多数情况下就是我们寻找的基地址。
内存访问权限
maps
返回的信息中已经包含了权限访问信息。
如果要执行hook
,就需要写入的权限,可以使用mprotect
来完成:
注意修改内存访问权限时,只能以“页”为单位。
mprotect 的详细说明见这里。
指令缓存
注意.got
和.data
的section
类型是 PROGBITS
,也就是执行代码。处理器可能会对这部分数据做缓存。
修改内存地址后,我们需要清除处理器的指令缓存,让处理器重新从内存中读取这部分指令。
方法是调用__builtin___clear_cache
:
注意清除指令缓存时,也只能以“页”为单位。__builtin___clear_cache
的详细说明见这里。
验证
我们把main.c
修改为:
重新编译运行:
是的,成功了!
我们并没有修改libtest.so
的代码,甚至没有重新编译它。我们仅仅修改了main
程序。
libtest.so
和main
的源码放在github
上,可以从这里获取到。
(根据你使用的编译器不同,或者编译器的版本不同,生成的libtest.so
中,也许malloc
对应的地址不再是0x3f90
,这时你需要先用readelf
确认,然后再到main.c
中修改。)
使用 xhook
当然,我们已经开源了一个叫xhook
的工具库。
使用xhook
,你可以更优雅的完成对libtest.so
的hook
操作,也不必担心硬编码0x3f90
导致的兼容性问题。
xhook
支持armeabi
, armeabi-v7a
和arm64-v8a
。
支持Android 4.0 (含)
以上版本 (API level
>= 14
)。
经过了产品级的稳定性和兼容性验证。可以在这里 获取xhook
。
总结一下xhook
中执行PLT hook
的流程:
- 读 maps,获取 ELF 的内存首地址(start address)。
- 验证 ELF 头信息。
- 从 PHT 中找到类型为 PT_LOAD 且 offset 为 0 的 segment。计算 ELF 基地址。
- 从 PHT 中找到类型为 PT_DYNAMIC 的 segment,从中获取到 .dynamic section,从 .dynamic section中获取其他各项 section 对应的内存地址。
- 在 .dynstr section 中找到需要 hook 的 symbol 对应的 index 值。
- 遍历所有的 .relxxx section(重定位 section),查找 symbol index 和 symbol type 都匹配的项,对于这项重定位项,执行 hook 操作。hook 流程如下:
(1) 读 maps,确认当前 hook 地址的内存访问权限。
(2) 如果权限不是可读也可写,则用 mprotect 修改访问权限为可读也可写。
(3) 如果调用方需要,就保留 hook 地址当前的值,用于返回。
(4) 将 hook 地址的值替换为新的值。(执行 hook)
(5) 如果之前用 mprotect 修改过内存访问权限,现在还原到之前的权限。
(6) 清除 hook 地址所在内存页的处理器指令缓存。
FAQ
可以直接从文件中读取 ELF 信息吗?
可以。
而且对于格式解析来说,读文件是最稳妥的方式,因为ELF
在运行时,原理上有很多section
不需要一直保留在内存中,可以在加载完之后就从内存中丢弃,这样可以节省少量的内存。
但是从实践的角度出发,各种平台的动态链接器和加载器,都不会这么做,可能它们认为增加的复杂度得不偿失。
所以我们从内存中读取各种ELF
信息就可以了,读文件反而增加了性能损耗。
另外,某些系统库ELF
文件,APP
也不一定有访问权限。
计算基地址的精确方法是什么?
正如你已经注意到的,前面介绍libtest.so
基地址获取时,为了简化概念和编码方便,用了“绝大多数情况下”这种不应该出现的描述方式。
对于hook
来说,精确的基地址计算流程是:
- 在 maps 中找到找到 offset 为 0,且 pathname 为目标 ELF 的行。保存该行的 start address 为 p0。
- 找出 ELF 的 PHT 中第一个类型为 PT_LOAD 且 offset 为 0 的 segment,保存该 segment 的虚拟内存相对地址(p_vaddr)为 p1。
- p0 - p1 即为该 ELF 当前的基地址。
绝大多数的ELF
第一个PT_LOAD segment
的p_vaddr
都是0
。
另外,之所以要在maps
里找offset
为0
的行,是因为我们在执行hook
之前,希望对内存中的ELF
文件头进行校验,确保当前操作的是一个有效的ELF
,而这种 ELF
文件头只能出现在offset
为0
的mmap
区域。
可以在Android linker
的源码中搜索“load_bias”
,可以找到很多详细的注释说明,也可以参考linker
中对 load_bias_
变量的赋值程序逻辑。
目标 ELF 使用的编译选项对 hook 有什么影响?
会有一些影响。
对于外部函数的调用,可以分为3
种情况:
- 直接调用。无论编译选项如何,都可以被 hook 到。外部函数地址始终保存在 .got 中。
- 通过全局函数指针调用。无论编译选项如何,都可以被 hook 到。外部函数地址始终保存在 .data 中。
- 通过局部函数指针调用。如果编译选项为 -O2(默认值),调用将被优化为直接调用(同情况 1)。如果编译选项为 -O0,则在执行 hook 前已经被赋值到临时变量中的外部函数的指针,通过 PLT 方式无法 hook;对于执行 hook 之后才被赋值的,可以通过 PLT 方式 hook。
一般情况下,产品级的ELF
很少会使用-O0
进行编译,所以也不必太纠结。
但是如果你希望你的ELF
尽量不被别人PLT hook
,那可以试试使用-O0
来编译,然后尽量早的将外部函数的指针赋值给局部函数指针变量,之后一直使用这些局部函数指针来访问外部函数。
总之,查看C/C++
的源代码对这个问题的理解没有意义,需要查看使用不同的编译选项后,生成的ELF
的反汇编输出,比较它们的区别,才能知道哪些情况由于什么原因导致无法被PLT hook
。
hook 时遇到偶发的段错误是什么原因?如何处理?
我们有时会遇到这样的问题:
- 读取 /proc/self/maps 后发现某个内存区域的访问权限为可读,当我们读取该区域的内容做 ELF 文件头校验时,发生了段错误(sig: SIGSEGV, code: SEGV_ACCERR)。
- 已经用 mprotect() 修改了某个内存区域的访问权限为可写,mprotect() 返回修改成功,然后再次读取 /proc/self/maps 确认对应内存区域的访问权限确实为可写,执行写入操作(替换函数指针,执行 hook)时发生段错误(sig: SIGSEGV, code: SEGV_ACCERR)。
- 读取和验证 ELF 文件头成功了,根据 ELF 头中的相对地址值,进一步读取 PHT 或者 .dynamic section 时发生段错误(sig: SIGSEGV, code: SEGV_ACCERR 或 SEGV_MAPERR)。
可能的原因是:
- 进程的内存空间是多线程共享的,我们在执行 hook 时,其他线程(甚至 linker)可能正在执行 dlclose(),或者正在用 mprotect() 修改这块内存区域的访问权限。
- 不同厂家、机型、版本的 Android ROM 可能有未公开的行为,比如在某些情况下对某些内存区域存在写保护或者读保护机制,而这些保护机制并不反应在 /proc/self/maps 的内容中。
问题分析:
- 读内存时发生段错误其实是无害的。
- 我在 hook 执行的流程中,需要直接通过计算内存地址的方式来写入数据的地方只有一处:即替换函数指针的最关键的那一行。只要其他地方的逻辑没有错误,这里就算写入失败了,也不会对其他内存区域造成破坏。
- 加载运行安卓平台的 APP 进程时,加载器已经向我们注入了 signal handler 的注册逻辑,以便 APP 崩溃时与系统的 debuggerd 守护进程通讯,debuggerd 使用 ptrace 调试崩溃进程,获取需要的崩溃现场信息,记录到 tombstone 文件中,然后 APP 自杀。
- 系统会精确的把段错误信号发送给“发生段错误的线程”。
- 我们希望能有一种隐秘的,且可控的方式来避免段错误引起 APP 崩溃。
先明确一个观点:
不要只从应用层程序开发的角度来看待段错误,段错误不是洪水猛兽,它只是内核与用户进程的一种正常的交流方式。
当用户进程访问了无权限或未mmap
的虚拟内存地址时,内核向用户进程发送SIGSEGV
信号,来通知用户进程,仅此而已。
只要段错误的发生位置是可控的,我们就可以在用户进程中处理它。
解决方案:
- 当 hook 逻辑进入我们认为的危险区域(直接计算内存地址进行读写)之前,通过一个全局 flag 来进行标记,离开危险区域后将 flag 复位。
- 注册我们自己的 signal handler,只捕获段错误。在 signal handler 中,通过判断 flag 的值,来判断当前线程逻辑是否在危险区域中。如果是,就用 siglongjmp 跳出 signal handler,直接跳到我们预先设置好的“危险区域以外的下一行代码处”;如果不是,就恢复之前加载器向我们注入的 signal handler,然后直接返回,这时系统会再次向我们的线程发送段错误信号,由于已经恢复了之前的 signal handler,这时会进入默认的系统 signal handler 中走正常逻辑。
- 我们把这种机制简称为:SFP (segmentation fault protection,段错误保护)
- 注意:SFP需要一个开关,让我们随时能够开启和关闭它。在 APP 开发调试阶段,SFP 应该始终被关闭,这样就不会错过由于编码失误导致的段错误,这些错误是应该被修复的;在正式上线后 SFP 应该被开启,这样能保证 APP 不会崩溃。(当然,以采样的形式部分关闭 SFP,用以观察和分析 hook 机制本身导致的崩溃,也是可以考虑的)
具体代码可以参考xhook
中的实现,在源码中搜索siglongjmp
和 sigsetjmp
。
ELF 内部函数之间的调用能 hook 吗?
我们这里介绍的hook
方式为PLT hook
,不能做ELF
内部函数之间调用的hook
。
道哥注解:
外部函数是被记录到.plt
这个section
中的,因此可以在这个section
中一步一步找到它的重定位地址,然后进行修改。
对于内部函数来说,比如一个使用static
关键字修饰的函数,编译器在编译时,可能就直接把函数的地址“硬编码”在引用它的地方了。
这也是为什么:如果一个函数只在文件内部使用,最好加上 static 关键字。
一个原因是安全,防止与其他文件中的符号重名,还有一个原因是加快启动速度,因为不需要重定位啊!
inline hook
可以做到,你需要先知道想要hook
的内部函数符号名(symbol name
)或者地址,然后可以hook
。
有很多开源和非开源的inline hook
实现,比如:
substrate:http://www.cydiasubstrate.com/
frida:https://www.frida.re/
inline hook
方案强大的同时可能带来以下的问题:
- 由于需要直接解析和修改 ELF 中的机器指令(汇编码),对于不同架构的处理器、处理器指令集、编译器优化选项、操作系统版本可能存在不同的兼容性和稳定性问题。
- 发生问题后可能难以分析和定位,一些知名的 inline hook 方案是闭源的。
- 实现起来相对复杂,难度也较大。
- 未知的坑相对较多,这个可以自行 google。
建议如果PLT hook
够用的话,就不必尝试inline hook
了。
------ End ------