Помните, мы рассказывали о взломе ШГУ Hyundai Tucson (часть 1, часть 2)? Автор опирался на похожую работу, проделанную владельцем Hyundai Ioniq 2021. И совсем недавно у него вышло продолжение — взлом свежей, более защищённой прошивки. Cloud4Y предлагает почитать, что же там изменилось и какие проблемы остались.

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

Предыстория

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

Что мне особенно понравилось в этом автомобиле, так это бортовая информационно-развлекательная система (IVI). У неё была беспроводная связь Android Auto, которая считается редкостью в этом ценовом диапазоне, приятная плавная анимация в меню, которая означает, что CPU/GPU не такой уж маломощный, или, по крайней мере, программное обеспечение, которое он запускал, не слишком раздутое.

Как и в случае со многими новыми гаджетами, я хотел поиграть с ним и посмотреть, что можно с ним сделать. И я это сделал, о чём уже успел рассказать ранее. Но зачем я пишу об этом снова?

Потому что это Hyundai ¯\_(ツ)_/¯

Где-то в конце июля 2022 года компания Hyundai удалила ссылки на загрузку всех своих прошивок для DAudio2. Осталось только сообщение, в котором говорилось, что обновления вернутся 1 сентября. Возможно, кто-то в Hyundai/Mobis прочитал мой блог и захотел исправить свои проблемы. В ожидании этого я начал готовиться к взлому новой прошивки.

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

Затем они сделали это ещё раз. Перенесли дату на "октябрь 2022 года".

Наконец, 24 октября 2022 года они выпустили новый набор обновлений прошивки.

Смотрим внутрь

Я быстро скачал zip-архив новой прошивки и извлёк файлы.

Подождите, файлы?

Вместо обычного, единственного файла enc_system_package_{version}.zip было два файла:

Один с ожидаемым именем «enc_system_package_134.100.220927.zip» и другой с именем «enc_d2vsystem_package_134.100.220927.zip».

Используя ранее найденные пароль и ключи шифрования, я смог разархивировать и расшифровать файл enc_system_package_134.100.220 927.zip, но с другим файлом это не прокатило. Hyundai изменил ключи.

Старая игра, новый раунд 

Итак, если я хочу получить самую последнюю и самую лучшую прошивку, мне придётся взломать её снова. Но как я могу это сделать?

Первым делом нужно было собрать информацию. Оба предоставленных zip‑файла оказались полными системными обновлениями, поэтому я решил выяснить разницу между ними.

Но поскольку Hyundai изменил пароль к архиву, мне пришлось его взломать. Используя bkcrack (инструмент, который я изучил в первой части), я смог успешно расшифровать «d2v» zip, используя файлы из обычного zip.

Разумеется, большинство файлов в обновлении были зашифрованы, но файл system.img — нет. Поэтому я сравнил два файла system.img. Оказалось, они идентичны.

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

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

Если это так, то новый пароль и ключи шифрования находились в «старом» zip‑файле обновления, который я мог бы прочитать. Если их найти, то можно попытаться расшифровать свежую прошивку d2v и иметь возможность менять её, как это было в прошлый раз.

Начинаем копать

Поиски были похожи на попытку отыскать иголку в стоге сена, но я хотя бы знал, какой стог сена ворошить. Опыт подсказывал мне, что логика обновления находится в исполняемом файле /usr/bin/updateagent в Recovery image (updateboot.img). После извлечения updateagent я приступил к его декомпиляции и быстро выяснил пароль нового zip‑архива.

Я не смог извлечь zip‑архив обновления d2v в Windows, используя пароль «$09#$모비스98@!OTA$$» , но команда unzip в Linux сработала безупречно. Далее требовалось найти ключ шифрования/вектор инициализации (IV), а также открытый ключ RSA, используемый для проверки подписи обновления прошивки.

Простая математика

