WPE|52wpe|我爱WPE

 找回密码
 注册会员
搜索
  • 1281查看
  • 0回复

[转贴] 转载

主题

好友

-2

积分

乞丐

发表于 2015-4-10 21:43:53 |显示全部楼层
现在我们开始!首先,你要知道游戏中储存数据的几种格式,这几种格式是:字节(BYTE)、字(WORD)和双字(DOUBLE WORD),或者说是8位、16位和32位储存方式。字节也就是8位方式能储存0~255的数字;字或说是16位储存方式能储存0~65535的数;双字即32位方式能储存0~4294967295的数。  


 


       为何要了解这些知识呢?在游戏中各种参数的最大值是不同的,有些可能100左右就够了,比如,金庸群侠传中的角色的等级、随机遇敌个数等等。而有些却需要大于255甚至大于65535,象金庸群侠传中角色的金钱值可达到数百万。所以,在游戏中各种不同的数据的类型是不一样的。在我们修改游戏时需要寻找准备修改的数据的封包,在这种时候,正确判断数据的类型是迅速找到正确地址的重要条件。  


  在计算机中数据以字节为基本的储存单位,每个字节被赋予一个编号,以确定各自的位置。这个编号我们就称为地址。


在需要用到字或双字时,计算机用连续的两个字节来组成一个字,连续的两个字组成一个双字。而一个字或双字的地址就是它们的低位字节的地址。  


现在我们常用的Windows 9x操作系统中,地址是用一个32位的二进制数表示的。而在平时我们用到内存地址时,总是用一个8位的16进制数来表示它。  


二进制和十六进制又是怎样一回事呢?  


  简单说来,二进制数就是一种只有0和1两个数码,每满2则进一位的计数进位法。同样,16进制就是每满十六就进一位的计数进位法。16进制有0--F十六个数字,它为表示十到十五的数字采用了A、B、C、D、E、F六个数字,它们和十进制的对应关系是:A对应于10,B对应于11,C对应于12,D对应于13,E对应于14,F对应于15。而且,16进制数和二进制数间有一个简单的对应关系,那就是;四位二进制数相当于一位16进制数。比如,一个四位的二进制数1111就相当于16进制的F,1010就相当于A。  


       了解这些基础知识对修改游戏有着很大的帮助,下面我就要谈到这个问题。由于在计算机中数据是以二进制的方式储存的,同时16进制数和二进制间的转换关系十分简单,所以大部分的修改工具在显示计算机中的数据时会显示16进制的代码,而且在你修改时也需要输入16进制的数字。你清楚了吧?  


  在游戏中看到的数据可都是十进制的,在要寻找并修改参数的值时,可以使用Windows提供的计算器来进行十进制和16进制的换算,我们可以在开始菜单里的程序组中的附件中找到它。  


  现在要了解的知识也差不多了!不过,有个问题在游戏修改中是需要注意的。在计算机中数据的储存方式一般是低位数储存在低位字节,高位数储存在高位字节。比如,十进制数41715转换为16进制的数为A2F3,但在计算机中这个数被存为F3A2。  


看了以上内容大家对数据的存贮和数据的对应关系都了解了吗? 好了,接下来我们要告诉大家在游戏中,封包到底是怎么一回事了,来!大家把袖口卷起来,让我们来干活吧!

二:什么是封包?  

怎么截获一个游戏的封包?  

怎么去检查游戏服务器的ip地址和端口号?  

   Internet用户使用的各种信息服务,其通讯的信息最终均可以归结为以IP包为单位的信息传送,IP包除了包括要传送的数据信息外,还包含有信息要发送到的目的IP地址、信息发送的源IP地址、以及一些相关的控制信息。当一台路由器收到一个IP数据包时,它将根据数据包中的目的IP地址项查找路由表,根据查找的结果将此IP数据包送往对应端口。下一台IP路由器收到此数据包后继续转发,直至发到目的地。路由器之间可以通过路由协议来进行路由信息的交换,从而更新路由表。  

       那么我们所关心的内容只是IP包中的数据信息,我们可以使用许多监听网络的工具来截获客户端与服务器之间的交换数据,下面就向你介绍其中的一种工具:WPE。  

WPE使用方法:  

执行WPE会有下列几项功能可选择:  


       NETSTAT命令的功能是显示网络连接、路由表和网络接口信息,可以让用户得知目前都有哪些网络连接正在运作。或者你可以使用木马客星等工具来查看网络连接。工具是很多的,看你喜欢用哪一种了。  

NETSTAT命令的一般格式为:  

NETSTAT [选项]  

命令中各选项的含义如下:  

