От голой печатной платы до root: аппаратный взлом ZyXEL P-870HN через UART

Две фотографии немаркированной платы роутера с телефона → последовательная консоль → обход аутентификации → root-оболочка — воспроизведение реальной, до сих пор не пропатченной цепочки CVE-2025-0890 (скрытая учётная запись supervisor) + CVE-2024-40891 (инъекция команд в CLI) на оборудовании, которым я владею.

автор damik0 · 2026-08-13 · руководство по аппаратному взлому

  📷 PCB photos ─▶ 🔬 chip recon ─▶ 🏷️  model ID ─▶ 📍 find UART (J2)
       └─▶ 🔌 serial console ─▶ 🚪 hidden account ─▶ ⛓️  break out of CLI
              └─▶ 🐚 root shell ─▶ 🔓 dump + crack every credential

TL;DR

На моём столе валялась какая-то плата роутера. Без корпуса, без маркировки, и без понятия, что это. Не имея ничего, кроме двух её фотографий, я считал все чипы с PCB, точно определил модель, нашёл последовательный (UART) разъём, подключился к нему, вошёл через заводскую учётную запись-бэкдор, выбрался из запертого вендорского меню в root-оболочку Linux и вытащил с устройства все пароли — взломаны менее чем за секунду.

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

Сначала главное: это моё собственное оборудование

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

Над чем я ковырялся

Я определил ID по номеру платы на шелкографии 45-402-000022 и штрихкоду, сверившись с TechInfoDepot, таблицей оборудования OpenWrt и FCC ID I88P870HN51B:

Почему номер платы — это ключ, открывающий всё: такие ODM-шлюзы — это референсные разработки. Как только номер детали на шелкографии совпадает с документированной платой, вы получаете в наследство чужую домашнюю работу — точный чип флеш-памяти, расположение и распиновку UART, учётные записи по умолчанию. Идентификация — не формальность; это то, что превращает слепое зондирование в целевую атаку.

Как всё происходило

Шаг 0 — выгрузка фотографий с телефона

Сначала небольшой шаг для удобства: я набросал крошечный загрузчик фотографий по LAN (только стандартная библиотека Python, ноль зависимостей), чтобы можно было снимать плату на телефон, а снимки сразу попадали на мой компьютер. Половина успешной сессии — это устранение вот таких трений.

Шаг 1 — чтение платы

Я прошёлся по чипам на фотографиях высокого разрешения. Типы корпусов рассказывают историю ещё до того, как вы прочитаете маркировку: BGA в центре — это мозг, TSOP-48 — почти всегда параллельная флеш-память, маленькая банка с коаксиальным хвостиком — радиомодуль. SoC прятался под RF-экраном (он там для ЭМС и в качестве теплораспределителя), поэтому я снял крышку, чтобы прочитать маркировку под ней — Broadcom BCM6368.

Плата с картой: (1) SoC BCM6368, (2) DDR2 RAM, (3) WiFi BCM43222, (4) линейный трансформатор DSL, (5) магнетики Ethernet, (6) внутренние USB-разъёмы, (7)(8) маркировка платы, (9) консольный разъём J2, (10) незапаянная посадочная площадка JTAG.

Шаг 2 — даём устройству имя

Шелкография 45-402-000022 точно совпала с документированной платой, и каждый чип — SoC, флеш, WiFi, 64 МБ RAM — сошёлся один к одному с вариантом -53b. Теперь я не просто знал, что это; я знал, где находится её UART и какая учётная запись впустит меня внутрь.

Шаг 3 — охота за UART

Прямо рядом с SoC находился запаянный 6-контактный угловой разъём с шелкографией J2 и треугольником, отмечающим вывод 1. Подтверждено по странице OpenWrt для этой модели:

115200 8N1, 3.3V TTL.

Как найти UART, когда никакая вики не подсказывает распиновку — вот та часть, которая показывает, что это не просто следование рецепту:

