Машина

Прошлым летом я купил Hyundai Ioniq SEL 2021 года. Это хороший экономящий топливо гибрид с приличным набором функций: беспроводные Android Auto/Apple CarPlay, беспроводная зарядка для телефона, сиденья с подогревом и люк в крыше.

Особенно мне понравилась в этой машине система In-Vehicle Infotainment (IVI). Как я говорил ранее, у машины есть беспроводное Android Auto, что довольно редко для такого ценового диапазона. Приложение имеет красивые плавные анимации меню, поэтому я понял, что ЦП/GPU не такие уж и слабые; или, по крайней мере, ПО ест не слишком много ресурсов.

Как и со всеми остальными моими гаджетами, я решил немного поэкспериментировать и посмотреть, что можно сделать с этой системой.

Цель

IVI в автомобиле, как и многие другие системы в наши дни — это просто компьютер. Моя цель заключается в том, чтобы хакнуть IVI для получения root-доступа и попробовать запустить на ней собственное ПО. Разумеется, первым этапом взлома устройства является исследование.

Я искал ответы на следующие вопросы:

• Что работает в этом устройстве?
  
  • Существует две версии IVI: для навигации, использующая Android, и система на основе Linux.
  
  
• Кто-нибудь взламывал его раньше?
  
  • Навигационную систему на основе Android легко взломать, установив свои APK через меню разработчика.
  • Систему на основе Linux ещё никто не взламывал.
  
  
• Есть ли режим разработчика у системы IVI с Linux?
  
  • Да, есть

Режим разработчика

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

Выяснилось, что в моей IVI можно войти в режим разработчика, перейдя на экран Software Update, быстро нажав десять раз слева от кнопки Update, а потом один раз справа от неё.


Если экран не появлялся сразу после завершения нажатий, я просто повторял процесс.


Режим разработчика (Engineering Mode) защищён PIN-кодом из четырёх цифр. Это руководство помогло мне понять, что используется PIN-код «2400».

Перейдя в режим разработчика, я прошёлся по меню и посмотрел на все доступные опции. Там была куча диагностики, журналов отладки и скрытых параметров. Моё внимание привлекли несколько меню:

• USB copy
  
  • В этом меню есть подопции копирования логов на USB-накопитель или обновления отдельных частей системы с USB.
  • Одна из опций давала понять, что удерживание кнопки Radio на IVI тоже запускает сбор логов.
  
  
• Module Info > ISV Setting
  
  • В этом меню есть опция ADB TCP, а также радиокнопки для SW Test Tools.
  
  

При помощи этих параметров я сохранил на свой USB-накопитель множество логов и попытался использовать ADB для доступа к IVI.

ADB TCP

Я подключил свой телефон при помощи беспроводного Android Auto, чтобы добраться до Wi-Fi системы IVI, и попытался просканировать порты устройства, но не смог найти открытого порта ADB. Позже выяснилось, что на самом деле эти опции ничего не делают.

Логи

Логи оказались настоящей сокровищницей информации о внутренней работе IVI.

Логи сохраняются на USB в одном большом tar.gz под названием daudio2.0v_{Date}-{Time}.tar.gz.


В архиве содержится множество файлов, в том числе лог ядра, вывод команды top, логи logcat и логи BlueLink.


Самый интересный из файлов логов — это файл logcat. По сути, для каждого приложения, запущенного в IVI, активно ведутся логи, и все они направляются в этот файл.

Взлом

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

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

Мне пришло в голову, что проще всего будет сделать это, скачав обновление прошивки и распаковав его.

Прошивка

Я провёл дальнейшие исследования и изучил логи. Выяснилось, что в этих IVI работает D-Audio2V, разработанная Hyundai Mobis. D-Audio2V — это второе поколение Hyundai Display Audio OS, оно используется в различных автомобилях Hyundai и Kia. Обнаружилось, что на сайте Hyundai Mobis есть доступная для скачивания часть исходного кода D-Audio2. Я просмотрел его, но по большей части это были просто небольшие патчи разных опенсорсных проектов для работы системы Wi-Fi.

Обновления прошивки систем D-Audio2 находились на сайте update.hyundai.com в разделе Display Audio Software Update. К сожалению, конкретно для моего автомобиля там обновления не было, поэтому я просто скачал обновления для пары других машин.

Файлы прошивок скачиваются в виде простых файлов .zip, внутри которых находится ещё один файл .zip. Внутренний .zip называется enc_system_package_{version}.zip. Похоже, внутри system_package содержится прошивка для разных модулей IVI наподобие GPS и HD Radio, а также образ самой системы.

Обновление выглядело многообещающе, я попытался извлечь образ системы, но…


Весь .zip был зашифрован.

Однако это не охладило меня: на моём компьютере уже установлены инструменты наподобие John The Ripper и Hashcat, которые можно использовать для брутфорса паролей zip. Я попробовал взломать перебором пароль с ограничением до восьми символов, потому что с этим моя система могла справиться за разумное время, но ничего не получилось. Ещё я попробовал использовать некоторые из своих списков слов, но тоже потерпел неудачу.