-a 显示所有socket,包括正在监听的。  

-c 每隔1秒就重新显示一遍,直到用户中断它。  

-i 显示所有网络接口的信息。  

-n 以网络IP地址代替名称,显示出网络连接情形。  

-r 显示核心路由表,格式同"route -e"。  

-t 显示TCP协议的连接情况。  

-u 显示UDP协议的连接情况。  

-v 显示正在进行的工作。

三:怎么来分析我们截获的封包?  

       首先我们将WPE截获的封包保存为文本文件,然后打开它,这时会看到如下的数据(这里我们以金庸群侠传里PK店小二客户端发送的数据为例来讲解):  

第一个文件: 复制内容到剪贴板 代码:SEND-> 0000 E6 56 0D 22 7E 6B E4 17 13 13 12 13 12 13 67 1B  

SEND-> 0010 17 12 DD 34 12 12 12 12 17 12 0E 12 12 12 9B  

SEND-> 0000 E6 56 1E F1 29 06 17 12 3B 0E 17 1A  

SEND-> 0000 E6 56 1B C0 68 12 12 12 5A  

SEND-> 0000 E6 56 02 C8 13 C9 7E 6B E4 17 10 35 27 13 12 12  

SEND-> 0000 E6 56 17 C9 12  第二个文件: 复制内容到剪贴板 代码:SEND-> 0000 83 33 68 47 1B 0E 81 72 76 76 77 76 77 76 02 7E  

SEND-> 0010 72 77 07 1C 77 77 77 77 72 77 72 77 77 77 6D  

SEND-> 0000 83 33 7B 94 4C 63 72 77 5E 6B 72 F3  

SEND-> 0000 83 33 7E A5 21 77 77 77 3F  

SEND-> 0000 83 33 67 AD 76 CF 1B 0E 81 72 75 50 42 76 77 77  

SEND-> 0000 83 33 72 AC 77  我们发现两次PK店小二的数据格式一样,但是内容却不相同,我们是PK的同一个NPC,为什么会不同呢?  

       原来金庸群侠传的封包是经过了加密运算才在网路上传输的,那么我们面临的问题就是如何将密文解密成明文再分析了。  

因为一般的数据包加密都是异或运算,所以这里先讲一下什么是异或。  

   简单的说,异或就是"相同为0,不同为1"(这是针对二进制按位来讲的),举个例子,0001和0010异或,我们按位对比,得到异或结果是0011,计算的方法是:0001的第4位为0,0010的第4位为0,它们相同,则异或结果的第4位按照"相同为0,不同为1"的原则得到0,0001的第3位为0,0010的第3位为0,则异或结果的第3位得到0,0001的第2位为0,0010的第2位为1,则异或结果的第2位得到1,0001的第1位为1,0010的第1位为0,则异或结果的第1位得到1,组合起来就是0011。异或运算今后会遇到很多,大家可以先熟悉熟悉,熟练了对分析很有帮助的。  

   下面我们继续看看上面的两个文件,按照常理,数据包的数据不会全部都有值的,游戏开发时会预留一些字节空间来便于日后的扩充,也就是说数据包里会存在一些"00"的字节,观察上面的文件,我们会发现文件一里很多"12",文件二里很多"77",那么这是不是代表我们说的"00"呢?推理到这里,我们就开始行动吧!  

   我们把文件一与"12"异或,文件二与"77"异或,当然用手算很费事,我们使用"M2M 1.0 加密封包分析工具"来计算就方便多了。得到下面的结果:  

第一个文件: 复制内容到剪贴板 代码:1 SEND-> 0000 F4 44 1F 30 6C 79 F6 05 01 01 00 01 00 01 75 09  

SEND-> 0010 05 00 CF 26 00 00 00 00 05 00 1C 00 00 00 89  

2 SEND-> 0000 F4 44 0C E3 3B 13 05 00 29 1C 05 08  

3 SEND-> 0000 F4 44 09 D2 7A 00 00 00 48  

4 SEND-> 0000 F4 44 10 DA 01 DB 6C 79 F6 05 02 27 35 01 00 00  

5 SEND-> 0000 F4 44 05 DB 00第二个文件: 复制内容到剪贴板 代码:1 SEND-> 0000 F4 44 1F 30 6C 79 F6 05 01 01 00 01 00 01 75 09  

快速发帖

您需要登录后才可以回帖 登录 | 注册会员

手机版|Archiver|WPE|52wpe|我爱WPE ( 闽ICP备15009081号 )

GMT+8, 2024-4-29 06:30 , Processed in 0.058636 second(s), 16 queries .

返回顶部