[译] MoPaQ归档格式

MoPaQ归档格式

© 2006-2010 Justin Olbrantz (Quantam) and Jean-Francois Roy (BahamutZERO). All Rights Reserved.

在不修改本文的前提下对本文的散发和复制没有任何限制；但希望能够提供本文的链接以使每个人都能够看到最新的版本。在其他地方允许自由引用本文的内容，但请附上来源以及原作者。

内容

• 1 MoPaQ格式简介
• 2 MoPaQ格式
  • 2.1 一般归档布局
  • 2.2 档案头部
  • 2.3 块表
  • 2.4 扩展块表
  • 2.5 散列表
  • 2.6 扩展属性
  • 2.7 文件数据
  • 2.8 列表文件
  • 2.9 弱数字签名
  • 2.10 强数字签名 - 概要
  • 2.11 强数字签名 - 细节
  • 2.12 自定义数据
    • 2.12.1 自定义数据文件
• 3 算法源代码
  • 3.1 加密／解密
  • 3.2 散列与文件密钥的计算
  • 3.3 FILETIME与time_t的转换
  • 3.4 FILETIME与NSDate的转换
  • 3.5 从32位与16位值构建64位大档案相对地址
  • 3.6 扇区校验
  • 3.7 查找文件
  • 3.8 删除文件
• 4 常量
  • 4.1 区域编码

MoPaQ格式简介

MoPaQ（或MPQ）格式是暴雪娱乐的Mike O'Brien（取名来自Mike O'brien PaCK）所设计的一种档案文件。该格式已被用于了从暗黑破坏神开始到目前为止暴雪所有的游戏。它是一种高度优化了的只读游戏归档格式，并在此方面表现得很出色。

暴雪的MoPaQ读取函数已经被包含在了各种静态的或者动态链接的Storm模块中，而通常暴雪的MoPaQ写入函数仅仅被包含于总是被静态链接的MPQAPI模块中；不过在星际争霸2里，Storm模块也已经包含了MoPaQ写入函数。

StormLib - 由Ladislav Zezula（非暴雪娱乐的员工）编写的一个开源的MoPaQ读写库，在该领域已经研究了很长时间了。由于有段时间没有更新了，它还不支持所有新的MoPaQ特性。但是它包含了MoPaQ所使用的压缩算法的实现代码，诸如PKWare Implode算法、MoPaQ霍夫曼压缩算法、以及MoPaQ使用的IMA ADPCM压缩。

MoPaQ格式

MoPaQ格式中所有的数字都采用小端存储；带符号数采用补码表示形式。数据类型被表示为int（整数，后跟位数）、byte（8位）或者char（存有ASCII字符的字节）。所有的大小和偏移若无特殊说明则都以字节数为单位。结构体成员会以以下形式列出：

相对于结构体开始的偏移: 数据类型(数组大小) 成员名称 : 成员描述

 

一般归档布局

• 档案头部
• 文件数据
• 文件数据 - 特殊文件
• 散列表
• 块表
• 扩展块表
• 强数字签名

这只是一般性的档案布局，但它并不是绝对的。已经发现有些档案的散列表和块表被放在档案头部之后、文件数据之前。

但是从星际争霸2开始，要求块表必须紧跟在散列表之后。

档案头部

00h: char(4) Magic             标志着该文件是一个MoPaQ档案。必须为ASCII "MPQ" 1Ah。04h: int32 HeaderSize          档案头部的大小。08h: int32 ArchiveSize         整个档案的大小，包含其头部，且不包含强数字签名。                               该大小是用来确定数字签名进行散列计算的区域的。                               该字段在燃烧远征MoPaQ格式中已被废弃，                                而是用从档案的开头到散列表、块表或者扩展块表的末尾（取值最大的那个）来计算。0Ch: int16 FormatVersion       MoPaQ格式的版本号。如果该值为负MPQAPI会打开失败。已知的版本有：0000h                  原始版本。HeaderSize应为20h，且不支持大尺寸档案。0001h                  燃烧远征格式。HeaderSize应为2Ch，支持大尺寸档案。0Eh: int8 SectorSizeShift      该档案中每个逻辑扇区所占用的磁盘扇区（512字节）数，为2的幂指数形式。                               档案中每个逻辑扇区的大小等于512 * 2^SectorSizeShift.                                由于Storm库的Bug，该值只能是3（4096字节的扇区）.10h: int32 HashTableOffset     散列表起始位置的偏移，相对于档案的开始处。14h: int32 BlockTableOffset    块表起始位置的偏移，相对于档案的开始处。18h: int32 HashTableEntries    散列表的入口数。必须是2的整数幂，且在原始MoPaQ格式中小于2^16，在燃烧远征格式中小于2^20。1Ch: int32 BlockTableEntries   块表的入口数。从燃烧远征起新增的字段：20h: int64 ExtendedBlockTableOffset   扩展块表起始位置的偏移，相对于档案的开始处。28h: int16 HashTableOffsetHigh        大尺寸档案的散列表偏移值的高16位。2Ah: int16 BlockTableOffsetHigh       大尺寸档案的块表偏移值的高16位。

