Головоломка

vlad072
Offline
Зарегистрирован: 01.08.2017

Здравствуйте уважаемые знатоки!

Вкратце такое дело. Есть брелок с двумя кнопками "открыть" и "закрыть". На приёмном устройстве считываю пришедшую с него информацию, приходит 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 

 

DIYMan
DIYMan аватар
Offline
Зарегистрирован: 23.11.2015

A9 ^ 36 = 9F

05 ^ E2  = E7

95 ^ E6 = 73

Это что касается открытия, зависимость, думаю, понятна. Дальше рыть лень.

З.Ы. Правда, и на закрытие такая же байда - XOR первого байта со вторым (не учитываем первый и последний байт пакета) - даёт третий. Как распознать направление команды (открыть или закрыть) - пока не понятно.

sadman41
Offline
Зарегистрирован: 19.10.2016

Мож в битовом поле рассмотреть.

DIYMan
DIYMan аватар
Offline
Зарегистрирован: 23.11.2015

sadman41 пишет:
Мож в битовом поле рассмотреть.

Вполне возможно, что там и есть зависимость, а XOR - типа контрольки для проверки валидности пакета. Проще прогу написать, которая выведет биты, уж больно лениво в калькуляторе пырить :)

vlad072
Offline
Зарегистрирован: 01.08.2017
open:
00000010 10101001 00110110 10011111 11110001
00000010 00000101 11100010 11100111 11110001
00000010 10010101 11100110 01110011 11110001
00000010 11111100 11101111 00010011 11110001
00000010 00010110 00001101 00011011 11110001
00000010 10010101 11100110 01110011 11110001
00000010 01000110 00000101 01000011 11110001
00000010 11100101 11100010 00000111 11110001
00000010 11011110 00001111 11010001 11110001
00000010 01111001 11110111 10001110 11110001
close:    
00000010 00011101 10000111 10011010 11110001
00000010 00110101 10001110 10111011 11110001
00000010 01001101 10000011 11001110 11110001
00000010 01010010 11001100 10011110 11110001
00000010 11010010 11001100 00011110 11110001
00000010 11001001 00110000 11111001 11110001
00000010 11011111 00010111 11001000 11110001
00000010 01100111 01110011 00010100 11110001
00000010 11011010 11101100 00110110 11110001
00000010 10000001 00100000 10100001 11110001

 

vlad072
Offline
Зарегистрирован: 01.08.2017

Есть основание полагать (проверить на практике сложно - надо кромсать проводку автомобиля, очень не хотелось бы), что данная последовательность является двусторонним обменом, а именно, касаемо первой строки алгоритм такой:

брелок  <->  замок
-----------------
0x20  ->            // запрос ключа
         <-  0xA9   // случайный ключ
0x36  ->            // контрольный <xor> байт
0x9F  ->            // хешированный ключ
         <-  0x1F   // ключ принят

Ведь исходя и строк:

02 05 E2 E7 F1 
02 E5 E2 07 F1  
// а так же 
02 52 CC 9E F1 
02 D2 CC 1E F1

именно предпоследний байт является хешем второго, а 3й контрольной суммой. Т.е. нужно раскусить две 8-битных хеш-фунции вида f(A9) = 9F (открытие) и f(1D) = 9A (закрытие). Может с этим кто поможет? У самого не получается.

DIYMan
DIYMan аватар
Offline
Зарегистрирован: 23.11.2015

vlad072 пишет:

 Т.е. нужно раскусить две 8-битных хеш-фунции вида f(A9) = 9F (открытие) и f(1D) = 9A (закрытие). Может с этим кто поможет? У самого не получается.

Предполагать-то можно всё, что угодно, по сути. Но, как верно замечено, это только предположения. Сходу зависимость не видится, если и правда используется хэш-функция, то пока хз, что там унутре.

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

DIYMan
DIYMan аватар
Offline
Зарегистрирован: 23.11.2015

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

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

Это так, мысли вслух, может, поможет.

sadman41
Offline
Зарегистрирован: 19.10.2016

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

DIYMan
DIYMan аватар
Offline
Зарегистрирован: 23.11.2015

sadman41 пишет:
А меня вот смущает тот факт, что на два разных "случайных" ключа первый байт "ответа" бывает одинаков.

Ткни, пж, пальцем, не совсем понял, о чём конкретно речь. Интересно помозговать.

vlad072
Offline
Зарегистрирован: 01.08.2017

