Anti-debugging Skills in APK

0x00 时间相关反调试


通过计算某部分代码的执行时间差来判断是否被调试,在Linux内核下可以通过time、gettimeofday,或者直接通过sys call来获取当前时间。另外,还可以通过自定义SIGALRM信号来判断程序运行是否超时。

0x01 检测关键文件


(1)/proc/pid/status、/proc/pid/task/pid/status

在调试状态下,Linux内核会向某些文件写入一些进程状态的信息,比如向/proc/pid/status或/proc/pid/task/pid/status文件的TracerPid字段写入调试进程的pid,在该文件的statue字段中写入t(tracing stop):

pic1

(2)/proc/pid/stat、/proc/pid/task/pid/stat

调试状态下/proc/pid/stat、/proc/pid/task/pid/stat文件中第二个字段是t(T):

pic2

(3)/proc/pid/wchan、/proc/pid/task/pid/wchan

若进程被调试,也会往/proc/pid/wchan、/proc/pid/task/pid/wchan文件中写入ptrace_stop。

0x02 检测端口号


使用IDA动态调试APK时,android_server默认监听23946端口,所以通过检测端口号可以起到一定的反调试作用。具体而言,可以通过检测/proc/net/tcp文件,或者直接system执行命令netstat -apn等。

0x03 检测android_server、gdb、gdbserver


在对APK进行动态调试时,可能会打开android_server、gdb、gdbserver等调试相关进程,一般情况下,这几个打开的进程名和文件名相同,所以可以通过运行状态下的进程名来检测这些调试相关进程。具体而言,可以通过打开/proc/pid/cmdline、/proc/pid/statue等文件来获取进程名。当然,这种检测方法非常容易绕过――直接修改android_server、gdb、gdbserver的名字即可。

0x04 signal


信号机制在apk调试攻防中有着非常重要的作用,大部分主流加固厂商都会通过信号机制来增加壳的强度。在反调试中最常见的要数SIGTRAP信号了,SIGTRAP原本是调试器设置断点时发出的信号,为了能更好的理解SIGTRAP信号反调试,先让我们看看一下调试器设置断点的原理:

和x86架构类似,arm架构下调试器设置断点先要完成两件事:

  1. 保存目标地址上的数据
  2. 将目标地址上头几个字节替换成arm/thumb下的breakpoint指令

Arm架构下各类指令集breakpoint机器码如下:
[crayon-5a318c736fdf3109167448/]
在目标地址上用原来的指令替换之前的breakpoint指令调试器设置完断点之后程序继续运行,直至命中断点,触发breakpoint,这时程序向操作系统发送SIGTRAP信号。调试器收到SIGTRAP信号后,会继续完成以下几件事:

  1. 回退被跟踪进程的当前pc值

当控制权回到原进程时,pc就恰好指向了断点所在位置,这就是调试器设置断点的基本原理。在知道上述原理之后,再让我们继续分析SIGTRAP反调试的细节,如果我们在程序中间插入一条breakpoint指令,而不做其他处理的话,操作系统会用原来的指令替换breakpoint指令,然而这个breakpoint是我们自定义插入的,该地址上并不存在原指令,所以操作系统就跳过这个步骤,进入下一步回退pc值,即breakpoint的前一条指令。这时就出现问题了,下一条指令还是breakpoint指令,这也就造成了无限循环。

为了能继续正常执行,就需要模拟调试器的操作――替换breakpoint指令,而完成这个步骤的最佳时机就是在自定义signal的handle中。Talk is cheap,show me the code,下面给出此原理的简单实例:

[crayon-5a318c736fdfe661358094/]
 

在代码中主动触发breakpoint指令,然后在自定义SIGTRAP handle中将breakpoint替换成nop指令,于是程序可以正常执行完毕。

其中可使用r_debug-r_brk来触发异常,其原理即是用到了linker中一些调试特性。Linker中有一个和调试相关的结构体r_debug,其定义如下:

[crayon-5a318c736fe03938512389/]
 

r_debug是以静态变量的形式存在于linker中,其初始化代码如下:

[crayon-5a318c736fe06341559124/]
 

在初始化时,r_debug中的r_brk函数指针被初始化成了rtld_db_dlactivity函数,该函数只是一个空的桩函数:

[crayon-5a318c736fe08820212944/]
 

没调试下,该函数即为空函数,而在调试状态下会将该函数的内容改写为相应指令集的breakpoint指令。所以先注册自己的signal函数处理breakpoint异常(SIGTRAP),然后在运行时调用该函数,即可触发自定义SIGTRAP的接管函数。而动态调试时,SIGTRAP会先被调试器接收,这样不仅能迷惑调试器,还能在自定义接管函数中做一些tricky的事。

0x05 检测软件断点