档案头部是档案中的第一个结构体，位于档案的偏移0位置处；不过档案本身不一定非要从其所属文件的0偏移处开始。档案相对于所属文件本身的偏移量被存在ArchiveOffset里。如果档案不是从文件开头处开始的话，则必须从一个磁盘的扇区边界处（512字节）起始。早期版本的Storm要求档案必须位于所属文件的尾部（ArchiveOffset + ArchiveSize = 文件大小），不过在较新的版本中该要求已经不复存在（也是由于强数字签名并不被认为是档案的一部分）。

块表

块表包含了档案中每个区域的入口信息。区域可以是单一文件、空闲空间或者不被使用的块表入口。空闲空间可以用来覆盖写入新文件（通常该空间是由删除的文件数据产生的）。空闲空间入口的BlockOffset和BlockSize不能为0，而同时FileSize与Flags必须为0; 块表是被加密了的，可以用"(block table)"的散列值作为密钥解密。每个入口的结构如下：

00h: int32 BlockOffset   块开始位置的偏移，相对于档案的起始位置。04h: int32 BlockSize     块在档案中占用空间的大小。08h: int32 FileSize      块中所存储文件数据的大小。仅当块是一个文件的时候才有效，否则无意义，应置0。                         如果文件是被压缩了的，则该值为解压后的文件大小。0Ch: int32 Flags         该块的标志掩码。已确定有以下的值：80000000h        该块是一个文件，且其他各标志位表示文件数据的格式；否则该块是空闲空间或者未被使用。                         如果该块不是一个文件，则其他所有标志必须清位，FileSize应为0。04000000h 文件的每个扇区都带有校验码（将在文件数据一节中解释）。如果文件既未被压缩又未被Implode则忽略该标志。        02000000h        文件是一个删除标记，表示该文件已不再存在。                         这使得补丁档案可以删除查找链上优先级较低的档案中的文件。01000000h        文件被作为一个整体保存，而不是分成若干扇区。00020000h        该文件的密钥是经过块偏移和文件大小校正的（将在文件数据一节中详细介绍）。                         文件必须被加密。00010000h        文件被加密。00000200h        文件被压缩，不可Implode。00000100h        文件被Implode. 不可压缩。

扩展块表

扩展块表是为了让档案能够支持大于4GB（2^32字节）而新增的。该表储存了块表中每个块的档内偏移的高位。它仅仅是一个简单的int16数组，存储着每个块的档内偏移的第32-47位，第48-63将固定被认为是0。档案中每个单独的块仍然有4GB大小的限制。该表仅存于燃烧远征中超过4GB的档案里。

不同于散列表和块表，扩展块表既没有被加密也不带压缩。

散列表

为了能够高速访问MoPaQ，不使用文件名而是采用一个大小为2的整数幂的散列表来索引。一个文件根据其文件路径、语言和平台将得到唯一的标识。

文件在散列表中的起始入口（home entry）为其路径的散列值。当发生冲突时（起始入口已经被另一个文件所使用）采用顺序溢出（progressive overflow）方式，文件将被放在下一个可用的散列表入口里。搜索文件时需从起始入口开始遍历散列表，直到文件被找到，或者已到达散列表的末尾，亦或者遇到一个空的散列表入口（FileBlockIndex为FFFFFFFFh）。

散列表总是加密了的，其密钥为"(hash table)"的散列值。