sadman41 пишет:
А меня вот смущает тот факт, что на два разных "случайных" ключа первый байт "ответа" бывает одинаков.

Вот и я о том, что судя по всему первый байт ответа - это контрольная сумма, а сам зашифрованный ключ идёт за ней. В том числе чтоб сходу запутать.

vlad072
Offline
Зарегистрирован: 01.08.2017

DIYMan пишет:

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

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

Это так, мысли вслух, может, поможет.

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

sadman41
Offline
Зарегистрирован: 19.10.2016

DIYMan пишет:

sadman41 пишет:
А меня вот смущает тот факт, что на два разных "случайных" ключа первый байт "ответа" бывает одинаков.

Ткни, пж, пальцем, не совсем понял, о чём конкретно речь. Интересно помозговать.


#5, второй блок кода

sadman41
Offline
Зарегистрирован: 19.10.2016

В том и смысл защиты - сделать подбор ключа экономически невыгодным мероприятием.

Но ведь можно и побрутфорсить. Там же всего байт. Значит, положим, полбайта на открытие, полбайта на закрытие. Допускаем, что второй байт - xor, т.е. пытаемся долбануть третий. сэмплы и смотрим - точно ли множество открывашек не пересекается со множеством закрывашек... Если это так - пытаемся понять, чем они отличаются или есть ли жесткое соответствие реквеста ансверу.

DIYMan
DIYMan аватар
Offline
Зарегистрирован: 23.11.2015

sadman41 пишет:
#5, второй блок кода

Ага, спасибо, увидел. Это, судя по всему, не мусор, а вполне себе контролька XOR, если предположение о существовании "f(байт) = байт" результата верно. 

vlad072
Offline
Зарегистрирован: 01.08.2017

sadman41 пишет:
В том и смысл защиты - сделать подбор ключа экономически невыгодным мероприятием. Но ведь можно и побрутфорсить.

чтоб побрутфорсить надо либо резать проводку от трансивера, прежде сняв торпеду (это пц), либо найти аналогичный трансивер на разборке за адекватные деньги (что сделать так же не удалось). Есть ещё вариант купить у китайцев шилды к ардуинке приёмник и передатчик на 315/433МГц в надежде что и несущие частоты и модуляция совпадут, но такая вероятность сами понимаете...

sadman41 пишет:
есть ли жесткое соответствие реквеста ансверу.

есть: строки 4, 7 самого первого листинга

sadman41
Offline
Зарегистрирован: 19.10.2016

vlad072 пишет:

sadman41 пишет:
есть ли жесткое соответствие реквеста ансверу.

есть: строки 4, 7 самого первого листинга


Это уже неплохо. Может обойдется таблицей перекодировки - массивом на 255 байт.

vlad072
Offline
Зарегистрирован: 01.08.2017

Тогда уж 512, открытия 256 и закрытия 256. Вариант так то хороший, но для этого нужно получить ответы на все 00..FF случайные ключи, а это проблематично (см. выше). Глазом опытного криптолога бы глянуть на это действа, думаю ничего сложного, есть некая функция скорей всего. Задавал вопрос на соответственном форуме, видимо светлым головам лениво заморачиваться.

sadman41
Offline
Зарегистрирован: 19.10.2016

Если команда - 1 байт, то как в нее 512 значений влезет?

DIYMan
DIYMan аватар
Offline
Зарегистрирован: 23.11.2015

sadman41 пишет:
Это уже неплохо. Может обойдется таблицей перекодировки - массивом на 255 байт.

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

Можно, конечно, брутфорсер самообучающийся написать, и скормить ему исходные данные. По идее, может что-то выдать, но это не точно. Я бы для начала постулировал, что все операнды - однобайтовые. Брал бы "случайный ключ", делал бы над ним преобразования, чтобы получить хэш. Как хэш получен - проверять эти преобразования на остальных данных. Не прошло через сито - преобразования не годны. Прошло через сито - возможно, они правильны, но это не точно :)

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

sadman41
Offline
Зарегистрирован: 19.10.2016

vlad072 пишет:
Задавал вопрос на соответственном форуме, видимо светлым головам лениво заморачиваться.


Почему единственное предположение - лень?

Если нет исходника декриптора, то без статистического анализа не обойтись, имхо.

DIYMan
DIYMan аватар
Offline
Зарегистрирован: 23.11.2015

Вот, пошукал немного: https://sourceforge.net/projects/reveng/

Надо пробовать, может, подобная тулза чего и даст.

