Взлом протокола обмена, определение алгоритма подсчета CRC Опции

[ARV]

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

Сам обмен я просниффил, оказалось достаточно просто, в пакете данных нашел поля адреса, в этом я точно уверен. Все остальные данные пока не известны, где находятся в пакете, но главное - в конце пакета (подозреваю очень сильно!) есть поле какой-то контрольной суммы. Во всяком случае, при изменении буквально 1-2 битов в пакете 4 последних байта сильно меняются, что наталкивает...

Так вот: каким способом можно вычислить алгоритм, по которому ведется подсчет этой КС? Прошивка МК недоступна, естественно... Я пробовал брутфорсить при помощи утилиты reveng, но ничего не вышло... Что посоветуете?

Вот просниффленные пакеты с трех разных передатчиков:

Код

73 07 61 = BA AF 20 05 1C 00 00 00 00 00 00 00 00 00 00 09 0A 00 00 00 00 00 00 80 00 00 00 41 41 00 3C 12 = 71 6D 62 87
73 07 61 = BA AF 40 60 18 00 00 00 00 00 00 00 00 00 00 09 0A 00 00 00 00 00 00 80 00 00 00 41 41 00 3C 12 = 3B 80 07 A9
73 07 61 = BA AF 60 00 16 00 00 00 00 00 00 00 00 00 00 09 0A 00 00 00 00 00 00 80 00 00 00 41 41 00 3C 12 = 01 6D 67 BD
73 07 61 = BA AF 20 05 12 00 00 00 00 00 00 00 00 00 00 09 0A 00 00 00 00 00 00 80 00 00 00 41 41 00 3C 12 = 71 20 62 88

72 4F 1B = BA 9C 60 00 62 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 = 01 30 E7 F6
72 4F 1B = BA 9C 40 62 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 = D0 13 85 05
72 4F 1B = BA 9C 60 00 5E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 = 01 12 E7 CA
72 4F 1B = BA 9C 20 0B 5E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 = 0B AA EC 80

73 10 07 = 25 41 20 04 1E 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 12 = 47 06 62 4C
73 10 07 = 25 41 40 60 1C 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 12 = 19 20 06 70
73 10 07 = 25 41 60 00 1A 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 12 = 01 6A 66 4E
73 10 07 = 25 41 20 04 18 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 12 = 78 0C 4E 45
знаками равенства я отделил в начале область адреса (я уверен, что это так) и в конце - область контрольной суммы (100% уверенности в назначении этих байтов нет)

[Baser]

Если CRC стандартная, то можно попробовать перебрать популярные полиномы (стандарты).
Для CRC32 вроде популярных немного, но могут быть нюансы: сдвиг вправо/влево, начальное значение, пост инверсия.
Еще могут не все байты пакета охватывать CRC.

Вообщем попробовать подбором. Мне такое один раз удалось для CRC16, правда там все было исключительно стандартно.

[adnega]

в конце пакета (подозреваю очень сильно!) есть поле какой-то контрольной суммы. Во всяком случае, при изменении буквально 1-2 битов в пакете 4 последних байта сильно меняются, что наталкивает...

А возможно ли получить один и тот же пакет два раза? У таких пакетов последние 4 байта будут совпадать?

[ARV]

Вообщем попробовать подбором.

Собственно, для подбора нужен какой-то автоматизированный инструмент, иначе просто нереально. Знаете такой?

А возможно ли получить один и тот же пакет два раза? У таких пакетов последние 4 байта будут совпадать?

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

[adnega]

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

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

[Baser]

Собственно, для подбора нужен какой-то автоматизированный инструмент, иначе просто нереально. Знаете такой?

Я в свое время, не зная ничего кроме Си и микроконтроллеров, набрал стандартных алгоритмов и прямо в отладчике МК прокрутил несколько десятков вариантов для перехваченной посылки с CRC. Повезло, подобрал.

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

[ARV]

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

Я же говорю, что простое решение - reveng - результата не даёт, надо что-то оригинальнее...

