Версия для печати темы

Нажмите сюда для просмотра этой темы в обычном формате

Форум разработчиков электроники ELECTRONIX.ru _ Форумы по интерфейсам _ Взлом протокола обмена

Автор: ARV Apr 6 2018, 13:08

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

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

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

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

Автор: adnega Apr 6 2018, 13:43

Цитата(ARV @ Apr 6 2018, 16:08)

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

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

Автор: ARV Apr 6 2018, 16:17

Цитата(Baser @ Apr 6 2018, 17:35)

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

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

Цитата(adnega @ Apr 6 2018, 17:43)

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

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

Автор: adnega Apr 6 2018, 17:00

Цитата(ARV @ Apr 6 2018, 19:17)

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

Автор: Baser Apr 6 2018, 20:22

Цитата(ARV @ Apr 6 2018, 19:17)

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

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

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

Автор: ARV Apr 7 2018, 05:36

Цитата(Baser @ Apr 7 2018, 00:22)

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

Я же говорю, что простое решение - http://electronix.ru/redirect.php?http://reveng.sourceforge.net/ - результата не даёт, надо что-то оригинальнее...

Автор: _pv Apr 7 2018, 05:59

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

Автор: k155la3 Apr 7 2018, 09:35

Цитата(ARV @ Apr 6 2018, 19:17)

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

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

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

Автор: ARV Apr 7 2018, 13:28

Цитата(k155la3 @ Apr 7 2018, 12:35)

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

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

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

Автор: Сергей Борщ Apr 7 2018, 15:13

QUOTE (ARV @ Apr 7 2018, 15:28)

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

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

Автор: ARV Apr 8 2018, 11:42

Цитата(Сергей Борщ @ Apr 7 2018, 18:13)

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

Автор: k155la3 Apr 8 2018, 13:51

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

Автор: ARV Apr 8 2018, 18:22

Цитата(k155la3 @ Apr 8 2018, 16:51)

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

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

Автор: esaulenka Apr 9 2018, 19:53

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

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

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

Автор: ARV Apr 10 2018, 07:51

Я набрал еще пакетов для статистики. Выяснилось, что пакеты передатчиков, которые полежали два дня сильно отличаются от ранее полученных, т.е. пока девайсы спят, они живут. Но каких-то кардинальных знаний новые пакеты не прибавили. Каждая строка в нижеследующих дампах - это отдельный пакет, интервалы между передачами пакетов примерно одинаковые - секунд 15-20.

Код

7310072541    2004 48    0000000000000000000000008240C1000041824244404242003F12    4B89E468
7310072541    4060 48    0000000000000000000000008240C1000041824244404242003F12    47778004
7310072541    6000 48    0000000000000000000000008240C1000041824244404242003F12    0166E062
7310072541    2004 48    0000000000000000000000008240C1000041824244404242003F12    4B89E468
7310072541    4060 48    0000000000000000000000008240C1000041824244404242003F12    47778004
7310072541    6000 46    0000000000000000000000008240C1000041824244404242003F12    01E6E06C
7310072541    2004 46    0000000000000000000000008240C1000041824244404242003F12    4B09E466
7310072541    4060 46    0000000000000000000000008240C1000041824244404242003F12    47F7800A
7310072541    6000 46    0000000000000000000000008240C1000041824244404242003F12    01E6E06C
7310072541    2004 46    0000000000000000000000008240C1000041824244404242003F12    4C0EE461

724F1BBA9C    6100 10    0000000000000001000002000081840000000000000000005C3C12    01FD3D39
724F1BBA9C    210B 10    0000000000000001000002000081840000000000000000005C3C12    0C423674
724F1BBA9C    4162 10    0000000000000001000002000081840000000000000000005C3C12    FD795FE5
724F1BBA9C    6100 10    0000000000000001000002000081840000000000000000005C3C12    01FD3D39
724F1BBA9C    210B 10    0000000000000001000002000081840000000000000000005C3C12    0C423674
724F1BBA9C    4162 10    0000000000000001000002000081840000000000000000005C3C12    FD795FE5
724F1BBA9C    6100 10    0000000000000001000002000081840000000000000000005C3C12    01FD3D39
724F1BBA9C    210B 10    0000000000000001000002000081840000000000000000005C3C12    0D433675
724F1BBA9C    4162 10    0000000000000001000002000081840000000000000000005C3C12    FD795FE5
724F1BBA9C    6100 10    0000000000000001000002000081840000000000000000005C3C12    01FD3D39

