给大家介绍一下反调试汇总的原理及实现方式，以及各种反调试的扩展
反调试汇总：
针对于一些大型apk 反调试不一定是让你不能调试 -> 让你得到一个错误的结果
逆向某一个算法 传参 中间会根据一些数据运算 如果检测到反调试 计算错误
1.IDA调试端口检测
监测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壳)
5.apk线程数量检测
比如说：我们写了一个demo apk 来调用so文件(要调试的apk比较大 环境比较复杂 调试的时候容易跑蹦)
demo apk线程数量一般 不是很多，相较于原apk
找到检测点 nop掉
6.apk进程fd文件检测
类似于apk线程数量检测
/proc/pid/fd/文件个数差异
检测apk是否以debug模式启动 即使进行ida调试了 程序的大部分功能依然没有运行 所以fd文件较正常偏少
找到检测点 nop掉
7.安卓系统自带调试检测函数
android.os.Debug.isDebuggerConnected(); 当程序被调试时 返回值为 true
根据全局变量 DebuggerActive来判断
特征： 在java层 搜索 isDebuggerConnected 函数名
动态调试时在libart.so 中 _ZN3art3Dbg15gDebuggerActiveE函数下断 让其函数值为 0 或者直接在内存窗口
修改全局变量
8.ptrace检测
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的打开或访问事件 自己设置要监测的文件
当然，除此之外 还有别的反调试 比较多的就是这个环境问题