Статья Аппаратный пентест: JTAG, UART и SPI для извлечения прошивок и получения shell

На аудите сетевого оборудования промышленного объекта четыре UART-пада нашлись за двадцать минут после вскрытия корпуса - два из них давали root shell без аутентификации, третий выплёвывал лог загрузки с паролями в plaintext. Прошивка, снятая через SPI с микросхемы Winbond W25Q16, содержала захардкоженные SSH-ключи и отладочный аккаунт. Initial access обеспечил паяльник и USB-TTL переходник за 300 рублей - до сетевых атак и fuzzing дело не дошло.

Три интерфейса - UART, SPI и JTAG - покрывают подавляющую часть задач по hardware hacking IoT-устройств. Ниже - конкретное оборудование, команды, ошибки, которые стоят времени, и чёткие критерии выбора интерфейса под задачу.

Место аппаратного пентеста в цепочке атаки​

Аппаратный анализ встраиваемых систем - не отдельная дисциплина, а конкретный этап kill chain. В терминах MITRE ATT&CK физический пентест оборудования покрывает несколько тактик:

• Reconnaissance - сбор информации о hardware-платформе (T1592.001, Hardware) и прошивке устройства (T1592.003, Firmware). Визуальный осмотр платы, идентификация чипов по маркировке, определение архитектуры процессора.
• Initial Access - физическое подключение к отладочным интерфейсам (T1200, Hardware Additions). UART-консоль с root shell - классика жанра.
• Collection - извлечение данных из flash-памяти (T1005, Data from Local System). SPI-дамп через flashrom.
• Credential Access - поиск захардкоженных учётных данных в извлечённой прошивке (T1552.001, Credentials In Files). Default-аккаунты (T1078.001, Default Accounts) попадаются в firmware с пугающей регулярностью.
• Persistence - модификация системной прошивки (T1542.001, System Firmware) или прошивки отдельных компонентов (T1542.002, Component Firmware) для закрепления.

Типичная последовательность: вскрытие корпуса → визуальный осмотр → поиск отладочных интерфейсов → подключение к UART → получение shell или лога загрузки → SPI flash дамп прошивки → анализ образа → поиск уязвимостей. При необходимости - JTAG для отладки или обхода Secure Boot. Каждый интерфейс решает свою задачу, и выбор зависит от цели.

Требования к окружению: оборудование и софт​

Перед тем как вскрывать корпус, стоит собрать минимальный набор. Без него - только зря поцарапаете пластик.

Оборудование:

Компонент	Примеры	Ориентировочная цена
USB-to-TTL адаптер	CP2102, FT232RL, CH340	150–400 руб
SPI/JTAG программатор	Bus Pirate, CH341A, Tigard, FT2232H-based	500–3000 руб
SOIC8 test clip	Pomona 5250 или совместимые	300–1500 руб
Логический анализатор	Saleae Logic clone (24 МГц)	500–1500 руб
Мультиметр	Любой с режимом continuity	от 500 руб
Dupont-проводки	M-F, F-F	100 руб

Софт (Linux - Kali, Ubuntu, Debian):

• [URL='https://www.flashrom.org/']flashrom[/URL] - чтение/запись SPI flash (активный open-source проект, регулярные релизы)
• [URL='https://github.com/ReFirmLabs/binwalk']binwalk[/URL] - анализ и распаковка образов прошивок
• minicom или screen - терминал для UART
• [URL='https://openocd.org/']OpenOCD[/URL] - работа с JTAG/SWD
• PulseView (sigrok) - декодирование логических сигналов
• Ghidra или radare2 - реверс-инжиниринг бинарей

Минимальные системные требования: 4 ГБ RAM для базовой работы с flashrom и binwalk, 8+ ГБ если планируется реверс крупных образов в Ghidra. Процессор непринципиален - утилиты работают на любом x86_64.

Визуальный осмотр платы: recon на физическом уровне​

Физический пентест оборудования начинается с визуального осмотра PCB. По данным VoidStarSec, первое, что стоит сделать с любым embedded-устройством, - «visual teardown», во время которого идентифицируются все компоненты и потенциальные attack-поверхности.

Что искать:

Микросхемы памяти. SPI flash - обычно 8-выводные SOIC8 или WSON8 корпуса. Маркировки Winbond (W25Qxx), Macronix (MX25Lxx), GigaDevice (GD25Qxx) - верный признак flash-памяти с прошивкой. Datasheet по маркировке даст распиновку и список поддерживаемых команд.

