MPQ hash

需要引用的内容是一些前辈通过黑客技术,逆向工程,反汇编技术等等方法所获得的,由于某种非人力不可抗拒因素,这里不能列出他们的名字,抱歉!
...
MPQ文件是一种压缩包(pack)格式,它可以单独存在如*.mpq,也可以寄存在其他文件中如*.w3m,*.w3x
它有一个标准的32byte的header:
CODE:
struct TMPQHeader
{
   DWORD dwMpqFlag;
   DWORD dwHeaderSize;   
   DWORD dwArchiveSize;
   USHORT wFormatVersion;
   USHORT wBlockSize;
   DWORD dwHashTablePos;
   DWORD dwBlockTablePos;
   DWORD dwHashTableSize;
   DWORD dwBlockTableSize;
};

其中dwMqpFlag是一个常量,它的值为'MPQ',用来定位MPQ在寄主文件中的文件头位置。这个地址将作为MPQ包的基地址。
MPQ使用HashTable-BlockTable来定位一个文件在MPQ包中的位置,当然它们是经过确定密钥加密后放如MPQ包中的,以逃脱明文存放的危险。
在MPQ中的加密算法分两种:
1),摘要加密:把不定长度数据转化为定长的数据,hash算法得到一个DWORD
2),对称加密:把不定长度数据按DWORD转换为同样长度的数据。
上面两种加密在MPQ中会用到密钥,以确保Hash算法的更不可预料性和对称加密的密钥。
MPQ使用的密钥有5组,每组密钥(长0x100个DWORD)被全部用于某次加密。密钥是确定的,是可以在加密之前计算出来并且保持不变的常量。计算方法相当有规律:
CODE:
DWORD cryptTable[0x500]
void prepareCryptTable()
{
   DWORD dwHih, dwLow,seed = 0x00100001,index1 = 0,index2 = 0, i;
   for(index1 = 0; index1 < 0x100; index1++)
   {
for(index2 = index1, i = 0; i < 5; i++, index2 += 0x100)
{
       seed = (seed * 125 + 3) % 0x2AAAAB;
       dwHih= (seed & 0xFFFF) << 0x10;
       seed = (seed * 125 + 3) % 0x2AAAAB;
       dwLow= (seed & 0xFFFF);
       cryptTable[index2] = (dwHih| dwLow);
}
   }
}

然后就可以使用MPQ中的加密函数了。
CODE:
DWORD HashString(char *lpszFileName,DWORD dwCryptIndex)
{
   unsigned char *key = (unsigned char *)lpszFileName;
   DWORD seed1 = 0x7FED7FED, seed2 = 0xEEEEEEEE;
   int ch;
   while(*key != 0)
   {
ch = toupper(*key++);
seed1 = cryptTable[(dwCryptIndex<< 8) + ch] ^ (seed1 + seed2);
seed2 = ch + seed1 + seed2 + (seed2 << 5) + 3;
   }
   return seed1;
}

这个Hash函数被用来Hash一个filename根据密钥0,密钥1,密钥2获得三个Hash:Hash,Hash1,Hash2.
其中Hash被用来在HashTable中定位。Hash%HashTableSize就是索引。
CODE:
struct TMPQHash
{
   DWORD dwHash1;
   DWORD dwHash2;
   USHORT lcLocale;
   USHORT wPlatform;
   DWORD dwBlockIndex;//0xFFFFFFFEh,0xFFFFFFFFh表示该HashItem无效.
};

当然很可能几个不同的filename对应到了一个索引,这时就依靠Hash1,Hash2来校验。
只要找到Hash1和Hash2都符合的HashItem就读取BlockIndex并进入BlockTable,否则校验下一个HashItem。由此 可见MPQ的设计比较科学!如果检查一个MPQ中不存在的filename是否在MPQ包中,花费的时间是相当可观的,将会查询完整个 HashTable。

struct TMPQBlock
{
DWORD dwFilePos;
DWORD dwCSize;
DWORD dwFSize;
DWORD dwFlags;
};

