给大家介绍一下反调试汇总的原理及实现方式，以及各种反调试的扩展
反调试汇总：
针对于一些大型apk 反调试不一定是让你不能调试 -> 让你得到一个错误的结果
逆向某一个算法 传参 中间会根据一些数据运算 如果检测到反调试 计算错误
**调试端口检测**
监测android_server文件端口信息 默认的23946(5D8A)
更改端口 31927 -> 过掉此反调试
**2.调试器进程名检测**
监测android_server gdbserver gdb等进程
通过ps命令来监测有没有相应的进程信息 android_server as
更改android_server文件名 -> 过掉反调试
**3.父进程名检测**
app应用的进程都是由zygote fork 而来 也包括系统应用
vs远程调试 用可执行文件加载so:父进程名为gdbserver
**4.自身进程名检测**
多用于单独调用so 包括 apk来调用so 可执行文件调用so
apk来调用so -> 包名与原apk的包名一致
LoadLibrary()函数加载so文件 仅有这种情况 除非它是自定义linker加载so文件(360壳)
**线程数量检测**
比如说：我们写了一个demo apk 来调用so文件(要调试的apk比较大 环境比较复杂 调试的时候容易跑蹦)
demo apk线程数量一般 不是很多，相较于原apk
找到检测点 nop掉
**进程fd文件检测**
类似于apk线程数量检测
/proc/pid/fd/文件个数差异
检测apk是否以debug模式启动 即使进行ida调试了 程序的大部分功能依然没有运行 所以fd文件较正常偏少
找到检测点 nop掉
**7.安卓系统自带调试检测函数**
(); 当程序被调试时 返回值为 true
根据全局变量 DebuggerActive来判断
特征： 在java层 搜索 isDebuggerConnected 函数名
动态调试时在 中 _ZN3art3Dbg15gDebuggerActiveE函数下断 让其函数值为 0 或者直接在内存窗口
修改全局变量
**检测**
IDA gdb 都要附加
一个app只能被附加一次
在自己app中开一个线程 然后附加本应用 如果附加失败 证明应用被调试
先于别的附加 自己附加自己 那么本应用就不能被附加 从而避免被调试
可以在ptrace函数做手脚 hook函数 ida动态调试时打断点做处理 或者直接干掉反调试
以debug模式启动
分界线 理论上以上调试都是直接跑蹦 一下有特殊情况
**9.函数hash值检测**
为什么ida中打了断点 程序会断在此位置？ 软件断点 不唯一 int 3 调试异常 bkpt断点指令
根据这个原理 来检测一段指令的hash值时候发生变化 变化了就说明存在软件断点
没有创建线程 扫了一下 -> 会在调试点直接崩溃
创建线程 循环比较函数hash值是否相等 若不等 则kill
可以从 创建线程api出发 同时，此调试点肯定在指令被检测之前运行 之后是不可能的
可以试试 ctrl +f7 即 回溯
**10.断点指令检测**
和上面其实并没有本质区别
**11.系统源码修改检测**
tracePid检测 _ZN3art3Dbg15gDebuggerActiveE函数
查看 /proc/pid/status 目录下的 tracePid 是否为0 若为0 则未被调试 若不为0 则被调试
解决办法：可以修改系统源码实现 tracePid 恒为0 不论是否被调试
动态调试的反调试检测点
程序直接挂掉 直接可以nop掉或者fopen函数下断 打开/proc/pid/status目录时 修改内存中 tracePid的值
可以自己附加自己 查看tracePid是否为0 若为0 则修改了系统源码 kill进程 若不为0 则为修改
**12.单步调试陷阱**
可以模拟IDA打下断点，即修改相应指令的二进制 将其改为bkpt指令 需要修改内存也属性 mprotect()
自己注册断点处理函数 做什么事？
把断点处指令 恢复成正常的指令 等一些列工作
如果IDA动态调试走到此断点处 IDA会正常的处理此断定指令 但是我们的信号处理函数已经将此指令处理完毕
IDA做了重复性的工作 -> 程序崩溃
崩溃特点：立即崩溃 程序一般不会被kill 会指令走不动 f8 f9 一直弹信号
借助于IDA调试缺陷来设置的反调试
反调试设置的地方可能不在这个指令崩溃的附近 反调试点不太好找
内联汇编 __asm__{}; 有可能在内联汇编中做此反调试 反调试设置的地方在其周围
**13.基于信号的检测**
signal() raise() 发送信号
利用IDA先截获信号特性的检测
IDA总是先于我们的应用程序截获信号
signal(SIGTRAP, myhandler); SIGTRAP：调试信号 myhandler：信号处理函数(自己实现的)
信号处理函数 可以设置一个全局变量
终止进程方式可以kill进程 或者 sleep()
先给程序设置signal 并实现信号处理函数
在关键函数里或者开一个线程 隔时 发送信号 即 raise()
若信号未收到 则程序被调试
信号 消息机制 被捕获就会消失 一次性
**14.利用IDA解析缺陷反调试**
BLX BX 跳转指令 可切换指令集
X带指令切换 L带链接
IDA解析 是Thumb指令还是Arm指令时可能出错 递归下降算法来反汇编指令
这种情况多发生于静态分析 动态调试指令执行基本不会出现
__asm __volatile{"","memory"} asm 前缀 从这里开始指令为汇编指令
volatile 会面的汇编指令不要给我优化 按我的执行
让IDA 指令识别错误 即Arm Thumb指令 错误识别类型 -> 导致程序无法正常运行
nop掉
**15.时间反调试**
gettimeofday() time() 常用
通过获取两个时间 来计算出时间间隔 从而确定时候被反调试
如果我们进行调试时 不f8单步 或者不停留 那么这种反调试是无用的
关键算法 或者程序比较靠前的地方
在gettimeofday函数下断 最近的两次调用 将其返回值改成一样的
直接找到反调试设置的地方 然后给nop
time()函数 time_t结构体 clock()函数 clock_t结构体 gettimeofday()函数
timeval结构 timezone结构 clock_gettime()函数 timespec结构 getrusage()函数 rusage结构
**16. Inotify事件监控dump**
防dump文件
Inotify系列api来监控mem或pagemap的打开或访问事件 自己设置要监测的文件
当然，除此之外 还有别的反调试 比较多的就是这个环境问题
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137