DIYMan
DIYMan аватар
Offline
Зарегистрирован: 23.11.2015

http://ww1.microchip.com/downloads/en/DeviceDoc/Article_AC10_Turn-Key-Passive-Entry.pdf - читать с раздела "Bi-Directional Authentication" - очень интересно ;)

DIYMan
DIYMan аватар
Offline
Зарегистрирован: 23.11.2015

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

vlad072
Offline
Зарегистрирован: 01.08.2017

Так эта утилита для подсчёта crc

sadman41
Offline
Зарегистрирован: 19.10.2016

Самое забавное будет, если результат преобразования унутре зависит от ID системы/приватного ключа, который всегда разный и шьётся на заводе.
Тогда можно сливать воду. Решение будет только для конкретного случая.

DIYMan
DIYMan аватар
Offline
Зарегистрирован: 23.11.2015

vlad072 пишет:

Так эта утилита для подсчёта crc

Описание точно прочитали? 

It calculates reversed CRCs to give the bit pattern that produces a desired forward CRC

Что не даёт нам право отбросить возможность, что применяется один из известных алгоритмов ;)

DIYMan
DIYMan аватар
Offline
Зарегистрирован: 23.11.2015

sadman41 пишет:
Самое забавное будет, если результат преобразования унутре зависит от ID системы/приватного ключа, который всегда разный и шьётся на заводе. Тогда можно сливать воду. Решение будет только для конкретного случая.

Да скорее всего. Лично я бы так и сделал. Именно поэтому я не зря спрашивал про железо, а то - дело тёмное ;)

vlad072
Offline
Зарегистрирован: 01.08.2017

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

Чем большее становится понятно, тем понятней что ничего не понятно )))

DIYMan
DIYMan аватар
Offline
Зарегистрирован: 23.11.2015

vlad072 пишет:

Чем большее становится понятно, тем понятней что ничего не понятно )))

Ну уж нам-то - тем более непонятно. Может, там запорожец ушастый. Или - БелАЗ. Да чего я, в конце-концов, вымаливаю детали? Машина, так машина, перепривязать, так перепривязать. 

Без огромного количества нужной конкретики - задача не решаема.

ВН
Offline
Зарегистрирован: 25.02.2016

Помнится в нашей системе автоидентификации с открытым ключом, повтор кода при непрерывной работе происходил примерно через год. 

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

vlad072
Offline
Зарегистрирован: 01.08.2017

DIYMan,

Mazda 6, штатный брелок центрального замка. Экспериментальным путём выяснено, что общение трансивера с блоком управления происходит по однопроводной шине с подтяжкой к +12 по протоколу UART на скорости 10750 бод. Что от этого становится понятней?

sadman41
Offline
Зарегистрирован: 19.10.2016

Понятно становится, что Мазда - не Жигуль и простых способов защиты в ней скорее всего нет.

-NMi-
Offline
Зарегистрирован: 20.08.2018

vlad072 пишет:

Чем большее становится понятно, тем понятней что ничего не понятно )))

А ты думал это как на дуньке моргало светодиодное заваять? )))))))))))))))))))

Там будет чото-типа функции с синхрословом+сессионный ключ=пачка байт.

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

Ежли асилишь - дерзай.         ))))))))))))))))))))))))))))))))))))

ВН
Offline
Зарегистрирован: 25.02.2016

ну да, вскрыть и типа попробовать прочитать ....

-NMi-
Offline
Зарегистрирован: 20.08.2018

Можно просто купить за десятку зелени уже считанный дамп на фрикерских площадках и не париццо с разбором блока.

DIYMan
DIYMan аватар
Offline
Зарегистрирован: 23.11.2015

vlad072 пишет:

DIYMan,

Mazda 6, штатный брелок центрального замка. Экспериментальным путём выяснено, что общение трансивера с блоком управления происходит по однопроводной шине с подтяжкой к +12 по протоколу UART на скорости 10750 бод. Что от этого становится понятней?

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

vlad072
Offline
Зарегистрирован: 01.08.2017

-NMi-

Ларёк с бесплатной раздачей KESS'ов закрылся на карантин

DIYMan

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

ВН
Offline
Зарегистрирован: 25.02.2016

Что там вам надо ваще хз .

УК РФ Статья 272. Неправомерный доступ к компьютерной информации

Примечания. 1. Под компьютерной информацией понимаются сведения (сообщения, данные), представленные в форме электрических сигналов, независимо от средств их хранения, обработки и передачи.

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