1

我有一堆从元数据中可以看出应该是 PDF 的文件。其中一些确实是完整的 PDF。其中一些似乎是 PDF 文件的第一部分，尽管它们缺少 the%%EOF和其他页脚值。

其他似乎是 PDF 文件的最后一部分（它们没有任何 PDF 的标题，但它们确实有这些%%EOF东西）。奇怪的是，它们从以下 16 字节的魔术头开始：

0x50, 0x4B, 0x57, 0x41, 0x52, 0x45, 0x00, 0x00, 0x00, 0x00, 0x00, 0x57, 0x49, 0x4E, 0x33, 0x32( PKWARE WIN32)。

我做了很多可能会产生误导的推论，但它似乎不是一种压缩方案（这些%%EOF东西是纯文本的），并且在我被允许深入研究的几个文件中，开始之间存在相关性有了这种魔力，看起来就像 PDF 二进制文件的最后一段。

有人对这里可能使用的文件格式有任何提示吗？

更新：我现在观察到PKWARE WIN32非 PDF 文件也会发生这种情况。推测还表明这些文件以类似的方式拆分。

更新 2：事实证明，此PKWARE WIN32标头实际上以重复的间隔出现，其位置可以通过紧接在标头之前的一些字节来预测。

我还收到了一些间接的传闻，这些传闻表明这些文件被压缩并且没有分成多个部分，尽管在 3 个案例中有 2 个告诉我输出文件大小我的二进制文件只小到可以忽略不计。

谜团还在继续。

4

1 回答 1

0

好的，所以这最终成为一种非常奇怪的格式。总的来说，它是一种压缩方案，但它的应用不一致，并且以一种混淆问题的方式轻轻包裹。

任何这些文件的前 8 个字节都会以它自己的魔法开始，接下来的 8 个字节可以读取为 long 来告诉我们输出文件的最终大小。

然后有一个 16 字节的“节”（四个整数），其第一个数字只是一个增量计数器，其第二个整数表示直到下一个“节”中断的字节数，其第三个整数对我来说有点神秘，并且其第四个 int 为 0 或 1。如果该 int 为 0，则按原样读取下一个（无论多少）字节。它们是有效载荷。

如果它是 1，那么接下来您将获得这些PKWARE标题之一。老实说，我知道如何以最差的方式解释它们，而不是从原始问题中的魔法开始，它们总共有 42 个字节长。

如果您有 PKWARE 标头，请从要读取的字节数中减去 42，然后使用 PKWARE 的“内爆”算法将剩余字节视为压缩。这意味着您可以使用 zlib 的“explode”实现来解压缩它们。

遍历文件并考虑所有这些标头并将压缩和未压缩的部分拼凑在一起，直到用完字节并最终得到输出文件。

我不知道为什么只有部分文件被压缩，也不知道为什么它们被分成这样的块，但它似乎适用于我拥有的有限样本数据。也许稍后我会发现实际上已经沿着这些边界分割的文件，或者采用了某种奇特的重复数据删除，但至少现在我可以解释为什么它看起来像我看到了部分 PDF——这些文件只是部分压缩了。

于 2021-11-11T21:48:10.447 回答