从裸露 PCB 到 root：通过 UART 硬件破解 ZyXEL P-870HN

两张无标签路由器板的手机照片 → 串口控制台 → 认证绕过 → root shell —— 在我自己的硬件上复现这条真实存在、至今未修补的攻击链 CVE-2025-0890（隐藏的 supervisor 账户）+ CVE-2024-40891（CLI 命令注入）。

作者：damik0 · 2026-08-13 · 硬件破解实战记录

  📷 PCB 照片 ─▶ 🔬 芯片侦察 ─▶ 🏷️  型号识别 ─▶ 📍 找到 UART (J2)
       └─▶ 🔌 串口控制台 ─▶ 🚪 隐藏账户 ─▶ ⛓️  突破 CLI
              └─▶ 🐚 root shell ─▶ 🔓 转储并破解所有凭据

TL;DR

我桌上放着一块来历不明的路由器主板。没有外壳，没有标签，完全不知道是什么。仅凭两张照片，我从零开始：逐一读取 PCB 上每颗芯片，锁定具体机型，找到串口（UART）排针并接上，通过一个出厂后门账户进入系统，从被锁定的厂商菜单中逃逸到 root Linux shell，最后把设备上所有密码都导了出来——不到一秒即全部破解。

这些漏洞都不是我发现的。它们是 ZyXEL 已公开记录、且厂商表示不会修复的问题。这个仓库要讲的是方法本身——端到端的完整过程，以及每一步背后的推理。

先说清楚：这是我自己的硬件

• 目标是一块我本人拥有的路由器主板。
• 入口是 PCB 上的物理串口——没有远程攻击，不涉及第三方网络，也没有任何暴露到互联网的东西。
• 整个过程它都放在我的工作台上，处于物理隔离（air-gapped）状态。
• 目标是端到端地跑完整个硬件破解流程，并将其记录下来，确保可复现。

我在研究什么

我通过丝印板号 45-402-000022 和条形码确定了设备型号，并与 TechInfoDepot、OpenWrt 的硬件列表以及 FCC ID I88P870HN51B 做了交叉比对：

为什么板号是解锁一切的钥匙： 这类 ODM 网关都是参考设计。一旦丝印部件号与某个有文档记录的板子匹配，你就继承了别人的功课——确切的闪存芯片、UART 的位置和引脚定义、默认账户。识别型号不是走形式；正是这一步把盲目探测变成了定点攻击。

破解过程

第 0 步 —— 把照片从手机里弄出来

先做个小工具提升体验：我随手写了个极简局域网照片上传器（仅用 Python 标准库，零依赖），这样我可以用手机拍摄主板，照片直接落到电脑上。一次顺利的破解，一半靠的就是消除这类摩擦。

第 1 步 —— 识读主板

我对着高清照片逐颗识别芯片。在读取丝印之前，封装类型就已经透露了端倪：中间的 BGA 是主控，TSOP-48 几乎一定是并行闪存，带同轴线尾巴的小金属罐是射频模块。SoC 藏在一块射频屏蔽罩下面（用于 EMI 屏蔽并兼作散热片），于是我撬开屏蔽罩读取下面的丝印——Broadcom BCM6368。

主板标注图：(1) BCM6368 SoC，(2) DDR2 内存，(3) BCM43222 WiFi，(4) DSL 线路变压器，(5) 以太网网络变压器，(6) 板载 USB 排针，(7)(8) 主板丝印，(9) J2 控制台排针，(10) 未焊接的 JTAG 焊盘。

第 2 步 —— 确认具体型号

丝印 45-402-000022 与有文档记录的板子完全吻合，而且每一颗芯片——SoC、闪存、WiFi、64 MB 内存——都与 -53b 版本逐一对应。此时我不仅知道它是什么，还知道了它的 UART 在哪里、用哪个账户能进去。

第 3 步 —— 寻找 UART

SoC 旁边有一个已焊接的 6 针直角排针，丝印为 J2，带有一个三角标识指向第 1 脚。与 OpenWrt 该型号的页面比对确认：

115200 8N1，3.3V TTL。

当没有 wiki 告诉你引脚定义时，如何找到 UART —— 这部分说明这不仅仅是照着菜谱做：

• GND —— 在主板断电状态下，与地平面/屏蔽罩之间导通（蜂鸣）。
• VCC —— 上电后稳定在约 3.3 V 的电源轨。
• TX —— 空闲时为高电平，约 3.3 V（UART 的 mark 状态）；设备开机并开始输出日志的瞬间，会明显拉低/跳动。这个跳动就是控制台在说话。
• RX —— 通常比较安静：悬空或被弱上拉/下拉，启动时没有活动。

