反调试防御网机制
一、介绍：
反调试对于逆向安全工作者再熟悉不过了，一般是配合壳的形式出现，我认为反调试在某些时候还是能起到一定作用的，特别是在Android应用程序的逆向过程中，由于其一Android动态调试建立过程相对于其他比较麻烦点，其二即使在通过一定的脚本可以过掉调试一半的前面的反调试，但是如果这种反调试本身是随机的且随着样本的不同是呈现多样性的，那么这种就起不到好的效果了。
二、原理机制：
对于一个So文件在加载的过程中，我们都知道主要这么个.init/.init_array->JNI_Onload->应用层过程，因此提出一种随机多样性的反调试防御机制，即：反调试检测机制是随机的，并且反应机制是随机的，以及等攻击者patch前面的反调试关键点的时候，后面的反调试会进行检测并作出随机性的反应。这样来动态的建立起来反调试之间的联系，以增大攻击者的调试难度。
三、原理图：
略
四、实现
1.随机点插入随机检测机制：
对于反调试的检测机制可以参考https://bbs.pediy.com/thread-223460.htm，里面总结的很全。由于反向检测机制，可以产生很多的检测机制。至于随机性可以在对APK进行加固的时候壳里面随机的选择反调试。
2.随机的反应机制：
如果一旦被检测到，要做出一定的反应，但是目前看到的反应机制但部分还停留在“杀死进程退出”这样的情况下，其实还可以考虑比如一个死循环这样的情况下，或者让IDA报出异常，或者把攻击者引入一个错误的逻辑处等等，反正可以自由发挥。
3.反向检测机制：
我们知道对于常用的过反调试的手段是NOP掉反调试函数的调用点。这个时候提出反向检测机制，如图上所示，如果一旦前面的反调试的调用点被patch掉，后面进行检测，一旦检测到可以随机的再次响应，这样就形成了一个网状的防御体系结构。这样一个个的反调试机制之间不是独立静止的而是互动的，从而进一步的增大攻击者的逆向成本。
这个时候如果攻击者找到这种规律后，方法一：先把对应的调用反调试的地方NOP掉，等运行完这段指令以后再进行还原HEX，方法二： NOP掉后面检测函数，这样就避免了上面的这种检测，但是找出这样的攻击规律只要能够付出时间成本就可以。
具体的实现如下：
略
五、总结
本身反调试在阻止逆向者去动态调试时起不到根本的作用，一般只是配合壳的形式出现。只是增大逆向者分析成本的一种手段而已，如果觉得自己加固本身做的很强。比如虚拟机机制保护，这时候如果认为：”随便你调试，不care！！”，那么就可以不使用反调试。本文介绍没有过多的技术创新点，只提供一种机制。