前言
为了更好的使用Frida工具，需要研究此工具的实现原理。故准备此篇文章，现目前很多安全厂商对Frida工具没有进行防御检测，所以此处提出如果安全厂商对Frida工具进行检测，那么我们应该如何去bypass这个检测。
正文
1.针对与Frida的检测，现目前其实也就是几种常见的基于特征的检测。比如检查frida开启的端口、被注入进程中是否存在frida-agent-32.so模块、检测进程是否有frida-server、探测端口通信D-bus协议。以上是针对与frida的主流检测技巧，其实frida工具也是基于ptrace，但是和ida有点不同，frida使用ptrace attach到进程之后，往进程中注入一个frida-agent-32.so模块，此模块是frida和frida-server通信的重要模块，所以frida不会一直占用ptrace，注入模块完成后便detach。我们也知道，现目前主流的安全加固都会防止程序被attach，基本策略是fork一个子进程然后attach到父进程上去，然后起到了其他程序attach不了这样的效果。这里仅仅讨论实现方案，其实这里的bypass方案还是很多的。在这里可以思考正常程序启动完成之后，frida就无法往程序上附加了，那么这里如何bypass反附加的程序呢？其实这里就可以参见常见的app调试，spwan这种操作，即为在程序启动的时候断下，然后attach。frida其实提供了这样的一个功能
frida -U -f com.app -l script.js --no-pause
正如上面的命令，其中-f 即spwan，在程序最先启动的时候注入。--no-pause是不暂停。这里就可以绕过正常程序反附加的保护措施，但是如果程序中还存在基于frida特征检测的代码，那么我们就需要根据其检测点，来bypass检测。
2.frida注入进程的同时会让进程load一个frida-agent-32.so，退出注入的时候会把此so模块unload。
laod.png
unload.png
这里可以看到退出的时候frida把so模块unload了，其实在使用过程中，可以知道frida使用ptrace的时机仅仅只有几秒钟，流程是attach、inject so、detach。注入之后，如果我们想再开一个frida注入，可以发现这里注入的时候不会调用ptrace了，因为模块中以及注入了so了。
这里思考的问题是通过修改系统源码或者更早时机的注入，是app启动主动注入so。那么我们就不需要调用ptrace来注入，就可以直接和app进程通信。
网友评论