上一节说了使用SIGTRAP反调试的原理,由此可以衍生出另一种很常见的反调试方法――检测软件断点。软件断点通过改写目标地址的头几字节为breakpoint指令,只需要遍历so中可执行segment,查找是否出现breakpoint指令即可。实现大致如下:

[crayon-5a318c736fe0e945529911/]
 

大家在使用IDA调试的时候,也许会注意到IDA的代码窗口和hex view窗口在设置断点的时候,目标地址的内容并没有发生改变,其实这是IDA故意将其隐藏了,设置完断点之后直接用dd dump内存就能看见设置断点的地址头几字节发生了改变。

0x06 进程间通信


大部分加固会新建进程或者新建线程,在这些新建的线程和进程中完成反调试操作,然而如果这些进程、线程相对独立的话,很容易通过挂起、杀死的方式直接使得反调试失效。为了保证反调试线程、进程的存活,就需要一种通信方式,定期确认反调试线程、进程依然存活,所以进程间通信是高级反调试不可或缺的方式。在Linux下有很多进程间通信的方式,比如管道、信号、共享内存、套接字(socket)等,下面提供一个通过管道将反调试进程和主进程联系起来的简单例子:

[crayon-5a318c736fe14428761971/]
 

传统检测TracerPid的方法是直接在子进程中循环检测,一旦发现则主动杀死进程。本实例将循环检测TracerPid和进程间通信结合,一旦反调试子进程被挂起或被杀死,父进程也会马上终止,原理大致如下图:

pic3

父进程的守护线程在从pipe中read到statue值之前,默认statue值为-1,收到子进程往pipe中写的statue值之后,重置statue值,如果未被调试,statue值为0,反之则为被调试状态。该做法的优势在于,一旦反调试进程被终止或被挂起,守护线程也能马上发现。

当然,如果通过hook或者修改kernel同样可以轻易的绕过这种反调试。这种做法只是为了演示而写的简单例子,真实的进程间通信反调试可以写的复杂的多,大家可以尽情发挥想象。

0x07 dalvik 虚拟机内部相关字段


在dalvik虚拟机中自带了检测调试器的代码,其本质是检测DvmGlobals结构体中的相关字段:

[crayon-5a318c736fe19644268874/]
 

检测调试器的函数:

[crayon-5a318c736fe1c202606555/]
 

本质是检测该dalvik虚拟机中DvmGlobals结构体中的调试器状态字段:

[crayon-5a318c736fe1e295522574/]
 

知道原理之后可以更进一步,不通过这些Dalvik虚拟机的自定义函数,而是直接获取这些字段值,这样可以更好的隐藏反调试信息。

0x08 IDA arm、thumb指令识别缺陷


众所周知,IDA采用递归下降算法来反汇编指令,而该算法最大的缺点在于它无法处理间接代码路径,无法识别动态算出来的跳转。而arm架构下由于存在arm和thumb指令集,就涉及到指令集切换,IDA在某些情况下无法智能识别arm和thumb指令,比如下图所示代码:

pic4

bx r3指令会切换指令集,而参数r3是动态计算出来的,IDA无法失败r3的值,而默认将bx r3后面的指令当成跳转地址,将后面地址的指令识别成了arm指令,而实际上其仍为thumb指令。

在IDA动态调试时,仍然存在该问题,若在指令识别错误的地点写入断点,有可能使得调试器崩溃。

0x09 Ptrace


Ptrace是gdb等调试器实现的核心,通过ptrace可以监控、控制被调试进程的状态、信号、执行等。而每个进程在同一时刻最多只能被一个调试进程ptrace,根据这个原理,可以主动ptrace自己的关键子进程,这样可以在一定程度上防止子进程被调试。

为了防止fork出来的反调试子进程被直接挂起或杀死,可以通过Ptrace的PTRACE_PEEKTEXT、PTRACE_PEEKDATA、PTRACE_POKETEXT等参数来完成父子进程之间的通信,比如子进程中使用的解密密钥先存于父进程空间,父进程往ptrace的子进程中写入密钥后,再解密出关键数据。

总之,通过ptrace增加父子进程之间的联系,是十分有效并且广泛存在于各类加固的反调试方法。

0x0A Inotify 监控文件


在Linux下,inotify可以实现监控文件系统事件(打开、读写、删除等),加固方案可以通过inotify监控apk自身的某些文件,某些内存dump技术通过/proc/pid/maps、/proc/pid/mem来实现内存dump,所以监控对这些文件的读写也能起到一定的反调试效果。

0x0B 总结


本文总结了主流加固厂商大部分反调试技巧,APK下的反调试技巧和win、linux下的大同小异,核心原理都是类似的。说到底,反调试只能尽可能的增加逆向难度,APK的安全防护绝不能仅仅依靠反调试,APK安全需要从整体架构上入手,在关键代码上加入强混淆,甚至通过vmp来增大关键代码的逆向难度。

0x0C Reference


转载自:http://drops.wooyun.org/mobile/16969    原文作者:超六、曲和