ARV 1 6 апреля, 2018 Опубликовано 6 апреля, 2018 · Жалоба Коллеги! Прошу помочь, хотя бы советом, в решении проблемы реверс-инжиниринга ИК-протокола обмена. Есть "фирменная" система, состоящая из приемника ИК-сигналов и кучи передатчиков сигнала. Передатчики посылают пакеты данных, в которых есть их собственный адрес и еще что-то. Сам обмен я просниффил, оказалось достаточно просто, в пакете данных нашел поля адреса, в этом я точно уверен. Все остальные данные пока не известны, где находятся в пакете, но главное - в конце пакета (подозреваю очень сильно!) есть поле какой-то контрольной суммы. Во всяком случае, при изменении буквально 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 5 6 апреля, 2018 Опубликовано 6 апреля, 2018 · Жалоба Если CRC стандартная, то можно попробовать перебрать популярные полиномы (стандарты). Для CRC32 вроде популярных немного, но могут быть нюансы: сдвиг вправо/влево, начальное значение, пост инверсия. Еще могут не все байты пакета охватывать CRC. Вообщем попробовать подбором. Мне такое один раз удалось для CRC16, правда там все было исключительно стандартно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 6 апреля, 2018 Опубликовано 6 апреля, 2018 · Жалоба в конце пакета (подозреваю очень сильно!) есть поле какой-то контрольной суммы. Во всяком случае, при изменении буквально 1-2 битов в пакете 4 последних байта сильно меняются, что наталкивает... А возможно ли получить один и тот же пакет два раза? У таких пакетов последние 4 байта будут совпадать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ARV 1 6 апреля, 2018 Опубликовано 6 апреля, 2018 · Жалоба Вообщем попробовать подбором. Собственно, для подбора нужен какой-то автоматизированный инструмент, иначе просто нереально. Знаете такой? А возможно ли получить один и тот же пакет два раза? У таких пакетов последние 4 байта будут совпадать? пока что не удалось добиться такого, при каждой передаче по непонятному алгоритму меняются 5-7 байты. Пока что я не выявил их назначение, поэтому не могу сказать, возможно ли добиться повторяемости. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 6 апреля, 2018 Опубликовано 6 апреля, 2018 · Жалоба пока что не удалось добиться такого, при каждой передаче по непонятному алгоритму меняются 5-7 байты. Пока что я не выявил их назначение, поэтому не могу сказать, возможно ли добиться повторяемости. Тут уже грустно. Если контрольная информация используется для проверки целостности сообщения приемной стороной, то это одна ситуация. Если это нужно для защиты протокола от несанкционированного использования - то совершенно другая. Скорее всего, используется некий seed, для какой-нить псевдослучайной последовательности, но в этом случае можно было бы весь обмен обфусцировать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Baser 5 6 апреля, 2018 Опубликовано 6 апреля, 2018 · Жалоба Собственно, для подбора нужен какой-то автоматизированный инструмент, иначе просто нереально. Знаете такой? Я в свое время, не зная ничего кроме Си и микроконтроллеров, набрал стандартных алгоритмов и прямо в отладчике МК прокрутил несколько десятков вариантов для перехваченной посылки с CRC. Повезло, подобрал. Сейчас, думаю, для стандартных полиномов должны быть программы перебора по известному пакету. Ибо ничего сложного в такой программе нет. Нужно поискать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ARV 1 7 апреля, 2018 Опубликовано 7 апреля, 2018 · Жалоба Сейчас, думаю, для стандартных полиномов должны быть программы перебора по известному пакету. Ибо ничего сложного в такой программе нет. Нужно поискать. Я же говорю, что простое решение - reveng - результата не даёт, надо что-то оригинальнее... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 77 7 апреля, 2018 Опубликовано 7 апреля, 2018 · Жалоба Первая и четвертая строки отличаются на пару бит, 12 <-> 1C и "контрольные суммы" отличаются не особо. Должно быть что-то вроде суммы/произведения, у обычной CRC не было бы такой похожести при малых изменениях. Адрес скорее первые пять байт а не три. Ну и данных маловато, по четырем посылкам состоящим в основном из нулей не разобраться. И ещё надо как-то повоздействовать на датчики, чтобы показания менялись, и эти изменения отслеживать в данных. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 27 7 апреля, 2018 Опубликовано 7 апреля, 2018 · Жалоба Собственно, для подбора нужен какой-то автоматизированный инструмент, иначе просто нереально. Знаете такой? . . . Очень давно переписывал ф-ию подсчета CRC для универсального применения (те с любым полиномом, с любым направлением сдвига и старт. значением). Это не очень сложно. Стандартных полиномов не так много. Направления сдвига - 2 (оноже - "зеркальный" полином). Стандартные длины 8-16-32, плюс может быть не стандартная, например 24. Но "рояль" может не сработать, даже при правильном подборе алгоритма CRC, если девайс при подсчете суммы добавляет скрытые байты в подсчет. (те они включаются в подсчет для каждого пакета на сторонах передатчика и приемника в качестве константы, но через канал связи не передаются) ps В пакете могут присутствовать байты, которые не должны включаться в подсчет CRC. А есть возможность не сниффить, а "стрельнуть" в приемник своим пакетом ("ловить на живца") :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ARV 1 7 апреля, 2018 Опубликовано 7 апреля, 2018 · Жалоба А есть возможность не сниффить, а "стрельнуть" в приемник своим пакетом ("ловить на живца") :)Это, разумеется, один из этапов "взлома", но пока что я к нему не приступил. Все вами сказанное я понимаю, но продолжаю надеяться, что не все так сложно, особенно со скрытыми байтами. Просто система не та, чтобы так стараться сделать её невзламываемой, главное - обеспечить надежность передачи по ИК-каналу, который, в принципе, достаточно "грязный". Так что я все-таки надеюсь, что слишком хитрых трюков не будет... Мне вот уже подсказали, что XOR первых пяти байтов даёт НОЛЬ, хотя АДРЕС содержится только в первых трех - может быть, эта часть и не входит в общую КС... но 4 байта КС - это намекает на CRC32, что выглядит явно избыточным для пакета из 39 байт... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 136 7 апреля, 2018 Опубликовано 7 апреля, 2018 · Жалоба но 4 байта КС - это намекает на CRC32, что выглядит явно избыточным для пакета из 39 байт...Там может быть, например, 2 байта обычной суммы и 2 байта контрольной суммы Флетчера. Я бы на вашем месте обратил пристальное внимание на сообщение от _pv. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ARV 1 8 апреля, 2018 Опубликовано 8 апреля, 2018 · Жалоба Там может быть, например, 2 байта обычной суммы и 2 байта контрольной суммы Флетчера. Я бы на вашем месте обратил пристальное внимание на сообщение от _pv.Я обращаю внимание... но не все понятно. Например, что за КС Флетчера - не ясно, в интернете что-то непонятное написано (по-русски). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 27 8 апреля, 2018 Опубликовано 8 апреля, 2018 · Жалоба А есть возможность проверить что эти пакеты принимаются корректно другим приемником ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ARV 1 8 апреля, 2018 Опубликовано 8 апреля, 2018 · Жалоба А есть возможность проверить что эти пакеты принимаются корректно другим приемником ? Приемник пока один. Статистику по пакетам буду набирать для имеющихся передатчиков... Потом буду гондобить свой передатчик и пытаться обмануть приемник... Пока это все, что в моих силах. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 9 апреля, 2018 Опубликовано 9 апреля, 2018 · Жалоба Мысли на уровне ".опой чую": - передатчик 1, пакеты 1 и 4. Изменился 1 байт данных, изменились [1] и [3] байты КС. - передатчик 2, пакеты 1 и 3. Полностью аналогично. - все остальные варианты - КС меняется значительно. Имхо, Сергей Борщ прав - это какие-то костыли для совместимости, и две двухбайтовые КС одна в другой. И _pv прав, это не настоящий CRC / Флетчер / что-то продвинутое. Там от смены одного бита всё переворачиваться должно, а мы этого не видим. И да, если это две КС, может прокатить халява - одна из них не проверяется. "Испорченные" посылки пробовали? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться