2014-10-29 9 views
0

Я пытаюсь перепроектировать CRC. Когда я вычисляю CRC-16 для данных, он очень похож на crc-send с данными, но не точно равен.Обратное проектирование неизвестно 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'), как предложено [здесь] (http://stackoverflow.com/ questions/12438495/methods-to-nail-down-16-bit-crc-checksum-algorithm-used-by-windows-ce-executable), предположим, что это не обычный вариант стандартного CRC (значения init, polys , окончательный XOR). Вполне возможно, что есть ошибка в реализации стандартного CRC ... или они намеренно делают что-то тонко нечетное. – hcs

+0

Я думаю, что они действительно делают что-то тонко странное. Я пробовал reveng, и я не получал результатов при использовании более двух пакетов. – Douwe66

+0

Другая возможность заключается в том, что они инициализируют исходное значение CRC ненулевому значению и эквивалентно предварительному ожиданию байта входному потоку или, возможно, добавлению байта в конец потока. – Ryan

ответ

0

Возможно, вы ошибочно идентифицировали местоположение одного из байтов CRC. Тот факт, что один байт CRC всегда согласуется с вашим CRC-16, настоятельно предлагает вам иметь правильный алгоритм CRC.

+0

Что вы имеете в виду с расположением байт CRC? Первые 7 байтов, конечно, не являются CRC, потому что они содержат точные цифры информации, которая мне нужна в двоичном формате. – Douwe66

+0

Я имею в виду, что байт, отличный от вашего вычисления CRC, может быть не байт CRC. Я предполагаю, что вы находите '603D' в сообщении где-то. «3D» не соответствует вашему CRC, но первый байт, например. совпадения '60', _allways_. Так что, возможно, второй байт правильного CRC, '21' находится где-то в другом месте. –

+0

Альтернативное объяснение состоит в том, что в сообщении сохраняется только один байт 16-разрядного CRC. –

0

У вас есть правильная реализация CRC16. Существует несколько различных версий CRC16. Например, в википедии перечислены CRC16-IBM, CITT, DNP, VÖV и некоторые другие. Также это может быть большой проблемой или CRC является выборкой.