Статья Аппаратный пентест IoT устройств: полное руководство по атакам на firmware и hardware-интерфейсы

В двух из трёх IoT-устройств, которые попадают ко мне на стол, UART-консоль отдаёт root shell без единого запроса пароля. Третье хотя бы спрашивает логин - но admin:admin проходит с первой попытки. Это не результат целенаправленного поиска уязвимых образцов. Это норма индустрии, где отладочные интерфейсы остаются открытыми в серийных устройствах, прошивки подписываются чем попало (или не подписываются вовсе), а обновления летят по HTTP. Аппаратный пентест IoT устройств - единственный способ увидеть эту картину целиком, от физического осмотра платы до получения полного контроля над устройством и его инфраструктурой.

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

Карта темы: от вскрытия корпуса до эксплуатации​

#	Подтема	Подробнее
1	UART, JTAG, SPI - физический доступ к отладочным интерфейсам	Аппаратный пентест: JTAG, UART и SPI для извлечения прошивок и получения shell
2	Реверс-инжиниринг прошивок: binwalk, Ghidra, статический анализ	Реверс-инжиниринг прошивок: binwalk, Ghidra и статический анализ firmware
3	Эмуляция прошивок: QEMU, Firmadyne, динамический анализ	Эмуляция прошивок embedded Linux: QEMU, Firmadyne и динамический анализ без устройства
4	Методология тестирования IoT по OWASP ISTG	Пентест IoT-устройств: от разведки и разборки до эксплуатации по OWASP ISTG
5	Обход Secure Boot и защита загрузчиков	Обход Secure Boot: техники атаки на верификацию загрузчика
6	Харденинг UEFI: BIOS-пароли, TPM, Intel Boot Guard	Харденинг UEFI и защита firmware: что реально работает
7	Реверс-инжиниринг UEFI: от SPI-flash до DXE-драйверов	Реверс-инжиниринг UEFI-прошивки: от дампа SPI-flash до анализа DXE-драйверов в Ghidra
8	Обход защиты BIOS на залоченных прошивках	Обход защиты BIOS: отключение Secure Boot на залоченных прошивках
9	Side-channel атаки: power analysis, timing, EM emanation	Side-channel атаки на практике: power analysis, timing attacks и electromagnetic emanation
10	Side-channel атаки на чиплеты (2.5D/3D системы)	Side-channel атаки на чиплеты: новая физическая поверхность атаки
11	Пентест медицинского оборудования: DICOM и lateral movement	Взлом медицинского оборудования: от fingerprinting до lateral movement через DICOM
12	Preauth RCE в embedded web-серверах (Mongoose)	Preauth RCE и обход mTLS: разбор уязвимостей Mongoose

Бизнес-логика атаки: зачем ломают IoT и embedded-системы​

Прежде чем лезть в техники - зачем всё это злоумышленнику. IoT-устройство само по себе редко бывает конечной целью. В подавляющем большинстве реальных инцидентов скомпрометированная железка - это foothold для lateral movement в корпоративную сеть. IP-камера с root shell превращается в плацдарм для сканирования внутреннего сегмента. Промышленный контроллер с захардкоженными credentials даёт доступ к OT-сети без единого алерта на SIEM - потому что трафик от «легитимного» устройства проходит мимо мониторинга.

По данным IBM X-Force Threat Intelligence Index 2025, 70% расследованных атак затронули критическую инфраструктуру. Отдельный тренд - рост использования действительных учётных данных как вектора initial access на +71% год к году. Откуда берутся эти credentials? Часть - из утечек, часть - из фишинга, но существенная доля извлекается напрямую из прошивок: захардкоженные пароли, приватные ключи SSL, API-токены к облачным сервисам.

Полная цепочка атаки через IoT: физический доступ к устройству -> извлечение прошивки -> поиск credentials и уязвимостей -> получение shell -> разведка внутренней сети -> lateral movement -> доступ к целевым активам. Каждый этап - отдельный навык и отдельный набор инструментов.

7 уровней атакующей поверхности IoT-устройства​

