扒光tp后的一些感想

完成对tp的跟踪后有一些感触

tp不愧为游戏保护中的软柿子，它对自己的保护除了反调试之外，就是汇编花指令了（我称他代码混淆），对我个人来说，最麻烦的就是他的代码混淆了，经历过他两种完全不同的混淆方式，最开始的比较简单，就是一大段循环，循环的出口就是要调用的函数，规律很好找，每次跳出循环时esi edi 寄存器的值都一样，当时就笑骂腾讯的人弱智，后来他们把代码混淆的方式改变了，我没有发现特别容易明显的规律，只能靠常规处理花指令的方式，它的一些执行代码往往夹杂在这些化指令当中，不过还好，它的花指令不多，只要有耐心一步步跟踪也能跟踪到目标函数，我采用的是参数跟踪法：断点目标参数访问（读写），能省不少时间。

其实有时候也会站在tp开发人员角度去考虑问题，怎么不让人跟踪到自己的代码。

首先：我觉得不能采用传统的反调试方法（至少不能只靠传统的反调试方法），其次在检测到调试后不能做那么明显的处理，比如：重启。如果是我的话，我会随机修改部分代码，导致蓝屏或其他。比如：但我检测到自己被调试后，我往代码段随机写能导致异常的指令，这样的结果是要么蓝屏，要么什么事情都没发生。此时就算知道被检测调试了，但想定位检测代码就太难了。

其次，对于SSDT hook 不管是inlinehook 还是headhook 要绕开还是很轻松的。SSDT函数说白了就是个被玩滥了东西，靠它保护游戏还真是不靠谱，有什么其他办法呢？以我绕开SSDT的经历，还真是没有好办法，呵呵。除非往更加底层走，这方面我没研究，所以也就没发言权了。

还有，对于tp的检测线程，这方面感觉tp处理的太没水平了，我将他的线程执行函数return掉，他居然就没有其他的校验机制去校验。如果是我来做tp，我想我肯定会有线程是否正常执行的检测，这种方法很多，实现又容易。同样的道理，对于IoQueueWorkItem开始执行的异步函数执行检测也可以有很多种方法。

先写这些吧，呵呵，懒了，以后有时间继续补充吧