现在看论坛里还有人在发愁游戏的反调试，我总觉这块已经没意思了，反来复去就那么点东西了。今天来说一下，先r3:
有人发过一个贴子，说没驱动，没钩子，OD附加成功了，但一下断点，游戏就退出了。这是因为od下软件断点，是写入一个0xcc的指令，也就是int3,但是游戏线程在启动时，调用过ZwSetInformationThread，使用了其中0x11号的功能，这个函数的作用可以使调试器接收不到这个线程的调试信息，因为调试器接收不到，游戏就自己处理了这个中断，当然会出错。解决办法就是提前hook住内核函数ZwSetInformatonThread,如果发现有调用这个函数的，并且是0x11功能的，直接给他返回成功就行了。还有一个WS的反调试就是驱动的，遍历线程内核对象，然后直接在HideFromDebugger上写入1。这是驱动的反调试，以后再讨论。
还有一种反调试就是调用ZwQueryProcessInformation,这个函数在kernel32.dll里还有一个包装函数，这是查进程内核对象DebugPort处的，解决办法也是写个驱动,钩住内核函数ZwQueryProcessInformation，如果发现有调用的，且是那个功能号的，直接返回空就行了。
以上两种反调试，在《加密和解密》上都有，现在OD的插件太强大了，像检测IsBeingDebugger位的，直接插件就能解决了。一般的游戏调试,还会钩住DbgBreakPoint和DbgUiRemoteBreakPoint这两个函数，这个解决方法就太简单了，瞬间秒杀。
我比较欣赏的有两款游戏的反调试，都是r3下的，神魔大陆和大唐无双。神魔大陆创建过一个线程，里面加入了SEH，并且不断触发int1，这不是r3下可以调用的中断，所以是个错误，然后SHE就会去处理，如果调试器附加上，就会干扰这个过程，然后就出错了。还有就是它设置了TLS，然后其中一个tls callback放在了DbgBreakPoint或DbgUiRemoteBreakPoint上了，然后将这某个函数的开头改成了ret 0xc,如果你敢恢复这个函数，就使使tls callback不正常，游戏会卡死，有木有，大家有木有碰上。如果不恢复，调试器会附加不上，怎么解决？大家自己想去吧。再说大唐无双，它会不停地检测IsBeginDebugger位，如果发现了，就会关闭游戏，设置了插件，有时候附加的时候，还会被它抓住，十次附加游戏，总有那么三四次游戏会关闭，大家有木有碰上。这个游戏每十分钟，这个时间是我掐着表数出来的，会调用BlockInput这个函数，来阻塞键盘与鼠标的输入，然后主线程触发一个异常来取消。这个东西真WS。
就扯这么多吧，其实没啥好说的。今天阳光灿烂，春暖花开，大家都空多出去走走。

补充：

昨天闲扯了一下r3下的游戏反调试，水平低，没说好，大家看着玩吧。今天再说一下r0的：
一般的反调驱动，都会钩NtOpenProcess,SSDT HOOK或者inline HOOK,这是一般反应，连进程都不打开，OD就更不能调试了，这个也阻止了注入，还有处理NtReadVirtualMemory与NTWriteVirtualMemory这两个，深一点还会处理KeAttachProcess或KiAttachProcess。TP的保护就是这样，不同的是，它处理了NtOpenProcess与NtOpenThread里面的一个调用的函数，这应该叫什么HOOK？对付SSDT HOOK，我有时候会用Inline HOOK,对会Inline hook,却可以用SSDT HOOK来跳过前面的那几个JMP。
DebugPort清空，这个都会整，汇编代码一般都是xchg eax,dwor dptr [xxx]。反调驱动在加载时，都会判断操作系统版本，然后保存DebugPort的偏移的硬偏移，因为EPROCESS这个结构，微软没公开啊。反正TP与PP都会这样。我都是把那个偏移改成ExitTime。改了会重启，因为有检测，断电式重启，是向键盘控制器的0x64端口写入0xfe,重启代码还会加VM。检测debugPort的代码后面还会有一个检测，我以前写过一篇日志，就是说这个事，〈螳螂捕蝉，黄雀在后），，后来又删了，哈哈。要找到检测debugport的代码，是用调试器下读写断点，狠狠心，自己写个小的调试器，就行了。有人是用缺页内存的方法，好象是hook int 0xe,我用的是hook int 0x1。
驱动的确比应用的反调试有作为，因为它能检测很多东西，在调试的道路上随便放暗樵就当了搞。其实我不怕它处理代码，因为用xuetr这类的工具，一目了然，都能看到,Object HOOK也不怕。最被它检测DebugObject这样的事，还有的检测别进程的句柄，慢慢试吧。在重启中永生。
今天依旧阳光灿烂。