我正在尝试对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的第一部分。
最简单的方法是查看计算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
我认为他们确实做了些微妙的事情。我试过reveng,并且在使用超过2个数据包时没有得到结果。 – Douwe66 2014-10-30 18:44:43
另一种可能性是,它们将起始CRC值初始化为非零值,这相当于在输入流之前预先输入一个字节,或者可能会在流结尾添加一个字节。 – Ryan 2015-02-26 19:01:21