如果一款程序,在动手之前,就能知道个大概,调用了哪些关键API,用户交互流程是怎样,有信心,逆向最多就只是困难,而不是不可及的事情了。
我只参与一款外挂的制作,但相比其他的外挂,更用心。不是找找漏洞,找个Call 就了事的,游戏地图,AI,游戏自身控制流程,才是有意思的。从OD的反汇编上有时能清楚的看到整个程序的流程。
     我这款游戏的流程或许是最简单不过的,按键消息->响应处理->协议填充->Send(),反过来Recv()->协议处理->功能调用。如此简单的流程,我想任何人都知道直接从Send,Recv 入手,一旦被加密的数据包被接收到,一般来说就是立即解密,所以加解密也能花点时间就出来了。一个规则的数据包,都是包大小+类型代码+实际数据,类型代码一般是有的,而客户端解析数据包又只是个switch,一个超长的函数中就包括了所有的功能调用,再根据功能解析数据的数据,那也只是时间问题。
     这是个非常简单的模型,你切入的时候可能不会像我说的这么容易,但所有游戏的输入输出无非都要通过send、recv。输入无非是键盘、鼠标,任何一方面都能成为切入点。
简单的模型下,用户输入与输出(send)在一个调用序列中,这种是最容易的。
      我说的这个模型很简单,似乎没什么技术含量,实际中,游戏客户端可能会加入超多内联函数,不用switch,采用call [eax*??]的形式,反正就是让你看着心烦,或许我们需要更好的技巧,以前我是硬着头皮啃下这些代码,现在头没那么晕乎了。
      这些反汇编代码都还是明文,只要有心都还啃的下去。
      有些程序加上虚拟机,光调试都成问题,反汇编更是不知所云。这也罢,水平不足,就另取蹊径。
      说道这里,看一下整个外挂,对于游戏的切入点。加解密,可由Send、Recv入手。功能调用,可由Recv、Send、或者键盘、鼠标相关调用入手。数据包中的协议功能。则由解密后的数据包追踪着手。
      地图方面,缺少dx9的相关知识,只能猜测,或许从地形高度图、碰撞检测着手。这些又和移动包相互关联。当然了用户点击移动->图形引擎处理->碰撞检测->发送数据包。流程一般不会变。能否追踪到自己需要的东西,就看个人能力了。
      最初,超长的反汇编代码,不知道哪里是关键所在,我就使用强制跳转(跳转 改jmp),NOP掉函数调用,用来查看关键代码。耐心是很重要的,基本上不费什么脑力。。。
      漏洞方面,一般是从逆向过程中发掘的,如果你觉得某个处理流程或者数据结构有可疑,它就很可能是个漏洞。比如你发现他的移动包都是每秒不超过4个,每个包之间不超过20的距离,如此精心构造的包,可能就是服务器害怕压力,将部分验证简单化。有些漏洞则是游戏很难避免的,比如CS中的透视能力。所有基于dx的游戏都应该存在,同时基于3D地图的Z坐标运算,服务器也不可能实时验证。
     你能从逆向过程中看到程序的先天不足,和他的精妙之处,真是非常的有意思。
     能最广的了解各方面知识的基本原理,对逆向是大有益处。