我有以下记录的命令包,每个32字节:
3da89fc200180010000000000000000024100001240400010000000000000000
d427eb5a00180010000000000000000024100001240300010000000000000000
984870ff00180010000000000000000024100001240200010000000000000000
4ab8076100180010000000000000000024100001240100010000000000000000
06d79cc400180010000000000000000024100001240000010000000000000000
前 4 个字节应该是其余 28 个字节的“以太网 CRC-32”校验和。我想创建自定义命令,所以我需要弄清楚如何计算 CRC。
我尝试了我能想到的 CRC32 的任何变体,甚至对上面给出的数据尝试了“reveng -w 32 -c”,希望找到正确的 CRC 设置。运气不好。我怀疑在 CRC 计算之前甚至可能之后发生了一些奇怪的数据重新排序。
我该如何解决这个问题?是否有一种自动化的方法来尝试数据的不同排列?
由于消息之间的变化很小(只有三位发生变化),我只能说它们与作为 CRC 的那些字节并不不一致。该结论来自唯一的相关消息,该消息具有不同的十六进制数字中的
3
。这取决于该位置带有 0
、1
和 2
的消息。如果我获取这些消息的 CRC 并将它们一起异或,我会得到带有 3
的消息的 CRC。 0x06d79cc4 ^ 0x4ab80761 ^ 0x984870ff == 0xd427eb5a
。
因此数据与 GF(2) 上的线性函数一致,即 CRC。我能说的就这么多了。我可以使用该方法来计算这三位的任何其他可能值的函数。
这就是我从所提供的数据中所能得出的结论。
稍微详细说明一下数学:如果我将其中一条消息(包括 CRC)与所有其余消息进行异或,我现在就有了初始值为零且最终异或为零的 CRC 示例。那些被取消了。因此,我选择在不同位置带有
0
的消息。我现在收到的消息全部为零,除了 1
、2
、3
或 4
数字。如果我用 1
和 2
排除新消息,我会在该位置收到一条带有 3
的消息。您会发现它与新消息(带有 CRC)相匹配,并在该位置带有 3
。它们匹配的事实表明,该集合与前四个字节并不矛盾,前四个字节是剩余字节的 GF(2) 上的线性函数。