写在前面
我们在逆向软件时难免会遇到一些反调试策略，这篇文章就来详细总结下，现阶段比较流行的几种反调试策略及解决方案。
特定文件检测
反调试功能： 通过检测文件方式，检测android_server文件是否存在设备中的指定目录/data/local/tmp/下，如果存在，将结束程序，达到反调试的目的。
解决方案： 使用mv android_server as修改特定文件的文件名即可防止特定文件名检测。
特定端口检测
反调试功能： 通过检测端口方式，检测android_server默认端口是否正在开启；通过adb shell ➔ su ➔ cat /proc/net/tcp来检查结果是否包含对应的16进制，IDA默认端口23946转换成16进制就是5D8A。
解决方案： 修改特定端口即可防止特定端口检测。android_server本身支持自定义端口号的，命令很简单：./android_server -p12345 直接加上-p参数即可，注意端口号和参数之间没空格；
ptrace占用附加
反调试功能： IDA调试，动态调试必须要附加的，这里提前进行占用，代码ptrace(PTRACE_TRACEME, 0, 0, 0);其中PTRACE_TRACEME代表：本进程被其父进程所跟踪。其父进程应该希望跟踪子进程，一般一个进程只能被附加一次。后面再附加调试就会失败，达到反调试的目的。
解决方案： 直接逆向分析so，一般是到JNI_OnLoad中就可查看到相关代码NOP掉即可！
TracePid检测
反调试功能： 在应用的so层加个循环检查自己status中的TracerPid字段值，应用正在调试时此值是非0的，那么就认为被附加调试了。
adb shell ➔ su ➔ ps | grep 软件的包名 ➔ cat /proc/进程ID/status | grep TracerPid
解决方案： 分析so层相关检测判断NOP掉 或 一劳永逸：修改内核信息 即可！
调试状态检查
检查应用是否属于debug模式
直接调用Android中的flag属性：ApplicationInfo.FLAG_DEBUGGABLE，判断是否属于debug模式，这个其实就是为防止现在破解者为了调试应用将应用反编译在AndroidManifest.xml中添加：android:debuggable属性值，将其设置true。然后就可以进行调试。
添加这个属性之后，我们可以用 dumpsys package [packagename]命令查看debug状态，所以我们可以检查应用的AppliationInfo的flag字段是否为debuggable即可！
解决方案： 修改 AndroidManifest.xml 文件，将 android:debuggable 属性设置为 false，也可通过将/default.prop中的Android系统属性ro.debuggable修改为1即可使得设备所有应用可以被调试。使用动态调试中方法二提到的magisk环境及模块，直接修改手机为可调试状态即可！
检查应用是否处于调试状态
这个也是借助系统的一个api来进行判断：android.os.Debug.isDebuggerConnected();这个就是判断当前应用有没有被调试，我们加上这段代码之后进行jdb连接操作：jdb -connect com.sun.jdi.SocketAttach:hostname=127.0.0.1,port=8700，当连接成功后，这个方法就会返回true，那么我们可以利用这个api来进行判断当前应用是否处于调试状态来进行反调试操作。
解决方案： 逆向相关程序，直接搜索关键词并定位，去除相关检测代码并重打包即可！注意软件一般有签名校验。
签名校验
反调试功能： 准备来说不算是反调试方案，但是也是一种安全防护策略，签名校验一般现在有很多用途，用意在于防止二次打包。
解决方案： 逆向相关程序，直接搜signatures关键词并定位，去除相关检测代码并重打包，也有一键去除工具(NP、MT)即可！
模拟器检测
反调试功能： 检测应用是不是运行在一台模拟器中，如果是，将结束程序，达到反调试的目的。
public static boolean isEmulator() {
try {
Class systemPropertyClazz = Class.forName("android.os.SystemProperties");
boolean kernelQemu = getProperty(systemPropertyClazz, "ro.kernel.qemu").length() > 0;
boolean hardwareGoldfish = getProperty(systemPropertyClazz, "ro.hardware").equals("goldfish");
boolean modelSdk = getProperty(systemPropertyClazz, "ro.product.model").equals("sdk");
if (kernelQemu || hardwareGoldfish || modelSdk) return true;
} catch (Exception e) {
// error assumes emulator
}
return false;
}
private static String getProperty(Class clazz, String propertyName) throws Exception {
return (String) clazz.getMethod("get", new Class[] {String.class}).invoke(clazz, new Object[] {propertyName});
}
解决方案： 修改调试器以消除特征性代码或数据，或使用其他不易被检测到的调试器。
代码执行时间差检测
反调试功能： 动态调试时关键代码的前后时间差比正常执行时要大许多，因此可以计算两段代码执行所用的时间，如果超出一般正常情况下设定的值就认为代码被调试，将结束程序，达到反调试的目的。五个能获取时间的api：
time()函数、time_t结构体
clock()函数、clock_t结构体
gettimeofday()函数、timeval结构、timezone结构
clock_gettime()函数、timespec结构
getrusage()函数、rusage结构
int gettimeofday(struct timeval *tv, struct timezone *tz);
void check_time()
{
int pid = getpid();
struct timeval t1;
struct timeval t2;
struct timezone tz;
gettimeofday(&t1, &tz);
gettimeofday(&t2, &tz);
int timeoff = (t2.tv_sec) - (t1.tv_sec);
if (timeoff > 1) {
int ret = kill(pid, SIGKILL);
return ;
}
}
解决方案： 尽量减少调试器的干扰，或使用模拟器等环境加速执行。
写在后面
这些反调试都是通常比较常见的，只有我们了解了反调试的方式，才能对应的过掉反调试。
特定文件检测、调试端口检测、进程名称检测、定时轮询检测、self-debugging反调试，JDWP协议反调试。
特定文件检测：对特定目录下的特定文件名称进行检测,如：android_server等，如果存在，将结束程序。
调试端口检测：对正在运行的特定端口进行检测，如：23946等，如果存在，将结束程序。
进程名称检测：对正在运行的特定进程名称进行检测，如：android_server等，如果存在，将结束程序。
定时轮询检测：启动一个循环，定时对TracerPid的值等其他特点进行检测，如果发生被调试的特征的变化，将结束进程。
self-debugging反调试：利用一个进程只能被调试一次的特点，创建一个子进程用来对自身进行调试，让其他调试程序无法调试。
JDWP协议反调试：通过一个isDebuggerConnected方法，用于判断JDWP调试器是否正在工作，如果存在，将结束程序。
参考文章：
Android安全防护之旅—应用"反调试"操作的几种方案解析：https://developer.aliyun.com/article/179707
android逆向之-反调试：https://blog.csdn.net/u013346208/article/details/122929650
安卓逆向-反调试与绕过反调试的几种姿势：https://forum.butian.net/share/776
Android逆向之反调试：http://pwn4.fun/2017/04/15/Android%E9%80%86%E5%90%91%E4%B9%8B%E5%8F%8D%E8%B0%83%E8%AF%95/
[原创]对安卓反调试和校验检测的一些实践与结论：https://bbs.kanxue.com/thread-268155.htm
移动安全面试题—调试&反调试：https://juejin.cn/post/7265926762731192379