730761BAAF    2005 38    000000000000000000000000408080000000000000000000000012    72A86A57
730761BAAF    4060 38    000000000000000000000000408080000000000000000000000012    699B0F2C
730761BAAF    6000 38    000000000000000000000000408080000000000000000000000012    01A46F64
730761BAAF    2005 38    000000000000000000000000408080000000000000000000000012    72A86A57
730761BAAF    4060 38    000000000000000000000000408080000000000000000000000012    699B0F2C
730761BAAF    6000 38    000000000000000000000000408080000000000000000000000012    01A46F64
730761BAAF    2005 36    000000000000000000000000408080000000000000000000000012    73296A58
730761BAAF    4060 36    000000000000000000000000408080000000000000000000000012    691B0F22
730761BAAF    6000 36    000000000000000000000000408080000000000000000000000012    01246F6A
730761BAAF    2005 36    000000000000000000000000408080000000000000000000000012    73296A58

734F33656A    2000 76    7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012    01073806
734F33656A    4000 6C    7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012    03D0387E
734F33656A    600C 6C    7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012    830234DE
734F33656A    2000 6C    7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012    0199381C
734F33656A    4000 6C    7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012    03D0387E
734F33656A    600C 6C    7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012    830234DE
734F33656A    2000 6C    7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012    0199381C
734F33656A    4000 6C    7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012    03D0387E
734F33656A    600C 6A    7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012    830734D8
734F33656A    2000 6A    7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012    029F3819

Однозначно очевидно, что первые 5 байт - это адрес передатчика, хотя значащих байт там только 3 и то без старших 2 бит. XOR этих 5-и байтов всегда равен 00, т.е. последний байт - это XOR-КС, а предыдущий - какой-то довесок, подгоняющий КС до нуля.

Следующие 2 байта абсолютно закономерно от передачи к передаче меняются попарно и по кругу, т.е. каждая третья передача будет иметь те же самые значения в этих байтах. Закономерность явно есть, но что это может значить? передавать 3 варианта по кругу - зачем?!

Следующий байт от передачи к передаче имеет тенденцию к закономерному уменьшению, но после длительной паузами между передачами значение байта снова возрастает (по показанным дампам это не видно, но это так) - подозреваю, что это напряжение на литиевой батарейке.

Дальше - неизвестно что, но всегда заканчивается на 12. Честно говоря, это как-то настораживает...

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

Но все эти закономерности пока никак не помогли мне понять, как же, блин, считаются эти КС... Пробовал при помощи reveng подбирать полиномы - ни для 16-битных, ни тем более для 32-битных не находится. пробовал брать часть пакета без адреса - тот же результат. пробовал брать без 1 или 2 последних байт, пробовал в последних 4 байтах удалять через 1, т.е. оставлять 1-3 или 2-4 байты - нулевой результат

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

Автор: Baser Apr 10 2018, 10:11

Цитата(esaulenka @ Apr 9 2018, 22:53)

... и две двухбайтовые КС одна в другой.

Может быть это инкапсуляция одного протокола другим? Типа был у них проводной протокол, запихнули его внутрь ИК-протокола. Тогда может быть две двухбайтовые контрольные суммы в конце, относящиеся к данным разной длины.

Автор: ARV Apr 10 2018, 10:21

Цитата(Baser @ Apr 10 2018, 14:11)

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

Автор: Flood Apr 10 2018, 10:30

Цитата(ARV @ Apr 10 2018, 13:21)

Часто проще изучить прошивку устройства, чем заниматься подбором.

Автор: ARV Apr 10 2018, 10:55

Цитата(Flood @ Apr 10 2018, 14:30)

Часто проще изучить прошивку устройства, чем заниматься подбором.

Вы всерьез верите, что она незалоченная?!

Автор: vesago Apr 10 2018, 18:01

Случаем не для буренок таги? http://electronix.ru/redirect.php?https://electronix.ru/forum/index.php?showtopic=133779&hl=

Автор: ARV Apr 10 2018, 18:29

