У меня есть старое, больше не произведенное электронное устройство с последовательным портом. Я пытаюсь перепроектировать пакет CRC/контрольная сумма/хэш данных, используемый в этом устройстве.
Кто-нибудь с острыми глазами, острыми математическими навыками, которые могут взломать эту вещь?
Вот что я знаю до сих пор...
- Каждый пакет всегда равен 21 байту. 19 байтов данных плюс 2 байта в конце для CRC/контрольная сумма/хэш
- Следовательно, здесь нет байтов длины или заголовка. Все 19 байтов участвуют в вычислении хэша.
- У меня есть возможность генерировать определенные объемы пакетов данных с помощью устройства
- Мои первые мысли состоят в том, что пакеты данных имеют своего рода расчет CRC-16
- Итак, я следил за подсказками в www.cosc.canterbury.ac.nz/greg.ewing/essays/CRC-Reverse-Engineering.html
-
Проверено, что мои образцы пакетов данных наблюдали "принцип суперпозиции", описанный выше в веб-ссылке. Это указывает на то, что они имеют математическое отношение XOR.
-
Начинал чувствовать себя хорошо... но потом был в тупике после этого. Не удалось определить многочлен CRC-16. Существует большая вероятность того, что эти хэши пакетов данных не связаны с CRC, а скорее являются домашней схемой brew.
-
Прочитайте "НЕПРАВИЛЬНОЕ РУКОВОДСТВО ДЛЯ АЛГОРИТМОВ ОБНАРУЖЕНИЯ ОШИБОК CRC" Росса Н. Уильямса
- См. http://www.ross.net/crc/download/crc_v3.txt
- Также используется приложение: CRC Reveng - обратное инженерное приложение
- См. reveng.sourceforge.net
- Еще не повезло...
-
К сожалению, у меня нет доступа к любому из исходных/двоичных кодов устройств
-
Также выполнялись тесты, чтобы увидеть, используются ли другие хэши, такие как контрольная сумма Fletcher
Вот несколько примеров моих пакетов данных.
0x47366B2EE00000000000751CEB5F3469543B585E2D
0x47366B2ED00000000000751CEB5F3469543B582A2C
0x47366B2EC80000000000751CEB5F3469543B580B2B
0x47366B2EC40000000000751CEB5F3469543B58BB2A
0x47366B2EC20040000000751CEB5F3469543B58DFE7
0x47366B2EC10000000000751CEB5F3469543B58A328
0x47366B2EC08000000000751CEB5F3469543B584127
0x47366B2EC04000000000751CEB5F3469543B588126
0x47366B2EC02000000000751CEB5F3469543B580525
0x47366B2EC01000000000751CEB5F3469543B580124
Обратите внимание на следующие данные об этих пакетах данных...
- CRC находится в последних двух байтах пакета данных.
- Если я посмотрю на биты в логическом анализаторе, я сам выражал байты как MSB-first
- Следовательно, пакет 0x47366B2EE00000000000751CEB5F3469543B585E2D отображается в двоичном формате как:
- 01000111............................................................. 00101101
-
(0x47)..................................................................... (0x2D)
-
Я не знаю, является ли моя система большой или малозначной, но вполне определенные байты - это LSB-first
- Обратите внимание, что для вышеприведенных 10 выборок пакета данных каждый пакет отличается на 1 бит смещением до 10 бит. За исключением 5-го пакета, где мне пришлось изменить 2 бита
-
См. байты данных, которые следуют за частью пакета данных 0x47366B2E.
-
Только один шаблон, который я вижу, это последнее уменьшение байтов на один (2D, 2C,...) для каждого пакета данных. (За исключением 5-го пакета, где мне пришлось изменить 2 бита)
- Этот последний байт НЕ является некотором порядковым номером, так как я могу сгенерировать их в любое время с одинаковым значением.
- Но это может дать нам подсказку о математическом хеше.
Любая помощь приветствуется!