识别文件的最少字节答案

【问题标题】：Fewest bytes to identify a file识别文件的最少字节
【发布时间】：2019-06-19 02:52:15
【问题描述】：

我目前正在做一个小项目，结果证明这是一个挑战。这是设置：我有一个相当旧的处理器，用于各种产品。大约有 500 种不同的固件版本可用于各种应用。它们有时相差几个字节~1k，其他时候只共享 5%。现在我想通过为每个版本创建一个唯一的标识符来识别它。我已将固件二进制文件作为可用于工作和训练的文件。

目标是，当任何设备通过时，我想读出已安装固件的尽可能少的字节，因为 9600 波特的连接速度相当慢。尽管固件总共只有大约 64k，但完全读取它需要相当长的时间（由于协议开销、时钟速度等原因，大约需要 5 分钟）

我正在考虑一些逻辑，它将解析存储的固件文件并确定其哪些字节可用于唯一标识它。每当有设备经过时，它就会相互读取每个指纹字节，这很像旧的 T9 文本预测，以缩小候选范围，直到找到正确的固件。为此，我需要建立一个包含最优化的指纹字节集的数据库。但是怎么训练呢？如何找到超过 500 个文件的最重要字节？

到目前为止，我已尝试对文件进行统计分析，并找到文件之间差异最大的前 50 个字节。问题是，即使占用 50 个字节，我也会得到多个创建相同哈希的版本。

非常欢迎任何可能解决该问题的建议或算法！如果您对此有完全不同的想法，我很乐意听到！

【问题讨论】：

为什么要投反对票？
为什么不使用 HASH ？ ...为整个固件创建一个 MD5 哈希（或任何校验和...）并发送它...您极不可能找到具有相同哈希的 2 个不同固件...而哈希本身只有几个字节长...计算它也应该比您的 5 分钟快很多...但是您需要在设备本身上计算哈希...
@Spektre 如果固件不支持这样做，那么在设备上计算哈希有点困难。
好吧，如果这是不可能的，那么关于设备的更多信息可能会有所帮助......它是否在代码中编码了一些版本信息？固件之间有什么区别（不同的消息，）它的内部协议会改变吗？发送接收数据包，它有相同的命令吗？ ...所有这些都可以用于检测而无需实际读取固件
正常的做法是你有一个内容的散列，正如已经提到的。它可以是您计算的哈希值，和/或存储到固件中的数据的一部分。对于大多数固件而言，具有与固件一起存储的预先计算的哈希值，或者至少在固件更新时可用是正常的。哈希通常用于验证任何更新是否成功（即存储的内容实际上是预期的固件）。

【解决方案1】：

识别值可能不同的所有字节位置。然后找到“最有效的拆分器”，即探测值会将当前集合拆分为最小子集（在 minmax 意义上）或更多子集的位置。

然后递归地对每个子集重复整个过程。这将产生一个决策树，为您提供（希望是短的）字节序列进行测试。

这是一种启发式方法，可能不是最优的，我希望

假设每次拆分都是平衡的，但每次都产生两个子集，那么测试序列不会超过 10 个字节。

【讨论】：

感谢您的回复！这就是我在帖子中提到的 50 个字节所做的事情。我没有把它放入二叉树的麻烦，但由于我为每个“路径”创建了一个哈希，它归结为同一件事。即使取值不同的 50 个字节，也不足以找到正确的固件。它需要某种优化来根据先前选择的路径减少树中的节点。
@Corelgott：不，这不是你所做的。我描述的过程保证了每一个版本都会被区分。如果幸运的话，10 到 20 个字节就足够了。但它们并不总是在相同的位置。请不要肤浅地阅读。
我同意这是最实用的方法。与构建分类树的ID3算法基本相同。使用“散列”不是一个好方法：系统最终会处理比它必须处理的更多（可能更多）的数据，因为它无法使其测试适应它迄今为止收集的信息。跨度>
我知道你要去哪里......我想得越多，这个方法就越有希望。我刚刚使用哈希来确保路径的唯一性。但是你是对的，散列它们不会使用所需的最小数据集。与我的方法最大的不同是由于细分，子组在他们自身中得到了优化。我的缺乏这个，因此我看到了我遇到的问题。我会试一试...