编辑：事实证明这是一个自定义校验和算法，而不是CRC-32。对于好奇的here is a snippet C代码计算以下示例中的21 FF 1D E4校验和。
我正在使用一些似乎受CRC-32保护的十六进制文件，但是使用标准CRC-32和其他已知参数重新计算无法产生匹配。
我所知道的是，数据跨越116个字节，校验和有4个额外字节。我可以生成大量的消息密钥对示例，我只是找不到它们之间的任何关系。
我不想用十六进制转储来填充这篇文章，所以我在这里粘贴了几个：http://mathb.in/12246。
11 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 21 FF 1D E4
这可能是一个奇怪设置的CRC-32，还是完全不同？什么是确定校验和如何产生的方法？
更新：我能够在消息中对1位进行微小的更改：
00000000000000000000000000000000000000000000000000000000, 32C9A1E6 00000000000000000000000000000000000000000000000000000001, BD25904E 00000000000000000000000000000000000000000000000000000002, B437A286 00000000000000000000000000000000000000000000000000000003, 8AB790EE 00000000000000000000000000000000000000000000000000000004, 2DDC3AEB 00000000000000000000000000000000000000000000000000000005, 208B3859 00000000000000000000000000000000000000000000000000000006, 87E0925C 00000000000000000000000000000000000000000000000000000007, E59391AE 00000000000000000000000000000000000000000000000000000008, B07292FC 00000000000000000000000000000000000000000000000000000009, 830EA655
更改任何内容而不更新校验和会相应地创建一条被拒绝的消息。
如果由于叠加原则（独占或检查）而不能成为CRC-32，是否有任何方法可以执行分析以查找消息和校验和对中的任何属性或模式？
答案 0 :(得分：2)
假设您在链接的示例中获得了正确的消息和检查值，那么它不是CRC。对于消息的GF（2）上的CRC或任何线性函数，如果消息1与消息2异或，等于消息3与消息4异或，则应该是相同的确认值为真。
您的邮件中只有一个字节不同。由于45 ^ 4A == 43 ^ 4C，所以当异或时的相关检查值也应该相等。他们不是。
如果您确实有CRC，那么您可以使用reveng来尝试梳理CRC参数。