Русскоязычные материалы по тестированию безопасности IoT обычно сводят всё к nmap -sV и поиску дефолтных паролей. На практике атакующая поверхность embedded-устройства разворачивается на семи уровнях, и стандартный сетевой пентест покрывает от силы два из них.

Уровень 1 - Физический корпус. Антитамперные механизмы (или их отсутствие), доступность разъёмов, видимые test points на PCB. Первое, что делаешь, получив устройство - вскрываешь корпус и фотографируешь плату с обеих сторон.

Уровень 2 - Hardware-интерфейсы. UART, JTAG/SWD, SPI, I2C - контактные площадки, которые производитель использовал при разработке и забыл отключить в серии. По OWASP ISTG это компонент внутренних интерфейсов, доступных после вскрытия корпуса (PA-4 по модели атакующего).

Уровень 3 - Микросхемы памяти. SPI NOR/NAND flash, EEPROM - чипы, в которых физически лежит прошивка. Даже если UART залочен и JTAG отключён через fuse bits, прямое чтение флеш-памяти программатором даёт побайтовую копию firmware.

Уровень 4 - Прошивка (firmware). Файловая система, конфигурация, бинарники, механизм обновления. Центральный элемент анализа: здесь живут захардкоженные credentials (MITRE ATT&CK T1552.001 - Credentials In Files), устаревшие компоненты (OWASP IoT Top 10 I5) и скрытые отладочные эндпоинты.

Уровень 5 - Сетевые сервисы. Web-интерфейс, Telnet, SSH, MQTT, CoAP - всё, что слушает на портах. Тут классические web-уязвимости (command injection, broken authentication) пересекаются со спецификой embedded: RTOS без ASLR, BusyBox с набором утилит десятилетней давности.

Уровень 6 - Беспроводные протоколы. Wi-Fi, BLE, Zigbee, Z-Wave, LoRa, проприетарные RF-протоколы. Каждый требует своего инструментария: от CC2531-адаптеров для Zigbee-перехвата до SDR для анализа проприетарных частот.

Уровень 7 - Облачный backend и API. Мобильное приложение, REST API, облачная инфраструктура - место, где данные устройства уходят наружу. Тестируется по стандартным методологиям (OWASP WSTG, OWASP API Security Top 10), но с учётом специфики device-to-cloud коммуникации.

OWASP IoT Security Testing Guide (ISTG) формализует эту модель через компонентную декомпозицию: каждый элемент устройства тестируется отдельно, а модель атакующего строится на пересечении уровня физического доступа и авторизации. Подробный разбор методологии, включая скоупинг по ISTG и привязку к MITRE ATT&CK: Пентест IoT-устройств: от разведки и разборки до эксплуатации по OWASP ISTG.

UART, JTAG, SPI: 3 протокола, которые открывают любое устройство​

Это ядро аппаратного пентеста - физическое подключение к отладочным интерфейсам на плате. Большинство embedded-устройств используют один или несколько из этих протоколов для программирования и отладки при производстве.

Требования к окружению​

Минимальный набор для работы с hardware-интерфейсами:

• Мультиметр - идентификация GND, VCC, поиск неразмеченных пинов (~1 500–3 000 руб.)
• USB-UART адаптер (FT232RL, CP2102) - подключение к UART-консоли (~300–800 руб.)
• Логический анализатор (Saleae Logic клон или оригинал) - определение протокола и baud rate (~2 000–15 000 руб.)
• JTAGulator или Bus Pirate - автоматическая идентификация JTAG-пинов (~3 000–8 000 руб.)
• Программатор CH341A или Dediprog SF100 - прямое чтение SPI flash (~500–25 000 руб.)
• ПО: minicom/screen (GNU/Linux) или PuTTY (Windows) для serial-соединения, OpenOCD для JTAG
• ОС: Kali Linux или любой дистрибутив с установленными flashrom, OpenOCD. RAM: от 4 ГБ хватает для работы с интерфейсами; 8+ ГБ понадобятся на этапе анализа прошивок в Ghidra

UART - первая точка входа​

