过检测一般可以从退出方式入手。检测到环境异常会想办法退出程序，大致分成 libc 函数方案和 svc 退出方案。

libc: exit, kill, _exit 等，可以直接调用 FCAnd.anti.anti_debug(); 过掉（有漏的函数可以补充）。

svc: syscall 相关。

libc 层面frida  可以直接 hook 相关函数然后打印堆栈就可以定位到检测点。

svc 用frida 无法直接 hook ，可以采用下面的通用过检测思路。

文中主要脚本引用自： https://github.com/deathmemory/FridaContainer

网上也有人分享过用 frida stalker 检测svc 的方式，也是办法之一，但 stalker 稳定性一直是个问题，所以这里采用了： ida python + frida 的方式。

主要就是将分析 so  调用 svc 的位置用 ida python 部分来实现。直接上 idapython 代码

可以在 python/android/idaSearchSvc.py加载到 ida 执行，此时会输出该so 的 svc 所有的调用地址，如：

将上面输出的 svc_address_list全部hook 掉，或直接调用 FCAnd 的封装代码：

然后用 frida spawn的方式启动目标进程就会打印出所有调用 svc 的堆栈信息。为了及时hook 可以选择在目标 so 加载之后开始 hook 

得到堆栈信息如下：

大概翻一下，出现频率比较多的基本就是。0x51b10 -- 0x51580

接下来就是 ida 定位到相关地址，看看检测逻辑就可以判断和绕过了。

比如这里检测函数是 sub_515C4，那进去看一下这个函数都检测了什么，详细就不展开了，只说一下结论，这个函数主要检测了：

/proc/self/task/%s/status 的线程名

/proc/self/fd/%s  的 readlink 判断特征名

/proc/self/maps 的 frida 特征名

没什么新鲜的检测点，但奇怪的是明明我的frida 做过去特征，按理说这些点应该都过掉了才对，结果还是被检测然后程序退出了，又回过头反复确认了就是这个检测点无疑，那到底是 sub_515C4的哪个检测逻辑触发的检测呢？

既然确定了就是 sub_515C4检测的，而且检测点就这么几个文件，那到底是哪里出了问题，先用 frida hook snprint 函数过滤它的路径拼接，发现影响检测的就是 /proc/self/task/%s/status。针对它的检测也就以下三个特征逻辑：

gum-js-loop

gmain

pool-frida

前两个确定在编译去特征frida 的时候都是替换过的，可疑的只有 pool-frida，但是我在frida 源码里和生成的文件里没有直接搜到这个关键字符串，不信邪，为了确定到底是不是它，我们进一步用 frida 的 stalker 来验证一下。

在 sub_515C4onEnter 的时候开始 follow ，退出时unfollow 减少不必要的性能损耗和异常。

打印的结果如下：

结合 IDA 分析的关键分支地址去看，前面我们已经怀疑 pool-frida 的判断逻辑了，这里trace 出来以后，只需要搜索一下 pool-frida 判断逻辑的相关地址有没有被打印出来就定位到了，不用一行行去看trace 。

至此得到了该函数的执行路径，定位到关键点：0x51afc

确定它走的就是 status 相关的检测逻辑。

第二个关键点：0x51D34

说明它确实是检测的 pool-frida这下是确定就是这个检测逻辑了，但之前搜索源码和生成bin 文件都没有这个关键词，剩下的可能就是这个字符串可能是拼接出来的。

最终定位到是 pool-%s也就是拼接后的pool-frida。

顺便说一下这个pool-frida线程，是在进程启动时才会有的临时线程，frida 环境 ready后这个线程会退出。

知道问题就好办了，在我们给frida 过检测的脚本里把这个字符串替换掉就可以了。

又可以愉快的 hook 了 : )

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！