关于Win7 x64下过TP保护(应用层)

eeooooo · 发表于 2016-10-16 04:46:57

调试对象：DXF
调试工具：CE、OD、PCHunter、Windbg
调试先言：TP的应用层保护做得比较多，包括对调试器的检测，比如CE工具会被DXF报非法。有的保护还是内核与应用层交替保护。

应用层：
1、TP让调试器卡死(内核互动)

如图，TP会检测调试器让调试器暂停运行，实际上就是暂停了调试器所有的线程而已。
这个保护是今年7月份新出的，所以我这里重点分析下，我刚开始调试的时候就发现OD会莫名其妙地卡死。
打开PCHunter发现OD的进程线程全部被暂停了。
开始我认为是TP调用了SuspendThread(函数:暂停指定线程)来让调试器卡死的。
于是我就打开Windbg附加并在这个函数上下断点，发现没有断下来。
然后我认为是调用了接口函数NtSuspendThread(函数:暂停指定线程<内核接口>)
但是还是没有断下。所以排除了DXF在Ring3调用了暂停线程让OD卡死。
于是我思考了一下，打开虚拟机，简单过了双机调试保护（一段时间后还是会蓝屏），在DXF启动之后，
在Windbg输入!process OD的进程ID 来查看线程的调用堆载，我发现了很有意思的东西。
SuspendCount被置为了1，再看看调用堆载。
原来TP在Ring0中调用了KiSuspendThread来暂停OD的线程啊。怪不得断不下来。
于是我在KiSuspendThread头部下断点，发现当OD打开的时候会断下，
这个是它的函数开头
0: kd> u KiSuspendThread
nt!KiSuspendThread:
fffff800`03e6cc60 48895c2408     mov    qword ptr [rsp+8],rbx
fffff800`03e6cc65 4889742410    mov    qword ptr [rsp+10h],rsi
fffff800`03e6cc6a 57             push rdi
fffff800`03e6cc6b 4883ec30       sub    rsp,30h
fffff800`03e6cc6f 8364245800    and    dword ptr [rsp+58h],0
fffff800`03e6cc74 65488b1c2588010000 mov rbx,qword ptr gs:[188h]
fffff800`03e6cc7d 4885db       test rbx,rbx
它还保留着用__stdcall的调用约定，在64位下一般都是__fastcall
通过对参数的分析，我发现这个函数的第一个参数也就是rbx，里面存的是线程对象。
我在网上也没有找到相关的信息，于是我自己在头部改成了ret。
之后运行OD就不会卡死了。
继续深究，原来TP创建了一个内核回调，就是CreateProcess的回调，
自己可以打开PCHunter查看。
当发现是OD的进程被创建时，就会调用这个函数让进程暂停。
哦，原来是这样，那我们有什么办法解决它呢？怎么才能让调试器正常运行呢？
方案:1、自己恢复调试器的进程(推荐) 2、删除内核回调(驱动推荐)3、Hook KiSuspendThread 绕过(稍难)
在这里我推荐第一种，因为我们是要在应用层下操作。
方法很简单，当我们打开OD工具时，打开PCHunter选择OD的进程，右键恢复进程运行即可。
也可以自己做一个工具，恢复OD的进程，但是你要确保自己的程序不会进入黑名单。
至此，我们的调试器能正常打开了。

2、函数钩子(Hook)
这个保护不能说是新鲜了的吧，在应用层里很多游戏都这么干。
其实就是把一些重要的调试函数进行钩子，导致程序崩溃或者无法调试。
我们打开PCHunter，来到如图的位置，选择DXF的进程->右键选择扫描。

现在你只需要坐下等大约5分钟吧，好像有一千多个钩子(笑)，要有耐心。
看到图中3个钩子了吗，它就是我们要说的。
我这里来说明下这3个函数的用途。

DbgUiRemoteBreakin:远程中断，附加调试器时调试器会发送信息让进程走这里。
KiUserExceptionDispatcher:UEF异常处理函数，梦老大讲解过的，这个我们不能随便恢复，干脆不用管它
因为DXF自己制造异常自己处理。
LdrInitalizeThunk:映像文件链入口，当DLL载入时会经过这里，如果我们不恢复它将无法注入DLL。

这3个钩子有两个是我们必须恢复的，就是一和三。
第三个比较好处理，PCHunter中已经给出了函数原来的机器码。我们之间用PCHunter恢复也可以自己写个程序恢复
但是第一个就不好了，我们必须用程序自己来恢复,因为:

红线部分是需要重定位的，机器每次开机都会不同，我们可以通过获取自己程序的这个位置的代码来恢复。
具体怎么恢复这里就不说了，我会贴出代码给大家。
那么2个Hook搞定后我们就要来解决崩溃问题了。

3、异常崩溃
大家可以发现OD附加DXF后运行，游戏会莫名其妙地崩溃，你可能会认为OD被DXF检测到了，其实它是个通用
的反调试的手法。
自己给自己制造异常，自己处理，如果OD抢着处理这个异常，反而会使进程崩溃。
这个就是它异常崩溃的原理。
其实是一个线程在自发异常的，怎么把它揪出来呢？
打开Windbg，附加DXF，运行，可以发现一段时间后，Windbg断下
如图所示：

线程ID:F08 发送了一个内存访问异常(0x80000002)它故意让Windbg断下。
它需要试探是否有调试器，于是我们就找到它了，把f08换成十进制发现是
3848的线程发送异常的，在PCHunter中可以看到，如图所示，它是由ntdll.dll发送的。
唯一的办法就是结束这个线程，右键->结束线程，搞定，OD附加DXF不会崩溃了。
但是你得自己做个程序来找到这条线程然后来结束掉，可以通过搜索线程入口特征码的方式来
找到它。
那么现在，我们调试DXF再也没有问题了。但是CE工具开启久了也会被提示非法，怎么办？

4、检测非法工具
也许大家非常想要知道怎么办。
它检测非法工具的原理是:
使用ReadProcessMemory(函数:读取进程内存)搜索进程特征码，找到属于非法工具的特征码后游戏消失，提示非法重启。
若想解决它，我们有以下方案:
1、删除工具中的特征码 2、在内核中拦截NtReadVirtualMemory或KeStackAttachProcess来绕过搜索
3、找到搜索的线程，结束该线程。

其实我发现第3种是一劳永逸，所以我在这里说下第三种方法。
打开PCHunter找到如下几条线程。选择后同时右键结束，OK，CE再也不会非法了。