[安卓逆向]常见调试和反调试及解决方案

写在前面

我们在逆向软件时难免会遇到一些反调试策略，这篇文章就来详细总结下，现阶段比较流行的几种反调试策略及解决方案。

特定文件检测

反调试功能： 通过检测文件方式，检测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