Аппаратные атаки представляют большую угрозу для всех устройств с микроконтроллерами (далее – МК), поскольку с их помощью можно обойти разные механизмы безопасности. От таких атак тяжело защититься программными или аппаратными средствами. Для примера можно прочитать статью от STMicroelectronics про различные виды аппаратных атак и методы защиты МК.
Мы – команда Raccoon Security – заинтересовались этой темой, поскольку одним из направлений деятельности нашей компании является разработка embedded-устройств, в том числе содержащих механизмы защиты информации. По большей части нас интересуют glitch-атаки, поскольку они позволяют проскользнуть мимо исполняемых инструкций МК. Это серьезная угроза для конфиденциальной информации, содержащейся в МК, и самое опасное последствие таких атак – считывание закрытой прошивки в обход механизмов безопасности, предусмотренных разработчиками МК.

На конференциях Hardwear.io 2018 в Гааге и EmbeddedWorld 2019 в Нюрнберге компания NewAE демонстрировала устройство ChipWhisperer, позволяющее реализовать ту часть неинвазивных аппаратных атак, которые не требуют глубинных знаний наноэлектроники и наличия специфического оборудования. При помощи этого устройства мы изучили безопасность embedded-устройств и поняли, как минимизировать результат подобных атак. Под катом – что у нас получилось.

В предыдущей статье мы разбирались с Vcc-glitch-атаками при помощи ChipWhisperer. Нашей дальнейшей целью стало поэтапное изучение процесса считывания защищенной прошивки микроконтроллеров. С помощью подобных атак злоумышленник может получить доступ ко всем паролям устройства и программным алгоритмам. Яркий пример – взлом аппаратного криптокошелька Ledger Nano S с платой МК STM32F042 при помощи Vcc-glitch-атак.

Интересно? Давайте смотреть под кат.

Предыстория

Стажировка – это процесс получения знаний и опыта. Наша команда Raccoon Security считает, что повышение уровня информационной безопасности окружающих нас устройств и ПО невозможно без передачи этих знаний и опыта будущим поколениям специалистов. Именно поэтому мы уже много лет организуем индивидуальные стажировки для талантливых студентов и выпускников.

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

TDD для микроконтроллеров. Часть 1: Первый полет
TDD для микроконтроллеров. Часть 2: Как шпионы избавляют от зависимостей
TDD для микроконтроллеров. Часть 3: Запуск на железе

В первой части нашего цикла статей мы начали освещать тему эффективности применения методологии TDD для микроконтроллеров (далее – МК) на примере разработки прошивки для STM32. Мы выполнили следующее:

1. Определили цель и инструменты разработки.
2. Настроили IDE и фреймворк для написания тестов.
3. Написали тест-лист для разрабатываемого функционала.
4. Создали первый простой тест и запустили его.

Во второй статье мы описали процесс разработки платформонезависимой логики по методологии TDD.

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

Подробности – под катом.

Зачем?!

Наверное, это первая эмоция большинства людей, прочитавших название статьи. Однако, давайте представим следующую ситуацию: в процессе исследования устройства вы доходите до точки, когда можете исполнить внутри устройства свой код, и хотите вывести через UART заветное "Hello, Habr!", помигать светодиодами на плате как на новогодней ёлке или включить JTAG, но всего этого в вашем распоряжении нет.

В этой статье мы покажем необычный способ трассировки прошивки устройств с помощью эмулятора SPI-флешек.

Разработка своего устройства от А до Я. Часть 2: Создание устройства

В предыдущей статье мы рассказали о том, что такое электронное устройство и как начать разработку собственного девайса. Мы рассмотрели следующие этапы:

• проработка концепции устройства;
• разработка функциональной схемы;
• разработка принципиальной схемы;
• закупка компонентов;
• макетирование и симуляция устройства.

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

Сложная завязка

Предыстория...

Исследование

«Да я роботов по приколу изобретаю!» Рик Санчес

Многим известно, что в 2019 году АНБ решило предоставить открытый доступ к своей утилите для дизассемблирования (реверс-инжиниринга) под названием Ghidra. Эта утилита стала популярной в среде исследователей благодаря высокой «всеядности». Данный материал открывает цикл статей, посвященных плагину ghidra_nodejs для Ghidra, разработанному нашей командой (https://github.com/PositiveTechnologies/ghidra_nodejs). Задача плагина — десериализовать содержимое jsc-файлов, дизассемблировать байткод функций и декомпилировать их. В первой статье мы обсудим сущности и байткод движка V8, а также тезисно опишем сам плагин, про который подробно расскажем в последующих статьях.

Рано или поздно все сталкиваются с программами на языке JavaScript, их так и называют скриптами. JavaScript — это полноценный язык со своим стандартом ECMA Script, скрипты которого выполняются не только в браузере, но и на сервере.

Скрипты исполняются с помощью специальной программы, которую называют движком (engine) JavaScript. За годы движкостроения их понапридумывали предостаточно: V8, SpiderMonkey, Chakra, Rhino, KJS, Nashorn и т. д.

Автор: Константин Молодяков

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

Я наткнулся на одну особенность APK-файлов — специальную подпись с особым блоком метаданных, Frosting. Она позволяет однозначно определить, распространялся ли файл через Google Play. Эта подпись будет полезна для антивирусных вендоров и песочниц при анализе вредоносов. Кроме того, она может помочь криминалистам при поиске источника файла.

Информации об этом практически нет. Удалось найти только раздел Security metadata in early 2018 в Android Developers Blog и утилиту Avast, которая позволяет проверить данную подпись. Я решил изучить эту штуку, проверить корректность предположений разработчиков Avast о содержании Frosting-блока и поделиться своими выводами.