Взлом при помощи bkcrack

Далее я начал искать другие инструменты или сервисы, которыми можно было бы воспользоваться. Так я нашёл bkcrack. Как оказалось, традиционное шифрование zip можно сломать при помощи атаки известным открытым текстом. Это значит, что если я смогу найти как минимум 12 байтов одного из файлов, находящихся внутри зашифрованного zip, то потенциально смогу расшифровать и весь файл.

Началась охота за подходящим файлом. Я посмотрел список файлов в зашифрованном zip и нашёл пару хороших кандидатов для атаки. Внутри папки MODEM\us есть файл modem_version.txt длиной 37 байтов. Так как это текстовый файл, вероятно, он имеет человекочитаемый формат.


Сначала я загуглил файл в Интернете, надеясь, что смогу найти подходящий, но в основном находил мёртвые FTP-ссылки, поэтому решил пойти другим путём.

Я надеялся, что Hyundai использует одинаковые модули модемов в своих IVI, а следовательно и одинаковые файлы прошивок модема. Если я смогу найти незашифрованное обновление модема для другой IVI, то, возможно, найду и соответствующий файл modem_version.txt.

На сайте с обновлениями Hyundai я выяснил, что у Hyundai есть специальное ПО для обновления IVI навигации.


Я установил ПО Navigation Updater и скачал последнее обновление для Hyundai Ioniq Navigation IVI 2020-2021 годов.

Затем я перешёл в папку, куда ПО распаковало файлы, и открыл tar-файл system_package.


Внутри находилась папка modem, в которой находился очень знакомый набор файлов! Однако файл modem_version.txt имел другой размер.


Я знал, что есть множество других файлов, которые тоже могут подойти. Но какие из них будут совпадать с нужными?

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


К счастью, ко мне на помощь пришёл zip. При создании файла zip для каждого файла в нём вычисляется CRC. CRC (cyclic redundancy check) — это алгоритм нахождения контрольной суммы, которую программа распаковки zip использует для проверки того, что файл был расшифрован/распакован правильно. Одинаковые файлы генерируют одинаковые CRC. Так как файлы обновления системы навигации находились в файле tar, а не zip, я извлёк их, а затем запаковал в zip.


Совпала одна пара файлов: partition.mbn. Я нашёл нужный мне открытый текст.

Я загрузил в bkcrack найденный текст, и…


Не сработало? Но почему?

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


Однако попытки использовать эти ключи приводили к созданию неправильного файла zip




Я вернулся на страницу issues bkcrack на Github и изучил все issue. Там я и узнал, что «открытый текст» (plaintext) должен быть не из самого исходного файла, а из правильно сжатой версии исходного файла.

Мне нужно было найти конкретную программу и параметры, которые Hyundai Mobis использовала для сжатия исходного zip.

Я запаковал файл partition.mbn при помощи встроенного приложения Windows для создания zip. Не сработало. Затем я попробовал все комбинации параметров в 7Zip.


Я даже написал на C# программу, которая использовала библиотеку сжатия для создания каждой возможной комбинации.

Но ничего не сработало. Я подумал, что вряд ли Hyundai использовала какую-то неизвестную программу Windows для zip, поэтому перешёл на Linux.

Я создал множество файлов zip с различными параметрами при помощи инструмента командной строки zip, установленного в моей версии Kali.


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


Я использовал найденные bkcrack «мастер-ключи» для создания zip, и…

Наконец-то?

Мне удалось успешно извлечь все файлы из зашифрованного zip!

bkcrack также позволяет восстановить пароль к zip из найденных им мастер-ключей, поэтому я попробовал использовать эту возможность, но программа не смогла найти ничего длиной до 16 символов, а большего количества символов взломать на своём PC я бы не смог.

Но поскольку теперь мне всё было доступно, я извлёк файл system.img, находившийся внутри папки enc_system.

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

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

Сетевой доступ

Также я выяснил, что установлен драйвер для USB-адаптеров Ethernet RTL8152/8153.


Я купил несколько USB-адаптеров Ethernet на основе RTL8153, надеясь, что у них есть открытые порты. У одного из купленных мной адаптеров был встроенный USB-хаб, из-за чего он оказался несовместимым с IVI, но второй купленный был прямым адаптером Ethernet, что позволило мне успешно подключиться к системе. К сожалению, он позволял мне только получить доступ к серверам CarPlay и Android Auto, других открытых портов не было.

В процессе реверс-инжиниринга двоичного файла automotivefw я выяснил, что параметр ADB TCP в режиме разработчика присваивает eth0 IP-адрес 192.168.7.110.