Для них, родимых.
Я продвинулся куда дальше всех, но все равно уперся в КС

Автор: vesago Apr 10 2018, 20:01

Однако. Не думал, что кто-то еще в такой области работает Мне нужно было слепить эмулятор ридера этих тагов, чтобы вместо них системе скармливать RFID какие. Главное, чтобы ID коровы отбивался. Я на атмеге смастерил аппарат, который передавал на шину блок данных. К сожалению с контрольной суммой не разобрался. Поэтому были заготовки, слитые с реальных тагов. Эти сэмплы и передавал. С виду контрольная сумма линейная. Не полиномы-хэши. Но проект заглох, поэтому дальше не разбирался.

Автор: ARV Apr 11 2018, 04:22

Цитата(vesago @ Apr 11 2018, 00:01)

Но проект заглох, поэтому дальше не разбирался.

Не заглох, как видите... Всё ещё надеюсь разломать протокол...

Автор: vesago Apr 11 2018, 06:01

В таге у меня стоял MSP430. Я пробовал подцепиться - залочен был. Аналитически, подбором алгоритма чисто, тяжковато расколоть. Надо как-то заставить дивайс незначительно данные менять. Или слепить эмулятор и перебором пытаться формировать пакеты, пока не скормятся. Я, помню, тоже пытался и микрофон отпаивать, и не шевелил, а он все равно вываливал кучу измененных данных.

Автор: ARV Apr 11 2018, 08:54

Цитата(vesago @ Apr 11 2018, 10:01)

У меня все то же самое, разве что я даже не пытался подключаться к контроллеру по очевидной причине защищенности. А остальное - так и есть. Данные меняются сами по себе, связи с внешним миром при этом не прослеживается. Но кое-что по формату стало понятнее... кроме КС.

Автор: Baser Apr 11 2018, 09:00

Цитата(vesago @ Apr 11 2018, 09:01)

В таге у меня стоял MSP430. Я пробовал подцепиться - залочен был.

А какой тип и ревизия? У них кое-где был дырявый бутлодер, который до сих пор выпускают.

Автор: vesago Apr 11 2018, 09:17

Цитата(Baser @ Apr 11 2018, 12:00)

А какой тип и ревизия? У них кое-где был дырявый бутлодер, который до сих пор выпускают.

У меня вот такой

Наверное, все-таки неподцепливался. Не вижу следов пайки. Надо будет попробовать из спортивного интереса. Может и незалочен. По всякому бывает. В последнее время я работал с 6 буржуйскими платами. Из них 4 незалочены.

Автор: k155la3 Apr 11 2018, 09:34

Цитата(ARV @ Apr 8 2018, 21:22)

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

1. Приемник может быть (и скорее всего для этого применения есть) селективный. (принимает только "свои" корректные пакеты).
2. Если используется даже примитивное шифрование данных (XOR по всем или части данных), то разломать будет трудно.
Под разломать я понимаю разобраться как формируется CRC или чего оно там.
CRC может считаться с динамически изменяемым стартовым значением. Эти 2 или 4 байта могут передаваться в начале пакета (не обязательно).
3. То что меняется в пакетах - возможно - температура чипа. (не помню в F149 есть или нет встроенный ADC температуры)
Онаже может использоваться для кодирования в качестве "случайного" числа.
Также возможно передается данные о состоянии батарей.

Автор: vesago Apr 11 2018, 09:41

Во как на объекте выглядит

Автор: Baser Apr 11 2018, 09:57

Цитата(vesago @ Apr 11 2018, 12:17)

У меня вот такой

Судя по всему это Rev.N
У него бутлодер v1.10 - дырка там есть, и эти ревизии http://electronix.ru/redirect.php?https://electronix.ru/forum/index.php?showtopic=145244.

Немного занимался этим вопросом. Лет 10 назад коллеги с сахары и электроникса расковыряли этот вопрос и даже выложили на всеобщее обозрение. Но вскоре по просьбе заинтересованных людей все почистили, дабы не давать в руки совсем уж "пионеров". Я когда год назад искал, уже ничего не нашел, но указаний куда копать достаточно. По моим прикидкам, для спецов нашего уровня хватит пары недель для написания считывалки прошивки, использующую эту уязвимость.

Автор: k155la3 Apr 11 2018, 10:42

