Пишем универсальную глитч-машину

Для проведения очередной глитч-атаки на новом семействе процессоров Renesas возникла идея создания относительно универсальной глитч-машины на базе микроконтроллера Raspberry Pi Pico

Для проведения очередной глитч-атаки на новом семействе процессоров Renesas возникла идея создания относительно универсальной глитч-машины на базе микроконтроллера Raspberry Pi Pico

Автомобильные блоки управления полны компонентов, промаркированных нестандартно. Например, встречались микросхемы, на которых выбито "Toyota", хотя ежу понятно, что Toyota никаких процессоров не производит. Но в мире электроники при больших партиях производители чипов имеют возможность выбить на чипе ваш логотип, или маркировку, и разработчики ЭБУ этим активно пользуются, хотя цели их не совсем ясны.
Но нестандартная маркировка - это еще цветочки! Существует огромный пласт кастомных компонентов, выполненных "под заказ" для конкретного производителя ЭБУ. Такие проприетарные компоненты зачастую не только не имеют открытой документации, но и отсутствуют в линейке производителя.
Не так давно мы разбирались с процессором TMS470R1A256, очень популярный в блоках SRS 2007-2010 г.в.. На нём выбивают маркировки: TMS470R1VF3482 или TMS470AVF3482, однако достаточно подключиться к этому процессору посредством отладчика чтобы понять, что это процессор TMS470R1A256. Дело в том, что согласно datasheet на эти процессоры, в каждом процессоре есть device identification code register, прочитав который, вы сможете узнать part number данного процессора, который уже можно отыскать в datasheet.
Например, для TMS470R1A256: `The assigned device-specific part number for the A256 device is 0001010` что при переводе в hex = 0x0A. Много разработчиков написало программы для чтения данных процессоров, но почему-то блоки с процессорами, записанными этими программами, не выходили на связь. Пришлось разбираться с этим вопросом самостоятельно, результатом чего стала версия программы JLinkZReader, в которой проблема чтения и записи данных CPU была решена.

Мы платим немалые деньги за мощные карманные компьютеры, но реальный контроль над устройством часто остается мифом. Личный эксперимент с «неубиваемыми» приложениями и скрытой слежкой.
Вы купили телефон. Он лежит у вас в кармане. Вы за него заплатили. Казалось бы, он ваш. Но так ли это на самом деле? Моя недавняя история заставила меня усомниться в этом фундаментальном, казалось бы, факте.
Все началось с батареи. Мой телефон стал разряжаться подозрительно быстро. Будучи технически подкованным пользователем, я решил копнуть глубже. Без рут‑прав, но с помощью Android Debug Bridge (ADB) и команды ps, я начал изучать запущенные процессы. На первый взгляд — все чисто, только системные службы. Ничего криминального.
Потом случился инцидент с обновлением приложения Альфа‑Банка. Оно запросило доступ к «Неизвестным источникам» (разрешение на установку приложений). Я разрешил, обновил и... благополучно забыл об этом. Но позже вспомнил: держать приложение в списке источников — серьезный риск! Это как выдать кому‑то ключ от вашей крепости — оно может устанавливать другие приложения без вашего ведома. Я всегда строго контролирую этот список, оставляя там только абсолютно доверенные программы.
Каково же было мое изумление, когда, заглянув в настройки безопасности (Настройки > Безопасность > Установка неизвестных приложений), я обнаружил там несколько программ, которых точно не добавлял! Среди них было какое‑то безликое «Обратная связь» и загадочный «oms‑core».
«Ладно, — подумал я, — Сейчас исправим». Я спокойно снял галочки напротив этих приложений, лишив их статуса источника установки. Чувство выполненного долга длилось недолго. Какое‑то сомнение грызло меня. Я вернулся в настройки буквально через минуту... и обомлел. Галочки стояли на месте! Я проделал операцию еще раз — результат был тот же. Отключить эту функцию у этих приложений оказалось невозможно.

Ремонт блока SRS от Mitsubishi, главной особенностью является его предыстория, о том что с ним случилось до попадания в нашу лабораторию. Кажется, что после такого его уже не восстановить, однако все возможно.

В новой статье мы расскажем о необычном случае восстановления блока SRS от Audi A4, который был "сломан" после неудачного обновления прошивки. Вы узнаете:
Как внутренняя ошибка B2000 блокирует работу ЭБУ и почему её невозможно устранить стандартными методами.
Что такое технология voltage glitching и как она позволяет обойти защиту закрытых процессоров.
Какие инструменты и методы используются для восстановления автомобильных блоков управления.
Практические шаги по работе с процессором V850E2 и восстановлению флеш-памяти.
Статья будет полезна не только специалистам по автомобильной электронике, но и всем, кто интересуется современными технологиями и их применением в реальной жизни.

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

В статье обсуждается ремонт блока SRS от Volkswagen Crafter посредством исследования его прошивки. Статья рассчитана на профессионалов в области автомобильной электроники.