在星际争霸2之前，散列表是没有被压缩的。但在星际争霸2里该表可能会被压缩。如果块表的偏移不等于散列表的偏移加上其未压缩大小，星际争霸2会认为散列表是被压缩了的（不是被Implode）。该计算方法假设了块表是紧跟在散列表之后的，否则可能会失败或者宕掉。

每个入口都有如下的结构：

00h: int32 FilePathHashA    使用A方法计算的文件路径的散列值。04h: int32 FilePathHashB    使用B方法计算的文件路径的散列值。08h: int16 Language         文件的语言。这是一个Windows LANGID数据类型，并使用与其相同的值定义。                            0表示默认语言（美国英语），或者该文件语言无关。0Ah: int8 Platform          该文件所用于的平台。0表示默认平台。没有检测到其他值的出现。0Ch: int32 FileBlockIndex   如果散列表入口有效，则为文件对应的块表的索引。                            否则为如下的两个值：FFFFFFFFh           散列表入口为空，并且总是为空，中止对指定文件的搜索。FFFFFFFEh           散列表入口为空，但是在某个时候是有效的（换而言之，该文件被删除了），                            不中止对指定文件的搜索。

扩展属性

扩展属性可以为块表中的文件提供可选的文件属性。这些属性是在MoPaQ已经完全固化之后加入的，且并非所有的档案都需要有全部的（也可以完全没有）扩展属性。如果一个档案含有某项属性，那么该档案的块表中的每一个块都将含有一个属性实体, 尽管对于非文件的块这并没有意义。块属性的次序和块表中的块的次序是对应的，且个数也一致。这些属性以一维数组的形式保存在档案的"(attributes)"文件中（使用默认语言和平台）。同时此文件对应的属性不需要有效（逻辑上也不能有效）。与MoPaQ格式中所有其他结构不同，扩展属性中的入口可以不必对齐。同时需要注意在某些档案中发现故意设置的全零属性，大概是为了干扰破解而做的吧。该文件具有以下结构：

00h: int32 Version :           指定扩展属性的格式版本。目前只能是100。04h: int32 AttributesPresent : 档案中的扩展属性标识位掩码：00000001h: 文件的CRC32。00000002h: 文件时间戳。00000004h: 文件的MD5。08h: int32(BlockTableEntries) CRC32s :   档案中每个块的文件数据（未压缩的）的CRC32值。                                         如果档案不含CRC32则忽略。FILETIME(BlockTableEntries) Timestamps : 档案中每个块的时间戳。其格式为Windows FILETIME结构体。                                         如果档案不含时间戳则忽略。MD5(BlockTableEntries) MD5s :            档案中每个块的文件数据（未压缩的）的MD5值。                                         如果档案不含MD5则忽略。

文件数据

每个文件的数据都有以下结构组成：

int32(SectorsInFile* + 1) SectorOffsetTable  每个扇区相对于文件数据开始处的偏移。                                             最后一个入口包含的是整个文件压缩后的大小，                                             使得仅仅使用简单的减法运算就能轻易算出任何扇区的大小。                                             如果文件未被压缩则不存在也不需要该表。SECTOR Sectors(SectorsInFile)                文件中每个扇区的数据，一个挨一个地放置（具体见下面的描述）。

通常地，文件数据被切割成若干个扇区，以便于简单的流式访问。除了最后一个以外的所有扇区，每个的大小应该与档案头部的SectorSizeShift字段所指定的大小相等；而最后一个扇区则可能比它小，其大小依赖于整个文件的尺寸。但如果文件是被压缩的或者Implode的，扇区会比起实际包含的文件内容要小。当且仅当扇区内容无法被压缩算法压缩时（压缩后的扇区大小大于等于原文件数据大小），保存在压缩或Implode文件中的扇区数据是未经压缩的；此时SectorOffsetTable中该扇区的大小等于扇区中文件数据的大小（可以从FileSize计算得到）。

扇区如果带校验码，校验码会保存在文件末尾的一个附加扇区里，因此这样的文件的扇区表中会有一个附加入口；但是与文件中其他的扇区不同，该扇区总是被压缩（不是被Implode）且不带加密。该扇区由校验码的数组组成，对应于文件的每个扇区，但不包含校验码扇区本身。每个校验码都是从一个压缩的且未加密的的扇区计算得来的；想知道扇区校验的实现细节请参见下面的VerifySectorChecksum函数。

