对Inline Hook，Got Hook和SVC Hook一些检测的浅谈
本帖最后由 LivedForward 于 2022-11-27 17:05 编辑说到Inline Hook、Got Hook，大家并不陌生，在Native层都可以改变函数的执行返回值或修改传入参数的值。
在网上github现有比较成熟的Hook框架中，Got Hook的代表：XHook，Inline Hook：SandHook。
Got Hook就是在运行时修改got表的函数入口地址，这种Hook方案针对同一个进程的so文件
都需要修改它们的got表；Inline Hook就是在函数的前几个指令插入跳转指令，
使目标函数跳转到我们的函数执行逻辑里面来。
列举两张图，示例为Got Hook和Inline Hook的流程原理：
怎么去做检测呢？看到网上检测方案，真的感觉就像过家家一样，小打小闹。
比如检测有没有指定类，xposed：de.robv.android.xposed.XposedHelpers。
比如腾讯很久以前的乐固就主动抛出Java异常，然后检测Stack异常信息里面有没有xposed类的字符串。
或者是检测Package Name，或者是检测App Name，检测有没有libxxx.so文件，
再就是检测命名空间是否为XXXXX，比如SandHook的namespace就是SandHook。
其实我想问一句，这些检测方法就是掩耳盗铃，自欺欺人。把这些Hook框架稍微改动一下再重新打包，
这些方法就瞬间失效，更可笑的是网上都是这种检测方法，真的是让人贻笑大方。
在这里，我想提出几种检测思路：
[*]检测物理磁盘上的so文件与内存里的so文件的映射关系，比如.data、.text等等。
[*]检测指定的函数的前几个指令是否为跳转指令，比如arm64的跳转指令是0x058000050。
[*]检测系统lib库的so文件的指定函数地址与本进程so的导入函数地址是否相等。比如libc库的open函数。
这种方式需要先计算好got起始地址，导入表函数位置。
最后，针对SVC Hook的：SVC Hook有ptrace、seccomp、内存扫描svc指令。
内存扫描指令这种肯定不会存在，因为这种效率太低了，需要起一个线程监控，
而且稳定性也差。目前就seccomp的bpf最常用，这种就是设定filter过滤器规则，
拦截到指定的系统调用号后会产生一个信号量，这种信号量是你设定的，
然后就会执行事先使用sigaction注册的函数。
我们可以这样检测：注册一个sigaction处理逻辑，然后主动使用 sigqueue函数发送信号量，再接收，
如果没有接收到说明被seccomp的bpf规则拦截了，SVC已经被Hook了。
参考上篇帖子：一种可以规避大部分去签名校验的方法https://www.52pojie.cn/thread-1717714-1-1.html
* 大厂一般模块比较多，有需要静态链接的也有动态的，编译完自测都能检测出got或者inlinehook，是很正常的，因为其他团队的安全模块或者业务模块都可能有。具体去判断goto的地址就很复杂了，有可能并不可行。
* 爆搜内存这思路，在成熟的产品上上级直接就给你拒了，性能太差，设计不合理。爆搜svc了，爆搜inline特征都不可行，何况inline特征也不是一种，最多可以做到流行的hook框架检测。当然如果你只是自己开发小软件就没问题了
* 破解远比做安全加固容易，因为破解者在暗处，不同的人有不同的破解方法，破解者可无限次尝试
* 核心防护模块的核心代码，有些是黑科技，是从系统源码内核源码找到的思路。
* 各种保护技术的兼容问题，这点是最难的，因为开发要面对各种不同环境的手机，不同环境结果可能都不同。破解的话，只需要找一台能root的就可以了，难度低一个数量级
你想的这些，腾讯里那些挖系统漏洞的能想不到吗，人家可能二三十年前就玩过了。只不过为了稳定性和兼容性不上罢了
说的很好{:1_921:} 在mt也看到你的帖了{:301_998:} 感谢分享，值得参考
没有详细的教程吗？
小白来学习 感谢分享！！！ 感谢分享！！ 教程很棒！感谢分享
页:
[1]
2