Тестовые площадки и разъёмы. Ряды из 3–4 падов (GND, VCC, TX, RX) или неосаженные штыревые колодки - с высокой вероятностью UART. Если шелкография содержит надписи Tx, Rx, GND - вам повезло, как в случае с анализом VoidStarSec, где контактные площадки были подписаны прямо на плате. На production-версиях маркировку часто убирают - искать приходится мультиметром.

Следы удалённых компонентов. Пустые площадки с маркировкой R24, R47 - следы снятых pull-up резисторов отладочных портов. Как описывает wrongbaud при анализе роутера, «часто при осмотре serial-портов или JTAG-разъёмов видны следы резисторов, удалённых перед production». Пропаять на место резистор 0 Ом или 10 кОм и проверить - может оживить интерфейс. На практике это срабатывает чаще, чем хотелось бы вендорам.

Основной процессор. Маркировка SoC определяет архитектуру (ARM, MIPS, x86) и набор инструментов для дальнейшего реверса. Part number + datasheet = отладочные интерфейсы, распиновка, схема загрузки.

UART-интерфейс для пентеста: от тестовых падов до root shell​

UART (Universal Asynchronous Receiver Transmitter) - первый интерфейс, который стоит проверять на любом embedded-устройстве. Прост, не требует дорогого оборудования и часто даёт мгновенный результат: от отладочного лога до полноценного root shell.

Поиск и идентификация UART на плате​

UART работает асинхронно - без тактового сигнала. Линия TX в состоянии покоя удерживается на уровне логической единицы (обычно 3.3В). Это ключевой признак при прозвонке мультиметром.

Алгоритм поиска:

1. Найти кандидатов - группы из 3–4 контактных площадок, расположенных рядом.
2. Измерить напряжение каждого пина относительно GND при включённом устройстве.
3. Пин с устойчивым 3.3В (или 1.8В / 5В - зависит от логического уровня) - кандидат на TX.
4. При выключении устройства проверить скорость падения напряжения: медленное снижение (несколько секунд) - VCC (из-за конденсаторов на шине питания), быстрое падение - GPIO-линия (TX или RX). Этот приём описан wrongbaud при анализе отладочного порта роутера, и он реально экономит время.
5. Пин с 0В, не подключённый к GND (проверяется прозвонкой) - RX.

Если TX найден, но трафика нет - стоит подтянуть линию через 10 кОм к VCC. В исследовании VoidStarSec описан случай, где линия TX висела в LOW из-за отсутствия pull-up. После подтяжки к 3.3В на осциллографе появился трафик: KEY_B Down. KEY_B Dn->Up. - отладочный вывод.

Подключение и определение baud rate​

Подключение - TX устройства к RX адаптера, RX устройства к TX адаптера, GND к GND. Если устройство работает на 1.8В логике, а адаптер на 3.3В - нужен level shifter, иначе можно сжечь порт. Не спрашивайте, откуда я знаю.

Baud rate определяется по ширине минимального импульса на осциллографе или логическом анализаторе. Стандартные значения: 9600, 19200, 38400, 57600, 115200. В подавляющем большинстве IoT-устройств - 115200. Подключение через minicom -D /dev/ttyUSB0 -b 115200 или screen /dev/ttyUSB0 115200.

Что даёт UART при аппаратном пентесте:

• Лог загрузки U-Boot/Linux с версиями ядра, адресами загрузки, параметрами конфигурации
• Root shell без пароля - встречается чаще, чем хотелось бы
• Интерактивную консоль bootloader (U-Boot CLI), позволяющую модифицировать параметры загрузки, читать и записывать произвольную память
• Отладочный вывод с plaintext-паролями и токенами

Если в терминале мусор - первым делом проверяйте baud rate, потом уровень логики, потом правильность подключения TX/RX (поменяйте местами). В 80% случаев проблема в одном из этих трёх.

SPI flash: полный дамп прошивки устройства​

SPI (Serial Peripheral Interface) - синхронный протокол, по которому процессор общается с flash-памятью. SPI flash дамп даёт полный образ прошивки: загрузчик, ядро ОС, файловую систему, конфигурацию. По сути - всё содержимое устройства на блюдечке.

Подключение к SPI-чипу​

Стандартная распиновка 8-выводного SPI flash (SOIC8):

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

SOIC8 test clip - самый быстрый способ подключения. Зажим надевается на микросхему прямо на плате (in-circuit). Для WSON-корпусов (без выводов) придётся паять проводки к контактным площадкам или выпаивать чип.

Извлечение данных через flashrom​

flashrom - open-source утилита для чтения и записи SPI flash. Поддерживает сотни моделей чипов и множество программаторов.

# Raspberry Pi (spidev)
sudo flashrom -p linux_spi:dev=/dev/spidev0.0 -r firmware.bin

# CH341A программатор
sudo flashrom -p ch341a_spi -r firmware.bin

