Попытка обратного проектирования контрольной суммы пакета/CRC/хэша

У меня есть старое, больше не произведенное электронное устройство с последовательным портом. Я пытаюсь перепроектировать пакет 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 бита)

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

Любая помощь приветствуется!

Ответы

Ответ 1

ЕСЛИ это следует за простым отношением XOR, которое (контрольная сумма (A ^ B) == контрольная сумма (A) ^ контрольная сумма (B)), то есть простое решение грубой силы!

иллюстрации. Предположим, что у вас есть 1-байтовое значение с контрольной суммой K-бит, где K фактически не имеет значения, поэтому мы просто представляем контрольные суммы как c (i).

Шаг 1. Эксперимент: наблюдайте контрольную сумму c (-1) всего пакета нулей.

0b0000000 => c(-1)

Шаг 2. Эксперимент: наблюдайте контрольные суммы c (i) всей двоичной последовательности с одним 1 в них в позиции i

0b00000001 => c(0)
0b00000010 => c(1)
0b00000100 => c(2)
0b00001000 => c(3)
0b00010000 => c(4)
0b00100000 => c(5)
0b01000000 => c(6)
0b10000000 => c(7)

Значения, которые вы наблюдали для контрольных сумм для формы линейного базиса для GF (2), и отношения XOR теперь позволяют вам вычислять любую контрольную сумму.

Теперь вы можете вычислять контрольные суммы, добавляя контрольные суммы для каждой позиции бит с помощью 1, например. предположим, что вам нужна контрольная сумма 0XF3, которая в двоичном формате равна 0b11110011. Так как

0b11110011 = (0) + 0x80 + 0x40 + 0x20 + 0x10 + 0x02 + 0x01

то по соотношению XOR,

checksum(0b11110011) = c(7) + c(6) + c(5) + c(4) + c(1) + c(0) + c(-1)

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

Если вы выполняете это упражнение и экспериментально выписываете все 152 контрольных суммы базовых векторов, возможно, вы также найдете в этом процессе простой шаблон, который объясняет, как контрольные суммы поступают из базисных векторов.:) Если так, было бы неплохо опубликовать это здесь! (И, может быть, скажите нам, что мы реверсируем?)

Ответ 2

Я запускал некоторые пакеты через приложение под названием "SRP16", которое выполняет поиск и отображает параметры CRC16 Rocksoft. Выход:

===== Result parameter sets =====
CRC=$2a2c  Poly=$2817  init=$3141  xorout=$ffff  refin=true   refout=true 
 *** Second data set verified
CRC=$2a2c  Poly=$2817  init=$70f4  xorout=$0000  refin=true   refout=true 
 *** Second data set verified
CRC=$2a2c  Poly=$2817  init=$9bf3  xorout=$0000  refin=false  refout=true 
 *** Second data set verified
CRC=$2a2c  Poly=$2817  init=$da46  xorout=$ffff  refin=false  refout=true 
 *** Second data set verified
CRC=$2a2c  Poly=$4777  init=$1263  xorout=$0000  refin=false  refout=true 
 *** Second data set verified
CRC=$2a2c  Poly=$4777  init=$6f2d  xorout=$0000  refin=true   refout=true 
 *** Second data set verified
CRC=$2a2c  Poly=$4777  init=$a127  xorout=$ffff  refin=true   refout=true 
 *** Second data set verified
CRC=$2a2c  Poly=$4777  init=$dc69  xorout=$ffff  refin=false  refout=true 
 *** Second data set verified
CRC=$2c2a  Poly=$7354  init=$1dab  xorout=$0000  refin=false  refout=true 
 *** Third  data set verified
CRC=$2c2a  Poly=$7354  init=$417e  xorout=$0000  refin=false  refout=true 
 *** Third  data set verified
CRC=$2c2a  Poly=$7354  init=$a401  xorout=$0000  refin=false  refout=true 
 *** Third  data set verified
CRC=$2c2a  Poly=$7354  init=$f8d4  xorout=$0000  refin=false  refout=true 
 *** Third  data set verified
CRC=$2c2a  Poly=$8a23  init=$0fa0  xorout=$0000  refin=false  refout=true 
 *** Second data set verified
CRC=$2c2a  Poly=$8a23  init=$3f6a  xorout=$ffff  refin=false  refout=true 
 *** Second data set verified
CRC=$2c2a  Poly=$8a23  init=$cc70  xorout=$0000  refin=true   refout=true 
 *** Second data set verified
CRC=$2c2a  Poly=$8a23  init=$fcba  xorout=$ffff  refin=true   refout=true 
 *** Second data set verified
CRC=$2c2a  Poly=$9656  init=$3460  xorout=$0000  refin=false  refout=true 
 *** Third  data set verified
CRC=$2c2a  Poly=$9656  init=$ff4b  xorout=$0000  refin=false  refout=true 
 *** Third  data set verified
CRC=$2c2a  Poly=$a644  init=$195b  xorout=$0000  refin=false  refout=true 
 *** Third  data set verified
CRC=$2c2a  Poly=$a644  init=$70ca  xorout=$0000  refin=false  refout=true 
 *** Third  data set verified
CRC=$2c2a  Poly=$a644  init=$a3e8  xorout=$0000  refin=false  refout=true 
 *** Third  data set verified
CRC=$2c2a  Poly=$a644  init=$ca79  xorout=$0000  refin=false  refout=true 
 *** Third  data set verified
===== done =====

Возможно, попробуйте и посмотрите, работают ли они на вас?

Удачи!