每个扇区的格式取决于其类型。无压缩扇区只是简单地存放了原始的文件数据。Implode扇区则存放了原始压缩数据经过Implode算法压缩后的结果（这些扇区仅存于Implode文件）。压缩扇区（仅限于压缩且非Implode的文件）则被一种或者多种压缩算法所压缩，并带有以下结构：

byte CompressionMask : 该扇区使用的压缩类型的掩码。byte(SectorSize - 1) SectorData : 该扇区的压缩数据。

CompressionMask指出了该压缩扇区采用的是何种压缩算法。该字节也被计算在整个扇区的大小之内，并且如果该扇区的数据被压缩后的大小不足两个字节的话，数据将以未压缩的形式存放；换句话说，也就是说压缩后的结果至少要有一个字节的大小。另外，该字节也会和扇区数据一起被加密。有如下可用的算法被定义（参见StormLib获取具体的算法实现）：

20h: Sparse压缩。星际争霸2新增。40h: 单声道IMA ADPCM80h: 立体声IMA ADPCM01h: 霍夫曼编码02h: Deflate压缩（参见ZLib）。魔兽争霸3新增。08h: Implode（参见PKWare Data Compression Library）10h: BZip2压缩（参见BZip2）。魔兽世界：燃烧远征新增。

在星际争霸2之前，该字节为其所使用算法的标志位掩码的组合。可以组合的算法在压缩时会按照上述列表的顺序执行压缩，而在解压时则按照其逆序执行。

而在星际争霸2中，该字节已经被合起来看成是一个大的查找表的索引，根据其对应的值被解释为一个或者两个不同的压缩算法的组合。算法也不再是按位的组合，而必须是某个有效列表指出的组合；尤其是一些压缩类型（比如Deflate和Implode）现在是互斥的，并且必须和另一个数值较小的算法相组合（例如IMA ADPCM），而这些小数值算法之间又是互斥的。这里有一个例外（12h），它并不是两种算法的组合，而是一种单一的新算法（LZMA）。这里是各种有效组合的列表：

12h: LZMA压缩。星际争霸2新增。22h: Sparse压缩 + Deflate30h: Sparse压缩 + BZip241h: 单声道IMA ADPCM + 霍夫曼编码48h: 单声道IMA ADPCM + Implode81h: 立体声IMA ADPCM + 霍夫曼编码88h: 立体声IMA ADPCM + Implode

如果文件被作为一个整体保存（在其文件标志中指出），则只有一个扇区并保存了整个文件的数据。

如果文件被加密，则每个扇区（压缩／Implode之后）都使用该文件的密钥进行加密。文件的基础密钥（base key）由其路径的文件名部分的散列值（不包含目录部分，例如"directory/file"的密钥是"file"的散列值）来决定的。如果文件标志中指出密钥是经过校正的，则最终的密钥是由((基础密钥 + BlockOffset) XOR FileSize)计算得出的。每个扇区都使用(密钥 + 扇区在文件中从0开始算起的索引)进行加密。SectorOffsetTable使用(密钥 - 1)加密（如果SectorOffsetTable存在的话）。

当文件中所有扇区的大小和偏移都可以从FileSize计算得到时SectorOffsetTable会被省略掉。在一些场合有可能会出现这种情况，如果文件没有被压缩或Implode，那么基于档案的SectorSizeShift，所有扇区的大小和偏移都可以算得出。如果文件被作为一个整体的压缩或Implode单元保存，那么如前所述，该文件唯一的“扇区”大小等同于BlockSize和FileSize，因此SectorOffsetTable被省略。但是，只要文件是被压缩或Implode且文件不被作为一个整体看待的话，即使文件中只含有一个扇区（文件大小小于或等于档案扇区的大小），SectorOffsetTable也会存在。

列表文件

列表文件是一种对MoPaQ格式非常简单的扩充，它包含了该档案的（大多数）文件的路径。列表文件中并不包含文件的语言和平台信息。列表文件包含在一种非常简单的文本文件"(listfile)" 中（使用默认的语言和平台），它是由以';'、0Dh、0Ah或者它们的组合作为分隔符所分隔的文件路径的列表组成。文件"(listfile)"本身可以不在列表文件中。

