Официальный сайт компании Arduino по адресу arduino.cc
Головоломка
- Войдите или зарегистрируйтесь, чтобы получить возможность отправлять комментарии
Сб, 06/06/2020 - 21:15
Здравствуйте уважаемые знатоки!
Вкратце такое дело. Есть брелок с двумя кнопками "открыть" и "закрыть". На приёмном устройстве считываю пришедшую с него информацию, приходит 5 байт, первый 0x02, последний 0xF1, три средних несут некий "глубокий смысл". Задача в том, чтоб однозначно распознать, "закрытие" пришло или "открытие" с брелка. Ниже 10 раз нажата кнопка "открыть", потом 10 раз кнопка "закрыть". У кого есть варианты?
open: 02 A9 36 9F F1 02 05 E2 E7 F1 02 95 E6 73 F1 02 FC EF 13 F1 02 16 0D 1B F1 02 95 E6 73 F1 02 46 05 43 F1 02 E5 E2 07 F1 02 DE 0F D1 F1 02 79 F7 8E F1 close: 02 1D 87 9A F1 02 35 8E BB F1 02 4D 83 CE F1 02 52 CC 9E F1 02 D2 CC 1E F1 02 C9 30 F9 F1 02 DF 17 C8 F1 02 67 73 14 F1 02 DA EC 36 F1 02 81 20 A1 F1
A9 ^ 36 = 9F
05 ^ E2 = E7
95 ^ E6 = 73
Это что касается открытия, зависимость, думаю, понятна. Дальше рыть лень.
З.Ы. Правда, и на закрытие такая же байда - XOR первого байта со вторым (не учитываем первый и последний байт пакета) - даёт третий. Как распознать направление команды (открыть или закрыть) - пока не понятно.
Мож в битовом поле рассмотреть.
Вполне возможно, что там и есть зависимость, а XOR - типа контрольки для проверки валидности пакета. Проще прогу написать, которая выведет биты, уж больно лениво в калькуляторе пырить :)
Есть основание полагать (проверить на практике сложно - надо кромсать проводку автомобиля, очень не хотелось бы), что данная последовательность является двусторонним обменом, а именно, касаемо первой строки алгоритм такой:
брелок <-> замок ----------------- 0x20 -> // запрос ключа <- 0xA9 // случайный ключ 0x36 -> // контрольный <xor> байт 0x9F -> // хешированный ключ <- 0x1F // ключ принятВедь исходя и строк:
именно предпоследний байт является хешем второго, а 3й контрольной суммой. Т.е. нужно раскусить две 8-битных хеш-фунции вида f(A9) = 9F (открытие) и f(1D) = 9A (закрытие). Может с этим кто поможет? У самого не получается.
Т.е. нужно раскусить две 8-битных хеш-фунции вида f(A9) = 9F (открытие) и f(1D) = 9A (закрытие). Может с этим кто поможет? У самого не получается.
Предполагать-то можно всё, что угодно, по сути. Но, как верно замечено, это только предположения. Сходу зависимость не видится, если и правда используется хэш-функция, то пока хз, что там унутре.
Есть предложение: сдампить по возможности поболее кодов на открытие и закрытие, раз есть посыл, что побайтовый двусторонний обмен, то чем больше входящих данных, тем лучше.
Можно также предположить, что приемник и передатчик имеют общие приватные ключи для открытия и закрытия. Передатчик, когда нажата кнопка "открыть", применяет приватный ключ открытия на полученный случайный ключ от приемника, получает результат, вычисляет контрольку, посылает контрольку и результат. Приемник, получив пакет, обрабатывает внутри себя результат поочерёдно применяя к нему приватные ключи открытия и закрытия. Который подойдёт - такая и операция.
Следовательно, необходимо обеспечить, чтобы применение приватного ключа на блок данных давало однозначный и непересекающийся с применением другого приватного ключа на том же блоке данных, результат.
Это так, мысли вслух, может, поможет.
А меня вот смущает тот факт, что на два разных "случайных" ключа первый байт "ответа" бывает одинаков. Мошт там мусор какой подмешивается, чтобы мозги покомпассировать.
Ткни, пж, пальцем, не совсем понял, о чём конкретно речь. Интересно помозговать.
Вот и я о том, что судя по всему первый байт ответа - это контрольная сумма, а сам зашифрованный ключ идёт за ней. В том числе чтоб сходу запутать.
Можно также предположить, что приемник и передатчик имеют общие приватные ключи для открытия и закрытия. Передатчик, когда нажата кнопка "открыть", применяет приватный ключ открытия на полученный случайный ключ от приемника, получает результат, вычисляет контрольку, посылает контрольку и результат. Приемник, получив пакет, обрабатывает внутри себя результат поочерёдно применяя к нему приватные ключи открытия и закрытия. Который подойдёт - такая и операция.
Следовательно, необходимо обеспечить, чтобы применение приватного ключа на блок данных давало однозначный и непересекающийся с применением другого приватного ключа на том же блоке данных, результат.
Это так, мысли вслух, может, поможет.
Именно это я и имел в виду. Самый фиговый случай если никакой функции там нет, а просто некая жёсткая таблица соответствия. А жать кнопку до получения от замка всех вариантов "случайного" ключа можно до старости.
Ткни, пж, пальцем, не совсем понял, о чём конкретно речь. Интересно помозговать.
#5, второй блок кода
В том и смысл защиты - сделать подбор ключа экономически невыгодным мероприятием.
Но ведь можно и побрутфорсить. Там же всего байт. Значит, положим, полбайта на открытие, полбайта на закрытие. Допускаем, что второй байт - xor, т.е. пытаемся долбануть третий. сэмплы и смотрим - точно ли множество открывашек не пересекается со множеством закрывашек... Если это так - пытаемся понять, чем они отличаются или есть ли жесткое соответствие реквеста ансверу.
Ага, спасибо, увидел. Это, судя по всему, не мусор, а вполне себе контролька XOR, если предположение о существовании "f(байт) = байт" результата верно.
чтоб побрутфорсить надо либо резать проводку от трансивера, прежде сняв торпеду (это пц), либо найти аналогичный трансивер на разборке за адекватные деньги (что сделать так же не удалось). Есть ещё вариант купить у китайцев шилды к ардуинке приёмник и передатчик на 315/433МГц в надежде что и несущие частоты и модуляция совпадут, но такая вероятность сами понимаете...
есть: строки 4, 7 самого первого листинга
есть: строки 4, 7 самого первого листинга
Это уже неплохо. Может обойдется таблицей перекодировки - массивом на 255 байт.
Тогда уж 512, открытия 256 и закрытия 256. Вариант так то хороший, но для этого нужно получить ответы на все 00..FF случайные ключи, а это проблематично (см. выше). Глазом опытного криптолога бы глянуть на это действа, думаю ничего сложного, есть некая функция скорей всего. Задавал вопрос на соответственном форуме, видимо светлым головам лениво заморачиваться.
Если команда - 1 байт, то как в нее 512 значений влезет?
Тоже склоняюсь к такому мнению, имхо, так сильно проще будет, чем вычислять, через какие преобразования там проходят эти байты. Тыкаюсь и так, и эдак - пока не вижу зависимости.
Можно, конечно, брутфорсер самообучающийся написать, и скормить ему исходные данные. По идее, может что-то выдать, но это не точно. Я бы для начала постулировал, что все операнды - однобайтовые. Брал бы "случайный ключ", делал бы над ним преобразования, чтобы получить хэш. Как хэш получен - проверять эти преобразования на остальных данных. Не прошло через сито - преобразования не годны. Прошло через сито - возможно, они правильны, но это не точно :)
Короче, мутота одна, таблица соответствий - будет попроще. Но для начала я бы таки потыкал до посинения кнопку "открыть" - и снял бы огромный дамп данных. Потом - то же самое с кнопкой "закрыть". А то мы тут щас понамечтаем, что пересечений нет, а они там - бац, и появятся.
Почему единственное предположение - лень?
Если нет исходника декриптора, то без статистического анализа не обойтись, имхо.
Вот, пошукал немного: https://sourceforge.net/projects/reveng/
Надо пробовать, может, подобная тулза чего и даст.
http://ww1.microchip.com/downloads/en/DeviceDoc/Article_AC10_Turn-Key-Passive-Entry.pdf - читать с раздела "Bi-Directional Authentication" - очень интересно ;)
А вообще - было бы неплохо узнать, что за машина, что за железо, которое анализируем. А то может уже кто копался в подобном, или там известный алгоритм, а мы тут в угадайку играем.
Так эта утилита для подсчёта crc
Самое забавное будет, если результат преобразования унутре зависит от ID системы/приватного ключа, который всегда разный и шьётся на заводе.
Тогда можно сливать воду. Решение будет только для конкретного случая.
Так эта утилита для подсчёта crc
Описание точно прочитали?
It calculates reversed CRCs to give the bit pattern that produces a desired forward CRC
Что не даёт нам право отбросить возможность, что применяется один из известных алгоритмов ;)
Да скорее всего. Лично я бы так и сделал. Именно поэтому я не зря спрашивал про железо, а то - дело тёмное ;)
Если бы таблица (или алгоритм шифрования) была бы одна, все аналогичные тачки на парковке вскрывались бы разом при нажатии любого из хозяев на свой брелок. Фишка в том, что с одной стороны каждый ключ привязан к конкретной машине, с другой стороны любой ключ (имея другой, РОДНОЙ ключ от машины) можно перепривязать к любой аналогичной машине.
Чем большее становится понятно, тем понятней что ничего не понятно )))
Чем большее становится понятно, тем понятней что ничего не понятно )))
Ну уж нам-то - тем более непонятно. Может, там запорожец ушастый. Или - БелАЗ. Да чего я, в конце-концов, вымаливаю детали? Машина, так машина, перепривязать, так перепривязать.
Без огромного количества нужной конкретики - задача не решаема.
Помнится в нашей системе автоидентификации с открытым ключом, повтор кода при непрерывной работе происходил примерно через год.
Всякая подобная защита принципиально строится на том, что затраты по взлому даже относительно простого алгоритма на порядок больше цены любой машины.
DIYMan,
Mazda 6, штатный брелок центрального замка. Экспериментальным путём выяснено, что общение трансивера с блоком управления происходит по однопроводной шине с подтяжкой к +12 по протоколу UART на скорости 10750 бод. Что от этого становится понятней?
Понятно становится, что Мазда - не Жигуль и простых способов защиты в ней скорее всего нет.
Чем большее становится понятно, тем понятней что ничего не понятно )))
А ты думал это как на дуньке моргало светодиодное заваять? )))))))))))))))))))
Там будет чото-типа функции с синхрословом+сессионный ключ=пачка байт.
Самый "конкретный" способ решения твоей задачи = вскрыть бодик, вычитать прошку с проца и загнать её в эмулятор и трассирнуть функцию хеша ключа.
Ежли асилишь - дерзай. ))))))))))))))))))))))))))))))))))))
ну да, вскрыть и типа попробовать прочитать ....
Можно просто купить за десятку зелени уже считанный дамп на фрикерских площадках и не париццо с разбором блока.
DIYMan,
Mazda 6, штатный брелок центрального замка. Экспериментальным путём выяснено, что общение трансивера с блоком управления происходит по однопроводной шине с подтяжкой к +12 по протоколу UART на скорости 10750 бод. Что от этого становится понятней?
От этого становится понятней многое. Хотя бы то, что просто, быстро, дёшево - эту задачу не решить. Советую забить, реверс-инжиниринг этого дела обойдётся дороже, чем купить пустой ключ и прописать его в машине.
-NMi-
Ларёк с бесплатной раздачей KESS'ов закрылся на карантин
DIYMan
Я не говорил что мне нужен доп ключ, наоборот, мне нужно внедрить свой девайс под штатный ключ.
Что там вам надо ваще хз .
УК РФ Статья 272. Неправомерный доступ к компьютерной информации
Примечания. 1. Под компьютерной информацией понимаются сведения (сообщения, данные), представленные в форме электрических сигналов, независимо от средств их хранения, обработки и передачи.