|
|
|
Взлом протокола обмена, определение алгоритма подсчета CRC |
|
|
|
Apr 6 2018, 13:08
|
Профессионал
Группа: Свой
Сообщений: 1 143
Регистрация: 30-09-08
Из: Новочеркасск
Пользователь №: 40 581
|
Коллеги! Прошу помочь, хотя бы советом, в решении проблемы реверс-инжиниринга ИК-протокола обмена. Есть "фирменная" система, состоящая из приемника ИК-сигналов и кучи передатчиков сигнала. Передатчики посылают пакеты данных, в которых есть их собственный адрес и еще что-то. Сам обмен я просниффил, оказалось достаточно просто, в пакете данных нашел поля адреса, в этом я точно уверен. Все остальные данные пока не известны, где находятся в пакете, но главное - в конце пакета (подозреваю очень сильно!) есть поле какой-то контрольной суммы. Во всяком случае, при изменении буквально 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% уверенности в назначении этих байтов нет)
--------------------
Я бы взял частями... но мне надо сразу.
|
|
|
|
|
Apr 6 2018, 16:17
|
Профессионал
Группа: Свой
Сообщений: 1 143
Регистрация: 30-09-08
Из: Новочеркасск
Пользователь №: 40 581
|
Цитата(Baser @ Apr 6 2018, 17:35) Вообщем попробовать подбором. Собственно, для подбора нужен какой-то автоматизированный инструмент, иначе просто нереально. Знаете такой? Цитата(adnega @ Apr 6 2018, 17:43) А возможно ли получить один и тот же пакет два раза? У таких пакетов последние 4 байта будут совпадать? пока что не удалось добиться такого, при каждой передаче по непонятному алгоритму меняются 5-7 байты. Пока что я не выявил их назначение, поэтому не могу сказать, возможно ли добиться повторяемости.
--------------------
Я бы взял частями... но мне надо сразу.
|
|
|
|
|
Apr 6 2018, 17:00
|
Гуру
Группа: Свой
Сообщений: 2 724
Регистрация: 14-05-07
Из: Ярославль, Россия
Пользователь №: 27 702
|
Цитата(ARV @ Apr 6 2018, 19:17) пока что не удалось добиться такого, при каждой передаче по непонятному алгоритму меняются 5-7 байты. Пока что я не выявил их назначение, поэтому не могу сказать, возможно ли добиться повторяемости. Тут уже грустно. Если контрольная информация используется для проверки целостности сообщения приемной стороной, то это одна ситуация. Если это нужно для защиты протокола от несанкционированного использования - то совершенно другая. Скорее всего, используется некий seed, для какой-нить псевдослучайной последовательности, но в этом случае можно было бы весь обмен обфусцировать.
|
|
|
|
|
Apr 7 2018, 09:35
|
Профессионал
Группа: Свой
Сообщений: 1 123
Регистрация: 8-03-09
Из: Днепр
Пользователь №: 45 848
|
Цитата(ARV @ Apr 6 2018, 19:17) Собственно, для подбора нужен какой-то автоматизированный инструмент, иначе просто нереально. Знаете такой? . . . Очень давно переписывал ф-ию подсчета CRC для универсального применения (те с любым полиномом, с любым направлением сдвига и старт. значением). Это не очень сложно. Стандартных полиномов не так много. Направления сдвига - 2 (оноже - "зеркальный" полином). Стандартные длины 8-16-32, плюс может быть не стандартная, например 24. Но "рояль" может не сработать, даже при правильном подборе алгоритма CRC, если девайс при подсчете суммы добавляет скрытые байты в подсчет. (те они включаются в подсчет для каждого пакета на сторонах передатчика и приемника в качестве константы, но через канал связи не передаются) ps В пакете могут присутствовать байты, которые не должны включаться в подсчет CRC. А есть возможность не сниффить, а "стрельнуть" в приемник своим пакетом ("ловить на живца")
|
|
|
|
|
Apr 7 2018, 13:28
|
Профессионал
Группа: Свой
Сообщений: 1 143
Регистрация: 30-09-08
Из: Новочеркасск
Пользователь №: 40 581
|
Цитата(k155la3 @ Apr 7 2018, 12:35) А есть возможность не сниффить, а "стрельнуть" в приемник своим пакетом ("ловить на живца") Это, разумеется, один из этапов "взлома", но пока что я к нему не приступил. Все вами сказанное я понимаю, но продолжаю надеяться, что не все так сложно, особенно со скрытыми байтами. Просто система не та, чтобы так стараться сделать её невзламываемой, главное - обеспечить надежность передачи по ИК-каналу, который, в принципе, достаточно "грязный". Так что я все-таки надеюсь, что слишком хитрых трюков не будет... Мне вот уже подсказали, что XOR первых пяти байтов даёт НОЛЬ, хотя АДРЕС содержится только в первых трех - может быть, эта часть и не входит в общую КС... но 4 байта КС - это намекает на CRC32, что выглядит явно избыточным для пакета из 39 байт...
--------------------
Я бы взял частями... но мне надо сразу.
|
|
|
|
|
Apr 7 2018, 15:13
|
Гуру
Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095
|
QUOTE (ARV @ Apr 7 2018, 15:28) но 4 байта КС - это намекает на CRC32, что выглядит явно избыточным для пакета из 39 байт... Там может быть, например, 2 байта обычной суммы и 2 байта контрольной суммы Флетчера. Я бы на вашем месте обратил пристальное внимание на сообщение от _pv.
--------------------
На любой вопрос даю любой ответ"Write code that is guaranteed to work, not code that doesn’t seem to break" ( C++ FAQ)
|
|
|
|
|
Apr 9 2018, 19:53
|
Профессионал
Группа: Свой
Сообщений: 1 032
Регистрация: 13-03-08
Из: Маськва
Пользователь №: 35 877
|
Мысли на уровне ".опой чую": - передатчик 1, пакеты 1 и 4. Изменился 1 байт данных, изменились [1] и [3] байты КС. - передатчик 2, пакеты 1 и 3. Полностью аналогично. - все остальные варианты - КС меняется значительно.
Имхо, Сергей Борщ прав - это какие-то костыли для совместимости, и две двухбайтовые КС одна в другой. И _pv прав, это не настоящий CRC / Флетчер / что-то продвинутое. Там от смены одного бита всё переворачиваться должно, а мы этого не видим.
И да, если это две КС, может прокатить халява - одна из них не проверяется. "Испорченные" посылки пробовали?
--------------------
Тут обсуждается творческий порыв, а не соответствие каким-либо стандартам ©
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|