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

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

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

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

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

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

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

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

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

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

14
checksum crc

4 ответов

существует ряд переменных для рассмотрения 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

Типичные CRCs:

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.

17

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

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

1

Это может быть не CRC, это может быть код исправления ошибок, такой как Reed-Solomon.

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

1

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

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

0