完成对tp的跟踪后有一些感触
tp不愧为游戏保护中的软柿子,它对自己的保护除了反调试之外,就是汇编花指令了(我称他代码混淆),对我个人来说,最麻烦的就是他的代码混淆了,经历过他两种完全不同的混淆方式,最开始的比较简单,就是一大段循环,循环的出口就是要调用的函数,规律很好找,每次跳出循环时esi edi 寄存器的值都一样,当时就笑骂腾讯的人弱智,后来他们把代码混淆的方式改变了,我没有发现特别容易明显的规律,只能靠常规处理花指令的方式,它的一些执行代码往往夹杂在这些化指令当中,不过还好,它的花指令不多,只要有耐心一步步跟踪也能跟踪到目标函数,我采用的是参数跟踪法:断点目标参数访问(读写),能省不少时间。
其实有时候也会站在tp开发人员角度去考虑问题,怎么不让人跟踪到自己的代码。
首先:我觉得不能采用传统的反调试方法(至少不能只靠传统的反调试方法),其次在检测到调试后不能做那么明显的处理,比如:重启。如果是我的话,我会随机修改部分代码,导致蓝屏或其他。比如:但我检测到自己被调试后,我往代码段随机写能导致异常的指令,这样的结果是要么蓝屏,要么什么事情都没发生。此时就算知道被检测调试了,但想定位检测代码就太难了。
其次,对于SSDT hook 不管是inlinehook 还是headhook 要绕开还是很轻松的。SSDT函数说白了就是个被玩滥了东西,靠它保护游戏还真是不靠谱,有什么其他办法呢?以我绕开SSDT的经历,还真是没有好办法,呵呵。除非往更加底层走,这方面我没研究,所以也就没发言权了。
还有,对于tp的检测线程,这方面感觉tp处理的太没水平了,我将他的线程执行函数return掉,他居然就没有其他的校验机制去校验。如果是我来做tp,我想我肯定会有线程是否正常执行的检测,这种方法很多,实现又容易。同样的道理,对于IoQueueWorkItem开始执行的异步函数执行检测也可以有很多种方法。
先写这些吧,呵呵,懒了,以后有时间继续补充吧