UART (Universal Asynchronous Receiver-Transmitter) - двухпроводной протокол с линиями TX (передача) и RX (приём). На большинстве IoT-плат контактные площадки UART расположены рядом группой из 3-4 пинов (TX, RX, GND, иногда VCC). Идентификация: мультиметром находишь GND (проверка непрерывности с известной заземлённой точкой - экран разъёма, корпус), VCC (стабильное 3.3В или 5В), TX (активные переключения при загрузке, видны логическим анализатором), RX (обычно подтянут к high через pull-up, определяется методом исключения).

Подключаешь USB-UART адаптер: TX адаптера к RX устройства, RX адаптера к TX устройства, GND к GND. Перед подключением убедись, что уровни логики адаптера и устройства совпадают (обычно 3.3В). Подача 5В на 3.3В UART убьёт интерфейс устройства - без вариантов. FT232RL и CP2102 поддерживают 3.3В режим (через jumper или отдельный VCCIO pin). Запускаешь minicom -D /dev/ttyUSB0 -b 115200 - и видишь bootlog. В большинстве случаев baud rate составляет 115200, реже 9600 или 57600. Логический анализатор Saleae определяет скорость автоматически по захваченному сигналу.

Что ожидать: в продакшн-устройствах UART-консоль регулярно отдаёт полноценный Linux shell с правами root. Просто так, без вопросов. Если shell закрыт - виден bootlog U-Boot, из которого можно прервать загрузку и получить доступ к загрузчику (а оттуда - модифицировать аргументы загрузки ядра и получить тот же root).

Место в kill chain: UART - этап initial access. После получения shell начинается post-exploitation: вытягиваем /etc/shadow, анализируем конфигурации, ищем SSH-ключи и API-токены для lateral movement.

JTAG/SWD - отладка на уровне процессора​

JTAG (Joint Test Action Group) даёт доступ к отладочным функциям процессора: пошаговое выполнение кода, чтение/запись памяти, остановка CPU. JTAGulator подключается ко всем подозрительным контактным площадкам и через IDCODE/BYPASS-сканирование определяет распиновку TDI/TDO/TCK/TMS. Далее OpenOCD подключается к найденному интерфейсу.

SWD (Serial Wire Debug) - двухпроводная альтернатива JTAG, распространённая на ARM Cortex-M микроконтроллерах. Требует только SWDIO и SWCLK.

Ограничение: производители могут отключить JTAG через fuse bits (одноразовое программирование OTP-памяти). В этом случае интерфейс физически мёртв. Обойти fuse bits без специализированного оборудования (лазерный fault injection, FIB) невозможно - тут никакая хитрость не поможет.

SPI - прямое чтение флеш-памяти​

Когда UART заблокирован и JTAG отключён, остаётся последний козырь - чтение SPI-flash напрямую. Программатор CH341A подключается к ножкам микросхемы (через клипсу SOIC-8 или после выпаивания чипа), и flashrom -p ch341a_spi -r dump.bin создаёт побайтовую копию.

Когда использовать: SPI-чтение - метод, который работает практически всегда при физическом доступе к плате. Его ограничения: зашифрованная прошивка (встречается в устройствах enterprise-класса и военных системах) и BGA-корпуса микросхем без доступных ножек.

Пошаговый разбор всех трёх протоколов с реальными примерами подключения и скриншотами вывода: Аппаратный пентест: JTAG, UART и SPI для извлечения прошивок и получения shell.

Реверс-инжиниринг прошивки: от бинарного дампа до захардкоженных секретов​

Получив дамп прошивки (через UART, SPI, JTAG, перехват OTA-обновления или скачивание с сайта вендора), переходим к анализу. Это центральный этап пентеста прошивки firmware - именно здесь находятся 80% всех уязвимостей embedded-устройств.

Статический анализ: что искать в распакованной прошивке​

Первый шаг - понять, что внутри дампа. Binwalk сканирует бинарный файл на известные сигнатуры (заголовки файловых систем, сжатых архивов, ядер Linux) и вытаскивает вложенные компоненты. На выходе - корневая файловая система (SquashFS, JFFS2, cramfs) с полной структурой каталогов устройства.

Что искать после распаковки (в порядке приоритета):

1. Захардкоженные credentials - grep -ri 'password\|passwd\|secret\|token\|api_key' по всей файловой системе. Firmwalker автоматизирует процесс, проверяя /etc/shadow, /etc/passwd, конфигурационные файлы, SSL-сертификаты и приватные ключи. По MITRE ATT&CK это T1552.001 - Credentials In Files
2. Устаревшие компоненты - версии BusyBox, OpenSSL, ядра Linux. Устройства с BusyBox 1.19 и OpenSSL 1.0.1 - регулярная находка в 2025 году. Каждый устаревший компонент - потенциальный вектор для known CVE
3. Отладочные эндпоинты - скрытые CGI-скрипты, бэкдорные аккаунты, telnet-демоны, запускаемые по условию
4. Механизм обновления - скачивается ли прошивка по HTTP или HTTPS? Проверяется ли цифровая подпись? Возможен ли downgrade до уязвимой версии?

Глубокий реверс-инжиниринг в Ghidra​

Когда grep и Firmwalker отработали, Ghidra берёт на себя анализ бинарников: декомпиляция ARM/MIPS-кода, поиск небезопасных вызовов (system(), strcpy(), sprintf()), восстановление логики аутентификации. На одном проекте скрытый CGI-эндпоинт с command injection нашёлся именно так - его не было ни в документации, ни в веб-интерфейсе. Ghidra показала вызов system() с пользовательским вводом без какой-либо санитизации.

Ограничения статического анализа: обфускация кода, кастомные файловые системы без известных сигнатур, зашифрованные разделы прошивки (требуют извлечения ключа из bootloader или аппаратного модуля). В RTOS-системах (FreeRTOS, Zephyr) нет классической файловой системы - нужен прямой анализ бинарного образа с разбором memory layout и task structures.

Подробное руководство по инструментам и методикам статического анализа: Реверс-инжиниринг прошивок: binwalk, Ghidra и статический анализ firmware для поиска уязвимостей.

Эмуляция прошивок: динамический анализ без физического устройства​

Статический анализ показывает, что есть в коде. Динамический показывает, как код ведёт себя при исполнении - и именно тут всплывают buffer overflow, race conditions, обход аутентификации и другие runtime-уязвимости.

QEMU эмулирует процессорные архитектуры ARM, MIPS, PowerPC - основные платформы IoT-устройств. Firmadyne автоматизирует процесс: извлекает прошивку, определяет архитектуру, конфигурирует сетевой стек и запускает эмулированную систему с сетевым доступом. После этого можно натравливать стандартные инструменты: Nmap для сканирования портов, Burp Suite для тестирования веб-интерфейса, GDB для отладки конкретных бинарников.

Когда эмуляция не работает​

Эмуляция покрывает далеко не все случаи:

• Аппаратно-зависимый код - драйверы кастомных периферийных устройств, обращения к специализированным регистрам SoC
• Аппаратные крипто-модули - TPM, secure enclave, hardware RNG
• Проприетарные RTOS - без исходного кода ядра полная эмуляция невозможна
• Timing-зависимая логика - watchdog timers, real-time обработка прерываний

В таких случаях динамический анализ проводится на реальном устройстве через GDB, подключённый к JTAG/SWD. Без физической железки - никак.

Требования к окружению для эмуляции: GNU/Linux (Ubuntu 20.04+), RAM: минимум 8 ГБ (16 ГБ рекомендуется при одновременной работе Ghidra + QEMU), зависимости: QEMU, binwalk, Firmadyne (или FAT), Python 3.x.

Пошаговое развёртывание окружения эмуляции: Эмуляция прошивок embedded Linux: QEMU, Firmadyne и динамический анализ без устройства.

Разведка IoT-инфраструктуры: от FCC ID до Shodan​

Аппаратный пентест начинается задолго до вскрытия корпуса. Грамотная разведка определяет, с чем предстоит работать, и экономит часы на этапе физического анализа.

Пассивная разведка (OSINT)​

FCC ID - каждое радиоизлучающее устройство, продаваемое в США, проходит сертификацию FCC. В открытом доступе валяются фотографии внутренностей: PCB, чипы, антенны, маркировки микросхем. По MITRE ATT&CK это T1592.001 - Gather Victim Host Information: Hardware и T1592.003 - Firmware. Не вскрыв корпус, уже знаешь, какой процессор стоит внутри, где на плате искать UART, какой тип flash-памяти используется. Бесплатная разведка - бери и пользуйся.