如果你不知道波特率呢？115200 是 Broadcom CFE 的默认值，但在完全盲猜的情况下，你可以扫一遍常见速率（9600 → 115200），直到乱码变成可读的 ASCII；或者用示波器测量最窄的位周期，然后计算 1 / t。

第 4 步 —— 拿到控制台

我接了一个 USB-TTL 转接板（HW-597，PL2303），跳线帽设在 3.3V。这一点很关键：BCM6368 的 UART 是 3.3 V TTL，不是 RS-232（±12 V）——把真正的串口或 5 V 转接板接上去会烧掉引脚。先接地，然后 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 诊断命令，而该命令把用户输入不做任何过滤地直接拼接进 shell 字符串。于是我喂给它一个 shell 元字符：

> ping 127.0.0.1; sh

……然后掉进了一个 root BusyBox shell（#）。

为什么一个分号就够了： CLI 处理程序等价于执行 system("ping " + userinput)。; 结束了 ping 命令并启动第二条命令——sh——它继承了控制台的 stdin/stdout，于是你就得到了一个交互式 shell。该账户本身就是 uid 0；CLI 是挡在我和真正 shell 之间的唯一障碍，而未经过滤的输入直接拆掉了这堵墙。在隐藏账户之上再叠加一个已认证的 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 把它看作一段平坦的地址范围（在 MIPS KSEG1 中大约位于 0xB8000000），并作为一个单独的 MTD 分区暴露出来。这对转储来说是个好消息：NOR 读回的数据是干净的，没有 NAND 上那些 spare/OOB 字节和 ECC 的麻烦。/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 照片 → 识别 SoC → 找到 UART (J2) → 串口控制台
   → 隐藏账户 (F-1) → 锁定 CLI → 命令注入 (F-2)
   → root shell → 转储并破解所有凭据 (F-3)

“兄弟，这 0-day 真酷”——不，重点恰恰在此

这些都不是我发现的。这是通过物理访问对公开的、且当前仍然相关的漏洞进行的复现：

• CVE-2025-0890 —— 旧款 ZyXEL DSL CPE 上的弱/隐藏凭据，明确包含 supervisor:zyad1234。→ F-1
• CVE-2024-40891 —— 已认证的 CLI 命令注入，命令未经检查便传给 shell；与 CVE-2025-0890 串联利用。→ F-2
• 更早的 ZyXEL ping 注入系列：CVE-2015-6018、CVE-2017-6884。→ F-2

这些漏洞影响的是 ZyXEL 已表态不会修复的停产（EOL）设备，而且已被发现在真实环境中遭到利用——这正是动手去理解其机制的意义所在。这里的价值不在于新漏洞，而在于从芯片到 shell 的完整工作流，既已实践，又已记录。

真正该怎么修复

• 干掉硬编码账户。 每台设备使用唯一凭据，并在首次启动时强制修改。
• 对所有诊断输入进行过滤——采用字符白名单，绝不把用户输入拼接到 shell 中（使用带参数向量的 execve，而不是 system()）。
• 将密码存储迁移到 /etc/shadow，使用现代哈希算法（bcrypt / SHA-512-crypt），而不是 DES。
• 对于厂商不会修补的 EOL 硬件：换掉它。

未竟之事

• 转储固件：通过路由器自身的 WiFi + nc 从 mtd0（/dev/mtdblock0，5,197,824 字节）导出，然后用 binwalk 解包（预期包含 CFE 头 + LZMA 压缩的内核 + SquashFS rootfs + nvram）。完整方法见 evidence/dump-methods.md。
• 挖掘 nvram/config 中的 ISP 机密信息（PPPoE、WiFi PSK、TR-069 ACS URL、VoIP）。

我用到的装备

照片 PCB 分析（ImageMagick）、一块万用表、3.3 V 的 USB-TTL PL2303（HW-597） 转接板、用来连接串口控制台的 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 MB 内存版本）
• 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 — 通过 UART 获取 root shell
• Secure Ideas — 在 PCB 上寻找 UART 引脚定义
• SparkFun — CP2102 USB 转串口连接指南

工具

• John the Ripper · binwalk

最后再说一次，留作记录

这一切都发生在我自己的硬件上，处于物理隔离状态，不涉及任何第三方系统。这些漏洞均有公开记录，并已在上面列出出处。我为之署名的是端到端的硬件破解方法及其执行过程——而不是这些缺陷的发现。