通用Android Native Hook 检测
前言
Hook技术运用很广泛，从应用安全角度来看，Hook也是动态分析、破解一款程序的有效手段。为了提高自己应用被破解的门槛，我们需要一些检测(对抗)手段，目前也有很多检测方法，有些是针对特定工具来检测，有些较为通用，这里我把我的一些想法分享给大家，欢迎批评指正
目标
给定一个进程内的一个So模块，判断它是被inline hook或者GOT hook
GOT HOOK检测
首先简单的介绍一下GOT hook是怎么做的
ELF常见的重定位方式如下
创建一个测试工程(arm)，来了解一下R_ARM_JUMP_SLOT、R_ARM_GLOB_DAT和R_ARM_ABS32具体是怎么重定位的，工程部分代码如下
编译成共享文件(-shared -fPIC)之后，先看看汇编代码，6个BLX对应源码中6个调用过程
再看看.rel.dyn段和.rel.plt段内容(我为了方便查看，grep了一下输出，导致信息不完整)，其中前5项是在.rel.dyn段，最后一项(R_ARM_JUMP_SLOT)在.rel.plt段
第一列是需要进行重定位位置在文件的偏移，通过IDA，分别来看看各个位置在文件中的内容
1.R_ARM_GLOB_DAT - 0x1adb4、0x1adb8、0x1adbc (这些位置都在.got段)
2.R_ARM_ABS32 - 0x1b004、0x1b008 (这些位置都在.data段)
3.R_ARM_JUMP_SLOT - 0x1ae5c (这也在.got段)
现在把这个共享文件加载(dlopen)到内存，再看看内存中这6个地址(加载基地址+文件偏移)的内容
1.R_ARM_GLOB_DAT - 0x1adb4、0x1adb8、0x1adbc
2.R_ARM_ABS32 - 0x1b004、0x1b008
3.R_ARM_JUMP_SLOT - 0x1ae5c
这个0xF28FB625(0xF28FB624+1)就是strlen在内存中的入口
直接来总结(文件偏移用小写16进制，实际内存地址用大写16进制)
1.R_ARM_GLOB_DAT，重定位信息记录在'.rel.dyn'段中，其offset指向了.got段中的项，在加载到内存后，会将offset的内容修改为相应符号的实际内存地址
a.0x1adb4(strlen_ptr) 内容被修改成了 strlen 的实际内存地址(0xF28FB625)
b.0x1adb8(global_strlen1_ptr) 内容被修改成了 global_strlen1 的实际内存地址(0xD35DE004)
c.0x1adbc(global_strlen2_ptr) 内容被修改成了 global_strlen2 的实际内存地址(0xD35DE008)
2.R_ARM_ABS32 ，重定位信息记录在'.rel.dyn'段中，其offset指向了.data段中的项，在加载到内存后，会将offset的内容修改为相应符号地址
a.0x1b004(global_strlen1) 内容被修改成了 strlen 的实际内存地址(0xF28FB625)
b.0x1b008(global_strlen2) 内容被修改成了 strlen 的实际内存地址(0xF28FB625)
3.R_ARM_JUMP_SLOT ,重定位信息记录在'.rel.plt'段中，其offset指向了.got段中的项，在加载到内存后，会将offset的内容修改为相应符号地址
0x1ae5c (strlen_ptr_0) 内容被修改成了 strlen 的实际内存地址(0xF28FB625)
通过上面的图文描述，大概了解全局指针调用外部函数和局部指针调用外部函数的调用过程，这里在单独说一下直接调用外部函数的调用过程，也就是唯一一个在'rel.plt'段中的R_ARM_JUMP_SLOT类型，汇编中0x8c30和0x8c38这两个BLX，实际上会跳转到.plt段
然后在通过LDR指令将strlen_ptr_0指向的内容赋值给PC，最终实现函数调用
好了！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
明白了具体的重定位过程，检测GOT hook的核心思路也出来了，就是检测'.rel.dyn'和'.rel.plt'中的重定位项的offset指向的(实际内存)地址的内容是不是它应该在的模块
那么怎么获取'.rel.dyn'和'.rel.plt'中的重定位项内容呢？
解析加载后的ELF文件的Dynamic Segment，其中DT_JMPREL、DT_PLTRELSZ对应'.rel.plt'信息，DT_REL、DT_RELSZ对应'.rel.dyn'信息，你可能还需要DT_SYMTAB和DT_STRTAB来辅助解析符号名
那么怎么判断是不是符号应该在的区域呢？
一图便知
获取到了重定位项的实际内存地址之后，然后去/proc/self/maps里查找该地址所属的区域是否映射来至NEEDED的文件或是你自身
注意：如果你本来就有hotfix的情况，这里可能就会出现误报
最后代码就不提供了，主要也就是ELF的linking view 和 execution view 的解析
INLINE HOOK检测
在之前描述重定位的时候，要求是开启了-fPIC，位置无关代码让.text段的内容在ELF加载前后没有发生变化，那么检测inline hook的一个思路就出来了，对比内存中的.text段和文件中的.text的crc是否相等
大致流程
1.解析/proc/self/maps
2.匹配到你需要检测的so文件，获取其的加载基地址和文件路径
3.通过mmap将文件映射到内存，然后把内容传给ELF解析工具，获取其.text段的偏移和大小
4.通过偏移+加载基地址 和 偏移+mmap返回值 以及.text段大小来计算crc，并比对
那么如果没有开启位置无关怎么办呢？
目前我很少在Android上看到没有开启的PIC/PIE的ELF文件，查阅了相关资料，没有看到明确的要求，为了兼容没开启PIC/PIE的情况，这里还有一种方式来检测
扫描inline hook的跳转指令
arm 对应指令- LDR PC, [PC, #-4] 字节码 - 0xE51FF004
thumb32 对应指令- LDR.W PC, [PC, #0] 字节码 - 0x00F0DFF8
当然这个功能也可以用来定位具体被hook地址
如果还有其他的检测思路，欢迎评论私信
若有志同道合的小伙伴也欢迎私信加个微信^_^
查考链接：
1.https://source.android.com/security/enhancements/enhancements50
2.https://source.android.com/devices/tech/dalvik/configure?hl=en
3.https://www.codeproject.com/Articles/70302/Redirecting-functions-in-shared-ELF-libraries#_Toc257815978