Shodan / Censys - для устройств с сетевым доступом. Запрос по характерным баннерам (lighttpd, uhttpd, GoAhead-Webs, Boa HTTPd) идентифицирует модель и потенциальную версию прошивки. Открытые порты 1883 (MQTT без TLS), 5683 (CoAP), диапазон 8000–9000 - типичные маркеры IoT-устройств. По MITRE ATT&CK это T1596 - Search Open Technical Databases.

Сайт вендора - обновления прошивок часто доступны для скачивания. Самый простой способ получить firmware для анализа без физического контакта с устройством.

Активная разведка​

[Применимо: внутренний пентест, grey box] После подключения к сети, в которой работают целевые устройства:

• nmap -sV -O --script=banner <target> для идентификации сервисов
• Перехват MQTT-трафика (mosquitto_sub -h <broker> -t '#'), если брокер работает без аутентификации - по MITRE ATT&CK T1040 - Network Sniffing
• Для Zigbee - CC2531 адаптер + KillerBee (zbdump). Well-known Trust Center Link Key ZigBeeAlliance09 позволяет расшифровать join-процедуру и получить network key (работает на устройствах Zigbee HA 1.2 и старых Zigbee 3.0 deployments; в современных Zigbee 3.0 устройствах с обязательным Install Code расшифровка join требует знания уникального install code конкретного устройства)
• Для BLE - ubertooth или стандартный Bluetooth-адаптер с gatttool/bettercap

Secure Boot и защита загрузчика: почему обход работает чаще, чем должен​

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

Типичные векторы обхода:

• Неподписанный bootloader - первая стадия загрузки (ROM bootloader) проверяет подпись U-Boot, но сам U-Boot не проверяет подпись ядра. Цепочка доверия разрывается на втором звене - классика
• Downgrade атака - устройство принимает старую версию прошивки с известными уязвимостями, потому что anti-rollback не реализован. По документации он «есть», на практике - нет
• Glitching - электрический импульс на линии питания или тактирования в момент проверки подписи вызывает ошибку CPU, и проверка «пропускается». Для этого используется ChipWhisperer или самодельный glitcher

[Применимо: white box пентест, physical access level 4 по ISTG] Обход Secure Boot - продвинутая техника, которая требует понимания конкретной реализации загрузчика на конкретном SoC. Универсальных эксплойтов тут нет.

Технический разбор методов обхода: Обход Secure Boot: техники атаки на верификацию загрузчика для пентестеров.

Защитная сторона - какие механизмы реально работают и какие обходятся: Харденинг UEFI и защита firmware: BIOS-пароли, Secure Boot, TPM и Intel Boot Guard - что реально работает.

UEFI-прошивки: отдельная вселенная реверс-инжиниринга​

UEFI (Unified Extensible Firmware Interface) - стандарт прошивок для x86-платформ: серверы, ноутбуки, промышленные ПК, сетевое оборудование enterprise-класса. Анализ UEFI-прошивок принципиально отличается от работы с Linux-based firmware IoT-устройств.

Дамп SPI-flash (чип, в котором хранится UEFI) снимается программатором или через программный доступ (flashrom, Intel CSME tools). Далее UEFITool разбирает бинарный образ на отдельные модули: PEI (Pre-EFI Initialization), DXE (Driver Execution Environment), SMM (System Management Mode). Каждый DXE-драйвер - PE32+-бинарник, который загружается в Ghidra для препарирования.

Что ищем в UEFI-прошивке:

• SMM-уязвимости - ошибки в обработчиках System Management Interrupt дают доступ к ring -2, уровню привилегий выше ядра ОС. Это уже не просто «рут» - это бог машины
• Не отключённые BIOS-пароли - или пароли, хранящиеся в NVRAM в открытом виде
• Незащищённые переменные Secure Boot - возможность подмены ключей db/dbx/KEK
• Backdoor-модули - DXE-драйверы, добавленные за пределами стандартной сборки