Цитата(Baser @ Apr 11 2018, 12:57)

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

I D A отлично разбирается с кодом MSP430. Достаточно будет добраться до нижнего уровня формирования пакета. Пара дней максимум.
Далее взять тотже процессор и "рестартовать" клона уже на HW.

Автор: ARV Apr 11 2018, 11:41

К сожалению, семейство MSP430 для меня абсолютно неизвестное, никаких средств для работы с ним нет И даже по поводу ревизии я не понял - как её определить? Что за баг в бутлодыре, какие указания? Боюсь, что в разумное время я ответы на все эти вопросы не найду.

Автор: k155la3 Apr 11 2018, 13:03

Цитата(ARV @ Apr 11 2018, 14:41)

К сожалению, семейство MSP430 для меня абсолютно неизвестное, никаких средств для работы с ним нет

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

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

---
Если есть подопытный "кролик", попробуйте поснифить его инф. при разной температуре девайса
(нагретый мешочек с песком или лежалый в морозилке). Возможно удасться выловить поля в пакете, которые реагируют на это.
Ну, и напряжение батареи. Правда это опасно, тк при отключении батареи девайс может запросить сервис-обслуживания на спец-программаторе.

Автор: ARV Apr 11 2018, 13:11

Способы выделения полей в пакете в общих чертах мне известны, и какой-то успех в этом направлении есть. Но задача у меня стоит прежняя: научиться подсовывать свои данные в пакет. То поле, которое надо менять - поле адреса, - я уже вычленил на 100% в пакете. Остается совсем "пустяк" - подсунуть новый адрес в пакет так, чтобы приемник не заподозрил подвоха. И тут, к несчастью, знание остальных полей пакета очень мало поможет...

Кроме реверсинга прошивки и чистого везения с угадыванием, существуют ли какие-то подходы к раскрытию алгоритма КС? Может, я просто не знаю, как надо и пытаюсь изобрести велосипед?

Автор: k155la3 Apr 11 2018, 15:16

Цитата(ARV @ Apr 11 2018, 16:11)

. . . И тут, к несчастью, знание остальных полей пакета очень мало поможет...

Тут чем больше известной информации, тем лучше.
Ну, самый примитив - попробуйте поменять байты в последниих парах байт, может big-little endian - "счастливый случай"

и прогоните по стандартным CRC.
Поскольку здесь отмечали, что при изменении данных КС меняется "не очень", то возможно
в поледних 4 байтах сидит нечто CRC16, а в "лишних" 16 битах случайное число или шифр-код (это те биты, которые не меняются).
Для этого надо смотреть на бинарное представление этих 4 байт в выборке пакетов, смотреть "столбиком".
Возможно увидите "замерзшие" колонки нуля или единицы.
Это может быть ключ кодирования, общий для приемника и передатчиков.

Автор: halfdoom Apr 12 2018, 07:23

Цитата(ARV @ Apr 11 2018, 16:11)

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

А вы пробовали просто менять адрес и передавать остаток пакета как есть? Мне попадался счетчик, который при работе по IRDA протоколу анализировал поле адреса, в котором последним байтом шла КС адреса, а затем отдельно считал КС для оставшихся данных.

Что касается поиска алгоритма подсчета КС, то повезти может только в случае, если разработчик использовал что-то известное т.к. даже разгадать даже незначительную "адаптацию" весьма сложно из за большого количества неизвестных. Конечно, прежде чем отчаиваться, следует попробовать получить пакеты отличающиеся всего одним битом. Но самый быстрый способ, это, как уже говорили, попробовать слить прошивку.

Автор: ARV Apr 12 2018, 08:29

При помощи reveng я пробовал перебор (т.е. брутфорс) 8, 16, 24 и 32-битные варианты CRC для:
- полного пакета
- полного пакета с инверсией
- пакета без адреса
- пакета без адреса и без 1-2 байт в начале
- пакета без адреса и без 1,2,3 и 4 байт в конце
- пакет с адресом и без 1,2,3 и 4 байт в конце
- пакет без байта, находящегося перед предполагаемой КС и всегда имеющим значение 12
- пакет с адресом и без, у которого из 4 последних байт удалены четные или нечетные байты
все предыдущие варианты показали, что ВСЕ полиномы с начальным обнулением "регистра" и с заполнением, а так же с XOR в конце и без него, не подходят...

