Народ, есть такой интересный вопрос.

Имеется жезелка. К ней имеется софт. Они общаются по RS232, протокол проприетарный и нечитаемый. Нужно понять этот протокол и (в идеале) получить через него доступ к инженерным функциям железки, которые в софте сильно ограничены. Известно, что рашсиренная версия софта с нужными функциями в природе существует, но только в сервис-центре производителя, достать нереально. Документации по софту (кроме user manual) нет. Сервис-мануала на железку нет и достать его нереально. Софт обфусцирован, декомпиляция сильно затруднена.

Снял дамп обмена компа с железкой через Serial Port Monitor - там голый HEX, в котором ничего вразумительного найти не выходит, никаких читаемых данных в открытом виде не передается. Побудить железку что-то отвечать на ручные посылки тех же HEX значений, которые шлет в нее софт, не вышло. Отправка через софт в железку заранее известных данных ни к чему не привела - в дампе не удалось выловить ничего похожего.

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

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

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

Кабель RS232 нужно разводить на два компа и тогда уже смотреть обмен.

Обмен не односторонний.

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

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

Если протокол обычный текстовый - это одно, если бинарный, можно чисто графически какие-то закономерности посмотреть , типа размера пакета (например выведите дамп в hex при разной ширине страницы), дальше попытаться разобраться с полями, где int, где float и пр.

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

Очень похоже что идёт обмен ключами. Вопрос: при отключении нет "закрытия сессии"?
Не получается так что каждый раз получая новый ключ железка его запоминает, отдаёт, а потом для новой сессии предоставляет, но каждый раз меняя от предыдущего? Нет одинаковых кусков завершения прошлого обмена и начала следующего?

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

Это правильно, что вы отснифферили оба трафика одновременно, по Rx и по Tx. Но, боюсь, что на этом анализ данного протокола скорее всего и закончится, если только не появятся вновь открывшиеся обстоятельства.

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

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

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

А в железке там стоят какие-нибудь епромы, отдельно от процессора? если есть, то может, в их дампах тоже стОит порыться после каждой транзакции?

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

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

А что там с нашумевшими процессорными уязвимостями, которые дают прямой доступ к содержимому памяти компа? Может их использовать для взлома ключа? В момент исполнения программы её код не зашифрован поидее.

Sergey4565
А что там с нашумевшими процессорными уязвимостями, которые дают прямой доступ к содержимому памяти компа?
Теоретически сломать всё можно, но нет такой железки, которая стоила бы затраченных усилий.
С открытым-то протоколом намучаешься, а обмен длинными строками с последующей тишиной очень нехороший признак.