При помощи логов я обнаружил, что eth0 должен иметь MAC-адрес F4:50:EB:2E:58:00. Я надеялся, что изменив MAC-адрес своего адаптера RTL8153, я смогу получить доступ к сети, которая, если повезёт, имеет доступ к ADB.

Я перенаправил RTL-донгл в ВМ Kali и попытался использовать ethtool для записи в него нового MAC-адреса. Быстро выяснилось, что MAC-адрес RTL8153 невозможно изменить при помощи ethtool.

Я поискал онлайн-инструменты, способные это сделать, но изучив статьи, пришёл к выводу, что параметры MAC-адреса в этих чипах редактировать нельзя. Спустя несколько часов поисков я нашёл образы утилиты Realtek RtPGtoolUI. Судя по найденной информации, это была утилита, используемая производителями для настройки этих USB-адаптеров Ethernet, в том числе и для записи MAC-адресов. Благодаря прочитанной документации я также узнал, что во многих таких адаптерах вместо традиционного флеш-накопителя используется что-то под названием EFuses. Если в моём адаптере используется EFuses, то есть вероятность, что я не смогу обновить его даже при наличии нужного инструмента, но у меня оставалась надежда, и я продолжал искать.

Я потратил бесчисленное количество часов в попытках найти возможность скачать приложение. Наконец я нашёл подозрительный китайский форум с нужным файлом.


Немного поэкспериментировав, я смог успешно прошить новый MAC-адрес в адаптер, хотя в нём и использовался EFuses.

Сетевой доступ?

Я подключил прошитый адаптер Ethernet к USB-разъёму автомобиля, однако выяснилось, что ничего не изменилось. Через Wireshark я не увидел никакого отличающегося трафика. Я смог убедиться, что смена MAC-адреса произошла успешно, но это не дало мне дополнительного доступа и даже адреса IPv4.

Я просканировал адрес 192.168.7.110, который указывал на IVI, но нашёл только те же открытые порты CarPlay/Android Auto.

После этого я посмотрел логи и осознал, что устройство eth0 — это некий встроенный адаптер Ethernet, который всегда отключён. Какой бы USB-адаптер я ни использовал, он всегда отображался как eth1. Также в этот момент я понял, что пароль Wi-Fi дампился в логи при его генерации, то есть вместо этого я могу использовать подключение к Wi-Fi. Подключение к Wi-Fi дало мне тот же доступ к адаптеру Ethernet, только на этот раз моему ноутбуку был выдан правильный адрес IPv4.

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

Обновление прошивки

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

В образе системы мне не удалось найти ни одного двоичного файла, выполняющего обновление прошивки. Приложение Engineering Mode и приложение Setup давали понять, что после нажатия кнопки Update в параметрах устройство IVI загружается в режиме восстановления.


В папке enc_system обновления прошивки находился файл enc_updateboot.img. Я предположил, что этот образ содержит систему восстановления.

К сожалению, 7Zip не смог извлечь образ, как это было с файлом system.img. Открыв образ в Notepad++, я понял, почему так случилось.


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

Я проверил другие файлы в обновлении, все файлы с префиксом enc_ оказались зашифрованными.

Я снова зашёл в тупик. Без ключа шифрования я не смог бы узнать больше о процессе обновления системы.

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

Неужели это правда?

Изучая исходный код с сайта Mobis, я искал все файлы, где были скрипты оболочки. В результатах я нашёл скрипт оболочки linux_envsetup.sh.


Этот файл открыл передо мной все двери.

Оказалось, что это был скрипт, создающий файл zip обновления системы.


Пароль zip для обновления системы всё это время был на моём жёстком диске.


К счастью, способ шифрования, ключ и IV тоже находились в скрипте.


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


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


Google Git? Apple? Chegg????

Оказалось, что ключ шифрования в этом скрипте — это первый пример ключа AES 128bit CBC, указанный в документе NIST SP800-38A.


Не могла же Hyundai Mobis использовать этот ключ, и он использовался только для тестирования, так ведь?


Нет ошибки? Этого не может быть…

Я смог открыть файл в 7Zip, но в нём находился только один повреждённый элемент.


Однако пропустив этот файл через binwalk, я выяснил, что файл updateboot.img успешно распакован, и в нём куча информации.


Использовав аргумент -e (extract) в binwalk, я извлёк файл img, обнаружив barebone-установку linux.


Внутри папки /usr/bin folder я нашёл любопытный двоичный файл updateAgent.


Так как у меня уже был пароль zip и ключ шифрования, я решил поискать ключ подписки: если повезёт, то разработчики оставили не только публичный, но приватный ключ.

Поискав ключевые слова наподобие «RSA», я нашёл публичный ключ, но никакого приватного ключа.


Я снова загуглил часть публичного ключа.


О, разработчики снова использовали очень распространённый ключ. Любопытно, пользовались ли они туториалом RSA Encryption & Decryption Example with OpenSSL in C по ссылке…

Игра в ожидание

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

Дальнейшее развитие событий будет изложено во второй части статьи.