关于某dxf游戏的APIHOOK(2)

roger

上次那个APIHOOK处理下断在我电脑上测试是没问题的，但是许多人反映无效，只在部分电脑有效，说明这次更新游戏在其他地方也做了HOOK，我们今天就来研究一下它的HOOK。

首先目前可以确定，它第二个HOOK的函数为RtlUserThreadStart，这个不再赘述，CE VEH调试的原理就是注入个dll，注入DLL必然要创建线程，所以去看线程相关函数就可以了。

首先x64dbg附加，我们来看一下这个函数：

关于某dxf游戏的APIHOOK(2)

我们再来看一下正常程序的 RtlUserThreadStart ：

关于某dxf游戏的APIHOOK(2)

明显发现有区别，函数头部的rax是被修改了的，我们来看一下这里面存的啥玩意。

关于某dxf游戏的APIHOOK(2)

看到了一个熟悉的模块，ACE-DRV64.dll+xxxxx，不用说，肯定是检测模块，并且程序正常的 RtlUserThreadStart 肯定被这个地方接管了，我们来看一下这个函数长什么样子：

关于某dxf游戏的APIHOOK(2)

关于某dxf游戏的APIHOOK(2)

很熟悉吧，和 LdrInitializeThunk 那里的HOOK长的几乎一模一样，我们先测试一下直接nop可不可以，毕竟能偷懒就偷懒。。 首先先把 LdrInitializeThunk 那里处理了再nop这个。

关于某dxf游戏的APIHOOK(2)

加上之前的尝试，不是黑屏就是崩溃，肯定是不能NOP的，那我们只能慢慢分析它代码了，看看在哪里检测的。

首先先进到这个CALL里瞅瞅：

关于某dxf游戏的APIHOOK(2)

在这里它把原函数地址存到了rcx，然后下面一个跳转跳上去了，我们跟着它走过去看看：

关于某dxf游戏的APIHOOK(2)

我们先来走一遍，看看它的正常流程是如何的：

关于某dxf游戏的APIHOOK(2)

那么，检测肯定就在其中这几个判断之中，其中有两个CALL，后面都跟着返回值判断，那么猜测这两个CALL其中必有一个是用来检测线程合法性的，这时我们先恢复 LdrInitializeThunk 的HOOK，然后使用CE VEH附加(因为CE创建的线程是非法创建)，观察这两个CALL返回值会不会有变化：

我们在下断后的瞬间点Yes，断点被命中，程序断下：

第一个CALL还是依旧返回0，如图：

关于某dxf游戏的APIHOOK(2)

我们来看第二个CALL：

关于某dxf游戏的APIHOOK(2)

第二个CALL返回1 ！ 说明这个就是检测函数，如果线程创建合法，那么返回0，如果线程创建非法，则返回1，那么我们只需要处理以下这个地方即可：

关于某dxf游戏的APIHOOK(2)

处理之后，我们来测试一下：

关于某dxf游戏的APIHOOK(2)

ok，成功下断。

但是这样也有一些其他问题，我们这样只是修改了检测函数的返回值，但并没有真正过掉它的检测，虽然可以调试，但某些情况下可能还是会出一些问题，如果大家只是用来找数据调试那都是ok的。

如果你只是想调试，那么可以不必继续往下看了，下面我看一下里面的检测函数长啥样，干了点啥？

关于某dxf游戏的APIHOOK(2)

这.....这不和 LdrInitializeThunk HOOK那里长的一模一样吗。。我们来试一下在这里修改，不执行它的检测函数是否可行：

关于某dxf游戏的APIHOOK(2)

关于某dxf游戏的APIHOOK(2)

ok的，并没有崩溃，这里我建议动上面那个跳转(mov al,2 ret)，这里的(xor al,al)就不要动，虽然都差不多，但我感觉这样好一些。

现在我们再看看第二个CALL，使用CE附加游戏，让其断下：

关于某dxf游戏的APIHOOK(2)

关于某dxf游戏的APIHOOK(2)

这里面我看过了，就不再一步一步讲解了，只看一些有意思的东西：

关于某dxf游戏的APIHOOK(2)

关于某dxf游戏的APIHOOK(2)

这里面会记录你CE(或其他程序)的进程ID 进程名 创建线程类型等等信息，但咱们不用管,因为我们已经跳过了这个函数，并不会执行。

但是带一句 无论你干啥了游戏都会知道的,所以玩玩就行了

至此结束。

ACE-DRV64.dll+8E490 - E9 97024700 - jmp ACE-DRV64.dll+4FE72C

二进制

啥也不说了，加入收藏！