解密校验和/ CRC

Question

我试图找出对以下数据流的错误检查。数据来自用于编程电散热器加热器的商用遥控器。

我已经对大多数IR协议（RC5，NEC等）进行了广泛的研究，而且据我所知，它并不适合任何协议。但是，我不能确认它不是IrDA。

我使用的硬件是标准的Vishay IR 38kHz接收器，连接到运行WinLIRC的旧PC，因此我可以看到原始脉冲/空间序列，并通过各种测试/调整确认了配置中的基本参数（例如时间戳，其分辨率低至秒），数据以10位，一个起始位，8位数据字节和一个停止位的形式从IR出来。然后我将数据字节反转，比特交换的MSB-LSB使我达到与编程时间表叠加的点。

我的一个关键点是我认为是错误检查的最后一个字节，我知道这是因为我已经设置了一个测试装置来发送带有不同错误检查的数据并且加热器不接受它，并且接受记录的正确值。

下面是数据流，接下来是2次迭代，但每种情况下时间戳前进1秒。我可以看到错误检查之间有一些数学上的相似之处，但我已经尝试了所有8位CRC /校验和XOR，加法，减法等解码方法，并且还使用了尚未得出答案的数据。

对此有任何帮助非常感谢！

第1轮数据

二元十六进制说明

11111111 FF 255
00000000 0 0
00001111 F 15
10110011 B3 179
01001100 4C 76
00000000 0 0
00000000 0 0
00000000 0 0
00000011 3 3
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000011 3 3
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000011 3 3
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000011 3 3
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000011 3 3
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000011 3 3
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000000 0 0
00000011 3 3
00000000 0 0
00000000 0 0
00000011 3 3
00000010 2 2小时
00010010 12 18分钟
00000000 0 0 SECONDS
01101011 6B 107 CRC CHECK？

第二轮数据与第一轮相关时间印章： -

00000001 1 1 SECONDS
00110101 35 53 CRC检查？

第三轮数据与第一轮时间戳相反： -

00000010 2 2秒 11010111 D7 215 CRC CHECK？

第四轮数据与第一轮相关时间印章： -

00000011 3 3 SECONDS
10001001 89 137 CRC CHECK？

第五轮数据与第一轮相关时间印章： -

00000100 4 4秒 00001010 A 10 CRC CHECK？

第六轮数据与第一轮相关时间印章： -

00000101 5 5秒 01010100 54 84 CRC检查？

第7轮数据与第一轮相关的时间标志分钟： -

00011000 18 24分钟
00001101 D 13 SECONDS
01110001 71 113 CRC CHECK？

第八轮数据与第一轮相关的时间标志分钟： -

00011011 1B 27分钟
00111011 3B 59 SECONDS
01000111 47 71 CRC检查？

Answer 1

CRC RevEng可以轻松找到原始问题集的解决方案。这是紧凑性的Bash命令行： -

reveng -w 8 -s ff000fb34c00000003000000000003000000000003000000000003000000\
00000300000000000300000000000300000302\
{12006b,120135,1202d7,120389,12040a,120554,180d71,1b3b47}

返回： -

width=8  poly=0x31  init=0xa5  refin=true  refout=true  xorout=0x00  check=0x67  residue=0x00  name=(none)

由于所有流的长度相同，CRC RevEng无法同时计算Init和Xorout。 xorout=0x00是一种强制init=0xa5的推测，以便正确计算问题集中的流。长度不超过52个字节的流将需要两个参数，找到一个将为您提供计算它们的方法。

poly=0x31只在CRC-8/MAXIM下的目录中出现一次，该内容也会反映出来但有init=0x00;如果这确实是正在使用的算法，那么init=0xa5是一个输入算法的字节图像，不应该是（即第一个 n 字符不会被输入{ {1}}）;遗憾的是，我无法找到等同于CRC-8/MAXIM初始值的数据流前缀。

如果您需要代码来计算这些CRC，则可以使用其他软件包将CRC RevEng的Rocksoft™模型输出转换为C，例如pycrc或Mark Adler的crcany。

Answer 2

谢谢谢谢!!! 你已经钉了它！绝对精彩！ 我再次尝试复仇，但仍然无法得到任何东西，甚至复制你的例子。所以我在这个网站上试了一下： -

包括最后一个字节，你找到的poly和init以及bingo！

我的数据流总是相同的数量，52个字节。

再次，非常感谢所有人帮助我格式化等，当然还有答案！

AaronT。