И румынский подход:
Я хочу поделиться своим (полностью дилетантским) взглядом на эту проблему; У меня
есть друг, который знает кого-то, кто столкнулся с точно такой же проблемой, описанной
в этой теме: где-то в конце декабря злоумышленник получил доступ к системе и
заблокировал все устройства с помощью пароля BCU, и было невозможно вернуть
контроль над система.
Что я хотел бы упомянуть с самого начала, так это то, что я полный любитель, когда
дело доходит до аппаратного обеспечения (мои навыки в основном связаны с
программным обеспечением), поэтому некоторые из моих методов в лучшем случае на
любительском уровне. В любом случае, мне нравится взламывать схемы вместе. и
обратный инжиниринг, так что это казалось хорошей задачей, учитывая, что я никогда
раньше не работал с KNX.
Потратив несколько дней на разборку (кнопки Gira 5133/5131/5142, 8- и 16-канальные
актуаторы Gira и даже метеостанцию Gira), стало ясно, что в данном случае метод,
который использовал Лаймс, неприменим, так как у меня были только Устройства Gira, и
хотя все они питаются от микроконтроллеров Atmel (с которыми я хорошо знаком и с
которыми мне удобно щупать и тыкать), все устройства имеют установленные замки-
предохранители, поэтому нет возможности получить доступ к областям flash/eeprom и
получить более ограниченное пространство для атаки грубой силы.
Действительно, попытка перебора всего 32-битного пространства кажется на первый
взгляд невозможной, и на это уйдет несколько лет на одном устройстве при низкой
скорости 9600 бит/с шины KNX. Но наличие десятков или сотен устройств с (как
предполагается!) одним и тем же паролем дает проблеск надежды, тем более, если
можно найти какой-то способ хотя бы немного ускорить процесс.
При исследовании содержимого flash/eeprom стало очевидно, что кнопки могут помочь,
когда дело доходит до скорости атаки: кнопки (потерпите меня, я ничего не знал о
системе knx в то время) не напрямую подключен к шине, но используйте шинный
соединитель 3, и связь здесь фактически использует UART 115200 бит/с: в шинном
соединителе 3 есть микроконтроллер, который обменивается данными с шиной KNX на
ограниченной скорости 9600 бод и с самими кнопками на гораздо более высокой
скорости. Скорость 115200 бод. Более того, микроконтроллер в шинном соединителе
действует только как шлюз, а фактический пароль находится на кнопках
микроконтроллера. Проверка этой шины 115200 (это легко сделать с помощью любого
логического анализатора или, в моем случае, с помощью осциллографа Rygol) показала,
что используемый протокол похож на knx;
Итак, в этот момент я как бы решил, что параллельная отправка нескольких запросов на
аутентификацию на несколько устройств по этой более быстрой шине может помочь.
Следующим шагом будет выбор хоста (или хостов), которые будут использоваться для
форматирования и отправки пакетов на устройства. Первая идея (как обычно, та,
которая не работает) заключалась в том, чтобы использовать кучу недорогих плат
разработчика esp32, поскольку они имеют 2 (может быть, даже 3, если я смогу обойти
журнал загрузчика на UART0) аппаратных UART (на 115200 скорость передачи данных,
я правильно предположил, что можно использовать только аппаратные UART). Кроме
того, Wi-Fi можно использовать для организации атаки более высокого уровня.
Я уже знал, что, несмотря на скорость 115200 бод, у шины есть некоторые требования к
времени: хост не может отправлять как можно быстрее, и устройство будет задерживать
довольно много времени, прежде чем ответить, поэтому, возможно, некоторое
мультиплексирование может быть сделано программно (некоторое аппаратное
обеспечение). соображения должны быть приняты во внимание при подключении
большего количества устройств к UART, но, в конце концов, я так и не зашел так далеко
с этой идеей), чтобы соединить два устройства через порт UART esp32.Для этого
потребуется около 10 esps для подключения 60 устройств (10 esp x 3 UART x 2
устройства)... и при скорости 30 попыток в секунду (ага, на тот момент это было
желаемое за действительное) общее время на полное 32 битное пространство будет не
более 30 дней; хотя это и не очень хорошо, такое количество времени кажется чем-то,
что могло бы сработать, не так ли?
К сожалению, это не сработало, потому что, когда я исследовал шину со скоростью
115200 бод, я полностью упустил тот факт, что шина на самом деле использовала
формат последовательного кадра 9E1, что, как я полагаю, является просто причудой
реализации Atmel, поскольку это совсем не так. стандартный формат кадра (9N1 - это
ближайший стандарт, который я смог найти, который, возможно, использовался когда-то
в далеком прошлом на устройствах, отличных от Atmel, через странное соотношение
пробела / метки, которое, в свою очередь, на самом деле не является стандартным). В
любом случае, этот формат определенно не поддерживается аппаратными UART esp32.
После еще нескольких дней возни с некоторыми библиотеками SoftwareSerial для esp32,
которые поддерживали требуемый формат кадра, это определенно был тупик (именно
этого можно было бы ожидать от нескольких последовательных программ, работающих
на одном микроконтроллере).
Что требовалось, какой хост на базе Atmel для форматирования, отправки и получения
фреймов; Arduino Mega2560 (я обещал вам любительские решения, не так ли?) имеет 4
хороших аппаратных UART, которые только и ждут, чтобы их использовали.
Профессиональный подход состоял бы в том, чтобы, возможно, использовать одну (или,
может быть, больше) FPGA для реализации более 4 UART на хост, но у меня не было ни
одного из них, поэтому это был Arduino (в итоге у меня было 23!! Arduino, работающие
вместе ... Я позаимствовал каждый Arduino, который я смог найти у всех своих друзей, а
затем также купил довольно много из них ... к счастью, если вы покупаете небрендовые -
да здравствует открытое оборудование! - они довольно дешевы в ~ 10 евро здесь, в
Румынии).
Установка, которая в конечном итоге заработала, заключалась в подключении 3
устройств к 3 портам UART Arduino (я также отказался от мусора с
мультиплексированием), при этом четвертый UART был подключен к esp32 для
оркестровки. Этот 4-й порт мог быть программным последовательным портом, так как я
решил, что 9600 бит/с достаточно, чтобы просто получать задачи и сообщать о статусе,
но я точно знал, что программные последовательные порты искажают временные
прерывания в Arduino, и я был уже более чем сыт по горло. с программной реализацией,
поэтому я решил просто использовать для этой цели один из аппаратных. В esp32 я
использовал серийные номера, реализованные программно, так как у меня не было
требований по времени (но в итоге я использовал контрольные суммы для кадров
задачи/состояния, потому что это было несколько ненадежно, но недостаточно, чтобы
быть проблемой), потому что я хотел подключить четыре Arduino к одному esp32 (я мог
бы подключить больше, но у меня уже был лишний esp). В итоге я также напечатал на
3D-принтере небольшие стойки для хранения устройств и их Arduino вместе; даже в
этом случае с проводкой полный бардак... Эта настройка дала мне ~ 18 попыток в
секунду на устройство (некоторые устройства - 5133/5131 были на самом деле быстрее
~ 19+ попыток в секунду, а некоторые были медленнее - 5142 отвечали достаточно
быстро только для 8-9 попыток в секунду) ; Думаю, микроконтроллер был больше
загружен управлением маленьким дисплеем, и поэтому его ответы задерживались
больше).
Имея теперь 6 esp32, каждая из которых имеет 4 стойки (у шестой оказалось только три,
потому что я получал убывающую отдачу от более медленных 5142, которые у меня
были в наличии), каждая стойка имеет, в свою очередь, один Arduino и 3 устройства, я
разделил весь 32-битный домен. в 8192 "фрагментах" по 524288 ключей каждый (2^13
фрагментов x 2^19 ключей для удобства управления). Затем каждому устройству будет
назначен один случайный (в конечном итоге это очень помогло!) фрагмент, и он будет
пробовать каждый ключ в фрагменте (один фрагмент — это число от 0 до 8191:
сдвиньте число на 19 бит влево и начните увеличивать 2 ^ 19 раз; потом повторять, и
повторять, и повторять... довольно простая задача для реализации в Arduino, после
того, как я разобрался, какие кадры отправлять на устройство и как парсить ответы).
Затем esp32 будут пересылать данные в Arduino и обратно в php-скрипт с небольшой
базой данных sqlite, чтобы отслеживать прогресс. С такой настройкой один 5133/5131
закончит свой назначенный фрагмент примерно за 7:30-8:00; один 5142 финиширует
примерно в два раза быстрее.
Расчетное время в худшем случае оказалось ближе к 45 дням, но в итоге ключ был
найден примерно через 15 дней; Система проверила только ~ 37% всего 32-битного
пространства, а ключ, взятый в последовательном порядке от 0x00000000 до
0xFFFFFFFF, занимал ~ 73% пространства (так что, выполнив поиск случайным
образом, я получил 2-кратное ускорение, хотя это конечно не было никакой гарантии на
старте... Я не знаю достаточно статистики, чтобы сделать вывод, что рандом лучше, чем
последовательный, но в моем случае это очень помогло).
В любом случае, это то, чем я хотел поделиться с вами о своем первом опыте работы с
устройствами KNX
С уважением,
Джон