只在BlockTable中才纪录了有用的信息。把BlockTable和HashTable分离开,这充分体现了MPQ设计的科学性:如果把任何一个BlockItem中的属性放到HashTable中都会降低MPQ的安全性。
到这儿整个文件的定位工作就完了,下面仅仅需要根据Flags来分析文件采用的存储方式:
默认密钥加密,种子带文件长度和文件名修正的加密;
PKware压缩,Wave压缩,多方式压缩,不压缩。

前言:其实一年前研究mpq加密的时候就有这个想法,后来对加密失去兴趣,没有应用而已。 先从mpq读取(和写入)说起。市面上的软件大致有以下几种方法: 0.listfile式。0这个数字说明了它的原始。如果mpq没有用listfile明确叙述自己的文件组成,它就无法读取其中的文件。怎么说呢,这就好像只要犯人不招认,自己也认为犯人无罪的笨蛋侦探一样,严谨到无聊。典型例子不是别人,正是大名鼎鼎的WorldEditor地图编辑器。对付这种软件,删掉listfile就一切安好。 1.小白式。这种软件基本上用自制的dll(因为暴雪只提供了读mpq的storm.dll,没有写入),按照mpq文件格式非常循规蹈矩地一步步读出内容。问题在于mpq数据稍有不对就会导致崩溃。例如headermpq文件大小这项数据,war3读地图的时候根本不管,所以怎么写都不影响地图工作,但这类工具却会照着此数据读图,然后掉进番茄海的无底深渊。 典型例子是winmpqmpqmaster。 2.storm式。以火龙hke为代表。这类mpq软件用暴雪提供的storm.dll读取mpq,读取方式和暴雪一致。由于mpq文件被设计成“知道文件名(含路径)可以很容易读取,但扫描所有文件路径却几乎不可能”的格式,war3在读地图时只用在需要的时候读指定文件就ok,所以这类编辑器也模拟war3读地图的方式,逐渐推算出“需要的文件”从而读出地图中近乎全部文件,只要在物编中涉及到或jass中提及的路径,都会检测对应的文件并列在表中。这是一种近乎无敌的方法,不会报错(否则war3也玩不了这图),且war3map.j等固定文件必然被扫描出来(否则war3自己也找不到)。 然后是重点: 但这里有个致命问题——不管是火龙还是war3,不可能预知到游戏过程中全部的文件读取,更确切说,全部的字符串。如果字符串是明文写在脚本中,如“sound\\aaa.mp3”,那么火龙会认为这可能是个文件,然后顺藤摸瓜找到它。但如果写成“sound\\” + “aaa.mp” + I2S(3)等甚至加上存取哈希表动作,火龙或任何软件也无法完全预知。这种不可预测是理论级的,即“图灵机无法预测另一台图灵机的全部可能状态”,等价于著名的“停机问题”,而停机问题是“理论不可计算”的。所以在游戏中虽然能正常听到音乐(或看到特效等),但火龙却无法提前知道这个文件的存在。 样例的图中正是这样,隐藏了一个2m+的mp3文件,但火龙却只能读出一大打war3map.xxx。 然后这种方法也能隐藏其它文件,但无法隐藏在物编中使用到的文件(如被某单位使用的导入模型)、地图必备文件(如j)和覆盖原路径文件(如替换的载入图片)。 3.hash扫描式。但是还没完,还有一种方式,某些软件绕过mpq前面的哈希索引表,直接扫描后面的文件,这样虽然不能知道文件名,但能得到完整的文件列表(再怎么说文件也是封在mpq里的吧,把mpq整个扫一遍总能发现)。例子是新版mpqeditor,样例图和某人提供的火影图都能打开,能看到一堆没有文件名的文件,其中就有隐藏的mp3,改成mp3扩展名就能正常播放。这种方式应该没什么弊端(除了得不到正确文件名),如果和火龙结合,用上述方法隐藏的文件也能以“未知名文件”的形式显示出来,其他文件则完美显示。 所以mpq这种文件格式终究逃不过被拆的厄运,想完美隐藏文件果然是不可能的事情。全文完。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值