0

我正在开发一款分析 E01 比特流图像的软件。基本上，这些是取证数据文件，允许用户将磁盘上的所有数据压缩成一个文件。E01格式嵌入了关于原始数据的数据，包括源数据的MD5哈希和结果数据等。如果你有兴趣轻读，这里有EWF/E01规范。关于我的问题：

e01 文件包含一个“表”部分，它是一系列 32 位数字，它们是 e01 文件中实际数据块所在的其他位置的偏移量。我已经成功地将这些数据解析成一个列表，执行以下操作：

this.ChunkLocations = new List<int>();
//hack:Will this overflow?  We are adding to integers to a long?
long currentReadLocation = TableSectionDescriptorRef.OffsetFromFileStart + c_SECTION_DESCRIPTOR_LENGTH + c_TABLE_HEADER_LENGTH;
byte[] currReadBytes;
using (var fs = new FileStream(E01File.FullName, FileMode.Open))
      {
      fs.Seek(currentReadLocation, 0);
      for (int i = 0; i < NumberOfEntries; i++)
                {
                    currReadBytes = new byte[c_CHUNK_DATA_OFFSET_LENGTH];
                    fs.Read(currReadBytes,0, c_CHUNK_DATA_OFFSET_LENGTH);
                    this.ChunkLocations.Add(BitConverter.ToUInt32(currReadBytes, 0));
                }
       }

c_CHUNK_DATA_OFFSET_LENGTH 是 4 个字节/“32 位”数字。

根据 ewf/e01 规范，“块数据偏移中的最高有效位指示块是压缩的 (1) 还是未压缩的 (0)”。这似乎可以通过以下事实得到证明：如果我将偏移量转换为整数，结果中会有很大的负数（对于没有压缩的块，毫无疑问），但大多数其他偏移量似乎都正确增加了，但是每个偶尔会有疯狂的数据。ChunkLocations 中的数据如下所示：

346256
379028
-2147071848
444556
477328
510100

在 -2147071848 的情况下，MSB 似乎被翻转以指示压缩/缺乏压缩。

问题：所以，如果 MSB 用于标记压缩的存在，那么我真的在处理 31 位数字，对吗？
1. 在计算偏移值时如何忽略 MSB/计算 31 位数字？
2. 这似乎是一个奇怪的标准，因为它似乎会显着限制您可以拥有的偏移量的大小，所以我在质疑我是否遗漏了什么？当我导航到 e01 文件中的这些位置时，这些偏移看起来是正确的。

谢谢你的帮助！

4

2 回答 2

3

在处理二进制格式时，这种事情很典型。正如 dtb 指出的那样，对于这个应用程序来说，31 位可能已经足够大了，因为它可以处理高达 2 GiB 的偏移量。所以他们使用额外的位作为标志来节省空间。

您可以使用按位与来屏蔽该位：

const UInt32 COMPRESSED = 0x80000000;   // Only bit 31 on

UInt32 raw_value = 0x80004000;          // test value

bool compressed = (raw_value & COMPRESSED) > 0;
UInt32 offset = raw_value & ~COMPRESSED;

Console.WriteLine("Compressed={0}  Offset=0x{1:X}", compressed, offset);

输出：

Compressed=True  Offset=0x4000
于 2013-01-06T20:49:31.177 回答
1

如果您只想去除前导位，请使用 0x7FFFFFFF 对值执行按位和 (&)

于 2013-01-06T20:51:21.203 回答