[_pv]

Первая и четвертая строки отличаются на пару бит, 12 <-> 1C и "контрольные суммы" отличаются не особо. Должно быть что-то вроде суммы/произведения, у обычной CRC не было бы такой похожести при малых изменениях.
Адрес скорее первые пять байт а не три.
Ну и данных маловато, по четырем посылкам состоящим в основном из нулей не разобраться.
И ещё надо как-то повоздействовать на датчики, чтобы показания менялись, и эти изменения отслеживать в данных.

[k155la3]

Собственно, для подбора нужен какой-то автоматизированный инструмент, иначе просто нереально. Знаете такой?
. . .

Очень давно переписывал ф-ию подсчета CRC для универсального применения (те с любым полиномом, с любым направлением сдвига и старт. значением).
Это не очень сложно. Стандартных полиномов не так много. Направления сдвига - 2 (оноже - "зеркальный" полином).
Стандартные длины 8-16-32, плюс может быть не стандартная, например 24.
Но "рояль" может не сработать, даже при правильном подборе алгоритма CRC, если девайс при подсчете суммы добавляет скрытые байты в подсчет.
(те они включаются в подсчет для каждого пакета на сторонах передатчика и приемника в качестве константы, но через канал связи не передаются)

ps
В пакете могут присутствовать байты, которые не должны включаться в подсчет CRC.
А есть возможность не сниффить, а "стрельнуть" в приемник своим пакетом ("ловить на живца")

[ARV]

А есть возможность не сниффить, а "стрельнуть" в приемник своим пакетом ("ловить на живца")

Это, разумеется, один из этапов "взлома", но пока что я к нему не приступил.
Все вами сказанное я понимаю, но продолжаю надеяться, что не все так сложно, особенно со скрытыми байтами. Просто система не та, чтобы так стараться сделать её невзламываемой, главное - обеспечить надежность передачи по ИК-каналу, который, в принципе, достаточно "грязный". Так что я все-таки надеюсь, что слишком хитрых трюков не будет...

Мне вот уже подсказали, что XOR первых пяти байтов даёт НОЛЬ, хотя АДРЕС содержится только в первых трех - может быть, эта часть и не входит в общую КС... но 4 байта КС - это намекает на CRC32, что выглядит явно избыточным для пакета из 39 байт...

[Сергей Борщ]

но 4 байта КС - это намекает на CRC32, что выглядит явно избыточным для пакета из 39 байт...

Там может быть, например, 2 байта обычной суммы и 2 байта контрольной суммы Флетчера. Я бы на вашем месте обратил пристальное внимание на сообщение от _pv.

[ARV]

Там может быть, например, 2 байта обычной суммы и 2 байта контрольной суммы Флетчера. Я бы на вашем месте обратил пристальное внимание на сообщение от _pv.

Я обращаю внимание... но не все понятно. Например, что за КС Флетчера - не ясно, в интернете что-то непонятное написано (по-русски).

[k155la3]

А есть возможность проверить что эти пакеты принимаются корректно другим приемником ?

[ARV]

А есть возможность проверить что эти пакеты принимаются корректно другим приемником ?

Приемник пока один. Статистику по пакетам буду набирать для имеющихся передатчиков... Потом буду гондобить свой передатчик и пытаться обмануть приемник...
Пока это все, что в моих силах.

[esaulenka]

Мысли на уровне ".опой чую":
- передатчик 1, пакеты 1 и 4. Изменился 1 байт данных, изменились [1] и [3] байты КС.
- передатчик 2, пакеты 1 и 3. Полностью аналогично.
- все остальные варианты - КС меняется значительно.

Имхо, Сергей Борщ прав - это какие-то костыли для совместимости, и две двухбайтовые КС одна в другой.
И _pv прав, это не настоящий CRC / Флетчер / что-то продвинутое. Там от смены одного бита всё переворачиваться должно, а мы этого не видим.

И да, если это две КС, может прокатить халява - одна из них не проверяется. "Испорченные" посылки пробовали?