2014-10-29 100 views
0

我正在尝试对CRC进行逆向工程。 当我计算数据的CRC-16时,它与数据的crc发送非常相似,但不完全相同。逆向工程未知CRC

找出计算CRC的确切方法的最佳方法是什么? 是否可以在这里使用另一个多项式或可能是另一个初始值?

这里有一些数据包与自己的CRC相比,CRC-16:

Packet   CRC CRC-16 Difference 
118080009A28C0 - 603D 6021 28 
918080009A28C0 - A8BD A8A0 29 
518080009A28C0 - A47D A460 29 
D18080009A28C0 - 6CFD 6CE1 28 
318080009A28C0 - A27D A200 125 
B18080009A28C0 - 6AFD 6A81 124 
718080009A28C0 - 6665 6641 36 
F18080009A28C0 - AEE5 AEC0 37 
098080009A28C0 - 61BD 61B9 4 
898080009A28C0 - A93D A938 5 
C98080009A28C0 - 6D7D 6D79 4 
298080009A28C0 - A39D A398 5 
A98080009A28C0 - 6B1D 6B19 4 
698080009A28C0 - 67DD 67D9 4 
B1808800372880 - BAFD BAF0 13 
E18080009A28F8 - BDDD BDD0 13 
118080009A28FE - B0BD B0A0 13 
8080D728D72880 - 224C 224C 0 
80803728372880 - 02CC 02CC 0 
80803928392880 - 00C4 00C4 0 
8080B928B92880 - 36C4 36C4 0 
8080D728D72846 - 70CC 70CC 0 
80803728372846 - 504C 504C 0 
718080009A28C0 - 6665 6641 36 
718080009A28FC - 7765 7741 36 
F18080009A28C0 - AEE5 AEC0 37 
F18080009A28FC - BFE5 BFC0 37 
098080009A28C0 - 61BD 61B9 4 
098080009A28FC - 70BD 70B9 4 
898080009A28C0 - A93D A938 5 
898080009A28FC - B83D B838 5 
498080009A28FC - B4FD B4F8 5 
C98080009A28C0 - 6D7D 6D79 4 
C98080009A28FC - 7C7D 7D79 4 
298080009A28C0 - A39D A398 5 
298080009A28FC - B29D B298 5 
A98080009A28C0 - 7B1D 6B19 4 
A98080009A28FC - 7A1D 7A19 4 
698080009A28C0 - 67DD 67D9 4 
698080009A28FC - 76DD 76D9 4 

看来,CRC-16是正确的算法,但旁边有一个在德值变化小。它似乎基于数据的第一位到第十六位数字,甚至可能是CRC的第一部分。

+0

最简单的方法是查看计算CRC的代码。我最好的努力在使用[CRC RevEng](http://reveng.sourceforge.net/)('reveng -w 16 -s 603dc0289a00808011 a8bdc0289a00808091 a47dc0289a00808051 6cfdc0289a008080d1'),建议[here](http://stackoverflow.com/问题/ 12438495/methods-to-nail-down -16-bit-crc-checksum-algorithm-used-by-windows-ce-executable),表明它不是标准CRC的任何正常变体(init值,polys ,最终XOR)。标准CRC的实施可能存在缺陷......或者他们故意做些微妙的事情。 – hcs 2014-10-30 02:53:39

+0

我认为他们确实做了些微妙的事情。我试过reveng,并且在使用超过2个数据包时没有得到结果。 – Douwe66 2014-10-30 18:44:43

+0

另一种可能性是,它们将起始CRC值初始化为非零值,这相当于在输入流之前预先输入一个字节,或者可能会在流结尾添加一个字节。 – Ryan 2015-02-26 19:01:21

回答

0

您很可能错误地标识了其中一个CRC字节的位置。 CRC的一个字节总是与您的CRC-16一致的事实强烈地表明您拥有正确的CRC算法。

+0

你说的CRC字节的位置是什么意思? 前7个字节当然不是CRC,因为它们拥有我在二进制中需要的确切数量的信息。 – Douwe66 2014-10-30 18:43:22

+0

我的意思是不同于你的CRC计算的字节可能不是CRC字节。我假设你在消息的某个地方找到了“603D”。 '3D'与你的CRC不匹配,但是第一个字节,例如'60',_always_匹配。所以也许正确的CRC的第二个字节,'21'是在别的地方。 – 2014-10-30 18:48:54

+0

另一种解释是只有16位CRC的一个字节存储在消息中。 – 2014-10-30 18:51:13

0

您是否正确实施了CRC16。有几个不同版本的CRC16。例如维基百科列出了CRC16-IBM,CITT,DNP,VÖV等等。它也可能是一个很大的小问题,或者CRC是取样。