我们今天以实例来深入了解和分析一下 协yi请求漏洞导致的变态功能(无敌)以及如何安全应对。辅Zhu与反辅Zhu是相辅相成的,逆水行舟,不进则退。想做好一方面,必须也要精通你的背面。 以某两个网络游戏的无敌功能为例。(仅做技术交流) 一.泡泡堂 首先找到该游戏的发包函数,此游戏没有重新实现发包函数,直接send发送的加密包。我们说如果有无敌,不死的变态功能存在的话,一定会在发包的位置看到人物掉血包,人物死亡包或其他请求,因为如果没有这些对人物产生负面影响的请求的话,说明处理全在服务器,那么便不可能实现无敌,不死功能了。这是个必然的情况,因为无论是客户Duan还是服务端,总要有一个地方来计算这些结果数值。 明白了这个道理就很简单了。 我们在人物受到伤害的时候抓到请求。 可能有人会问,send位置发包比较频繁,很难抓到自己想要的请求,我们可以选择在send的位置hook来抓包,如果不懂hook,可以借助抓包工具总之我们是可以很容易抓到人物受到伤害的时候的请求的,这个游戏受到伤害就死亡了...也就是死亡请求。 send 头部下断 ,人物死亡请求是0x23包长的请求,虽然现在的请求是加密包,但是我们今天只是分析一个变态功能,并不需要去主动发送请求,所以不需要去找解密函数或则是明文包。 断下以后,我们通过函数调用关系返回找 人物死亡函数,只有在人物死亡的时候才会断下的函数,如果有多个这样的函数,选择第一个返回的即可,也就是最内层的即可,不懂为什么?因为最内层绕过了所有的条件判断, 最直接的实现功能 最内层死亡函数如下: push eax push 2 call 0095806D test eax, eax je short 007638B4 ; eax==0的时候跳转 跳过死亡CALL push -1 ; eax!=0的时候执行下去 人物死亡 push 3 lea ecx, dword ptr [ebp-44] call 00957FF4 lea ecx, dword ptr [ebx+5DFC] mov eax, dword ptr [ecx] push 1 call dword ptr [eax+C] mov esi, dword ptr [edi] mov ecx, ebx call 007665C9 push eax push dword ptr [ebp+8] mov ecx, edi push dword ptr [ebp-10] call dword ptr [esi+1F0] ; 人物死亡CALL push 4 lea ecx, dword ptr [ebp-44] call 00958039 or dword ptr [ebp-4], FFFFFFFF lea ecx, dword ptr [ebp-44] call 00957F3C call 00A4706C retn 4 我们有很多种选择 可以直接把死亡CALL NOP掉或则直接retn 。 可以把能跳过死亡CALL的跳转命令直接修改成JMP,如上文中的JE死亡判断。 也可以直接在send上下HOOK 如果包长为0x23 就不让其发送,当然在其他请求没有0x23的情况下,如果有相同的情况还要判断包头。 安全应对,既然知道了 整个的实现过程,分析起来也较为简单,根除的办法,扣血死亡判断放在服务器 考虑到游戏延时需求和服务器压力的话,就在关键点进行检测。 有什么不懂可以关注微信公众号:任鸟飞逆向 进行技术交流。
无敌效果图,如下人物和怪物相遇和被炸弹炸到都不会死亡了。 二.国内某知名ACT类型游戏 该游戏不同于泡泡堂的是,人物存在血量,而不是直接死亡,而且怪物掉血也会发包,所以我们在HOOK发包实现无敌的时候要区分人物自身和怪物 如果不从发包角度处理,那么就要找到 游戏的扣血函数,在扣血函数上做HOOK处理,但是不能直接NOP 或则跳过,因为那样,怪物也不掉血了... 这个游戏send 是不会直接断的,原因是重新写了send,那么在send的内层调用系统函数WSPsend上下断,直接可以返回重新写的send函数也就是真的发包函数 在通过发包函数,通过调用关系成功返回到扣血函数。 在函数上HOOK ,如果是人物直接返回,是怪物直接扣所有的血量,那么就实现了无敌和秒怪
|