查看: 31854|回复: 3
DNF检测原理分析篇
前言:看了那么多人发一些心得帖子,看着一些人说的东西有的对有的不对,如下纠正,当然在最后做点小guanggao,呵呵
1 CRC&&很多人老是把CRC和检测联系到一起，我也不知道这个概念是谁先灌输的, CRC是一套算法, 目的是来检测代码是否被更改过,所以DNF里
的CRC大都用来检测的是HOOK，至于一些数据异常，我拿个例子来说，比如以前的无消耗冷却，改物品代码为3，为什么用之后会小三？因为DNF
在使用的函数里加了一个判断跳转,当物品代码是3的时候跳转到一个地方进行详细检测,他的跳转不是一般的cmp 跳转之类的而是
mov eax,代码
jmp dword ptr[eax+基址]
当你的代码正常是跳转到一个地方,改过之后会跳转到另外一个地方,这种检测不叫CRC，请大家以后分清楚了，不要吧过检测直接就说是CRC
2 关于注入追封的，说实话我到现在没有被追过,检测有以下几点(非输入法注入,直接正常注入)
&&(1) 当然就是DLL模块的检测, 枚举本身进程, 可以在内核里挂个钩子NtQuerySystemInformation过滤一下你的模块
&&(2) 关于读取写入内存的,在R3中DNF没有HOOK检测,而是用了TP在R0中检测,R0中的检测最后结果是导致你网络连接中断
& && & 过掉NtReadVirtualMemory ,和NtWriteVirtualMemory即可,当然你如果注入DLL之后，不需要使用这两个函数,直接把地址转换
& && & 为指针即可
& && & *(ULONG *)address=值
& && &或者直接内联汇编
& && &mov ecx,address
& && &mov [ecx],值
&&(3) 过掉了以上还是不行的,在强行注入DLL的时候或者启动线程，会使用以下函数,没有恢复之前是没有任何效果的
& && & 1 GetProcAddress
& && & 2 LdrLoadDll
& && & 3 LdrInitializeThunk
& && & 4 ZwCreateThread
& && & 5 LoadLibraryExW
& &&&在几个月前,直接恢复这几个钩子就可以直接强行注入,但是在上个月,DNF用了一个CRC来检测这部分,不过这部分的检测代码VMP的镜像大
& & 可以在2层进行HOOK跳转绕过,目前稳定
&&(4)在注入代码之后会有一个线程循环读取你注入的代码,模块名字好像叫tp什么什么的,微软本身也有这一个模块,我也不清楚这模块是DNF改
过的，还是原来微软没有公开的用来回收内存的机制，直接返回
&&(5)还有一个更深层的检测,这个留一手吧,呵呵,DLL注入不需要考虑这种情况,我也就不多加介绍了
3 关于DNF登陆的检测
&&这个部分主要针对的是工作室了,登陆的时候会获取CPU 的ID，获取的实现方法并不是一般的函数,而是cpuid这个汇编来获取，所以相对来说
&&不是很好HOOK,解决办法可以分析出什么地方获取的, 进而在那个地方做一些手脚,当然你工作室的技术人员够厉害可以进入r-1,这样是可以
HOOK 这个汇编指令的,这样的话TP的所有反调试基本作废了
4 DNF的检测
& &请大家把这部分与CRC分开,这是两个概念,这里的检测很像一种异常检测机制,有如下两点,对于有编程功底的深有体会
& &(1) 已知异常检测 对于一些特定的数据出现,直接认定为是智辅,比如召唤吧,召唤的怪物代码,在我改召唤的时候召唤深渊BOSS
& &直接小三,或者是一些99W代码,一旦使用直接小三
& &(2)未知异常检测 这也是DNF高级的检测部分,我也不知道是不是大家口中所说的obj,本人一直深居,不知道各种名词
& && & 每一个类派生出对象之后都是有各种值来记录的,当这种值不符合常理之后就会出现下三
& && & 体现在这里,你在调试智辅的时候经常有些功能是用好几把才会出现小三,或者用很多把才会出现,我以前直接使用狂龙CALL
& && & 是直接CALL不是改代码那种，在刷100多疲劳的时候会出现小三
& &(3) 这一部分在上面两者之间,怎么说呢,DNF也没法认定这样会是非法,只能认定出现多少次就是不寻常的,比如我以前通过瞬移技能
& &直接调用的瞬移CALL,不是一般的瞬移CALL，这种CALL很稳定,但是到达一定次数就会出现小三
& &(4) CRC计数器应该就是异常的计数器吧,呵呵，我是这么理解的，可能定义这个CRC计数器的人又是另外一个概念了
5 静态CRC和动态CRC
&&起先我都没听过静态和动态,因为我没这么叫,我把他们叫为大检测和小检测,呵呵，不是很形象，这也证明大牛还是很多的、
静态:研究过DNFCRC的人应该都知道,有一个线程在反复反复的扫描整个DNF内存空间,这个地址大家都很熟悉了,呵呵0x1d什么什么的
&&在DNF中保存有黑名单的函数,这就是重点扫描对象,一旦发现就小三,但是一个扫描过程需要3-5分钟所以很慢
动态:在很久以前遇到的,确实有点意思,在这个地址你会发现每次启动DNF之后扫描的线程不是一样的，有时候是这了两个,有时候是其他两个
&&或者三个，这种随机的检测可能就是你们所叫的动态CRC了，但是你会发现变来变去就是这几个
静态CRC我以前处理过,很是复杂的,当时分析了一点现在与大家分享，因为没有分析完全所以不知道结果是不是这样的
(1) 这个线程检测是与其他线程息息相关的，肯定不能直接写返回
(2) 你会发现在这个检测中挂上钩子进行处理之后还是会被检测的,但是又没有其他代码读取这部分,呵呵我的分析有2
& & 1 DNF使用readProcessMemory来进行读取,所以触发不了硬件读断点
& & 2 DNF使用一些深层API获取每次执行的时间差，来判断自身是否被HOOK
& & 对于以上两个我做了实验如下,在两句不相干汇编的地方进行上下位置变换比如
& & 0x mov eax,0
& & 0x1234567d mov ebx,0换成了
& & 0x mov ebx,0
& & 0x1234567d mov eax,0
& & 结果一直没有出现小三,之后我又加上了跳转没有过滤任何内容包括状态寄存器,出现小三,经过我和一位大牛分析，可能原因是
& & 通过对比代码段执行的时间来检测的,当然这是个可能，并没有深究下去，DNF要在WINDOWS这种非实时的操作系统下实现这部分
& & 内容也是很不容易的
总结:过DNF检测其实难就难在VM上了,反调试很容易搞定,尤其是内核中的几个VM,做一个简单的映射镜像就处理过了，而R3里的检测因为大部分
都是VM所以不好分析,可以通过追踪EIP把所有执行路径打印出来详细分析具体流程,DNF的VM镜像一般都是两层,当然大部分都是没有VM过的，分
析VM是个很头疼的事情通常打印几十M的代码内容到记事本,所以与其找到VM的代码不如找没有VM的做一些HOOK，这样反而省事不少呢
呵呵，写了那么多心得,希望有共同研究的人可以加我的QQ一起学习,另外本人有一套软件,希望一些有实力的daili可以联系我
你这文章少了个转载吧？
怎么我在别的论坛都看见了
早看到过了，也不标明转载，不过还是支持下吧
Powered by
& 最好的辅助编程技术论坛