• GND — проверка целостности (писк) на земляной полигон/экран при обесточенной плате.
• VCC — шина, которая держит стабильные ~3.3 В после подачи питания.
• TX — в покое находится в высоком уровне ~3.3 В (маркерное состояние UART) и заметно проседает/мерцает в момент, когда устройство загружается и начинает вываливать свой лог. Это мерцание — консоль говорит.
• RX — обычно тихий: в воздухе или слабо подтянут, активности при загрузке нет.

А если вы не знаете скорость? 115200 — значение по умолчанию для Broadcom CFE, но вслепую вы бы либо перебирали распространённые скорости (9600 → 115200), пока мусор не превратится в ASCII, либо измерили самый узкий битовый период на осциллографе и вычислили 1 / t.

Шаг 4 — получаем консоль

Я подключил USB-TTL переходник (HW-597, PL2303) с перемычкой на 3.3V. Это важно: UART у BCM6368 — это 3.3 В TTL, а не RS-232 (±12 В) — подключите настоящий последовательный порт или переходник на 5 В, и вы сожжёте вывод. Сначала земля, затем RX/TX крест-накрест, VCC оставлен в воздухе, чтобы ничто не запитывало плату в обратную сторону. Перед подачей питания я проверил GND и VCC мультиметром, затем:

screen /dev/ttyUSB0 115200

Подал питание, наблюдал, как CFE передаёт управление ядру, как поднимается BusyBox init, и оказался на приглашении login.

Шаг 5 — парадная дверь была нараспашку · CVE-2025-0890

Логин поддался скрытой заводской учётной записи, которую ZyXEL никогда не документирует для конечного пользователя:

user:     supervisor
pass:     zyad1234

Полные системные привилегии. Это ядро CVE-2025-0890.

Шаг 6 — побег из вендорской клетки · CVE-2024-40891

Этот логин забросил меня в закрытый вендорский CLI (consoled, приглашение >): никакого sh, ни одного обычного Linux-инструмента — тюрьма, обёрнутая вокруг реальной системы. Но в нём был доступен диагностический ping, и эта команда подставляла свой аргумент прямо в строку оболочки без какой-либо санитизации. Поэтому я скормил ей метасимвол оболочки:

> ping 127.0.0.1; sh

