需要帮助理解奇怪的校验和或CRC

Question

我遇到了来自环境数据记录器的另一个旧的串行通信逆向工程挑战。 这次的挑战在于每次传输结束时的验证字节，例如校验和或 CRC，但很奇怪。

串行数据采用 ASCII 字节表示形式，一开始有点奇怪，最后的验证字节只有少数可能的值。

请记住：

• STX = 0x02（文本开始）
• ETX = 0x03（文本结束）

例如：

STX003B800D0003010800000000ETX 0x07

STX和ETX之间的所有数据都是ASCII格式，十六进制字节的真实消息是这样的：

02 30 30 33 42 38 30 30 44 30 30 30 33 30 31 30 38 30 30 30 30 30 30 30 30 03 07

末尾的验证字节可能会在以下观察到的值之间变化：

0x00 to 0x0f
0x70 to 0x7f

这非常奇怪，它不遵循我所知道和测试过的任何类型的校验和、CRC-8 或按位运算。

也许有人对如何尝试从串行通信中解码这个旧的验证字节有一些见解。

我将留下一些数据记录器和计算机之间通信的示例：

STX003B80000D000000ETX 0x0D
STX003B80010D010028466E000142580000463464003F80000000000000ETX 0x06
STX003B80010D0200183F800000000000004049999AETX 0x0B
STX003B80010D03008000000000441600004561000048A5AC604813ADC0462DD00041F266664720BE004720BE00429E0000474732000000000437A0000000000004416000000000000ETX 0x7E
STX003B80030D020048469E9E0040DCA15C3F88CA7B649E9C0042700000C1E71C72000000000000000000000000ETX 0x77
STX003B80050D010028466E00054248000040E000003F80000000000000ETX 0x71
STX003B80050D020050BF8000004755D700000000004755D70000000000BF8000003F80000042C800003DE13F213F800000ETX 0x07
STX003B80050D03005840E0000000000000000000003F81C61A41C807C0000000003F133333447D00004180000044AAA00048195D4ETX 0x78
STX003B80050D050070471DD10046ECBC00469EA000474483003F81B22D417000003F8000003F800000000000003F0000003FC28F5C000000000000000447D0000ETX 0x79
STX003B8012110000384BC67B2241800000418800003F814F4041C5A20741118FE800000000ETX 0x04
STX003B8012110000384BC969AC41800000418800003F816AF941C383340BEC4EC00000000ETX 0x79
STX003B8012110000104409800040000000ETX 0x7E
STX003B80170E030000ETX 0x09
STX003B800C0003010800000000ETX 0x00
STX003B800D0003010800000000ETX 0x07
STX003B800E0003010800000000ETX 0x06
STX003B800F0003010800000000ETX 0x05
STX003B80040003010800000000ETX 0x77
STX003B80010003010800000000ETX 0x72
STX003B80120E000000ETX 0x0F

到目前为止我发现了一些事情：

• 大部分数值都是浮点型变量，1.5就是3fc00000。
• 消息中的前3个字节是整数类型的设备序列号。
• 第8个字节是消息数据的字符数。
• 数据从第9个字节开始，以ETX结束。

到目前为止，我尝试了不同类型的校验和、CRC-8、XOR、NAND、NOR、NOT、AND、OR，以及不同的字节。 我使用过非常好的在线计算器，并且过去对我有帮助：

• CRC在线计算器
• 校验和在线计算器

我还尝试了奇怪的校验和，将结果值与预期值进行比较是没有意义的。

总之，我尝试将所有这些计算应用于 ASCII 和 HEX 格式的消息，包括整个消息和某些特定部分（例如仅数据）或排除消息的某些部分（例如 STX 和 ETX 字节）。

Answer 1

检查值是除示例消息（具有

96

的消息）之外的所有消息字节的异或。我猜想其中存在传输或转录错误。事实上，这是唯一一个消息字节数为奇数的示例，表明存在字节丢失。 （更有可能的是，丢失了三个字节。）