frida检测和过检测的分析

 

定位检测位置

通过so加载流程，那么就会知道linker会先对so进行加载与链接，然后调用so的.init_proc函数，接着调用.init_array中的函数，最后才是JNI_OnLoad函数，所以我需要先确定检测点大概在哪个函数中。

通过frida执行下面的脚本，定位是在哪个时机上检测frida的。

hook_open函数可以定位是具体那个so检测frida

 

过检测方案

主要思路就是通过修改替换frida中各种被检测的敏感字符信息、模块信息、注入行为。实现让检测的so文件无法比较到特征码信息，从而绕过检测。

 

基础检测

检测frida-server的文件名称：可以通过修改文件名称绕过检测；

检测frida的端口名27042:通过将端口名称改成其他端口绕过检测；

双进程保护：可以通过用spawn方式启动，绕过双进程保护。

 

检测D-Bus

检测它的原因是因为安卓系统中，D-Bus通信并不常见，而且不同于在传统Linux系统中广泛使用，安卓系统使用Binder机制来实现进程间通信（IPC），而不是使用D-Bus。

D-Bus是一种进程间通信(IPC)和远程过程调用(RPC)机制,最初是为Linux开发的,目的是用一个统一的协议替代现有的和竞争的IPC解决方案。

绕过检测D-Bus，可以通过hook系统库函数，比如strstr、strcmp等等

加载文件检测

检测/proc/pid/maps依赖文件maps文件中存储的是APP运行时加载的依赖

当启动frida后，在maps文件中就会存在 frida-agent-64.so、frida-agent-32.so 文件。

绕过检测方案

 

线程和打开文件检测

检测/proc/pid/tast下线程、fd目录下打开文件;

在 /proc/pid/task 目录下，可以通过查看不同的线程子目录，来获取进程中每个线程的运行时信息。这些信息包括线程的状态、线程的寄存器内容、线程占用的CPU时间、线程的堆栈信息等。通过这些信息，可以实时观察和监控进程中每个线程的运行状态，帮助进行调试、性能优化和问题排查等工作。

/proc/pid/fd 目录的作用在于提供了一种方便的方式来查看进程的文件描述符信息，这对于调试和监控进程非常有用。通过查看文件描述符信息，可以了解进程打开了哪些文件、网络连接等，帮助开发者和系统管理员进行问题排查和分析工作。

打开frida调试后这个task目录下会多出几个线程，检测点在查看这些多出来的线程是否和frida调试相关。

在某些app中就会去读取 /proc/stask/线程ID/status 文件，如果是运行frida产生的，则进行反调试。例如：gmain/gdbus/gum-js-loop/pool-frida等

gmain：Frida 使用 Glib 库，其中的主事件循环被称为 GMainLoop。在 Frida 中，gmain 表示 GMainLoop 的线程。

gdbus：GDBus 是 Glib 提供的一个用于 D-Bus 通信的库。在 Frida 中，gdbus 表示 GDBus 相关的线程。

gum-js-loop：Gum 是 Frida 的运行时引擎，用于执行注入的 JavaScript 代码。gum-js-loop 表示 Gum 引擎执行 JavaScript 代码的线程。

pool-frida：Frida 中的某些功能可能会使用线程池来处理任务，pool-frida 表示 Frida 中的线程池。

linjector 是一种用于 Android 设备的开源工具，它允许用户在运行时向 Android 应用程序注入动态链接库（DLL）文件。通过注入 DLL 文件，用户可以修改应用程序的行为、调试应用程序、监视函数调用等，这在逆向工程、安全研究和动态分析中是非常有用的。

绕过检测方案

 

其他检测

当frida-server启动时，在 /data/local/tmp/目录下会生成一个文件夹并且会生成一下带有frida的特征。

绕过检测方案：重新编译去特征方式，hook方式。

直接调用openat的syscall的检测在text节表中搜索frida-gadget.so / frida-agent.so字符串，避免了hook libc来anti-anti的方法。

注入方式改为

1、frida-inject

2、ptrace注入 配置文件的形式注入

3、编译rom注入

 

结束

原文来源：

https://bbs.kanxue.com/thread-278145.htm

原文始发于微信公众号（编码安全）：frida检测和过检测的分析