…и оказался в root-оболочке BusyBox (#).

Почему одной точки с запятой достаточно: обработчик CLI делает эквивалент system("ping " + userinput). Символ ; закрывает команду ping и запускает вторую — sh — которая наследует stdin/stdout консоли, так что вы получаете интерактивную оболочку. Учётная запись уже была uid 0; CLI был единственным, что стояло между мной и настоящей оболочкой, и несанитизированный ввод разрушил эту стену. Связывание аутентифицированной CLI-инъекции со скрытой учётной записью — это ровно тот паттерн, который отслеживается как CVE-2024-40891.

Шаг 7 — забираем добычу

Имея root, я посмотрел на систему и флеш:

# cat /proc/version
Linux version 2.6.30 ... (Buildroot 2010.02) #1 Mon Jun 11 2012

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 004f5000 004f5000 "Physically mapped flash"     # 5,197,824 bytes = the whole firmware

О чём говорит /proc/mtd: флеш — это параллельная NOR, отображаемая в память — CPU видит её как плоский диапазон адресов (примерно 0xB8000000 в MIPS KSEG1), представленный как единый MTD-раздел. Это отличные новости для дампа: NOR читается чисто, без запасных/OOB-байтов и странностей ECC, с которыми вы боретесь на NAND. /dev/mtdblock0 и есть образ прошивки.

Затем пароли. Никакого /etc/shadow нет — хэши лежат прямо в /etc/passwd с использованием древнего DES crypt:

supervisor:SuO7vycdWI/rU:0:0:Administrator:/:/bin/sh
support:xoKf506EVkGKw:1:0:Technical Support:/:/bin/sh
user:QWOftoXez8Goo:2:0:Normal User:/:/bin/sh
admin:OJGXQ9dWyb9m2:100:0:Administrator:/:/bin/sh

Я вытащил их и взломал офлайн с помощью John the Ripper (--format=descrypt). Все шесть пали меньше чем за секунду:

Почему они испаряются мгновенно: DES crypt(3) всегда использовал только первые 8 символов пароля и 12-битную соль, прогоняя 25 раундов DES. На современном CPU bitslice-взломщик DES пережевывает десятки миллионов кандидатов в секунду — так что тривиальные заводские пароли вроде admin или support даже не воспринимаются как работа. Эта схема устарела десятилетия назад; обнаружение её в поставляемой прошивке — вот настоящая находка.

Четыре заводские учётные записи с привилегиями уровня root, тривиальные пароли, одинаковые на каждом экземпляре этой модели.

Что на самом деле сломано

Вся цепочка одной строкой:

PCB photo → ID the SoC → find the UART (J2) → serial console
   → hidden account (F-1) → locked CLI → command injection (F-2)
   → root shell → dump + crack every credential (F-3)

«Крутой 0-day, бро» — нет, и в этом суть

Я ничего из этого не открывал. Это воспроизведение публичных и до сих пор актуальных уязвимостей при физическом доступе:

• CVE-2025-0890 — слабые/скрытые учётные данные, в явном виде включающие supervisor:zyad1234, на устаревшем DSL-оборудовании ZyXEL. → F-1
• CVE-2024-40891 — аутентифицированная инъекция команд в CLI, команды передаются в оболочку без проверки; эксплуатируется в связке с CVE-2025-0890. → F-2
• Более старая линия ZyXEL с инъекцией через ping: CVE-2015-6018, CVE-2017-6884. → F-2

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

Как это на самом деле исправить

• Устраните захардкоженные учётные записи. Уникальные учётные данные для каждого устройства, принудительная смена при первой загрузке.
• Санитизируйте каждый диагностический ввод — используйте разрешающий список символов, никогда не конкатенируйте пользовательский ввод в оболочку (используйте execve с вектором аргументов, а не system()).
• Перенесите хранение паролей в /etc/shadow с современным хэшем (bcrypt / SHA-512-crypt), а не DES.
• Для оборудования EOL, которое вендор не будет патчить: замените его.

Незавершённые дела

• Снимите дамп прошивки с mtd0 (/dev/mtdblock0, 5 197 824 байт) через собственный WiFi роутера + nc, затем распакуйте с помощью binwalk (ожидаются: заголовок CFE + сжатое LZMA ядро + SquashFS rootfs + nvram). Полный метод в evidence/dump-methods.md.
• Покопайтесь в nvram/config в поисках секретов провайдера (PPPoE, WiFi PSK, URL ACS для TR-069, VoIP).

Снаряжение, которое я использовал

Анализ PCB по фотографиям (ImageMagick), мультиметр, переходник USB-TTL PL2303 (HW-597) на 3.3 В, screen для последовательной консоли (115200 8N1) и John the Ripper (descrypt) для хэшей. Идентификация через OpenWrt, TechInfoDepot и базу данных FCC.

Источники и ссылки

Идентификация устройства

• TechInfoDepot — ZyXEL P-870HN-51b (номер платы 45-402-000022, флеш MX29LV640EBTI-70G)
• TechInfoDepot — ZyXEL P-870HN-53b (вариант с 64 МБ RAM)
• OpenWrt — ZyXEL P-870HN-5xb (страница устройства + распиновка последовательного порта)
• FCC ID I88P870HN51B

Уязвимости

• CVE-2025-0890 — скрытая учётная запись supervisor
• CVE-2024-40891 — аутентифицированная инъекция команд в CLI · контекст сообщения
• CVE-2015-6018 · CVE-2017-6884 — более ранняя инъекция команд ZyXEL через ping

Оборудование и методика

• Техническое описание Macronix MX29LV640E (PDF)
• OpenWrt — Справочник по последовательной консоли
• River Loop Security — Получение root-оболочки через UART
• Secure Ideas — Поиск распиновки UART на PCB
• SparkFun — Руководство по подключению CP2102 USB-to-serial

Инструменты

• John the Ripper · binwalk

Ещё раз, для протокола

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