# FTDI-based (Tigard, Attify Badge)
sudo flashrom -p ft2232_spi:type=232H -c "MX25L12835F/MX25L12845E/MX25L12865E" -r firmware.bin

Параметр -c явно указывает модель чипа - полезно, когда auto-detect не справляется. Список поддерживаемых чипов доступен на сайте flashrom.

Bus contention и способы обхода​

Если flashrom выдаёт No EEPROM/flash device found - скорее всего дело в bus contention. При in-circuit чтении VCC идёт не только на flash, но и на процессор. Процессор стартует и начинает обращаться к памяти одновременно с программатором - два master на одной шине. SPI такого не прощает.

Как описывает VoidStarSec при работе с SPI flash электрической зубной щётки: «если VCC-пин flash подключён к CPU, мы непреднамеренно запитываем процессор, вызывая bus contention - SPI-протокол не поддерживает двух master-устройств на одной шине одновременно».

Решения по возрастанию сложности:

1. Удержание процессора в reset. Найти пин RESET на SoC, подать LOW во время чтения. Чистый способ - процессор не стартует, flash свободна.
2. Выпаивание чипа. Hot air, ~350°C. Полностью снимает проблему contention. Минусы - нужно запаять обратно, и если есть anti-tamper, можно кирпичнуть устройство.
3. Пассивный перехват через логический анализатор. Подключить PulseView к SPI-линиям и записать трафик при загрузке. SPI-декодер восстановит данные. Минус: если процессор читает не весь flash при загрузке - образ неполный. Записать модифицированную прошивку этим способом нельзя.

В анализе роутера wrongbaud столкнулся с аналогичной проблемой: Bus Pirate не мог достаточно просадить линию Chip Select при in-circuit чтении Winbond W25Q16. После нескольких попыток с pull-down резисторами - выпаял чип hot air и снял дамп уже off-circuit. Иногда паяльник - самый надёжный дебаггер.

JTAG-отладка: полный контроль над процессором​

JTAG - интерфейс, изначально созданный для тестирования PCB, но ставший стандартом отладки embedded-процессоров. Для аппаратного пентеста JTAG-отладка даёт максимальный уровень доступа: чтение/запись памяти, остановка процессора, пошаговое выполнение, обход Secure Boot. Если UART - это подглядывание в замочную скважину, то JTAG - ключи от всех дверей.

Поиск JTAG-интерфейса на плате​

Стандартный JTAG использует 4 линии: TDI, TDO, TMS, TCK (плюс опциональный TRST). На production-платах они редко подписаны. Методы идентификации:

• Datasheet процессора - если маркировка SoC читается, в документации указаны пины JTAG. Самый надёжный путь.
• JTAGulator - аппаратный инструмент для автоматического перебора комбинаций пинов и определения JTAG-цепочки по IDCODE. Брутфорсит все возможные комбинации - долго, но работает.
• SEC Xtractor - по данным SEC Consult, их инструмент интегрирует JTAG brute-forcing и UART-сканирование, поддерживает напряжения от 1.8 до 5.5В.

JTAG vs SWD: когда что использовать​

SWD (Serial Wire Debug) - альтернативный отладочный интерфейс для ARM Cortex.

Критерий	JTAG	SWD
Линии	4–5 (TDI, TDO, TMS, TCK, TRST)	2 (SWDIO, SWCLK)
Архитектуры	ARM, MIPS, x86, RISC-V	Только ARM Cortex
Daisy-chain	Да	Нет
Поиск на плате	Сложнее (больше линий)	Проще (2 линии)

Если устройство на ARM Cortex - проверяйте SWD первым: меньше линий, проще найти. MIPS (многие роутеры на чипах QCA/Atheros/MediaTek) - только JTAG. Оба протокола поддерживает OpenOCD с адаптерами J-Link, ST-Link или FTDI-based.

Через JTAG/SWD + OpenOCD можно: читать flash процессора напрямую, минуя внешний SPI; дампить RAM в произвольный момент; обходить Secure Boot, если JTAG не fused; записывать модифицированную прошивку.

Анализ прошивки: реверс-инжиниринг извлечённого образа​

После получения дампа - через SPI, UART (XMODEM) или JTAG - начинается самое интересное. Первый шаг - определение структуры через binwalk:

$ binwalk firmware.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
0             0x0             U-Boot boot loader
262144        0x40000         U-Boot boot loader (copy)
524288        0x80000         uImage header, Linux kernel
2097152       0x200000        Squashfs filesystem, little endian

Типичная картина для embedded Linux: два образа U-Boot (основной и резервный), ядро и SquashFS - именно такую структуру описывает wrongbaud при анализе роутера. Извлечение файловой системы: binwalk -e firmware.bin, затем cd _firmware.bin.extracted/squashfs-root/.

