Как я могу угадать алгоритм контрольной суммы?

Предположим, что у меня есть некоторые пакеты с 16-разрядной контрольной суммой в конце. Я хотел бы догадаться, какой алгоритм контрольной суммы используется.

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

Затем я попробовал несколько вариантов CRC16, но без особого успеха.

Этот вопрос может быть более предвзятым по отношению к криптографии, но я действительно заинтересован в любых простых для понимания статистических инструментах, чтобы выяснить, какой CRC это может быть. Я мог бы даже перейти к рисованию различных алгоритмов CRC, если все остальное не получится.

История Backgroud: у меня есть серийный RFID-протокол с какой-то контрольной суммой. Я могу воспроизводить сообщения без проблем и интерпретировать результаты (без проверки контрольной суммы), но я не могу отправлять измененные пакеты, потому что устройство бросает их на пол.

Используя существующее программное обеспечение, я могу изменить полезную нагрузку чипа RFID. Однако уникальный серийный номер неизменен, поэтому у меня нет возможности проверять все возможные комбинации. Хотя я мог бы генерировать дампы значений, увеличивающихся на единицу, но недостаточно, чтобы сделать исчерпывающий поиск применимым к этой проблеме.

файлы дампов с данными доступны, если самого вопроса недостаточно: -)

Нужна справочная документация? НЕПРАВИЛЬНОЕ РУКОВОДСТВО ДЛЯ АЛГОРИТМОВ ОБНАРУЖЕНИЯ ОШИБКИ CRC - отличная ссылка, которую я нашел после того, как задал вопрос здесь.

В конце концов, после очень полезного намека на принятый ответ, чем на CCITT, я использовал этот CRC-калькулятор, и xored сгенерированная контрольная сумма с известной контрольной суммой, чтобы получить 0xffff, которая привела меня к выводу, что окончательный xor является 0xffff instread CCITT 0x0000.

Ответ 1

Для CRC существует ряд переменных:

Polynomial
No of bits (16 or 32)
Normal (LSB first) or Reverse (MSB first)
Initial value
How the final value is manipulated (e.g. subtracted from 0xffff), or is a constant value

Типичные CRC:

LRC:    Polynomial=0x81; 8 bits; Normal; Initial=0; Final=as calculated
CRC16:  Polynomial=0xa001; 16 bits; Normal; Initial=0; Final=as calculated
CCITT:  Polynomial=0x1021; 16 bits; reverse; Initial=0xffff; Final=0x1d0f
Xmodem: Polynomial=0x1021; 16 bits; reverse; Initial=0; Final=0x1d0f
CRC32:  Polynomial=0xebd88320; 32 bits; Normal; Initial=0xffffffff; Final=inverted value
ZIP32:  Polynomial=0x04c11db7; 32 bits; Normal; Initial=0xffffffff; Final=as calculated

Первое, что нужно сделать, это получить некоторые образцы, изменив, скажем, последний байт. Это поможет вам определить количество байтов в CRC.

Является ли это "самодельным" алгоритмом. В этом случае это может занять некоторое время. В противном случае попробуйте стандартные алгоритмы.

Попробуйте изменить либо msb, либо lsb последнего байта, и посмотрите, как это изменит CRC. Это даст указание направления.

Чтобы сделать его более трудным, существуют реализации, которые управляют CRC, чтобы он не повлиял на коммуникационный носитель (протокол).

Из вашего комментария о RFID, это означает, что CRC связан с коммуникациями. Обычно CRC16 используется для связи, хотя CCITT также используется в некоторых системах.

С другой стороны, если это отметка UHF RFID, то есть несколько схем CRC - 5 бит и 16 бит. Они документированы в стандартах ISO и в листах данных IPX.

IPX:  Polynomial=0x8005; 16 bits; Reverse; Initial=0xffff; Final=as calculated
ISO 18000-6B: Polynomial=0x1021; 16 bits; Reverse; Initial=0xffff; Final=as calculated
ISO 18000-6C: Polynomial=0x1021; 16 bits; Reverse; Initial=0xffff; Final=as calculated
    Data must be padded with zeroes to make a multiple of 8 bits
ISO CRC5: Polynomial=custom; 5 bits; Reverse; Initial=0x9; Final=shifted left by 3 bits
    Data must be padded with zeroes to make a multiple of 8 bits
EPC class 1: Polynomial=custom 0x1021; 16 bits; Reverse; Initial=0xffff; Final=post processing of 16 zero bits

Вот ваш ответ!!!!

Проработав ваши журналы, CRC является CCITT. Первый байт 0xd6 исключается из CRC.

Ответ 2

Вам нужно будет попробовать все возможные алгоритмы контрольной суммы и посмотреть, какой из них генерирует один и тот же результат. Однако нет гарантии того, какой контент был включен в контрольную сумму. Например, некоторые алгоритмы пропускают пробелы, что приводит к разным результатам.

Я действительно не понимаю, почему кто-то хочет это знать.

Ответ 3

Возможно, это не CRC, это может быть код с исправлением ошибок, например, Рид-Соломон.

Коды ECC часто составляют значительную часть размера исходных данных, которые они защищают, в зависимости от частоты ошибок, которую они хотят обрабатывать. Если размер сообщений больше, чем около 16 байт, 2 байта ECC недостаточно, чтобы быть полезным. Поэтому, если сообщение велико, вы, скорее всего, правы, что его некоторая CRC.

Ответ 4

Я пытаюсь взломать подобную проблему здесь, и я нашел довольно аккуратный сайт, который возьмет ваш файл и запустит контрольные суммы на нем с 47 различными алгоритмами и покажет результаты. Если алгоритм, используемый для вычисления вашей контрольной суммы, является любым из этих алгоритмов, вы просто найдете его среди списка контрольных сумм, созданных с помощью простого текстового поиска.

Веб-сайт https://defuse.ca/checksums.htm