Подробное руководство по реверсу UEFI: Реверс-инжиниринг UEFI-прошивки: от дампа SPI-flash до анализа DXE-драйверов в Ghidra.

Практические методы обхода защиты BIOS на залоченных прошивках: Обход защиты BIOS: отключение Secure Boot на залоченных прошивках.

Side-channel атаки: когда софт защищён, но физика подводит​

Side-channel атаки эксплуатируют не баги в коде, а физические свойства работающего чипа: потребление тока, время выполнения операций, электромагнитное излучение. Даже криптографически корректная реализация AES может «утечь» ключ через паттерны энергопотребления. Код безупречен, а железо сдаёт.

3 класса side-channel атак в практике пентеста​

Timing attacks - измерение времени выполнения криптографических операций. Если проверка пароля побайтовая (ранний выход при первом несовпадении), разница во времени ответа позволяет перебрать пароль посимвольно. Специализированное оборудование не нужно - хватит точного таймера.

[Применимо: внешний и внутренний пентест, любые устройства с сетевым доступом. Ограничение: не работает при constant-time проверке или random delay]

Power analysis - снятие графика потребления тока при выполнении криптоопераций. ChipWhisperer подключается к линии питания чипа и записывает power traces. Simple Power Analysis (SPA) позволяет визуально различить операции по паттерну потребления. Differential Power Analysis (DPA) использует статистическую корреляцию тысяч traces для извлечения ключа.

[Применимо: physical access, white box. Требует: ChipWhisperer (~25 000–60 000 руб.), навык работы с осциллографом]

Electromagnetic emanation - перехват EM-излучения процессора ближнепольной антенной. Не требует физического контакта с линией питания - антенна размещается над чипом на расстоянии нескольких миллиметров.

Детальный разбор каждого класса с практическими примерами: Side-channel атаки на практике: power analysis, timing attacks и electromagnetic emanation для пентестера.

Новое направление - атаки на межчиплетные интерконнекты в 2.5D/3D упаковках: Side-channel атаки на чиплеты: новая физическая поверхность атаки в 2.5D/3D системах.

Пентест IoT в специфических средах: медицина, промышленность, automotive​

Аппаратные уязвимости embedded систем проявляются по-разному в зависимости от отрасли. Универсальные техники (UART, firmware extraction) работают везде, но контекст применения и последствия кардинально различаются.

Медицинское оборудование​

Инфузионные насосы, мониторы пациентов, PACS-серверы для хранения рентгеновских снимков - все сидят на embedded-платформах с теми же проблемами: дефолтные credentials, устаревшие компоненты, отсутствие шифрования. Специфика: протокол DICOM (Digital Imaging and Communications in Medicine) передаёт медицинские изображения в открытом виде и часто используется как вектор lateral movement из сегмента медоборудования в корпоративную сеть.

Чем OT-угрозы отличаются от IT в медицине: стандартные EDR (CrowdStrike Falcon, SentinelOne) не устанавливаются на embedded-устройства с проприетарной ОС; обновления прошивок требуют сертификации FDA/Росздравнадзора, что задерживает патчинг на месяцы и годы; мониторинг SIEM «слеп» к трафику между медицинскими устройствами внутри VLAN - алерты просто не генерируются.

Подробный разбор: Взлом медицинского оборудования: от fingerprinting до lateral movement через DICOM.

Промышленные контроллеры (OT/ICS)​

PLC, RTU, HMI-панели - устройства, управляющие физическими процессами. Протоколы Modbus (function codes FC1–FC6 для чтения/записи регистров), DNP3, PROFINET не имеют встроенных механизмов аутентификации вообще. Скомпрометированный контроллер позволяет изменить уставки процесса - это уже не утечка данных, а физическое воздействие. Реальные прецеденты: TRITON (атака на систему противоаварийной защиты Schneider Electric Triconex), Industroyer (отключение электроподстанций в Украине).

Embedded web-серверы​

Mongoose, lighttpd, GoAhead - HTTP-серверы, встроенные в firmware IoT-устройств. Минимальный код, отсутствие hardening, работа в embedded-контексте без привычных защитных механизмов ОС общего назначения. Уязвимости в таких серверах затрагивают миллионы устройств одновременно - одна CVE, и целый класс железа лежит.

