在阅读了这里的大量帖子及其解决方案后，在 CRC 计算器中打孔已经好几天了。我似乎无法找到此代码基于哪个校验和。
背景
这是 Echolab 视频混合器的控制面板和主机之间串行通信的数据片段。Echolab 在 7 年前破产了，硬件多年来一直在积灰。作为将仍然良好的控制面板重新用于新硬件的项目，我需要将协议转换器连接到这些面板。
我已经启动并运行了不同系列的面板。但这些面板来自他们建造的最后一个系列。因此，他们似乎对他们的命令进行了校验。而且，我需要操作这些字符串中的数据，所以我需要弄清楚它们使用了哪个校验和。
FFFFFF030068000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000077CDDDE7A20
FFFFFF030069000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000078221EDC040
FFFFFF03006A0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000785774B0FC0
FFFFFF03006B000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000078B0C63AA00
FFFFFF03006C000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000078E5A2D1920
FFFFFF03006D0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000791974997E0
FFFFFF03006E000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000079A775A4720
FFFFFF03006F000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000079D3AEC7440
这里是按顺序发送的 8 条消息的示例。
FFFFFF 是协议中所有消息的标头，后跟消息标识符 [03]，然后是黑色字节，后跟地址字节（在这种情况下为 68 - 6F）。
我选择了这些消息，因为有效负载完全是空的。所以我可以在这个例子中展示校验和确实跳了很多..
077CDDDE7A20 Addr 68
078221EDC040 Addr 69
0785774B0FC0 Addr 6A
078B0C63AA00 Addr 6B
078E5A2D1920 Addr 6C
0791974997E0 Addr 6D
079A775A4720 Addr 6E
079D3AEC7440 Addr 6F
因此，仅更改地址编号，校验和就会发生很大变化。这告诉我它不是简单的 Xor 或 Add/count 和 Mod Checksum。所以我的猜测是它在 CRC 域的某个地方？但是在 Scandacore 和 Defuse 等在线校验和计算器上花了 2 天的时间。尝试了很多不同的组合，有和没有标题、消息 ID 等。但我似乎找不到正确的组合.. 所以我是一个有点迷失在这个..
我排除了校验和中有一个计时器。由于消息在稍后阶段重新出现，并且当存在相同的有效负载时仍然具有相同的校验和。
以下是一些包含数据的消息。（您可以看到 Message ID 05 每组消息重复两次）
FFFFFF0507FF07FF40800000030000000010100001000000000000000000000000000000000000000000000000000000303A3130303A31300000000000000000313A3030313A30300000000000000000000000000000000000300032003301210039003A003B00380035009F00AB0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007F5F6C0
FFFFFF01546F70204D656E752020202020202020202020204C6F6164204672616D6573746F72652031362020202020202020202020202020202020202020202020202020202020202020202020202020202020202D2D2D2D2D2D2050414E454C202D2D2D2D2D2D20202D2D2D2D2D204B45594D454D202D2D2D2D2D2D202020736176652020202020726563616C6C20202020207361766520202020206F6E2F6F6666202064D63D40
FFFFFF0507FF07FF40800000030000000010100001000000000000000000000000000000000000000000000000000000303A3130303A31300000000000000000313A3030313A30300000000000000000000000000000000000300032003301210039003A003B00380035009F00AB0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007F5F6C0
FFFFFF07426C6B20504331205043322054696D6543616D3143616D3343757420535372634642663146426632202020202020202020202004
更新 编辑 1
于是在发现了4 / 6 字节校验和之后。我更深入地了解这是为什么。
燃烧了半个晚上，查看并清理（使其更具可读性）源代码捕获（1000 多行）我无法让自己满意。
虽然用于这次捕获的大型机距离数周之遥，但我需要为自己找到一台大型机。
今天早上从这里开车 2 小时有一台大型机，不确定它是否可以与我的面板一起使用。因为它们之间可能存在固件差异。
于是有了！但是这是好的方面！为了便于比较，我没有像之前那样的空消息.. 但是拖尾使消息的构建更加清晰。特别是校验和。
所以我还发现我正在查看校验和的错误部分。（并错过了校验和字符串中应包含的 2 个字节。
首先是几个示例，下面是更多描述：
FFFFFF0301560000000000000000000000000000001F43333F3C0143330C6601431E0C060F430C0C3C01430C0C6001430C0C661F5F0C0C3C000000000000000000000000000000000000000000000E000000001B000000001B000000000E000000001B000000001B000000000E00000000000000000000000000000000006F686ABF4D60
FFFFFF03015700000000000000000000000000000000063E1F80000663318000060331800006031F8000060331800006633180003E3E318000000000000000000000000000000000000000000D7D4E1C3F0C0D4E1C630C0D5E36630C7D5E363F0C0D763E030C0D7663037D7D6663030000000000000000000000000000006F6874AEFEE0
FFFFFF03015800000000000000000000000000000007763161E00036316330003363303003736331E000336373000031461B3007714619E000000000000000000000000000000000000000000D7D4E1C3F0C0D4E1C630C0D5E36630C7D5E363F0C0D763E030C0D7663037D7D6663030000000000000000000000000000006F68FEEB80A0
FFFFFF03015900063E1F80000663318000060331800006031F8000060331800006633180003E3E318000000000001C39787EFC1C3B0D460C1E7B0D460C1E7B0C7E7C1B5B0D460C1B5B0D460C181979460C000000000000337B470000381B470000301B6F0000317B6F0000301B3B0000301B3B0000337B030000000000006F68FC406620
FFFFFF03015A00063E1F80000663318000060331800006031F8000060331800006633180003E3E318000000000001C39787EFC1C3B0D460C1E7B0D460C1E7B0C7E7C1B5B0D460C1B5B0D460C181979460C000000000000397D6380006C0D6380006C0D7780006C7D7780006C0D5D80006C0D5D8000397D418000000000006F688396C200
在这些示例中，我们有以下内容：
Header FFFFFF
Message Type 03
Address double byte 0158
Data 120 bytes big
X number 6F68 Seems to be data
Checksum FEEB80A0
X号是新的！对于其他大型机，这确实发生了一些变化。但是在这个大型机上，所有 346 条消息都保持不变，这些消息将数组写入一些 LCD 智能按钮。所以校验和确实是 4 个字节。
昨天我发现了来自校验和的 2 个 X 字节数。在较旧的样本中，第一个字符是 0.. 所以我假设他们在校验和的前后各放了一个 0..
现在我们知道校验和只有 4 个字节。突出的一点是它总是以 0 结尾。我认为这是故意的。因为 4 位填充有点奇怪，你不觉得吗？
因此，在我发布此消息后，我将使用这些新知识重新制作 CRC 网站。但我很想先更新这篇文章。