Автор: Сергей Борщ Apr 12 2018, 09:04

QUOTE (ARV @ Apr 12 2018, 10:29)

При помощи reveng я пробовал перебор (т.е. брутфорс) 8, 16, 24 и 32-битные варианты CRC

Уже много раз писали, что это не CRC. У CRC при изменении пары битов в сообщении никогда не будет изменения пары же битов в контрольной сумме - их будет значительно больше. Так что пробуйте что-то более простое - исключающее "ИЛИ", сумму, сумму с исключающим "ИЛИ", сумму с дополнением до нуля или другого числа и т.п.

Автор: ARV Apr 12 2018, 09:13

Так там и нет изменения пары битов, там все 4 байта меняются.

Цитата

734F33656A 2000 6C 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012 0199381C
734F33656A 4000 6C 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012 03D0387E

XOR и суммирование я пробовал, естественно, но, т.к. вариантов много, либо не нашел правильный, либо это в принципе не то...

Есть странная закономерность, но не могу понять, к чему она может привести: в последних 4 байтах всех пакетов одного и того же транспондера четные и нечетные байты слева направо связаны друг с другом.
Поясняю примером ABCD - 4 последних байта. Так вот, любому значению байта А всегда будет соответствовать одно и то же значение байта C, а для В соответственно D. Но обратной связи нет, т.е. к одному и тому же байту С могут "приводить" разные байты А.

Автор: k155la3 Apr 12 2018, 09:27

Цитата(ARV @ Apr 11 2018, 16:11)

. . . . Может, я просто не знаю, как надо и пытаюсь изобрести велосипед?

Мы все тут "не знаем как надо", поскольку этот процесс называется криптоаналитика, крутая весч основанная на математике, алгоритмах кодирования-декодирования, разделы мат. статистики и вероятностях и тд. Ну и мощных компах. А кто знает - помалкивает

---
Я Вам предлагал поискать описание системы и сертификат на ее безопасность-защищенность. Если ОН подразумевает шифрование (даже не пакета а только контрольного кода), то на мой взгляд разобраться не получится.
Можно было бы "погрузить" приемник бутфорсом пакетами с нулевыми байтами данных и "подбираемой" КС из 4 байт.
При таймауте "отзыва" приемника 1с на это уйдет сотня лет

Через 100 лет мы имеем статистический массив "правильных" пакетов всего лишь для одного (!) набора данных

---
Для начала все-же проверьте все поля пакета на "замерзшие" на одних позициях биты.
ps - и их "взаимозависимость" / корреляцию между собой (это по поводу ABCD)

Автор: ARV Apr 12 2018, 10:43

Я умом понимаю сложность задачи... но надеюсь еще пока на успех.
Не знаете какой-то софт, который бы позволял как-то автоматизировать хотя бы то, что вы посоветовали (а своих идей у меня тоже не мало)? Ну, например, быстро переводить HEX-строку в бинарный вид, инвертировать, XOR-ить и т.п. манипуляции делать? Основное время уходит именно на ручное преобразование и расписывание карандашиком...

Для логического анализатора софт вроде как весьма помог, но почему разработчики этого софта не додумались делать "стек" захваченных сигналов, чтобы можно было визуально сравнивать "этот" и "тот" или "пред-предыдущий"? И экспорт тоже та еще беда: для одной программы надо строку в том виде, как я тут привожу, т.е. без префиксов 0x, а лог.анализатор пишет с префиксами, да еще в CSV-таблице... пока вручную переформатируешь...

Я, конечно, что-то пописываю сам себе в помощь, но ведь на каждый случай утилитку писать тоже не самый оптимальный вариант по усилиям и срокам. Неужели ничего готового нет?

Цитата(k155la3 @ Apr 12 2018, 13:27)

Если ОН подразумевает шифрование (даже не пакета а только контрольного кода), то на мой взгляд разобраться не получится.

Это, будучи в отрыве от реальности, безусловно верно. Но логическое размышление не находит причин, по которым идентификатор коровы должен передавать инфу о том, активно она жует или нет, в зашифрованном виде... Да и тот факт, что адрес передается полностью в "сыром" виде (правда, старшими байтами вперед), как-то с шифрованием уже не вяжется...