Разбор конкретного случая: Preauth RCE и обход mTLS: разбор уязвимостей Mongoose на миллионах устройств.

Инструментарий аппаратного пентестера: что нужно в лаборатории​

Категория	Инструмент	Назначение	Бюджет (руб.)
Serial-интерфейсы	FT232RL / CP2102 (USB-UART)	Подключение к UART	300–800
Serial-интерфейсы	Bus Pirate	UART, SPI, I2C, JTAG - универсальный адаптер	2 000–5 000
Идентификация пинов	JTAGulator	Автоматическое определение JTAG-распиновки	8 000–15 000
Измерения	Мультиметр	Определение GND, VCC, измерение уровней	1 500–3 000
Измерения	Логический анализатор (Saleae / клон)	Перехват и декодирование протоколов	2 000–15 000
Flash-программирование	CH341A	Чтение SPI NOR flash	500–1 000
Flash-программирование	Dediprog SF100	Профессиональный SPI-программатор	20 000–30 000
Side-channel	ChipWhisperer	Power analysis, fault injection	25 000–60 000
RF/Wireless	CC2531 + кастомная прошивка	Zigbee-перехват	1 000–2 000
RF/Wireless	RTL-SDR	Разведка радиочастотного диапазона	2 000–4 000
Пайка	Паяльная станция + hot air	Демонтаж flash-чипов, подключение проводов	5 000–20 000

Программные инструменты: binwalk (распаковка прошивок), Ghidra (реверс-инжиниринг), Firmwalker (автоматический поиск артефактов), flashrom (работа с SPI flash), OpenOCD (JTAG/SWD), QEMU + Firmadyne (эмуляция), Wireshark (анализ трафика).

Минимальный входной порог: USB-UART адаптер + мультиметр + CH341A = примерно 2 500 руб. С этим набором уже можно подключиться к UART, тупо снять дамп SPI-flash и начать ковырять прошивку.

Decision tree: выбор вектора атаки на embedded-устройство​

Какую технику применять - зависит от того, что доступно и что разрешено скоупом проекта.

Шаг 1. Определить уровень физического доступа:

• Нет физического доступа -> только сетевая разведка и тестирование сервисов (уровни 5–7)
• Есть устройство, но вскрытие запрещено -> внешние интерфейсы (USB, Ethernet), OTA-обновления, сетевые сервисы
• Полный физический доступ -> все уровни, включая вскрытие, пайку, chip-off

Шаг 2. Проверить доступность прошивки без физического вмешательства:

• Прошивка валяется на сайте вендора? -> Скачать и анализировать статически
• Есть OTA-обновление? -> Перехватить трафик обновления (MITM)
• Ни то, ни другое -> переход к аппаратному извлечению

Шаг 3. При физическом доступе - последовательность проб:

1. Ищем UART -> подключаемся -> если shell - начинаем post-exploitation
2. UART заблокирован -> ищем JTAG/SWD -> если есть - читаем память через OpenOCD
3. JTAG отключён -> chip-off: снимаем дамп SPI-flash программатором
4. Flash зашифрован -> нужен ключ из bootloader (прерывание загрузки U-Boot через UART) или side-channel атака на крипто-модуль

Шаг 4. Анализ прошивки:

• Стандартная Linux-based система -> binwalk + Firmwalker + Ghidra
• RTOS без файловой системы -> Ghidra для прямого анализа бинарного образа
• Зашифрованный блоб -> поиск ключа в незашифрованных секциях (bootloader, U-Boot environment)

Регуляторный контекст: зачем аппаратный пентест нужен бизнесу​

Аппаратный пентест IoT устройств - не академическое упражнение. Это требование стандартов и регуляторов:

