|
|
声明：本文纯作者瞎掰，没有收集资料和进行实践。如果有任何与事实相违背的地方，请不要责怪。
经常玩对战地图的都知道，暴雪官方地图都有一个暴雪官方标志，在创建游戏项里选择地图或局域网游戏项里选择游戏主机都可以看到，拥有该标志的地图的地图名后面就是该标志。
我以前做过一个实验，用1.14版本的war3来建1.14之后出的官方地图。结果war3仍然能够识别出该地图是一个官方地图，并且给予它暴雪标志。
这说明了一个地图是否拥有暴雪标志并不是由war3决定，而是由war3map决定。
如果，你对一个拥有暴雪标志的地图进行任何的修改，都会导致该地图丢失暴雪标志。这说明了地图文件（也就是w3m|w3x文件）使用了数字签名技术。
下面介绍作者自以为的数字签名技术：
为了方便叙述，使用符号代替。
A：原始数据，C：签名数据
算法一：简陋的数字签名算法
函数f()是一个摘要算法（类似MD5，CRC，SHA-1算法，根据不定长度的数据得到定长的数据）
签名：C=f(A),
验证：B=f(A),check(B,C).
这个算法是个最差的签名算法了。
算法二：成熟的数字签名算法
签名：C=F(A),
验证：B=F1(A),D=F2(C),check(B,D)
其中D不能得到C，B不能得到A。
显然验证和签名之间有冲突：即可能把错误的签名验证为正确的签名，但是概率是相当低的。
这个算法防止了签名数据在内存中的明文对比。
但是设计这样一个成熟的数字签名算法如同设计RSA，DSA一样，需要高深的数学知识。
要把数字签名技术用到文件上面去，首先得在文件上找个地方存放签名数据C，它的地址通常是相对于文件的起始位置不变的，而且这个地址必须保证不为它用，仅用做存放签名数据C，一般这个地址在文件头里面。
一个支持数字签名的文件格式保存的数据显然分成了原始数据和签名数据。
当加密和和验证的时候都会忽略掉签名数据C，即不把签名数据C当作原始数据。
当修改支持数字签名的文件时，被修改的数据是原始数据或签名数据。无论作怎样的修改，都会导致原始数据和签名数据失去对应。这样就会失去正确的签名。
唯一的办法是，必须有函数F().在修改原始数据后，把签名数据数据也修改成F(A).
所以一个实际的数字签名算法是不公开的要不然就得借助中介机构（不属于本文讨论范围）。
在war3map文件头中恰好有这么一个unknow（不知道有什么用）区域。
下面是引用的文章“Inside the w3m files”中的一段。W3M/W3X Files Format
A W3M or W3X file is a Warcraft III Map file (AKA Warcraft III Scenario in the World Editor). It's just a MPQ (using a "new" compression format) with a 512 bytes header. Sometimes, for official W3M files, it uses a footer of 260 bytes for authentification purposes.
Here is the header format (fixed size = 512 bytes):
char[4]: file ID (should be "HM3W")
int: unknown
string: map name
int: map flags (these are exactly the same as the ones in the W3I file)
0x0001: 1=hide minimap in preview screens
0x0002: 1=modify ally priorities
0x0004: 1=melee map
0x0008: 1=playable map size was large and has never been reduced to medium
0x0010: 1=masked area are partially visible
0x0020: 1=fixed player setting for custom forces
0x0040: 1=use custom forces
0x0080: 1=use custom techtree
0x0100: 1=use custom abilities
0x0200: 1=use custom upgrades
0x0400: 1=map properties menu opened at least once since map creation
0x0800: 1=show water waves on cliff shores
0x1000: 1=show water waves on rolling shores
int: max number of players
followed by 00 bytes until the 512 bytes of the header are filled.
Here is the footer format (optional):
char[4]: footer sign ID (should be "NGIS" == 'sign' reversed)
byte[256]: 256 data bytes for authentification. I don't know how they are used at the moment.
byte[256]: 256 data bytes for authentification. I don't know how they are used at the moment.
翻译过来就是说：有256字节的数据被用做认可（authentification），我现在还不知道他们是怎么样被使用的。
显然这块区域应该是被用做数字签名的。C被我们找到了。
为了验证这个结论：我们要做实验
1，修改已经具备bj签名的war3map（比如对战地图）的C，发现该地图失去bj签名。
2，修改不具备bj签名的war3map的C（比如自己作的图），发现没有任何效果。
3，不同的具备bj签名的war3map的C一定是不同的。
4，不同的不具备bj签名的war3map的C可能是相同的。
D=F（C）。根据BJ的编程风格，这里的D多半是个无符号32位整数。
大公司的程序代码在内部基本上是通用的，如bj对mpq文件格式的使用。
在war3中还有对地图文件进行摘要的地方。为了减少编程工作量，这个地方可能也会用到F1()或是F()函数.这个地方就是war3存档文件。
每一个存档文件都对应了一个被存档的地图。如果被存档的地图有任何的改变，那么对不起，存档无法使用。
为了知道到底bj在存档文件中用的摘要函数是否就是F()或F1()。我们可以做实验。
每次开始游戏请使用相同玩家名、种族等参数。
开始一个地图（M1），进入游戏后立即进行存档，得到存档文件（S1）。
修改地图（M1）中的C得到地图（M2），再进入游戏立即存档，得到存档文件（S2）。
如果S1和S2都差不多，或是S1可以用M2读图，S2可以用M1读图。那么恭喜吧。
获取SB在存档文件（S）中的位置。
这个要麻烦一点，我们需要存档文件的格式分析，目前还没有任何文章是关于该文件格式的分析。
我们需要自己去分析，如同文章“Inside the w3m files”的作者分析war3map文件格式一样。
同样会得到一个unknow区域，这个区域应该属于文件头。一个存档文件，修改其他区域可能能够读图成功，也可能失败，但绝对不会出现，找不到被存档的地图的提示。相反，修改该unknow区域，我们读图的时候一定能够得到一个这样的提示。
这个区域就是SB，也就是对原始数据的摘要。
只要bj在存档文件中用的摘要函数就是F()或F1()，那么我们就成功了一半。
如果SB=C：（我们一脚跨入成功大门了）
我们可以对任意想要添加bj标志的地图进行存档，然后从存档文件中获得SB，然后把SB直接写到原来的地图文件中的C处。这样就获得了bj标志。
当然如果是这样的话，对一个已经有bj标志的地图存档，得到的SB和原地图中的C是一致的，我们可以根据这样来验证SB=C是否成立。
如果SB！=C
请止步吧...这些是cracker或hack的工作
其他本人中未论述到的情况都不利于我们取得bj标志。这里就不在叙述了。
本文是本人是半夜睡不着乱想的一点东西，害怕本人会忘记了，所以存水区一份。
看不惯的请忍之。 |
|
窥视卡
雷达卡
发表于 2006-12-30 10:24:53
提升卡
置顶卡
沉默卡
喧嚣卡
±????¨
千斤顶
???í?¨