Автор: _pv Apr 12 2018, 10:44

последние два байта - тупо xor от первых 18ти 16ти битных слов

Код

734F33656A 2000 6C 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C00001201 99 381C
hex($734F xor $3365 xor $6A20 xor $006C xor $7B7B xor $7B7B xor $7B7B xor $7B7B xor $7B7B xor $7B00 xor $0C0C xor $0C0C xor $0C0C xor $0C0C xor $0C0C xor $0C0C xor $0000 xor $1201)
$381C

734F33656A 600C 6C 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C00001283 02 34DE
hex($734F xor $3365 xor $6A60 xor $0C6C xor $7B7B xor $7B7B xor $7B7B xor $7B7B xor $7B7B xor $7B00 xor $0C0C xor $0C0C xor $0C0C xor $0C0C xor $0C0C xor $0C0C xor $0000 xor $1283)
$34DE

724F1BBA9C 4162 10 0000000000000001000002000081840000000000000000005C3C12FD 79 5FE5
hex($724F xor $1BBA xor $9C41 xor $6210 xor $0000 xor $0000 xor $0000 xor $0001 xor $0000 xor $0200 xor $0081 xor $8400 xor $0000 xor $0000 xor $0000 xor $0000 xor $5C3C xor $12FD)
$5FE5

Автор: ARV Apr 12 2018, 10:54

Цитата(_pv @ Apr 12 2018, 14:44)

последние два байта - тупо xor от первых 18ти 16ти битных слов

золотой вы мой человек!!!! приду домой - прошерстю все накопленные массивы - это ведь будет просто счастье, если вы правы!!!

я-то тупил на байте 12 перед 4-я последними - он всегда и во всех пакетах на одном и том же месте...

Автор: k155la3 Apr 12 2018, 11:00

Цитата(ARV @ Apr 12 2018, 13:36)

Я умом понимаю сложность задачи... но надеюсь еще пока на успех.
. . .
Неужели ничего готового нет?

"Готовое" есть, но в "очень специальных местах", где сидят "специальные" люди и чтут УК.
Можете посмотреть на github.com - искать "cryptoanalyze".
----
Вы тут помянули "идеи". Еще одна

Возможно в контрольном коде используется какой либо корректирующий-исправляющий код
вроде Хемминга. Ну, а если "идеи" не требуются - то удачи

ps вот КС в бинарном виде. Переводил вручную, возможны ошибки.

Код

0000 0001 0011 0000 1110 0111 1111 0110        01 30 E7 F6
1101 0000 0001 0011 1000 0101 0000 0101        D0 13 85 05
0000 0001 0001 0010 1110 0111 1100 1010        01 12 E7 CA
0000 1011 1010 1010 1110 1100 1000 0000        0B AA EC 80
0100 0111 0000 0110 0110 0010 0100 1100        47 06 62 4C
0001 1001 0010 0000 0000 0110 0111 0000        19 20 06 70
0000 0001 0110 1010 0110 0110 0100 1110        01 6A 66 4E
0111 1000 0000 1100 0100 1110 0100 0101        78 0C 4E 45
0111 0001 0110 1101 0110 0010 1000 0111        71 6D 62 87
0011 1011 1000 0000 0000 0111 1010 1001         3B 80 07 A9
0000 0001 0110 1101 0110 0111 1011 1101        01 6D 67 BD
0111 0001 0010 0000 0110 0010 1000 1000        71 20 62 88
0000 0001 1001 1001 0011 1000 0001 1100        0199381C
0000 0011 1101 0000 0011 1000 0111 1110         03D0387E

psps
функция С для преобразования int или long из бинарного вида в символьный
itoa(src,ascptr,2) ltoa(src,ascptr,2)

Автор: ARV Apr 12 2018, 11:04

Идеи требуются.
Но еще сильнее требуется какое-то обсуждение, потому что в одну голову думать - с ума сходишь, а толку ноль. А единомышленников нет вокруг
_pv вон какое классное предложение произнес: все ТУПО! причем, если посмотреть, то 5-й байт есть XOR предыдущих 4-х. теперь логично предположить, что есть третий с конца байт - и дело в шляпе! тут уже и перебором можно взять приемник на измор
лишь бы _pv оказался прав на всех пакетах всех транспондеров...