弱数字签名

弱数字签名为符合RSASSA-PKCS1-v1_5的数字签名，使用MD5散列算法和一个512位（弱的）RSA密钥（请参见RSA实验室PKCS1规范获取该协议的详细信息）。公钥和指数码作为资源被保存在Storm中，而私钥被保存在别的文件里，其文件名被传递给MPQAPI（私钥本身并没有保存在MPQAPI中）。签名保存在档案的"(signature)"文件中（默认语言和平台），且没有被压缩或加密。档案被从档案开始（容器文件的ArchiveOffset）到档案结束（长度取决于ArchiveSize，或者在扩展MoPaQ格式中计算得到的大小）进行散列计算；该数字签名文件在档案被署名之前加入，且档案署名时该签名文件所占据的空间都被当作二进制0来看待。该文件具有以下结构：

00h: int32 Unknown : 必须为0。04h: int32 Unknown : 必须为0。08h: int512 Signature : 数字签名。如MoPaQ格式中其他数一样为小端形式。

该数字签名的构造遵循RSASSA-PKCS1-v1_5规范，处理该格式非常之枯燥（该签名的校验程序编写主要是应用MD5函数和大数函数，这很无趣），所以最好交给专门的加密库，比如如下的OpenSSL去处理：

int mpq_verify_weak_signature(RSA *public_key, const unsigned char *signature, const unsigned char *digest) {    unsigned char reversed_signature[MPQ_WEAK_SIGNATURE_SIZE];    memcpy(reversed_signature, signature + 8, MPQ_WEAK_SIGNATURE_SIZE);    memrev(reversed_signature, MPQ_WEAK_SIGNATURE_SIZE);        return RSA_verify(NID_md5, digest, MD5_DIGEST_LENGTH, reversed_signature, MPQ_WEAK_SIGNATURE_SIZE, public_key);}

MPQKit包含了弱签名的RSA公钥，其格式为PEM的r73版本。

强数字签名 - 概要

强数字签名由SHA-1摘要和一些极其简单的填充组成，直接使用RSA加密。所有已知的暴雪的密钥都是2048位（强）RSA密钥；一个默认的密钥保存在Storm中。显然可以使用任何的RSA密钥，实际上，目前从未发现有人用到过默认密钥。强数字签名在容器文件里紧跟着档案的末尾存储。整个档案（从容器文件的ArchiveOffset位置开始，共ArchiveSize个字节）被作为一个整块计算散列值（该算法有一个例外，后面将会描述）。此外，一个签名在最终成型之前会在SHA-1摘要后跟一段附加数据，它的内容可以是任意的。该签名具有以下格式：

00h: char(4) Magic : 表示这里是一个数字签名。必须为"NGIS"（"SIGN"的回文）。04h: int2048 Signature : 数字签名，以小端格式存储。

当签名域被一个公钥加密时，它的大整数结果被保存为小端字序，其结构如下；

00h: byte Padding : 必须为0Bh。01h: byte(235) Padding : 必须为BBh。ECh: byte(20) SHA-1 : 档案的SHA-1摘要，符合标准SHA-1字序。

强数字签名 - 细节

本章主要是希望能够给出一个对暴雪公钥的使用，以及SHA-1摘要末尾的附加数据的细节描述。

魔兽争霸3地图

魔兽争霸3地图（.w3m与.w3x）由一个地图头部、一个头部后位于512偏移处的MPQ档案、以及其后的一个强数字签名所组成。魔兽争霸3地图密钥被用于魔兽争霸3地图的签名；SHA-1摘要由从地图头部起直到档案结束处的整个文件数据（即从容器文件的0偏移开始，共MapHeaderSize + ArchiveSize个字节）生成而来。地图数据计算了摘要之后，SHA-1摘要后将带上附加数据，其内容为地图文件名的全大写字符串。

Mac版魔兽世界补丁

Mac版魔兽世界补丁是由一个补丁程序("patcher")来合并的，该补丁程序内含有一堆standalone.MPQ档案资源，其中存放有补丁的内容。standalone.MPQ档案被Mac版魔兽世界补丁密钥署名；SHA-1摘要采用前面所述的一般场合的方法生成。摘要计算好之后，SHA-1摘要后将带上附加数据，其内容为"ARCHIVE"。

