文章总结： 本文分析ANJIAPTZ摄像头CVE-2026-31077漏洞，从UART硬件调试接口提取固件，绕过U-Boot环境CRC校验获取rootshell，静态分析发现apollo和noodles两个未认证后门，可未授权执行命令及绕过RTSP鉴权。建议将此类设备隔离VLAN、关闭异常端口、审计固件供应链，并监控异常XML命令特征。
综合评分： 85
文章分类： 漏洞分析,IoT安全,渗透测试,固件安全,应急响应
从 UART 焊到未认证后门：ANJIA PTZ 摄像头（CVE-2026-31077）
黑卷
黑卷
赛博安全攻防日记
2026年9月28日 11:16
上海
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
从 UART 焊到未认证后门：ANJIA PTZ 摄像头（CVE-2026-31077）
凌晨一点半，家庭监控告警显示有设备在扫网——源 IP 却指向隔离 VLAN 里的廉价云台摄像头。Zachary Mitev（innerfirez）据此拆解了 ANJIA AJ-L73PA1250 PTZ：UART → SPI 抽固件 → 绕过 U-Boot 环境 CRC → root shell，再静态挖出 apollo / noodles 上的未认证后门，最终拿到 CVE-2026-31077。下文按防御视角摘关键路径与发现，完整 PoC / 脚本细节以原作者公开材料为准。
告警从哪来：隔离网里的廉价 PTZ
这类摄像头常见于咖啡馆、店招、外墙挂装，标配「人形侦测」一类卖点。真正的成本，往往写在固件和云通道里。
摄像头外观与标签
先扫端口：Telnet + 非常规 RTSP
nmap 可见 Telnet(23)、RTSP 8554（不是常见的 554）、以及 ONVIF 相关端口。直接对 Telnet / RTSP 撞库未果，于是转向硬件。
23/tcp telnet
843/tcp unknown
1300/tcp （后续确认属 noodles）
6688/tcp ONVIF 一类
8554/tcp rtsp
8699/tcp / 16668/tcp
拆机找 UART：板边三针 3.3V
撕开外壳后，PCB 边缘有三根可疑测点，电压约 3.3V——典型调试串口。
主板边缘 UART 焊盘与接线
串口日志：有 U-Boot，也有口令墙
picocom、112500 baud。启动日志可见 U-Boot 2010.06-dirty、64 MiB DRAM、Linux 4.9.129、富瀚 FH8852V210、型号 AJ-L73PA1250、固件 v220901.1359。进系统后要账密；按 E 可停自动启动，但 U-Boot 本身仍要口令，常用字典打不开。
抽 Flash：改环境名 + 重算 CRC，而不是硬爆破
Flash 为 MX25L6433F，CH341A + flashrom 整片备份，再 binwalk 解开。
sudo flashrom -p ch341a_spi -c "MX25L6406E/MX25L6408E" -r backup.bin
环境区里有 ubootpwd（SHA-256），shadow 也有哈希——词表 / mask 均未破。
作者换思路：在十六进制编辑器里把变量名 ubootpwd 改成无效名（如 ubooOpwd）再刷回。U-Boot 报 bad CRC, using default environment——说明环境块带 CRC32，改字节后必须按芯片布局重算校验，修改后的环境才会被接受。这是硬件逆向里很常见的「破门不靠猜口令」路径：破坏校验语义 → 理解校验 → 合法写入。
进 U-Boot 后，可在 bootargs 上挂 rdinit=/bin/sh 拿到早期 root shell，再手动挂载 userdata（jffs2）。为便于后续静态分析与配置导出，作者在受控实验环境整理了 Telnet 可达的调试会话（细节见作者公开笔记）。
运行态：apollo + noodles 撑起「全家桶」端口
有 shell 后看进程与监听：
-
apollo：RTSP / ONVIF / 云逻辑主进程
-
noodles：本机控制通道（后文重点）
-
另有
dev_ctrl、inetd、telnetd等 -
监听大致包括 6688、8554、23、8699/16668，以及 843 / 1300（noodles）
-
在线时可见到外连 TCP（示例：
34.40.41.193:25515）
对防守方而言：一台「只该出流」的摄像头若常年开着 Telnet、非常规 RTSP 端口和神秘 1300，就该进资产基线与漏洞扫描清单。
静态分析：两条未认证后门
重点二进制是 apollo（云 + 流媒体）和 noodles（本机服务）。结论很硬：两者都藏有后门——一条动 RTSP 鉴权，一条可未认证以 root 执行命令。
关键痕迹（摘要）：
- apollo 内硬编码 RTSP 相关串（含
admin/ 固定口令形态的 URI 片段） - 默认配置打开 Telnet、RTSP、ONVIF，Web UI 关闭；端口 RTSP 8554、ONVIF 6688
- 配网 AP 前缀
Care-AP，默认钥一类字符串出现在配置语境中 - apollo 经 UPX 壳，解开后字符串与反编译才可读
IDA 侧可见：若存在 /home/dis_onvif_auth，RTSP 鉴权初始化会被跳过——这是后续「局域网一键失守」的关键开关文件。
与 /home/dis_onvif_auth 相关的 RTSP 鉴权旁路路径（示意）
noodles（静态 ARM ELF）在 TCP 1300 起未认证服务，解析类 XML 指令：SYSTEM / SYSTEMEX 可跑 shell；另有升级、文件传输、烧 MAC/SN、读写 env、拉 ELF 执行等路径；843 上还有宽松的 Flash policy；组播口也会响应。全程无认证、无来源过滤，且以 root 跑——对局域网攻击面评估，这几乎是「送分题」。
启动链、配置库与云侧轮廓
- 启动大致：
app_init.sh→start.sh→abin/apollo；ipc.db/systemcfg.db存身份与运行配置，app.cfg打开云 / RTSP / ONVIF / telnet - 硬件画像：富瀚 FH8852V2X0，Wi-Fi RTL8188FU / SSV6155P，固件
v220901.1359 - 云配置指向
svr.smartcloudcon.com一类域名，链路对端含上述 Google Cloud 段 IP；配套 App 生态为 CareCamPro / smartcloudcon 分析与广告接口
MITM 观察：摄像头本身很少走「干净」的 HTTP/HTTPS；更多是自定义 TCP 控制层，以及明文 UDP 做 NAT/P2P 引导（报文里可能带公网 IP/端口）。App 侧则有持久 UID/token、设备 DID、日志与广告/套餐接口——隐私与供应链评估时值得单独记账。
结论：CVE-2026-31077 与防守建议
作者联系厂商未果；App 方称摄像头厂家只是「借用」CareCamPro。约五个月后 MITRE 分配 CVE-2026-31077。
局域网可达时，未认证 noodles + RTSP 鉴权开关文件 + Telnet/shadow 可写，构成完整失守链；设备上还可读出明文 Wi-Fi STA 凭证——即便只拿到底层局域网访问，也可能外溢到家庭/门店无线。原页演示视频此处略过，上文静态图已覆盖主叙事。
给防守与采购的可执行建议（摘要）：
-
别把廉价云台当可信节点
：默认划隔离 VLAN，禁止其主动扫网、限制出站。
-
基线端口
：额外关注 1300 / 843 / 8554 / Telnet；能关尽关，关不掉就当已知风险挂账。
-
固件与供应链
：同类 Fullhan IPC SDK /「Care-*」配网指纹出现时，优先做二进制与配置审计。
-
检测思路
：局域网内对 1300 的异常 XML/命令特征、突然出现的
/home/dis_onvif_auth、Telnet 空口令登录，均可做狩猎信号。 -
披露
：对外复现请走合法授权与 CVE/厂商渠道；本文只做防御向技术记录。
免责声明：
本人所有文章均为技术分享，均用于防御为目的的记录，请勿用于其他用途，否则后果自负。
更多 IoT / 车联网 / 机器人 / AI 安全资料在星球里，扫码进「车联网攻防日记」。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：赛博安全攻防日记 黑卷
黑卷《从 UART 焊到未认证后门：ANJIA PTZ 摄像头（CVE-2026-31077）》