好久没有更新博客了，主要是忙项目的事，今日总结一下在Android中常遇到的反调试方法，一来帮助需要之人，二来加深自己的理解。
反调试在代码保护中扮演着很重要的角色，虽然不能完全阻止攻击者，但是还是能加大攻击者的时间成本，一般与加壳结合使用，核心还是加壳部分。
反调试可以分为两类：一类是检测，另一类是攻击，前者是去想各种办法去检测程序是否在被调试，如果正在被调试的话做出一些“反”的举措，比如退出等等，(当然这里退出不是一个万全之策，因为你暴露了反调试的位置点，这样攻击者就比较容易过反调试，更好的是想办法不让攻击者发现，并且跳到另一个位置，让攻击者懵逼，小弟不才，本文是采用退出的方式，更好的方法读者可以自己YY)，后者是采用攻击的方法，就是想办法让调试器不能正常工作或者是让调试器崩溃，从而阻止它，会在下一篇介绍。
本文只是简单反调试的一些基础部分，都是通过另起一个新的进程或者线程，这些很容易会使用kill大发杀死或者是通过别的方法挂起，从而很容易的过掉反调试，所以这时候会想到通过进程间通信的方式来确认反调试进程是不是还存在？这些会在下一篇里讲述。
第一种：一个进程最多只能被一个进程ptrace
我们知道在调试状态下，Linux会向/proc/pid/status写入一些进程状态信息，比如最大的变化是TracerPid字段会写入调试进程的pid,以下是在调试前后/proc/pid/status的文件的变化。
被调试前 被调试后
我们明显可以看到的是android_server附加的。
对于此中现象，解决的办法：一是根据Linux下一个进程最多只能被另一个进程跟踪，因此我们可以自己ptrace自己，然后让android_server不能够调试。
因此实现如下：
达到的效果是：
我们知道android所有的进程都是zygote进程fork出来的，那这里毫无疑问125就是zygote进程号。所以
以及达到的效果是IDA附加不上：
解决办法：静态分析在JNI_0nload处把anti_debug01()方法NOP掉。具体不再阐述。
第二种：检测Tracerpid的值
根据以上第一种方法的分析我们可以检测Tracerpid的值，如果不为0，只能说明一点：当前进程正在被调试，那我们就kill掉退出。
这里就不细说，应该很好理解。
实现重要函数如下：
达到的效果就是在附加上以后程序会退出。
当然我们可以加一个线程机制进行循环检测，来增大攻击者破解的难度这也是很多加固厂商采用的办法。
解决办法:一是以debug模式启动，在JNI_Onload处下断点，找到那个调用方法NOP掉，二是直接静态分析JNI_Onload,直接去掉方法的调用。
第三种:检测android_server端口号
我们知道android_server的默认监听的端口号是23946，所以可以通过检测这个端口号来起到一定的反调试作用，在Linux系统中在/proc/net/tcp会记录这些连接信息，首先我们看到在没有连接android_server时候的信息列表：
在这里我们重点关注这一列：代表本地地址与端口号，对于其他信息如果读者有兴趣可上网自行查阅。
在连接上android_server以后我们可以看到信息列表多了一行
我们可以看到在底层多了个5D8A的端口，这个是十六进制表示正是十进制23946的表示，因此我们可以检测这个文件下面的这个端口号来进行达到反调试的作用。当然这里我们也可以通过执行netstat –apn命令来进行查看
那么接下来我们就开始实现，实现的代码如下：
达到的效果也是一样在调试的时候检测到那个端口会退出，跟上面一样。
解决办法：换那个端口，很简单。
第四种：通过检测android_server这些关键字以及文件目录
我们知道在调试进程的时候，这个进程会被IDA中的android_server ptrace,并且这个进程名字存在于“/proc/pid/cmdline”中，当然这里的pid指的是android_server的进程号，这个可以通过TracePid来获得，通过下面这个图可以看出来：
如果不明显，我们可以把它adb pull出来，可以看到的是：
因此说在这里可以检测这个名字，如果有这个名字说明正在被调试，那我们就可以kill掉这个程序。
一般情况下，android_server都会放在/data/local/tmp/文件下，因此我们还可以检测这个文件是不是有android_server,如果有，程序就退出。
在这里我们可以发现这个思路好像很白痴相对于前几种，如果我们把这个名字改掉，然后放到别的目录下，不就可以一直对付这个反调试了吗？但是如果这个方法是第一次被应用到加固里面，说不定那时会让人有一劲懵逼。
下面来看检测android_server关键方法的实现部分：
检测关键目录/data/local/tmp是一个道理，此处略过。
第五种：检测在调试状态下的软件断点
首先在进行这个方法理解时，要对在调试时下断点有一定的了解，发现下断点还是利用ptrace系统函数，不得不佩服ptrace函数的强大，决定以后专门拿出一章进行好好研究，特别是ptrace注入这一节，在调试器设置断点的时候，首先完成两件事：
第一：保存目标地址上的数据
第二：将目标地址上的头几个字节替换为break point指令，命中断点触发breakpoint,这时程序向操作系统发送SIGTRAP信号，调试器收到SIGTRAP信号后，调试器会回退被跟踪进程的当前pc值，当控制权回到原进程时，pc就恰好指向了断点所在位置，这就是调试器设置断点的基本原理。
说了一大堆，软件断点通过改写目标地址的头几字节为breakpoint指令，那接下来类似于前面所讲的几种方法，直接进行检测文件，我们可以遍历so中的在可执行segment,查找是否出现breakpoint指令即可。
关键函数实现如下：源码会在附件中呈现
1.首先读取ELF文件在内存中的地址：关键函数如下：
2. 然后读取完以后，根据其对应的偏移地址进行检测有没有ARM、Thumb、Thumb2的断点指令，如果有的话，就kill掉。程序源码见附件。
解决办法:这般函数可以在JNI_Onload、com_java_XX这类的函数进行调用，但是对于有经验的逆向者来说，经过几次动态调试就可以找出问题的原因，然后对关键函数进行NOP掉。
第六种：使用Inotify对文件进行监控
我们知道在我们的动态调试的过程中，一般会查看调试进程的虚拟地址空间或者是dump内存，这时候就会涉及到对于文件的读写以及打开的权限，这时候如果能够检测它们的变化，这样岂不是很美妙？
然而偏巧的是在Linux下inotify就可以实现对文件系统事件的打开，读写的监管。如果通过Inotify监管这些，收到事件的变化，那我们就Kill掉进程。这里介绍下面主要会用到的几个常用的api:
1. inotify_init：用于创建一个 inotify 实例的系统调用，并返回一个指向该实例的文件描述符。Int fd=inotify_init();
2. inotify_add_watch：增加对文件或者目录的监控，并指定需要监控哪些事件。
int wd =inotify_add_watch(fd,path,mask);
这里path表示你要监听的文件目录，mask表示监听事件掩码，就是监听读了写了还是打开，删除等等。
3. read：读取包含一个或者多个事件信息的缓存。
主要是用来读取监听目录文件事件发生变化时的事件队列。
4. inotify_rm_watch：从监控列表中移出监控项目。
这个很好理解就是删除一个watch。
5. select(intnfds,fd_set* readset, fd_set* writeset, fe_set* exceptset, struct timeval* timeout):
select的第一个参数是文件描述符集中要被检测的比特数， 这个值必须至少比待检测的最大文件描述符大1；参数readfds指定了被读监控的文件描述符集。
这里由于篇幅要求，介绍的不详细，读者可以自行百度。
接着看实现部分：
第七种：调试时候代码执行时间差异检测
我们知道如果在程序执行的时候关键代码的前后的时间差异肯定是要比在动态调试的时候对应的关键代码的前后的时间差异要小的多，因此我们可以获取系统的时间，计算前后的差异，如果超出一般正常情况下的设定值，我们就认为此处的代码正在被调试，这时候就可以选择退出。或者是做出一些其他的事，逻辑比较简单，那以下是代码关键点的实现部分：
当然这里最重要的是获取系统的时间，获取系统时间的办法有很多，网上也有很多，可以自行查阅，这里介绍一种：
达到的效果是让程序退出，起到反调试的作用。
当然这个方法可以放在一个关键的逻辑地方，这里起到的效果就是检测到当前程序正在被调试，那我们下一步可以可以就像上面说的让程序退出。当然更高级的方法是不让它退出，读者可以自己YY。
第八种：Dalvik虚拟机内检测调试器函数
由于Dalvik自带这些内部检测调试器的代码，大致上是在被调试以后，改变那个调试器的状态字段，既然反调试就是第一步想办法检测出它正在被调试，第二步是真正的“反”，我们可以不动声色的去“反”，读者可以想办法YY，这里不多叙述。
总结篇：在这里看到的反调试都是以检测手段为主，也是比较常用的思路，当然也是一种低级反调试，因为容易爆露反调试点，只有在做反调试系统的时候这些手段交杂多用，才能给逆向者增加一定的成本开销。
附件篇：
附件是pdf文档和反调试源码：