需要注意Windows版魔兽世界补丁采用的是弱数字签名方案。

魔兽世界调查报告

魔兽世界的WDB目录下有一个Survey.MPQ档案。Survey.MPQ档案被魔兽世界调查报告密钥署名，其SHA-1摘要采用前面所述的一般场合的方法生成。摘要计算好之后，SHA-1摘要后将带上附加数据，其内容为"ARCHIVE"。

需要注意在燃烧远征的发行版里并没有发现Survey.MPQ档案的存在。

自定义数据

首次用于燃烧远征的第二版MoPaQ格式, 它是一个能让部分数据存放在档案之外的机制，但目前还不明白该机制的设计目的。它是由位于档案之前的一种叫做分流块的东西实现的。这种块的结构如下：

00h: char(4) Magic                  表示这是一个分流块。为ASCII "MPQ" 1Bh。04h: int32 UserDataSize             该档案中为自定义数据分配的字节数。                                    它不需要为数据解压后的大小，只需要等于该档案所存储的数据部分的最大值即可。08h: int32 ArchiveHeaderOffset      继续搜索档案头部的文件内起始偏移。0Ch: byte(UserDataSize) UserData    存有自定义数据的数据块。

当Storm在搜索档案头部时遇到了该块时，它将记住该分流块的位置，并且从该分流块中指定的偏移位置起继续搜索档案头部。

暴雪自制的档案将分流块放在了文件的开始处，且档案自身从分流块结束后下一个512字节的边界处开始。

自定义数据文件

某些基于未知的特征的档案可以包含一个分流快。在这种情况下，自定义数据被保存在一个档案中的一个名为"(user data)"的普通文件中。

算法源代码

这里给出的所有源代码都假设机器是采用小端字序的，且short类型为16位，long类型为32位，long long类型为64位。如果所给平台不符合这些假设的话则必须调整这部分代码。除了我在写该文档时所写的以外的代码都没有经过验证。

加密／解密

以下代码基于StormLib。

unsigned long dwCryptTable[0x500];// 加密与散列函数中用到了一个数字查找表。该表必须在首次调用这些函数之前进行初始化。void InitializeCryptTable(){    unsigned long seed   = 0x00100001;    unsigned long index1 = 0;    unsigned long index2 = 0;    int   i;    for (index1 = 0; index1 < 0x100; index1++)    {        for (index2 = index1, i = 0; i < 5; i++, index2 += 0x100)        {            unsigned long temp1, temp2;            seed  = (seed * 125 + 3) % 0x2AAAAB;            temp1 = (seed & 0xFFFF) << 0x10;            seed  = (seed * 125 + 3) % 0x2AAAAB;            temp2 = (seed & 0xFFFF);            dwCryptTable[index2] = (temp1 | temp2);        }    }}void EncryptData(void *lpbyBuffer, unsigned long dwLength, unsigned long dwKey){    assert(lpbyBuffer);    unsigned long *lpdwBuffer = (unsigned long *)lpbyBuffer;    unsigned long seed = 0xEEEEEEEE;    unsigned long ch;    dwLength /= sizeof(unsigned long);    while(dwLength-- > 0)    {        seed += dwCryptTable[0x400 + (dwKey & 0xFF)];        ch = *lpdwBuffer ^ (dwKey + seed);        dwKey = ((~dwKey << 0x15) + 0x11111111) | (dwKey >> 0x0B);        seed = *lpdwBuffer + seed + (seed << 5) + 3;*lpdwBuffer++ = ch;    }}void DecryptData(void *lpbyBuffer, unsigned long dwLength, unsigned long dwKey){    assert(lpbyBuffer);    unsigned long *lpdwBuffer = (unsigned long *)lpbyBuffer;    unsigned long seed = 0xEEEEEEEEL;    unsigned long ch;    dwLength /= sizeof(unsigned long);    while(dwLength-- > 0)    {        seed += dwCryptTable[0x400 + (dwKey & 0xFF)];        ch = *lpdwBuffer ^ (dwKey + seed);        dwKey = ((~dwKey << 0x15) + 0x11111111L) | (dwKey >> 0x0B);        seed = ch + seed + (seed << 5) + 3;*lpdwBuffer++ = ch;    }}

