看起来此元数据列出了在创建文件期间使用的文档 ID。您可以查看这篇文章：http : //www.hackerfactor.com/blog/index.php?/archives/2013/05/23.html，搜索“祖先”部分。

因此，它包含可以由 Adob​​e 应用程序“自然”放置在那里的技术元数据。

我相信我链接的所有内容都是安全的。对不起格式，我会尽力解决这个问题。

以下是一些元数据数量相似的候选对象。报告链接来自谷歌搜索“* DocumentAncestors 的项目数量过多”（来自exiftool，显然被 VirusTotal 使用）。

这是一个jpg 或 mp3 (report)，一个带有垃圾邮件文本的 png (report)，一个单独的 png (report)，以及两个具有相同 md5 (31a02712515ace35f1a593c14a7b5150) 的 png，但这个以“0”开头，就像您的示例一样。png（报告）和实时样本 png三星平板电脑（SAMPLE）。样本来自哈希；其他人没有生产样品。

来自“samsung”样本的直方图（我很快将 107,000 个条目的每个字节分开，通过 'uniq' 对它们进行排序和发送）可能用途有限，除了表明字节不是完全随机的。考虑到某些操作可能是如何编码的，这可能是意料之中的，但我假设一个生成纯随机 UUID 的编程错误。这不是最漂亮的照片，所以我可以继续努力。十进制 17 (0x11) 是底部的大尖峰。

我尝试了一些实验来查看是否可能存在一些编码数据（也是直方图的点），但大多将其视为处理文件时生成的元数据。

以下是一些额外的追求：

Adobe Photoshop CC 上的另一个论坛帖子正在创建有问题的 JPEG，这使得 OSX Preview.app 失去了对链接文件 (Note4Cover1.jpg) 的关注，该链接文件同样大但内部格式不那么好。

其他人拥有过多的项目，我认为这个链接建议如何删除额外的数据（警告它可能会删除你想要的东西）：

exiftool -xmp:all= -tagsfromfile @ "-all:all<xmp:all" FILE

一个警告：我发现使用 GIMP 以新名称打开和保存会删除数据，无论是否设置了保存它的复选框。根据此处其他答案链接的标准，这似乎不应该发生。

最后，differ (differ.readthedocs.org) 是一个图像报告库。我没有评估它，因为虽然它看起来很有用并且可以从可能的工具（如 exiftool 和 imagemagick）中转储统计信息，但设置起来可能有点棘手（github）。它仍然可能对取证数据有用。