Как я мог угадать алгоритм контрольной суммы?
Предположим, у меня есть несколько пакетов с 16-битной контрольной суммой в конце. Я хотел бы угадать, какой алгоритм контрольной суммы используется.
Для начала, из данных дампа я вижу, что изменение одного байта в полезной нагрузке пакета полностью меняет контрольную сумму, поэтому я могу предположить, что это не какой-то простой XOR или сумма.
Затем я попробовал несколько вариантов CRC16, но без особого успеха.
Этот вопрос может быть более предвзятым в отношении криптографии, но меня действительно интересуют любые простые для понимания статистические инструменты, чтобы узнать, какой CRC это может быть. Я могу даже обратиться к рисование различных алгоритмов CRC, если все остальное не сработает.
Предыстория: у меня есть серийный протокол RFID с какой-то контрольной суммой. Я могу без проблем воспроизводить сообщения и интерпретировать результаты (без проверки контрольной суммы), но я не могу отправлять измененные пакеты, потому что устройство сбрасывает их на пол.
Используя существующее программное обеспечение, я могу изменить полезную нагрузку чипа RFID. Однако уникальный серийный номер неизменен, поэтому у меня нет возможности проверить все возможные комбинации. Хотя я мог генерировать дампы значений, увеличивающихся на единицу, но этого недостаточно, чтобы сделать исчерпывающий поиск применимым к этой проблеме.
дамп файлов с данными доступны, если самого вопроса недостаточно :-)
Нужна справочная документация?БЕЗБОЛЕЗНЕННОЕ РУКОВОДСТВО ПО АЛГОРИТМАМ ОБНАРУЖЕНИЯ ОШИБОК CRC - отличная ссылка, которую я нашел, задав вопрос здесь.
В конце концов, после очень полезной подсказки в принятом ответе, чем CCITT, я использовал этот калькулятор CRC и xored сгенерировали контрольную сумму с известной контрольной суммой, чтобы получить 0xffff, что привело меня к выводу, что окончательный xor равен 0xffff в потоке CCITT 0x0000.
Нет, не могу. Я могу изменить часть данных и сгенерировать контрольные суммы, используя существующее приложение, которое общается с устройством, но это не весь пакет.
Стандарт CCITT определяет XOR с 0x0000? Разве это не всегда запрет?
Ответы 4
Вам придется попробовать все возможные алгоритмы контрольной суммы и посмотреть, какой из них дает тот же результат. Однако нет гарантии, какой контент был включен в контрольную сумму. Например, некоторые алгоритмы пропускают пробелы, что приводит к другим результатам.
Я действительно не понимаю, зачем кому-то это знать.
Я понимаю, зачем кому-то это нужно - если они проводят обратную разработку формата файла для создания этих файлов. Я сделал это.
Правильный. У меня есть серийный протокол RFID с какой-то контрольной суммой. Я могу без проблем воспроизводить сообщения и интерпретировать результаты (без проверки контрольной суммы), но я не могу отправлять измененные пакеты, потому что устройство сбрасывает их на пол.
Это может быть не CRC, это может быть код с исправлением ошибок, например код Рида-Соломона.
Коды ECC часто составляют значительную часть размера исходных данных, которые они защищают, в зависимости от частоты ошибок, которые они хотят обработать. Если размер сообщений превышает примерно 16 байт, 2 байта ECC будет недостаточно, чтобы быть полезными. Так что, если сообщение большое, вы, скорее всего, правы, что это своего рода CRC.
Верно, но сообщения намного меньше 256 байт, а контрольная сумма проверяется на довольно простом аппаратном устройстве, поэтому я предполагаю, что это своего рода CRC.
Если быть точным, мое самое длинное сообщение составляет 70 байт. В пакете есть дыра перед длиной, которая может увеличить возможную длину до одного байта, но я еще не видел реальных сообщений длиннее 70 байтов.
Для 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.
Это "самодельный" алгоритм. В этом случае это может занять некоторое время. В противном случае попробуйте стандартные алгоритмы.
Попробуйте изменить старший или младший бит последнего байта и посмотрите, как это изменит 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.
Я медленно теряю волосы (снова). Я пытался использовать CCITT со своими данными, но у меня это не работает. Можете ли вы поделиться фрагментом реализации и / или воспроизвести CRC на zorc.breitbandkatze.de/crc.html или lammertbies.nl/comm/info/crc-calculation.html
Не обращайте на меня внимания, окончательный xor равен 0xffff, а не 0x0000, как с ccitt ... Я сравнил контрольную сумму ccitt с самой контрольной суммой, и это привело меня в правильном направлении ...
Я пытаюсь решить аналогичную проблему и нашел довольно интересный веб-сайт, который возьмет ваш файл и выполнит для него контрольные суммы с помощью 47 различных алгоритмов и покажет результаты. Если алгоритм, используемый для вычисления вашей контрольной суммы, представляет собой любой из этих алгоритмов, вы просто найдете его среди списка контрольных сумм, созданных с помощью простого текстового поиска.
Сайт https://defuse.ca/checksums.htm
есть ли один, который может пойти другим путем, когда это возможно?
Можете ли вы получить контрольные суммы для любых данных?