散列与文件密钥的计算

这些函数似乎是从某个很古老的版本的StormLib继承而来的。已经过去太久以至于我已经忘了是哪个版本了。

// 所生成的散列值类型#define MPQ_HASH_TABLE_OFFSET0#define MPQ_HASH_NAME_A1#define MPQ_HASH_NAME_B2#define MPQ_HASH_FILE_KEY3// 该代码基于StormLibunsigned long HashString(const char *lpszString, unsigned long dwHashType){    assert(lpszString);    assert(dwHashType <= MPQ_HASH_FILE_KEY);        unsigned long  seed1 = 0x7FED7FEDL;    unsigned long  seed2 = 0xEEEEEEEEL;    int    ch;    while (*lpszString != 0)    {        ch = toupper(*lpszString++);        seed1 = dwCryptTable[(dwHashType * 0x100) + ch] ^ (seed1 + seed2);        seed2 = ch + seed1 + seed2 + (seed2 << 5) + 3;    }    return seed1;}#define BLOCK_OFFSET_ADJUSTED_KEY 0x00020000Lunsigned long ComputeFileKey(const char *lpszFilePath, const BlockTableEntry &blockEntry, unsigned long nArchiveOffset){assert(lpszFilePath);// 从路径中找出文件名部分const char *lpszFileName = strrchr(lpszFilePath, '//');if (lpszFileName)lpszFileName++;// 跳过/elselpszFileName = lpszFilePath;// 计算文件名的散列值，得到基础密钥unsigned long nFileKey = HashString(lpszFileName, MPQ_HASH_FILE_KEY);// 必要时用偏移调整密钥if (blockEntry.Flags & BLOCK_OFFSET_ADJUSTED_KEY)nFileKey = (nFileKey + blockEntry.BlockOffset) ^ blockEntry.FileSize;return nFileKey;}

FILETIME与time_t的转换

该段代码假设基准时间（零）为01/01/1970。在Windows、Unix System V systems与Mac OS X上也确实如此。但不清楚在其它平台上是否也成立。如果你打算移植到别的平台的话可能就需要自己去研究了。

该段代码未经测试，可能有错误

#define EPOCH_OFFSET 116444736000000000ULL// 01/01/1601到01/01/1970的时间差，单位100纳秒bool GetTimeFromFileTime(const FILETIME &fileTime, time_t &time){// FILETIME作为一个64位整数：从1601年1月1日起的时间，单位为100纳秒unsigned long long nTime = ((unsigned long long)fileTime.dwHighDateTime << 32) + fileTime.dwLowDateTime;if (nTime < EPOCH_OFFSET)return false;nTime -= EPOCH_OFFSET;// 将基准时间从01/01/1601转换到01/01/1970nTime /= 10000000ULL;// 转换100纳秒到秒time = (time_t)nTime;// 溢出检查（FILETIME为64位，而time_t为32位）if ((nTime - (unsigned long long)time) > 0)return false;return true;}void GetFileTimeFromTime(const time_t &time, FILETIME &fileTime){unsigned long long nTime = (unsigned long long)time;nTime *= 10000000ULL;nTime += EPOCH_OFFSET;fileTime.dwLowDateTime = (DWORD)nTime;fileTime.dwHighDateTime = (DWORD)(nTime >> 32);}

FILETIME与NSDate的转换

MPQKit的[NSDate]上有一个专栏介绍了NSDate与NTFS FILETIME之间的相互转换，并且经测试无误。

从32位与16位值构建64位大档案相对地址

unsigned long long MakeLargeArchiveOffset(unsigned long nOffsetLow, unsigned short nOffsetHigh){return ((unsigned long long)nOffsetHigh << 32) + (unsigned long long)nOffsetLow;}

扇区校验

