Jump to content

    

Взлом протокола обмена

Коллеги!

Прошу помочь, хотя бы советом, в решении проблемы реверс-инжиниринга ИК-протокола обмена.

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

 

Сам обмен я просниффил, оказалось достаточно просто, в пакете данных нашел поля адреса, в этом я точно уверен. Все остальные данные пока не известны, где находятся в пакете, но главное - в конце пакета (подозреваю очень сильно!) есть поле какой-то контрольной суммы. Во всяком случае, при изменении буквально 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% уверенности в назначении этих байтов нет)

Share this post


Link to post
Share on other sites

Если CRC стандартная, то можно попробовать перебрать популярные полиномы (стандарты).

Для CRC32 вроде популярных немного, но могут быть нюансы: сдвиг вправо/влево, начальное значение, пост инверсия.

Еще могут не все байты пакета охватывать CRC.

 

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

Share this post


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

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

Share this post


Link to post
Share on other sites
Вообщем попробовать подбором.

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

 

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

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

Share this post


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

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

Если это нужно для защиты протокола от несанкционированного использования - то совершенно другая.

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

Share this post


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

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

 

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

Share this post


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

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

Share this post


Link to post
Share on other sites

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

Адрес скорее первые пять байт а не три.

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

И ещё надо как-то повоздействовать на датчики, чтобы показания менялись, и эти изменения отслеживать в данных.

Share this post


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

. . .

Очень давно переписывал ф-ию подсчета CRC для универсального применения (те с любым полиномом, с любым направлением сдвига и старт. значением).

Это не очень сложно. Стандартных полиномов не так много. Направления сдвига - 2 (оноже - "зеркальный" полином).

Стандартные длины 8-16-32, плюс может быть не стандартная, например 24.

Но "рояль" может не сработать, даже при правильном подборе алгоритма CRC, если девайс при подсчете суммы добавляет скрытые байты в подсчет.

(те они включаются в подсчет для каждого пакета на сторонах передатчика и приемника в качестве константы, но через канал связи не передаются)

 

ps

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

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

Share this post


Link to post
Share on other sites
А есть возможность не сниффить, а "стрельнуть" в приемник своим пакетом ("ловить на живца") :)
Это, разумеется, один из этапов "взлома", но пока что я к нему не приступил.

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

 

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

 

Share this post


Link to post
Share on other sites
но 4 байта КС - это намекает на CRC32, что выглядит явно избыточным для пакета из 39 байт...
Там может быть, например, 2 байта обычной суммы и 2 байта контрольной суммы Флетчера. Я бы на вашем месте обратил пристальное внимание на сообщение от _pv.

 

Share this post


Link to post
Share on other sites
Там может быть, например, 2 байта обычной суммы и 2 байта контрольной суммы Флетчера. Я бы на вашем месте обратил пристальное внимание на сообщение от _pv.
Я обращаю внимание... но не все понятно. Например, что за КС Флетчера - не ясно, в интернете что-то непонятное написано (по-русски).

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
А есть возможность проверить что эти пакеты принимаются корректно другим приемником ?

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

Пока это все, что в моих силах.

Share this post


Link to post
Share on other sites

Мысли на уровне ".опой чую":

- передатчик 1, пакеты 1 и 4. Изменился 1 байт данных, изменились [1] и [3] байты КС.

- передатчик 2, пакеты 1 и 3. Полностью аналогично.

- все остальные варианты - КС меняется значительно.

 

Имхо, Сергей Борщ прав - это какие-то костыли для совместимости, и две двухбайтовые КС одна в другой.

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

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now