inappbillinglibrary这个文件夹是干嘛的可以删吗

Posted 2023-05-15

参考技术A 可

这个神奇的标题有啥文件格式？

【中文标题】这个神奇的标题有啥文件格式？

【英文标题】：What File Format Has This Magic Header?这个神奇的标题有什么文件格式？

【发布时间】：2021-12-17 15:58:55

【问题描述】：

我有一堆从元数据中可以看出应该是 PDF 的文件。其中一些确实是完整的 PDF。其中一些似乎是 PDF 文件的第一部分，尽管它们缺少 %%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 个告诉我输出文件大小我的二进制文件仅小到可以忽略不计。

谜团还在继续。

【问题讨论】：

PKWARE 建议使用类似 zip 文件的内容，尽管这不是 zip 标头。 PKWare 也确实生产了一些加密软件，可能与此有关。但是，%%EOF 绝不是 PDF 文件独有的！这也是 PostScript 程序中的正常注释，我认为您不能仅仅因为它的存在就认为内容是 PDF 文件。是否有 startxref 或 xref 令牌？还是文档信息字典、元数据、x y obj...endobj 序列？不仅仅是 %%EOF。

是的，他们也得到了startxref 的东西，更强烈地暗示它们是与 PDF 相邻的，正如元数据所暗示的那样。

startxref 听起来确实像一个 PDF 文件。由于您显然在某些地方有 PDF 文件的开头，而在其他地方有 PDF 文件的结尾，是否有人使用实用程序将大文件拆分为较小的块？

这是我正在追求的一种可能性和理论，但如果它是真的，那么至少这些作品不共享任何位置。有很多文件，它们散布在各处。我也不知道有任何 PKWARE 拆分实用程序——例如，多部分 zip 没有这些标题

没有任何有意义的样本。限制性网络背后的敏感数据等等。明天我会尝试让自己访问更多文件集，看看我是否在任何非 PDF 文件类型上观察到这种现象。

【参考方案1】：

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

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

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

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

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

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

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