Бинарник агента обновления выглядел иначе, чем раньше. Hyundai, должно быть, внесла какие‑то изменения. Одним из таких изменений был способ «хранения» ключа шифрования и IV в функции calcAES128().

Значения, которые я искал, были «iv» и «key» в строках 114/115. Поэтому я занялся реверс‑инжинирингом, чтобы найти их.

Код начинался с создания того, что я назвал «userIV». Это значение является комбинацией переданного значения и данных, найденных в unk_86510.

Затем код объединяет данные из unk_8651C и переданное значение, чтобы создать то, что я назвал «userKey».

После этого дважды вызывается функция AESDecryptWithKey(). Первый вызов расшифровывает значение в «byte_86528», используя ранее созданный «userIV» в качестве ключа и IV, а затем сохраняет его в «iv».

Второй вызов расшифровывает значение в «byte_86538», используя «userKey» в качестве ключа и IV, и сохраняет его в «key».

Это немного сбивает с толку, и я мог бы использовать лучшие имена переменных, но, по крайней мере, теперь у меня была логическая цепочка, используемая для определения реального ключа шифрования и IV. Единственное, что осталось неизвестным, это какое значение передаётся, чтобы получить «userIV» и «userKey»?

Я просмотрел ссылки на функцию calcAES128(), чтобы узнать, какое значение было передано. Оказалось, что это были первые 6 байт значения «variantDataStruct».

По своим предыдущим исследованиям я знал, что variant struct — это структура данных, используемая для хранения различной информации о транспортном средстве, например: модель, тип камеры заднего вида или поддержка HD Radio.

Чтобы выяснить, что именно задаёт variantDataStruct, я поискал ссылки на неё. Нашлась только одна функция, которая использовала её, receive_variant_data().

Теперь эта функция была декомпилирована не самым лучшим образом, но я смог понять, что она принимала какое-то значение буфера (с именем buf) и перемещала 30 байт из него в variantDataStruct. Поэтому я стал искать значение buf, что привело меня к функции receive_pd(). В ней я увидел лог, в котором говорилось о чтении данных из микома.

Micom? Больше похоже на MiHaveSeenThisBefore

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

Я также знал, что он работает путём чтения и записи пакетов в таком формате:

• Всегда FF (байт)

• SID (байт) - ID отправителя

• RID (байт) - ID получателя

• Тип: (байт)

• Функция(Int16, Big Endian)

• Длина полезной нагрузки (Int16, Big Endian)

• Полезная нагрузка (массив из {Payload Length} байтов)

Таким образом, агент обновления должен отправить пакет на micom с запросом данных варианта, а micom отвечает данными, которые в итоге оказываются в variantDataStruct.

Двигаясь вверх по цепочке вызовов, я пришёл к функции request_variant_info(). В ней она сохраняет некоторые данные в переменную v4, которая выглядит как пакет (строки 11-12).

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

• Начало пакета: FF

• ID отправителя (SID): 8A

• ID получателя (RID): 01

• Тип: 01

• Функция: 0117

• Длина полезной нагрузки: 0001

• Полезная нагрузка: 98 (байт контрольной суммы)

Таким образом, если бы я мог отправить этот пакет на micom и получить ответ, я мог бы получить первые 6 байт из него и использовать их для расшифровки ключа шифрования/IV!

Поскольку в части 4 я сделал приложение, которое можно использовать для взаимодействия с micom, я использовал его для отправки вышеуказанного пакета. Поскольку я отправлял его через сокет micom_mux, а не напрямую на /dev/tcc_ipc, как это делает агент обновления, я не добавлял байт контрольной суммы, поскольку процесс micomd сделает это за меня.

Я отправил «FF8A010101170001» и получил следующее: «FF018A0181171642??????????????????????????????????????????… » (затёр часть полезной нагрузки) успешный ответный пакет, который декодируется как:

• Начало пакета: FF

• ID отправителя (SID): 01

• ID получателя (RID): 8A

• Тип: 01

• Функция: 8117

