0

我试图找出 RAR恢复记录标题中的 crc32 字段基于哪些数据。我正在尝试根据以前的 RAR 卷和提取的内容重新创建 RAR 卷。我已经到了只有 12 个字节与正确/原始卷不同的程度。

这些名称基于unrar 源代码(arcread.cpp) 或RAR 技术说明。

RAR 文件由块组成。它们有一个标题和一个正文：

[header][body]

标头包含描述正文的元数据。这些块之一是 HEAD_TYPE=0x74文件头（档案中的文件）。

[header:a...FILE_CRC...z][body]

字段 FILE_CRC（4 个字节）是根据 [body] 中的所有可用数据计算的，它是一个存储或压缩文件。

恢复记录的块（HEAD_TYPE=0x7a 子块）与文件块非常相似，但它在标头中包含三个额外的字段：

[header:a...FILE_CRC...z, "Protect+", rsc, dsc][body]
    rsc: recovery sector count (4 bytes)
    dsc: data sector count (8 bytes)
assert dsc*2 + rsc*512 == size([body])

你会认为这个块的 FILE_CRC 是基于正文中的数据，就像文件块一样，但事实并非如此。（由其他人独立验证）所以我的问题是，用什么数据来计算这个 crc32？

我已经尝试过的一些事情：

  • 从 Protect+ 等开始。其次是身体
  • RR 子块开始之前的所有内容
  • 我在一个小 RAR 文件中强制使用了所有可能的范围。
4

1 回答 1

1

而不是使用默认种子（-0x1 或 0xFFFFFFFF）：

crc = crc32(data)
crc = crc32(data, ~0xffffffff)

一个 F 被丢弃（-0x10000000）：

crc = crc32(data, ~0x0fffffff)

向作者发送了一封电子邮件，回复如下：

据我快速查看 RAR 代码，这是所有 CRC16 数据和所有恢复记录奇偶校验扇区的 CRC32（列表中的“所有 RR 数据”）。

请注意，虽然 RAR 存储此校验和，但它不会在任何地方使用它。恢复时不需要。即使恢复记录部分损坏，其有效部分仍可用于恢复数据。我们可以使用CRC16检查每个扇区的修复成功，因此在恢复过程中不需要一个覆盖所有数据的CRC32。

尤金

就像最初的想法一样，块的 FILE_CRC 是基于主体中的数据。看起来 RAR 代码中的某处有错字。

TheUnarchiver2.7.1_src 的 XADRARParser.m 有以下注释代码：

    // Removed CRC checking because RAR uses it completely inconsitently
/*  if(block.crc!=0x6152||block.type!=0x72||block.flags!=0x1a21||block.headersize!=7)
...

差不多 3 年后，我发现其他人在那年早些时候已经找到了解决这个问题的方法。

# Why is this odd CRC initialiser used?
crc = crc32(rr_crcs, 0xF0000000)
于 2011-11-23T01:34:17.210 回答