Автор: _pv Apr 12 2018, 11:22

четвертый с конца байт - не КС, есть пакеты где только он и отличается
7310072541 2004 46 0000000000000000000000008240C1000041824244404242003F12 4B 09 E466
7310072541 2004 46 0000000000000000000000008240C1000041824244404242003F12 4C 0E E461

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

Автор: k155la3 Apr 12 2018, 11:53

Цитата(_pv @ Apr 12 2018, 14:22)

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

Хемминг код работает на базе XOR "зигзагом" по разрядам.

Автор: _pv Apr 12 2018, 12:06

Цитата(k155la3 @ Apr 12 2018, 18:53)

Хемминг код работает на базе XOR "зигзагом" по разрядам.

под один байт Хэмминга только 30 байт данных влазит,
да и зачем тогда считать 16ти битный xor при наличии Хэмминга? он ведь и обнаруживает ошибки лучше (двойные на том же месте простой xor пропустит) да ещё и исправляет.

Автор: k155la3 Apr 12 2018, 12:54

Цитата(_pv @ Apr 12 2018, 15:06)

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

Автор: _pv Apr 12 2018, 13:02

7310072541 2004 46 0000000000000000000000008240C1000041824244404242003F12 4B 09 E466
7310072541 2004 46 0000000000000000000000008240C1000041824244404242003F12 4C 0E E461

вот пакеты с минимальными отличиями, 4B->4C <=> 09 -> 0E разница как раз в младших трёх битах что там, что там.
Хэмминг бы другие биты тоже перевернул.
хотя есть и другие пакеты где отличий в старших битах нет вообще, а этот третий с конца байт отличается и там тоже, то есть не просто xor, а ещё с чем то.

Автор: k155la3 Apr 12 2018, 13:07

А ТС стопроцентно уверен, что пакеты "проснифферены" без ошибок ? (проверить-то их пока невозможно без КС) ?

Автор: ARV Apr 12 2018, 13:17

Только что проверил на всех имеющихся на сегодня дампах - при выбрасывании третьего с конца байта XOR двухбайтных слов всегда 0000!
Предположение _pv полностью подтвердилось!

Цитата(k155la3 @ Apr 12 2018, 17:07)

А ТС стопроцентно уверен, что пакеты "проснифферены" без ошибок ? (проверить-то их пока невозможно без КС) ?

Вы считаете, можно ошибиться в снятии протокола с выхода ИК-приемника типа TSOP при помощи логического анализатора? Снятый поток импульсов крайне удачно ложится на традиционный UART 4800

и более того, адрес в этом пакете на самом деле тот, который написан на транспондере, следовательно, протокол просниффен корректно

Тут еще в голову одна мысль пришла... размер пакета 39 байт - какая-то странная цифра... чтобы предположение _pv работало, надо 1 байт выкидывать. Но 39 делится на 3 - буду пробовать трехбайтные XOR-ы в разных комбинациях. Есть в этом смысл по вашему мнению или я снова тупить начинаю?

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

Автор: vesago Apr 12 2018, 13:23

Да, у них обычный UART 4800. По крайней мере ридер в сети на ней общается. Инверсный уарт.

Автор: _pv Apr 12 2018, 13:26

Цитата(ARV @ Apr 12 2018, 20:17)

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

730761BAAF 2005 38 000000000000000000000000408080000000000000000000000012 72 A8 6A57
730761BAAF 2005 36 000000000000000000000000408080000000000000000000000012 73 29 6A58

данные отличаются только в четырёх младших битах, бит0: 2->3 бит1-3: 8->6
никаким xorом это не может изменить старшие биты A8->29

Автор: k155la3 Apr 12 2018, 18:06

А как передатчик узнает, что ему надо передать инф. на приемник ?
Есть ли обратный канал связи, от приемника на передатчик ?

Автор: ARV Apr 12 2018, 18:56

Цитата(k155la3 @ Apr 12 2018, 21:06)

Есть: в приемнике есть газоразрядная импульсная лампа типа ИФК-120, она даёт вспышку, которая запускает передачу передатчика. У него есть фотодиоды, которые на эту вспышку реагируют. Никакой информации в сторону передатчика не передается, только один импульс.

Русская версия Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)