我有 120,000 个未知类型的文件（实际上要多得多；这只是一个任意子集）。Linuxfile无法识别它们（不一定是 Linux 文件），我尝试过的任何其他方法也无法识别它们。目前我只有两个关于它们的提示。一个是我怀疑使用了一些压缩——我有元数据声称文件大小总是比我观察到的要大一些。
另一个是，在其中 100,000 个文件中，前 16 个字节始终是：
ff ee ee dd 00 00 00 00 01 00 00 00 00 00 00 00
在我看来，这确实看起来像是一个文件头/魔法数字，但我就是想不起来。有人知道这表示什么类型的文件吗？或者，有人能说服我这些可疑的常见字节肯定不表示特定的文件类型吗？
更新
我不知道确切的逆向工程细节，但在我们的案例中，大多数文件都是在忽略前 29 个（？左右）字节后压缩的。因此，实际上问题已经解决（我们知道如何处理文件），但理论上问题仍未得到解答——我不知道哪个应用程序会定期在其压缩文件前面添加大约 29 个字节。[我不确定此时是否应该将问题留待解答。]
答案1
也许你可以尝试在其中一些文件上使用 TrID
http://mark0.net/soft-trid-e.html
来自 TrID 网站：
TrID 是一款旨在通过二进制签名识别文件类型的实用程序。虽然有类似的实用程序采用硬编码逻辑，但 TrID 没有固定规则。相反，它是可扩展的，可以训练以快速自动的方式识别新格式。
TrID 有很多用途：识别通过电子邮件发送给您的文件类型、协助取证分析、支持文件恢复等。
TrID 使用定义数据库来描述所支持文件类型的重复模式。由于该数据库会频繁更新，因此它以单独的软件包形式提供。只需下载 TrID 和此存档并解压到同一个文件夹中即可...
...
...
更新
读了您的更新后，我发现它们是 Zip 文件，前面添加了 29 个字节，也许这些添加的字节是由于这些文件的获取方式导致的某种“故障”。
示例 1：
这些文件可能是从文件服务器的大型单文件备份中提取的（例如，如果您使用 NTBackup 在单个文件中进行服务器备份，则 NTBackup 可能会在文件中实际包含的数据前面添加一些属性数据）
示例 2：
这些文件可能是从数据库中提取出来的，它们像 BLOB 对象一样存储
示例 3：
这些文件可能是从 RAW CD/DVD 映像中提取出来的（添加的字节可能来自对文件偏移量/文件系统的错误解释）
有无数的假设......也许如果你知道这些文件来自哪里，你可以做一些测试/检查，看看是否有一个实用程序/软件/工具/数据库/服务器将 zip 文件存档在其他文件/数据结构中，并在前面加上这 29 个字节。