• Длина полезной нагрузки: 1642

• Полезная нагрузка: {0x1642 байт}

Отлично, получено значение variantDataStruct. Возвращаемся к calcAES128(), чтобы выяснить значения userIV и userKey.

Это выглядело достаточно просто, но на всякий случай я скопировал псевдо-C и преобразовал его в C#. Затем заполнил variantData полезной нагрузкой пакета данных get variant и запустил его:

Он дал мне ключ и IV, которые я использовал для расшифровки файлов из d2v архива.

Ой, «bad decrypt»? :(

Видимо, куда-то закралась ошибка. Я вспомнил, что variantData для каждой модели автомобиля должны быть относительно уникальными, поскольку каждая модель автомобиля имеет разные возможности. И если бы variantData зависели от модели автомобиля, они имели бы разные вычисленные ключи/ivs и, следовательно, разные зашифрованные файлы.

Чтобы проверить, так ли это, я загрузил ту же версию обновления для Elantra и сравнил некоторые зашифрованные файлы в обновлении с файлами для Ioniq. Все сравниваемые файлы оказались идентичными. Это означало, что первые 6 байт из структуры variantData должны быть идентичны у разных моделей.

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

Ключ к решению проблемы был прямо у меня перед носом. В начале заголовка ответного пакета находилось 6 байт, которые я искал. Установив данные варианта в "FF018A0181171642" и запустив код, я получил следующие значения Key и IV:

• Key: F4DA05A5E848309EE8377464CF4254A3

• IV: 763AC2AFAC9E8EE379788B6CC08612B0

И это сработало!

Все это было необходимо для повышения уровня безопасности IVI и не так уж и сложно.

Выполнено на 66,6%

Теперь я окончательно убедился, что два файла обновления (обычный и d2v) идентичны и мог расшифровать всё обновление системы. Я также потратил время на поиск открытого ключа RSA, который используется для проверки подписи прошивки.

В конце концов я нашел функцию decryptPublicKey(). Эта функция вызывает calcAES128() так же, как и ключи шифрования, но вместо этого она проходит через другую ветвь функции. Эта вторая ветвь создаёт байты, которые используются в качестве ключа и IV для расшифровки файла «/usr/share/pub_key/updatePublic.info» в настоящий открытый ключ.

Я ещё раз скопировал декомпилированный код, перевёл его в C#, запустил, и он выдал мне ключ/iv: FF018A018117D0AD830AD5A7DABEDA72. Неплохо, хотя я не уверен, зачем они вообще пытались зашифровать открытый ключ (в конце концов, это открытый ключ, и хорошо, если он будет общеизвестен).

Затем я использовал найденный ключ/iv для расшифровки открытого ключа:

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApTCnVgqDkrE4VrnuEI5G
slnmP6GmO03Pg0RuW1wzWsP9BybsNX4GuULSCqr3MsZWOquSO3ftEM9c59LSuTli
9LE57zsfohoieeeFaE1mFW5fLio+AQhwpeEVIeOLzt/gX/bcq0c+JKcwEawpOxM0
GhMenNdA+jaODjlhK1cqjrTdBQUPcQNBguAbNU6VVufjmAsNTwT7hUVEvdZIllIo
RE8c3lQqRy7eV1nQxxQXiGSK/YkcAfjgmaSuLamdgBUcbc8s8wMs6xoXbJqxFXW1
2zDMXPD98g/mysGZgzfQPfr2w1r4b5q7wvC0kbhrcZFuJ9mmf1cufzB2NgMvzZJ6
qQIDAQAB
-----END PUBLIC KEY-----

Я погуглил этот ключ, но, похоже, он уникален. Не то, что в прошлый раз.

0% выполнено?

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

Рекомендация для Hyundai/Mobis

Всё это говорит о том, что безопасность в условиях неизвестности, которую практикует Hyundai/Mobis, совершенно не нужна. Сокрытие ключей не имеет значения, если у вас есть надлежащая система безопасности. Даже если пароль архива, ключ шифрования/iv и открытый ключ RSA будут опубликованы, обновления прошивки все равно будут безопасными, поскольку они используют уникальную пару открытых/закрытых ключей RSA. Всё, что это делает, это усложняет чтение и сопровождение оригинального кода. Возможно, даже будет легче упустить что-то в плане безопасности, потому что его труднее читать. Подумайте о программистах!

Давайте ломать

Итак, Hyundai/Mobis так или иначе поработали над безопасностью. Декомпилируя updateAgent, я обнаружил ещё кое-что интересное.

Обновления прошивки не обязательно должны быть зашифрованы.

В функции, которую я назвал "unzipUpdate", есть две логические ветви:

Одна ветка распаковывает zip на USB-накопитель с паролем, который я нашел, а другая распаковывает его без пароля. Вот общая логика того, как updateAgent обрабатывает обновления прошивки:

Большая схема

Для обычного человека это может показаться нормальным, но для индейца Зоркий Глаз видна потенциальная уязвимость: одна из этих веток просто не имеет никаких проверок безопасности. Если заставить систему принимать незашифрованный файл обновления (system_update.zip), я мог бы вносить какие угодно изменения.

95%?

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

С самого начала я решил сделать утилиту на C#, которая поможет автоматизировать процесс создания незашифрованного обновления прошивки. Я творчески назвал ее "HyundaiFirmwareDecrypter". Скачать

Я сделал так, чтобы она имела постепенные «шаги». Каждый шаг — это один нужный шаг в процессе создания расшифрованного ZIP-файла обновления.

Вы можете:

• Извлечь — извлекает ZIP-файл в формате d2v во временный каталог.

• Расшифровать — при необходимости расшифровывает все извлечённые файлы. Также переименовывает папки, начинающиеся с «enc_», чтобы их не было.

• Установить ADB Backdoor — включает TCP-сервер Android Debug Bridge, который можно использовать для доступа к корневой оболочке. Необходимо запускать как root/sudo.

• Вычислить хэши — вычисляет хэши SHA512 для каждого файла в обновлении и компилирует их в файл update.list.

• Создать Zip — заархивирует все файлы, создав файл обновления system_update.zip.

Утилита сделана для выполнения только этих задач. Это упрощает выполнение пользовательских модификаций, поскольку для этого достаточно выполнить первые два шага, Извлечь и Расшифровать, внести необходимые изменения в системные файлы, а затем выполните шаги «Вычислить хэши» и «Создать Zip», которые скомпилируют ваши изменения в файл обновления прошивки.

А если вам нужно «решение одним щелчком мыши», вы выполняете шаг «Установить ADB Backdoor» (-i), который активирует TCP-сервер ADB в обновлении прошивки. Это означает, что вы можете просто подключиться к Wi-Fi головного устройства или использовать Ethernet и инструмент adb, чтобы получить корневую оболочку. Для получения дополнительной информации см. Руководство «Как я взломал свой автомобиль: создание пользовательской прошивки».

Существует также простой в использовании аргумент «-a», который выполняет все шаги для создания незашифрованного файла прошивки с бэкдором ADB.

Я взял скомпилированный двоичный файл x64 linux и бросил его в новую папку на моей виртуальной машине Kali. Затем я перенёс в ту же папку последний zip-архив обновления прошивки для моего IVI (enc_d2vsystem_package_134.100.220927.zip).

Затем я создал резервное обновление прошивки командой:

sudo ./HyundaiFirmwareDecrypter enc_d2vsystem_package_134.100.220927.zip -a

Через минуту ожидания у меня в руках было незашифрованное обновление прошивки. Оставалось только выяснить, как его прошить.

Прошиваем

Процедура прошивки обновления на моем автомобиле оказалась простой. На моем ШГУ стояла версия 098.152.211 130, последнее обновление перед тем, как Hyundai исправила проблемы, которые я описывал в своих статьях.

Поскольку это обновление было выпущено до аудита безопасности, оно было более мягким в отношении функций, которые можно использовать для несанкционированной прошивки обновлений. В инженерном режиме была опция под названием «USB Image».

Кнопка "Update ALL" заставит IVI перезагрузиться в режим восстановления и прошить файл system_update.zip с флешки, следуя красивой блок-схеме, которую вы видели выше.

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

Так ура или не ура?

Всё здорово, но моё головное устройство всё ещё заблокировано, и на нём установлена ​​​​самая последняя и самая лучшая прошивка. А как насчёт всего остального?

Я решил заглянуть в последнюю прошивку и посмотреть, можно ли её взломать. И да, нашёл другой способ. Благодаря долгому изучению особенностей работы ШГУ удалось декомпилировать бесчисленное количество функций в 47 приложениях.

Одним из самых декомпилируемых является приложение Engineering Mode. По понятной причине в нём есть одни из самых интересных функций во всей системе.

В коде есть много упоминаний о всплывающем окне «Принудительное обновление» (Force Update») в параметре «Другой код» (Variant Coding). Было ясно, что он делает: пытается найти любой zip‑файл, похожий на системное обновление, на USB‑накопителе и перезагрузиться в режиме восстановления, используя его в качестве выбранного файла обновления.

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

После небольшого побочного квеста в виде попыток разгадать все секреты SetupApp я вернулся к приложению Engineering Mode и решил выяснить, как добраться до этого экрана. Судя по тому, что я нашёл в бинарнике, экран принудительного обновления был каким-то образом связан с экраном Variant Coding.

На экранах Variant Coding не видно никаких записей, связанных с системными обновлениями, но я знал, что возможны варианты. Во-первых, эта функция могла быть отключена на производственных IVI, или существовал какой-то секретный способ попасть на экран, например, как Engineering Mode или сервисный режим дилера.

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

Чтобы войти в режим дилера, вам необходимо:

• Установите громкость на 7, нажмите на ручку настройки,

• Установите громкость на 3, нажмите на ручку настройки,

• Установите громкость на 1, нажмите на ручку настройки

При последнем нажатии на ручку настройки отображается экран пароля. После ввода пароля (2400) запускается приложение Dealer Mode.

Как ни странно, просматривая функции, связанные с VariantCodingDisplay, я нашёл одну, которая срабатывала при нажатии ручки настройки.

Эта функция оказалась легко читаемой. Похоже, что она следовала той же схеме, которую использовал Dealer Mode.

На этот раз комбинация была 7, 5, 3 вместо 7, 3, 1.

Поскольку это событие было непосредственно на VariantCodingDisplay, я предположил, что если я введу этот код с помощью ручек громкости и тюнера, находясь на экране Variant Coding, отобразится ввод пароля принудительного обновления. И немедленно пошёл к своей машине. 

Я вошёл в инженерный режим только для того, чтобы обнаружить, что разработчики обновили пароль (и сделали его вдвое длиннее!). К счастью, список паролей легко найти в приложении Engineering Mode, а также во многих местах в интернете.

У меня сработал пароль 26031236.

У Variant Coding есть свой собственный новый блестящий, более длинный пароль. Используя тот же список, который я указал выше, вдалось подобрать код: 23060663. Как только я оказался в меню Variant Coding, я набрал секретный код: 7, *ручка настройки*, 5, *ручка настройки*, 3, *ручка настройки*…

И вуаля!

Я ввёл пароль 3600, система просканировала мою флешку и предложила установить незашифрованное обновление.

После выбора "Yes" головное устройство перезагрузилось и успешно переустановило мой файл обновления. Это также означает, что проверка версии не проводилась, так как версии были одинаковыми. Это означает, что функция "Force Update" может быть использована для понижения версии прошивки ШГУ в случае необходимости.

Итоги

ШГУ D-Audio на базе 2V теперь снова открыты для модификаций. Но подождите, неужели потрачена куча времени просто так?

Раздел, необязательный для чтения

Обращение простого парня Гринлуиджи1 к боссам Hyundai/Mobis 

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

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

Когда-нибудь в будущем вы перестанете поддерживать эти ШГУ.  Добавление новых функций, исправление ошибок, поддержка платформы в целом прекратятся.

Головное устройство — это инструмент, с помощью которого осуществляется дистанционный запуск, дистанционное управление климатом и удалённый мониторинг. Не говоря уже о навигации и воспроизведении музыки.

Если BlueLink просто перестанет работать в один прекрасный день, если Android Auto, Apple CarPlay или простое воспроизведение музыки начнут глючить, или возникнет проблема 2038 года, то ценность, долговечность и полезность наших транспортных средств будут сильно снижены.

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

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

Под «открытием платформы» я подразумеваю поддержку системой приложений, разработанных извне, и/или обновлений системы, разработанных извне. Вам не нужно будет открывать исходники всего вашего кода. Хотя это было бы неплохо, я понимаю желание или необходимость защиты интеллектуальной собственности компании (или другой компании).

Я также понимаю, что мир не чёрно-белый, и есть такие соображения, как снижение юридической ответственности. Но опять же, любой идиот может приклеить планшет к своей машине, подключить ключ OBD2 и что-то учудить. Если платформа открыта, ccOS и другие доступные API могут стать надёжной защитой от всего, что может негативно повлиять на транспортное средство. Сделать разработку приложений для головных устройств более безопасным выбором по сравнению с попытками напрямую поиграть с шиной CAN. Из-за всего этого и многого другого я рекомендую открыть платформу.

Вот план того, что, по моему мнению, необходимо, чтобы сделать платформу «открытой»:

• Предоставьте файлы заголовков системы, чтобы можно было разрабатывать приложения.

  • Просто еще раз включить файлы заголовков в системные обновления, как вы это делали раньше.

• Укажите способ установки обновлений приложений/прошивки.

  • Самый простой вариант — повторно включить кнопку «Обновить ВСЕ» в инженерном режиме, чтобы разрешить незашифрованные обновления. (Или сохранить текущую функцию принудительного обновления.)

  • Я также должен сказать, что для этого не требуется специального разрешения Hyundai/Mobis . Например, требуется специальный ключ от Hyundai / Mobis, чтобы «разблокировать» ШГУ. Ведь это все равно потребует от вас поддерживать эту функцию, и это не поможет людям, которым нужно разблокировать её после того, как вы перестали выдавать ключи.

Есть также ряд вещей, которые были бы полезны, но отнюдь не обязательны:

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

  • Это можно легко сделать, загрузив доступные приложения из файла .json.

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

• Продолжить разработку ccOS и API ccOS для существующих транспортных средств.

• Сделать общедоступной документацию по настройке среды разработки для приложений D-Audio 2V.

• Выложить некоторые встроенные приложения или их части с открытым исходным кодом для использования в качестве примеров.

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

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

• Формирование специализированной торговой площадки, управляемой Hyundai/Mobis, для приложений, включая одобренные приложения, созданные другими разработчиками (например, App Store).

• Иметь уровень в BlueLink или иным образом платить только за данные SIM-карты (+ небольшая надбавка?). Это позволит разрабатывать приложения, использующие интернет, а вам даст небольшой, но надежный постоянный поток доходов даже после закрытия BlueLink.

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

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

Спасибо за прочтение, greenluigi1

---

Что ещё интересного есть в блоге Cloud4Y

→ Спортивные часы Garmin: изучаем GarminOS и её ВМ MonkeyC

→ NAS за шапку сухарей

→ Взлом Hyundai Tucson, часть 1, часть 2

→ Взламываем «умную» зубную щётку

→ 50 самых интересных клавиатур из частной коллекции