bool VerifySectorChecksum(const void *buffer, unsigned int length, unsigned long checksum){if (checksum == 0)return true;// 忽略实际校验unsigned long bufferChecksum = adler32(0, buffer, length);if (bufferChecksum == 0)// 无法处理校验码0bufferChecksum = (unsigned long)-1;return (bufferChecksum == checksum);}

查找文件

#define MPQ_HASH_ENTRY_EMPTY 0xFFFFFFFFL#define MPQ_HASH_ENTRY_DELETED 0xFFFFFFFELbool FindFileInHashTable(const HashTableEntry *lpHashTable, unsigned long nHashTableSize, const char *lpszFilePath, unsigned short nLang, unsigned char nPlatform, unsigned long &iFileHashEntry){assert(lpHashTable);assert(nHashTableSize);assert(lpszFilePath);// 在散列表中查找文件的起始入口unsigned long iInitEntry = HashString(lpszFilePath, MPQ_HASH_TABLE_OFFSET) & (nHashTableSize - 1);// 是否已经到末尾了？if (lpHashTable[iInitEntry].FileBlockIndex == MPQ_HASH_ENTRY_EMPTY)return false;// 计算散列值，用以比较散列表入口冲突unsigned long nNameHashA = HashString(lpszFilePath, MPQ_HASH_NAME_A),nNameHashB = HashString(lpszFilePath, MPQ_HASH_NAME_B),iCurEntry = iInitEntry;// 检查散列表中的每一个入口直到遇到中止条件do{if (lpHashTable[iCurEntry].FileBlockIndex != MPQ_HASH_ENTRY_DELETED){if (lpHashTable[iCurEntry].FilePathHashA == nNameHashA && lpHashTable[iCurEntry].FilePathHashB == nNameHashB&& lpHashTable[iCurEntry].Language == nLang&& lpHashTable[iCurEntry].Platform == nPlatform){iFileHashEntry = iCurEntry;return true;}}iCurEntry = (iCurEntry + 1) & (nHashTableSize - 1);} while (iCurEntry != iInitEntry && lpHashTable[iCurEntry].FileBlockIndex != MPQ_HASH_ENTRY_EMPTY);return false;}

删除

bool DeleteFile(HashTableEntry *lpHashTable, unsigned long nHashTableSize, BlockTableEntry *lpBlockTable, const char *lpszFilePath, unsigned short nLang, unsigned char nPlatform){assert(lpHashTable);assert(nHashTableSize);assert(lpBlockTable);// 在散列表中查找文件unsigned long iFileHashEntry;if (!FindFileInHashTable(lpHashTable, nHashTableSize, lpszFilePath, nLang, nPlatform, iFileHashEntry))return false;// 在删除散列表入口之前，先取到块表索引unsigned long iFileBlockEntry = lpHashTable[iFileHashEntry].FileBlockIndex;// 删除文件在散列表中对应的入口memset(&lpHashTable[iFileHashEntry], 0xFF, sizeof(HashTableEntry));// 如果后面的入口为空，把该项标志为空；否则标志为已删除。if (lpHashTable[(iFileHashEntry + 1) & (nHashTableSize - 1)].FileBlockIndex == MPQ_HASH_ENTRY_EMPTY)lpHashTable[iFileHashEntry].FileBlockIndex = MPQ_HASH_ENTRY_EMPTY;elselpHashTable[iFileHashEntry].FileBlockIndex = MPQ_HASH_ENTRY_DELETED;// 如果该块占用了实际空间，标志该块为空闲空间；否则清除块表入口if (lpBlockTable[iFileBlockEntry].BlockSize > 0){lpBlockTable[iFileBlockEntry].FileSize = 0;lpBlockTable[iFileBlockEntry].Flags = 0;}elsememset(&lpBlockTable[iFileBlockEntry], 0, sizeof(BlockTableEntry);return true;}

常量

区域编码

    MPQNeutral      = 0,    MPQChinese      = 0x404,    MPQCzech        = 0x405,    MPQGerman       = 0x407,    MPQEnglish      = 0x409,    MPQSpanish      = 0x40a,    MPQFrench       = 0x40c,    MPQItalian      = 0x410,    MPQJapanese     = 0x411,    MPQKorean       = 0x412,    MPQDutch        = 0x413,    MPQPolish       = 0x415,    MPQPortuguese   = 0x416,    MPQRusssian     = 0x419,    MPQEnglishUK    = 0x809

 

原文地址：
http://wiki.devklog.net/index.php?title=The_MoPaQ_Archive_Format