• EU Cyber Resilience Act (CRA) - вступает в силу в 2027, требует от производителей подключённых устройств демонстрировать security by design и проводить оценку уязвимостей на всех уровнях, включая hardware
• ETSI EN 303 645 - европейский стандарт безопасности потребительских IoT-устройств: запрет дефолтных паролей, обязательный механизм обновления, минимизация атакующей поверхности
• OWASP IoT Top 10 - фреймворк для оценки рисков IoT: I1 (Weak Passwords), I4 (Insecure Update Mechanism), I5 (Insecure Components), I10 (Lack of Physical Hardening)
• ФЗ-187 о безопасности КИИ - для организаций, использующих IoT/embedded-устройства в составе критической информационной инфраструктуры: ФСТЭК надзирает за выполнением требований безопасности ЗОКИИ
• PCI DSS 4.0 - для устройств в платёжной инфраструктуре (POS-терминалы, платёжные киоски): требования к тестированию физической безопасности

Чеклист для передачи в отчёт:

1. Проверить наличие и работоспособность антитамперных механизмов корпуса
2. Идентифицировать и протестировать все отладочные интерфейсы (UART, JTAG, SWD)
3. Извлечь и проанализировать прошивку на наличие захардкоженных credentials
4. Проверить версии компонентов (BusyBox, OpenSSL, ядро) на known CVE
5. Верифицировать механизм обновления прошивки (HTTPS, проверка подписи, anti-rollback)
6. Проверить шифрование хранимых данных и передаваемого трафика
7. Протестировать сетевые сервисы и веб-интерфейс на стандартные уязвимости
8. Оценить устойчивость к downgrade-атакам на прошивку
9. Проверить изоляцию отладочных функций от production-режима
10. Задокументировать цепочку доверия Secure Boot (если реализована)

Куда движется аппаратный пентест: тренды 2025–2026​

EU Cyber Resilience Act создаёт юридическое давление на производителей - тестирование hardware security перестаёт быть «приятным дополнением» и становится обязательным условием выхода на рынок. Спрос на специалистов, способных работать с физическим уровнем устройств, растёт.

Технически: SoC-вендоры усиливают аппаратную защиту - ARM TrustZone, RISC-V Physical Memory Protection, secure enclaves. Fuse bits и encrypted boot становятся стандартом в новых чипах. Простые сценарии (открытый UART -> root shell) будут встречаться реже, а fault injection и side-channel атаки станут обязательными навыками пентестера, а не экзотикой.

Параллельно растёт автоматизация firmware-анализа: EMBA объединяет binwalk, Firmwalker, CVE-matching и статический анализ в единый pipeline. Но автоматизация не заменяет ручной анализ - она ускоряет тривиальную часть и освобождает время для глубокого реверса, где находятся серьёзные уязвимости.

Отработайте навыки на практике​

Аппаратный пентест - дисциплина, которая не изучается по документации. Нужна реальная плата перед глазами, паяльник в руках и логический анализатор на столе. На курсах Codeby по наступательной безопасности есть практические лабораторные среды для отработки описанных техник - от работы с firmware до эксплуатации уязвимостей embedded-систем.

Заключение​

Большинство команд, которые «тестируют безопасность IoT», на деле запускают Nmap по IP-адресу устройства, получают список открытых портов, проверяют дефолтные пароли на веб-интерфейсе - и пишут отчёт. Аппаратный уровень не трогают вообще. Результат предсказуем: отчёт содержит «критических уязвимостей не обнаружено», а через полгода кто-то покупает то же устройство на AliExpress, вскрывает корпус, находит открытый UART с root shell и захардкоженные credentials ко всему облачному backend.

Проблема не в инструментах - Bus Pirate стоит как два обеда в кафе. Проблема в том, что индустрия пентеста выросла из софтверной традиции, где всё происходит на экране. Паяльник, мультиметр, осциллограф - чужеродные предметы для специалиста, привыкшего к Burp Suite и Metasploit. И пока это так, embedded-устройства останутся самым слабым звеном в периметре любой организации.

На горизонте двух лет ситуация обострится: EU CRA потребует аппаратного тестирования от производителей, и рынку понадобятся специалисты, которых сейчас готовят единицы программ. Кто освоит работу с железом сегодня - окажется в позиции, где спрос кратно превышает предложение. А кто продолжит ограничиваться сетевым сканированием - будет писать отчёты, которые не стоят бумаги, на которой напечатаны.