逆向工程未知CRC

我正在嘗試對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的第一部分。

來源

2014-10-29 Douwe66

最簡單的方法是查看計算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

您很可能錯誤地標識了其中一個CRC字節的位置。 CRC的一個字節總是與您的CRC-16一致的事實強烈地表明您擁有正確的CRC算法。

來源

2014-10-30 04:48:06

你說的CRC字節的位置是什麼意思？前7個字節當然不是CRC，因爲它們擁有我在二進制中需要的確切數量的信息。 – Douwe66 2014-10-30 18:43:22

我的意思是不同於你的CRC計算的字節可能不是CRC字節。我假設你在消息的某個地方找到了「603D」。 '3D'與你的CRC不匹配，但是第一個字節，例如'60'，_always_匹配。所以也許正確的CRC的第二個字節，'21'是在別的地方。 – 2014-10-30 18:48:54

另一種解釋是隻有16位CRC的一個字節存儲在消息中。 – 2014-10-30 18:51:13

您是否正確實施了CRC16。有幾個不同版本的CRC16。例如維基百科列出了CRC16-IBM，CITT，DNP，VÖV等等。它也可能是一個很大的小問題，或者CRC是取樣。

來源

2015-02-26 17:33:21

逆向工程未知CRC

回答

相關問題