Question

我正在开发一款分析E01比特流图像的软件。基本上这些是取证数据文件，允许用户将磁盘上的所有数据压缩到单个文件中。 E01格式嵌入有关原始数据的数据，包括源的MD5哈希值和结果数据等。如果您对某些光读取感兴趣，则EWF / E01规范为here。在我的问题上：

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文件中的这些位置时，这些偏移似乎是正确的。

感谢您的帮助！

Answer 1

在处理二进制格式时，这种情况很典型。正如dtb所指出的，对于这个应用来说，31位可能相当大，因为它可以解决高达2 GiB的偏移。因此，他们使用额外的位作为标志来节省空间。

您可以使用按位AND屏蔽该位：

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

Answer 2

如果您只想剥离前导位，请使用0x7FFFFFFF

执行该值的按位和（＆amp;）

计算31位数/忽略最高位

2 个答案: