MEFF 0 17 февраля, 2017 Опубликовано 17 февраля, 2017 (изменено) · Жалоба Здравствуйте! Помогите решить головоломку =) Есть устройство, которое общается с программой на ПК. Общение происходит через немного модифицированный USB-COM. После USB-COM идет еще один переходник на базе МК с батарейкой, ограниченный по времени работы (производитель выдает "лицензию" на время). Программа на ПК о переходнике не знает (?), была написана для более старой версии устройства, которое общалось напрямую с USB-COM. Хочется этот переходник повторить. Логический анализатор показал, что линии RX и TX передаются как есть, с небольной задержкой на МК. С RTS и DTR вроде тоже понятно (указывают устройству, что подключен комп). НО есть еще один сигнал с переходника на устройство (D0 на скриншоте) - пачки импульсов с паузой в 3.051с. Длительность 1 импульса 3.054мс, длительность пачки 442.85мс. 442.85/3.054=145 бит. 1/0.003054=327.44 бит/с. Пачки разные =( Но бывают повторяющиеся последовательности. Обмен по TX/RX происходит во время этих пачек, в этот момент сигнал в 0 (но может это и совпадение, сильно мало обмена происходит). Если этот сигнал пропадает, то устройство перестает отвечать. Вот вторую последовательность привожу: 01111101000010001001000001000011101001111101111010001001000001111011101101000001 00001000100100000100001110100111110100001000110111110100001110100 Может, есть идеи, что это? Спасибо! Изменено 18 февраля, 2017 пользователем Vasily_ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 16 18 февраля, 2017 Опубликовано 18 февраля, 2017 · Жалоба Скорее всего, передается некий хеш с принятого сообщения, а устройство проверяет. Что, настолько дорогая лицензия? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Proton 1 18 февраля, 2017 Опубликовано 18 февраля, 2017 · Жалоба На картинке видно что сигнал D0 просто меняет полярность в начале каждого пакета данных по RX/TX и не несёт никакой информации. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MEFF 0 18 февраля, 2017 Опубликовано 18 февраля, 2017 · Жалоба Скорее всего, передается некий хеш с принятого сообщения, а устройство проверяет. Что, настолько дорогая лицензия? Хуже =) Не продают буржуи! Раньше да, за дорого, а сейчас - нет Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iosifk 3 18 февраля, 2017 Опубликовано 18 февраля, 2017 · Жалоба Вот вторую последовательность привожу: 01111101000010001001000001000011101001111101111010001001000001111011101101000001 00001000100100000100001110100111110100001000110111110100001110100 Может, есть идеи, что это? Берем какой нибудь простой язык: Си или Питон или еще что. И на этом простом языке пишем преобразователь битов в байты. Потому как знаем, что посылки в "COM" начинаются со стартового. Находим в последовательности первый после сброса стартовый и от него начинаем... Дальше наверняка 8 бит данных, потом может быть паритет и стоповые. Меняем число битов данных, меняем паритеты и стоповые. Ну со стоповыми просто. Если после данных хотя бы в одном месте только один стоповый, то значит так и дальше будет... Ну и пытаемся понять, что находится в данных. Там может быть протокол поверх байтов данных. Либо передача будет идти символьными кодами, либо байт-стаффинг. Либо начало-конец кадра передается по дополнительной линии, и байт-стаффинга нет... Вот тогда и смотрите, что передается в данных и как это можно трактовать... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 5 18 февраля, 2017 Опубликовано 18 февраля, 2017 · Жалоба Советчики - это какой-то ад. Лучше б выложенные картинки ВНИМАТЕЛЬНО посмотрели. 1. Сигнал D0 слабо коррелирует с TX/RX. На верхних полосах написано "timeline". И это таймлайн и есть. По RX|TX буквально несколько байт проскакивает (и на заметно большей скорости). 2. Сигнал D0 мало похож на UART. Во всяком случае, глазами старт/стоп биты не отыскиваются ни с 8-битными данными, ни с 9-битными. Русским языком написано, что длина пачки - 145 бит. Вот можно предположить, что старт-стопы у неё в начале и в конце. Советы: - посмотреть RX/TX на входе и на выходе. Проверяем гипотезу "данные передаются только при нуле этого хитро-сигнала". Точнее, выясняем, кто откуда синхронизируется - хитросигнал подстраивается под данные или данные задерживаются на нужное время. - преобразовать снятые данные в хекс. Лично мне глазами похожие куски было б легче искать. - (главное) подумать на тему эмуляции ПК и устройства. Подавать на эту коробочку заранее записанные сигналы, смотреть что меняется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MEFF 0 18 февраля, 2017 Опубликовано 18 февраля, 2017 · Жалоба Советчики - это какой-то ад. Лучше б выложенные картинки ВНИМАТЕЛЬНО посмотрели. Спасибо. Действительно здравые мысли. Я и сам после создания темы пришел к аналогичным выводам. То, что задержка с передачей RX/TX может специально откладываться не подумал, тоже надо будет проверить. Надо собрать больше инфы =( К сожалению, доступа к переходнику пока нет, буду готовиться. Буду эмулировать прогу на ПК и буду эмулировать переходник на компе+МК. С преобразованием в хекс пока не понятен размерность данных =( Напишу парсер для вывода лог анализатора, а то осциллограммы совсем не удобны для этого =( Думал, кто-нибудь узнает в этой последовательности BCD какой-нибудь, хитрую 5-битную кодировку или что-то подобное... ну да ладно Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
@Ark 0 18 февраля, 2017 Опубликовано 18 февраля, 2017 · Жалоба Хочется этот переходник повторить. Логический анализатор показал, что линии RX и TX передаются как есть, с небольной задержкой на МК. С RTS и DTR вроде тоже понятно (указывают устройству, что подключен комп). НО есть еще один сигнал с переходника на устройство (D0 на скриншоте) - пачки импульсов... Такие устройства, обычно, разрабатываются из расчета, что взлом их теоретически возможен, но экономически не целесообразен. То есть времени и денег на это вы затратите много больше, чем на покупку нового экземпляра... Совет простой - выбросьте все это оборудование на помойку и забудьте о нем навсегда. Это зря потраченные деньги. Решайте проблему с нуля. И извлеките полезный опыт из произошедшего. Никогда не покупайте оборудование с подобными "примочками" - не поощряйте таких производителей. Лучше купите подороже нормальное оборудование, у нормального производителя, с заводской гарантией. Мнимая, сиюминутная экономия, как правило, всегда ведет к последующим убыткам... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flood 12 18 февраля, 2017 Опубликовано 18 февраля, 2017 · Жалоба 145 бит - весьма немало. Такая защита может быть неломаемой, а атака на нее - чреватой потерей функциональности. Хотя, для шифрованных данных паттерн пачки слишком регулярен: 011111010000100010010000010000111010011111011110100010010000011110111011 0100000100001000100100000100001110100111110100001000110111110100001110100 Со стороны ключа рискованно, но можно проверить наличие повторного проигрывания: 1. Пишем несколько пачек в режиме связи ключ-устройство. 2. Отключаем устройство и более не подключаем к ключу. Пишем несколько пачек с ключа, не подключенного к устройству. Наличие пачек подтверждает применение одностороннего кода. Включаем питание устройства и сначала проигрываем ему пачки, записанные в п.1. Если такое проигрывание приводит к разблокировке - защита слабая (но это не значит, что она уже сломана). Если защита злая - такое проигрывание может убить устройство (детект попытки взлома). Далее, проигрывание пачек из п.2.должно разблокировать устройство. Это подтвердит гипотезу об одностороннем прыгающем коде. Связь с RX/TX тут не нужна и ее может вовсе не быть. Возможно, тут лучше зайти со стороны защищаемого устройства - на чем оно сделано и т.п. UPD: В зависимости от того, используется стоповый или стартовый бит: 7D 08 90 43 A7 DE 89 07 BB 41 08 90 43 A7 D0 8D F4 3A или: FA 11 20 87 4F BD 12 0F 76 82 11 20 87 4F A1 1B E8 74 Похоже, это две последовательные посылки. В каждой, возможно, пара 32-битных значений + чексумма. Какой-нибудь Keeloq? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
