При разработке аппаратных решений на базе микроконтроллеров производители хотят защитить свою прошивку от попадания в руки злоумышленников, так как в ней могут содержаться чувствительная информация, ключи шифрования, уникальные алгоритмы, представляющие ценность, и др. Для этого в большинстве микроконтроллеров реализованы технологии защиты от считывания (readout protection) встроенной флеш-памяти. Но так ли хорошо они защищают?

К сожалению, не все технологии Readout Protection работают так, как задумывалось. Для обхода защиты могут быть использованы уязвимости отладочных интерфейсов, нетривиальные атаки типа fault-injection и даже инвазивное вмешательство.

Мы в Positive Labs занимаемся исследованиями безопасности различного «железа». Поэтому, когда в наши руки попало устройство на базе микроконтроллера семейства GD32 компании GigaDevice, мы сами не заметили, как начали исследовать применяющиеся в этих микроконтроллерах технологии защиты. Данные микроконтроллеры довольно популярны и используются повсеместно, в том числе в качестве замены микроконтроллеров STM32, т.к. зачастую совместимы с ними по выводам и даже по карте адресного пространства. Исследование оказалось довольно увлекательным, а результаты — впечатляющими!

Появление эксплойта checkm8 можно назвать одним из важнейших событий прошедшего года для исследователей продукции Apple. Ранее мы уже опубликовали технический анализ этого эксплойта. Сейчас сообщество активно развивает джейлбрейк checkra1n на основе checkm8, поддерживающий линейку устройств iPhone от 5s до X и позволяющий установить на iOS пакетный менеджер Cydia и с его помощью устанавливать различные пакеты и твики.

checkm8 в значительной степени опирается на смещения различных функций в SecureROM и данных в SRAM. В связи с этим могут возникнуть вопросы: как изначально был извлечен SecureROM конкретного устройства? Был ли он извлечен с помощью уязвимостей, лежащих в основе checkm8, или каким-то другим образом?

Наверное, ответить на эти вопросы могут лишь сами исследователи, принимавшие участие в разработке checkm8. Однако, в этой статье мы расскажем об одном из подходов к извлечению SecureROM, основанном на уязвимостях, используемых в checkm8, и требующем минимальных знаний о структуре памяти устройства. Описанный метод не является универсальным и будет работать только на устройствах без технологии безопасности W^X. В качестве примера мы рассмотрим Lightning-видеоадаптер Apple (да, в этом адаптере есть свой SoC с SecureROM) и продемонстрируем не только извлечение SecureROM, но и полную реализацию функциональности checkm8 для этого адаптера.

Most likely you've already heard about the famous exploit checkm8, which uses an unfixable vulnerability in the BootROM of most iDevices, including iPhone X. In this article, we'll provide a technical analysis of this exploit and figure out what causes the vulnerability.

С большой вероятностью вы уже слышали про нашумевший эксплойт checkm8, использующий неисправимую уязвимость в BootROM большинства iDevice-ов, включая iPhone X. В этой статье мы приведем технический анализ эксплойта и разберемся в причинах уязвимости. Всем заинтересовавшимся — добро пожаловать под кат!

-0x01 — Intro

Данная статья посвящена разбору всех заданий Flare-On 2019 — ежегодного соревнования по реверс-инжинирингу от FireEye. В данных соревнованиях я принимаю участие уже второй раз. В предыдущем году мне удалось попасть на 11-ое место по времени сдачи, решив все задачи примерно за 13 суток. В этом году набор тасков был проще, и я уложился в 54 часа, заняв при этом 3 место по времени сдачи.

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

Если вас заинтересовало, то добро пожаловать под кат!

В рамках данной статьи мы достаточно подробно рассмотрим процесс написания эксплоита под уязвимость в Microsoft Edge, с последующим выходом из песочницы. Если вам интересно узнать, как выглядит этот процесс, то welcome под кат!