使用 stackplz 辅助分析 anti-frida(亲测可行)

使用 stackplz 过anti-frida

一般检测frida 比较常用的一个函数是 strstr. 这个函数类似于 isSubString. 判断子串

我们使用 stackplz hook strstr 看看是谁在调用strstr

./stackplz -n tv.danmaku.bili -l /apex/com.android.runtime/lib64/bionic/libc.so -w strstr --stack

执行结果如下

看看strstr的参数, 到底是不是针对一些环境的检测

/stackplz -n tv.danmaku.bili -l /apex/com.android.runtime/lib64/bionic/libc.so -w strstr[str:x0,str:x1]  -o tmp.log

结果如下

google 一搜

大概率就是 libmxxxoxxdsec.so 在检测frida

从hook strstr的调用堆栈里我们可以看到是从 thread_start 开始的。 所以我们hook thread_create 看看, 创建线程比较早，所以先关掉app, 执行命令后再打开app

./stackplz -n tv.danmaku.bili -l /apex/com.android.runtime/lib64/bionic/libc.so -w pthread_create --stack -o tmp.log

可以看到结果, 有13处

ida打开 看看 0x1d304

F5 看看

这里很像是在创建线程。 我们试试patch, 强行让它不创建。 把 BLR X19 指令改为 nop. 在此之前还有一个问题， patch后会不会崩溃？
arm64 函数调用约定 返回值给x0, 我们看看后续有没有用到x0. 如果没用到我们可以这么改, 用到了程序可能就会崩溃

看汇编

发现并没有用到返回值。 所以我们打开 https://armconverter.com/

看看nop 对应的机器码

用 010editor 把 BL X19 对应的机器码全部改为 1F2003D5

我一共patch了三处. 然后把patch后的 so文件 push 到 /data/app/~~1m1hzMqd9svUirtnyTGHvA==/tv.xxxxx.xxxx-rMRttoSdjUufKzwDHC3FtQ==/lib/arm64/

然后frida 打开还是崩溃. 发现app 又用了其他另外一个地方的 sec.so文件. 把 so文件复制到两个目录下以后。发现frida 可以成功附加. 最好改一下so文件的权限为 755. 跟原先一致