Что искать в распакованном образе:

• /etc/shadow, /etc/passwd - хеши или plaintext пароли
• Конфигурации в /etc/config/ - пароли Wi-Fi, API-ключи, SNMP community strings
• Скрипты в /usr/bin/, /usr/sbin/ - захардкоженные credentials, отладочные backdoor-аккаунты
• SSL-сертификаты и приватные ключи в /etc/ssl/
• Бинари веб-интерфейса - для реверса в Ghidra на предмет command injection, переполнения буфера

Default credentials (T1078.001, Default Accounts) и захардкоженные пароли в файлах (T1552.001, Credentials In Files) - самые частые находки. Даже когда веб-интерфейс требует смену пароля при первом входе, в firmware часто остаются сервисные аккаунты для отладки. Их забывают убрать - или намеренно оставляют «на всякий случай».

Когда какой интерфейс выбирать​

Задача	UART	SPI	JTAG/SWD
Быстрый recon	Да - первый шаг	Нет	Нет
Получение shell	Да (если есть консоль)	Нет	Да (через GDB stub)
Полный дамп прошивки	Частично	Да - основной метод	Да (медленнее)
Отладка в реальном времени	Нет	Нет	Да - единственный вариант
Запись модифицированной FW	Нет	Да	Да
Обход Secure Boot	Нет	Нет	Да (если не fused)
Стоимость оборудования	Минимальная	Средняя	Максимальная
Время на настройку	5–15 мин	15–30 мин	30–60 мин

Практическое правило: начинайте с UART (дёшево, быстро, часто даёт результат), переходите к SPI (полный дамп прошивки), используйте JTAG когда нужна real-time отладка или обход защитных механизмов.

Ограничения: где аппаратный пентест не сработает​

Аппаратный пентест - не серебряная пуля. Конкретные ситуации, когда описанные техники не дадут результата:

Fused JTAG. Production-устройства нередко отключают JTAG на уровне OTP fuses в процессоре. После прожига интерфейс физически неработоспособен. Проверить - только попыткой подключения: если IDCODE не отвечает и daisy-chain не определяется, скорее всего fused. Тут без вариантов.

Зашифрованная прошивка. Если образ в SPI зашифрован (AES с ключом в OTP-области процессора), дамп бесполезен без ключа. binwalk покажет entropy ~8.0 по всему образу - признак шифрования или сжатия. Для отличия - искать magic bytes известных алгоритмов (gzip, LZMA, LZ4).

Secure Boot с цепочкой доверия. Даже если прошивка извлечена и модифицирована, Secure Boot не даст загрузить изменённый образ без валидной цифровой подписи. Обход возможен через незакрытый JTAG - остановка процессора до этапа верификации подписи. Но если JTAG fused - замкнутый круг.

Чипы без поддержки в flashrom. Как описывает Nozomi Networks на примере камеры Verkada D40 с чипом HeYangTek HYF2GQ4UAACAE - если чип отсутствует в базе flashrom и datasheet недоступен, стандартный инструментарий бесполезен. Исследователям пришлось использовать специализированный программатор BeeProg2C с WSON-адаптером.

BGA-корпуса без тестовых точек. Если flash-память в BGA и впаяна под процессор без выведенных тестовых площадок - физический доступ к SPI-линиям крайне затруднён. Нужно либо перехватывать сигналы на уровне PCB-трасс (микроскоп + паяльная станция), либо искать альтернативные каналы - UART, сетевое обновление.

Половина production-устройств выходит с открытыми UART и незащищённым SPI. Это говорит не о технической сложности защиты, а о приоритетах вендоров. Закрыть JTAG через fuse, убрать отладочные аккаунты, зашифровать образ - каждая мера стоит минимальных усилий. Но time to market побеждает, и embedded security воспринимается как экзотика.

На каждом третьем аудите IoT-оборудования первая критическая находка - не XSS в веб-панели и не слабый TLS, а UART-консоль с root-доступом, которую никто не пытался отключить. Вендоры заявляют Secure Boot в маркетинговых материалах - на деле fuse не прожжены, JTAG открыт, а в /etc/shadow сидит root:: с пустым хешем.

Аппаратный пентест не требует zero-day эксплойтов или месяцев реверса. Мультиметр, SOIC8-клипса и понимание трёх базовых протоколов. Пока вендоры не начнут относиться к отладочным интерфейсам как к полноценной attack surface наравне с сетевыми портами, паяльник останется одним из самых эффективных инструментов initial access. Попробуйте вскрыть ближайший роутер из тестовой среды и найти UART - спорим, он там есть.