前言
一、编译环境搭建
1 物料准备
- 设备：pixel2（walleye）
- 源码：aosp源码
- build id：RP1A.200720.009
- tag：android-11.0.0_r1
- sdk version：Android11
- 驱动源码准备：驱动源码
2 工具准备
- 编译支撑系统：centos7，使用公司的云容器（16核32G、600G磁盘）
- 三方库准备
Unidbg特征检测汇总
Unidbg对抗点
- 不支持信号机制
- 内存布局检测
- Unidbg通过Java实现JNI的逻辑，导致JNI函数地址控制在0xfffe0000L - 0xffff0000L范围内，检测JNI函数地址是否处于该范围或者相邻两个函数的地址差值
- 类检测：Unidbg通常会对不存在的类也会正常返回
- 函数检测：对比methodid是否是hashcode
- 文件描述符：Unidbg的文件描述符通常是3-6
- uname判断
- hook框架检测（xhook、dobby）
- 依赖库对抗：Unidbg只实现了十余个常用so库
- 字节对齐？
- getenv
- 增加目标函数前置执行条件
Frida特征检测汇总
端口检测：frida默认暴露端口为27047通信方式检测：frida使用App低频使用的D-Bus通信协议来进行通信，可以遍历端口对它们发送D-Bus AUTH消息来判断是否存在REJECT的情况内存检测- so列表检测
- maps文件内容遍历检测
- 通过linker获取so list遍历检测
- 可执行段字符检测：遍历maps文件中带有可执行属性的segment，检测是否包含libfrida/frida:rpc等字符特征
- so列表检测
线程检测：遍历proc/self/task的文件内容，查找字符特征命名通道检测：遍历proc/self/fd，反查fd判断是否包含linjector字符特征section crc检验：对比内存中的so 各个section与本地的section的crc值对比segment属性检测：针对inline hook，由于frida是基于inline hook的，因此会改动libart，进而暴露在maps中会有rwxp属性的地址段inline hook跳转检测：frida inline hook和其他inline hook的原理相同，在函数的头几个字节通常是ldr、br这类的指令目录检测：针对/data/local/tmp下面的re.frida.server代码漏洞- elf头字节魔改：frida gum_try_parse_linker_proc_maps_line函数中在获取linker时会判断elf头字节是否匹配，可以选择修改elf头字节
- libc属性修改：使用目标libc的mmap将自身的相关so注册到目标maps表中;再执行目标libc的dlopen和dlsym函数将自身so中的函数进行执行，做法是主动mmap只读的libc从而让frida启动崩溃
检测线程保护匿名内存检测
额外需要注意的是
Frida源码编译说明
一、编译环境搭建
这次编译的目标版本是14.2.18
1 物料准备
- 设备：红米note11（MIUI12 Android11）
- frida源码：https://github.com/frida/frida
2 工具准备
参照官方编译指南
Frida特征对抗案例2
一、资源准备
- com.jingdong.app.mall 12.1.0
- pixel2 android10.0
- frida 14.2.2
二、分析思路
使用frida以spawn模式启动，可以发现进程直接崩溃，说明存在反调试
Frida特征对抗案例1
