2026 硬件攻击面实录：机器人、智能锁与心电贴

一台 2 万美元的人形机器人，90 磅重，能跑步能空翻，被一家公司当作"具身智能"的门面。2026 年，它被研究员 Olivier Laflamme 用 3 个月时间打到远程 root——工具是反编译的安卓 APP、几年前就被破解的固件加密、比人形机器人古老几十年的缓冲区溢出。没有零日市场，没有国家级攻击者，没有尖端技术。

这不是个例。同一个年份里，最日常的智能锁栽在写死的 AES 密钥上，最私密的医疗设备在无线电波里明文广播心电数据。四个案例，同一个病灶：APP 与硬件之间那条没人看守的信任链。

把镜头拉远看，这些案例共享一个反直觉的事实：没有一起攻击需要拆开设备。没有飞线，没有芯片开盖，没有侧信道采集。所有入口——APP、云端 API、蓝牙协议——都在设备外壳之外，都在厂商主动分发或暴露的界面里。硬件安全从业者花几十年建起来的"物理防护"体系，防的是上一个时代的攻击者。

这四个案例的选取也刻意覆盖了光谱的两端：宇树 G1 是"最贵的消费级机器人"，TTLock 是"最日常的出租屋门锁"，ECG 心电贴是"最私密的贴身医疗设备"，BLERP 则是"最底层的协议标准"。价格从 2 万美元到几十美元，攻击链从五步到一步，但失守的结构完全同构。这个同构性本身就是本文的核心论点：问题不在某个价位、某个品类、某家厂商，而在一条整个行业共用的、默认不设防的架构。

硬件安全的战场早就不在设备上了。攻击者不看你的设备拆解视频，他们看你的 APP——密钥在 APP 里、协议逻辑在 APP 里、云端校验依赖 APP 转发。设备本体的金属外壳，保护的只是一个早已被绕过的战场。如果你读过上一篇关于 ROS 2 与大模型时代的讨论，会发现宇树 G1 正是那个故事里的主角——这次我们从安全视角把它重新拆一遍。

为什么是 2026 年集中爆发？不是这一年攻击者突然变聪明，而是渗透率到了临界点：人形机器人开始进园区做导览，智能锁装进了出租屋，心电贴成了消费电子。设备基数越大，"APP 与硬件之间的信任链"这条默认没人看守的通道，就暴露在越多双眼睛下。Laflamme 们不需要等零日，他们只是第一批认真看了看这条通道的人。

主案例：宇树 G1 的五步攻击链

Laflamme 的两个 CVE（CVE-2026-76639 与 CVE-2026-76640）串成了一条从"物理接近"到"远程 root"再到"蠕虫传播"的完整链条。事实上这是两条独立的通路：CVE-2026-76640 走 BLE 与云端，CVE-2026-76639 走 AI 聊天服务，两条路都通向 root。先看主力通路（BLE 链）的全景，再逐个拆解"为什么这步能走通"。

图：五步攻击链全景。每个方框下面那行"本该"是关键——五道防线，每一道都存在，每一道都没启用。

第一步：APP 即地图。 研究入口不是拆机，是反编译安卓 APP。云端 API 的路径、BLE 特征值的 UUID、密钥分块重组的逻辑——全部写在 APP 的 Java 代码里。厂商把最敏感的协议逻辑分发到了每一个用户的手机上。对有 Android 逆向功底的人，这一步的门槛是一次 jadx 打开的等待时间。

这里值得展开一个行业惯性：厂商为什么把密钥逻辑放进 APP？因为产品要求"离线也能配网""断网也能开锁"，而端到端的密钥协商需要设备端有足够的算力与人机交互（屏幕、按键），低价 MCU 给不了。于是"让 APP 代替设备完成复杂逻辑"成了默认架构，安全边界就这样被体验需求一点点推到了手机上。理解这个惯性，你就理解了为什么这不是宇树一家的失误，而是整个行业的默认设置。

第二步：BLE 免配对写。 G1 的 BLE 服务无需配对即可写特征值，任何人靠近就能向机器人请求 RSA 加密的 key bootstrap blob。设备端没有任何"这个请求者是谁"的校验——无线电波范围内的所有人都是同等身份。注意这一步本身还没拿到任何明文秘密，拿到的只是一坨加密数据。真正的杀招在下一步。

第三步：云端成了解密预言机。 这是整条链最漂亮的一击。分块的密钥 blob 需要重组后发给云端 API /device/bindExtData，而云端不校验请求者是否拥有这台机器人。任何免费注册的账号，都能为任何一台 G1 拿到 AES-128 解密密钥。攻击者不需要攻破加密，只需要让云端替自己解密——厂商自己把"解密预言机"挂在了公网上。

第四步：配置脚本的回退路径。 拿到密钥后，向设备提交超长 WiFi 密码，触发配置脚本的一条错误处理路径，把机器人的网络指向攻击者热点。这一步之所以能走通，是因为密钥已经在手——设备的"信任"建立在已被拆穿的加密之上。从这里开始，攻击者不再需要物理接近：机器人自己走进了攻击者的网络。

"回退路径"这四个字值得每个固件开发者警惕。配置脚本的主流程大概率被测试过千百遍，但"输入超长密码导致脚本异常→进入错误处理分支"这种路径，往往只在开发的深夜里被写过一次、从来没被测过。它信任了前一步的输出，而前一步的信任根基（密钥保密性）已经被云端预言机拆掉——漏洞链的美丽与可怕都在于此：每一环单看都是"合理的设计假设"，串起来就是全线失守。

第五步：教科书式溢出。 G1 的 BLE 服务器实现存在 500 字节缓冲区无边界检查的问题，1050 字节的 payload 直接溢出，伪造 cleanup 结构体，控制流劫持到 root shell。这是整条链里唯一一处"传统意义"上的内存破坏漏洞——而它甚至不需要什么新技巧， 一个诞生于几十年前的漏洞形态，在一台 2026 年的人形机器人上畅通无阻。

溢出点出现在 BLE 服务器代码里还有一层讽刺：这个服务本来是给"手机 APP 配网"用的最小功能面，理论上应该是设备上被审计得最干净的代码之一。现实是，越靠近"只是个配网小工具"的代码，越少被安全团队认真看过——大家都去审运动控制与视觉模块了。攻击者的选题直觉从来如此：不打最复杂的模块，打最没人看的模块。

另一条路：AI 聊天服务（CVE-2026-76639）。 这条链更简洁到荒谬：G1 的 AI 聊天服务提供了一个"knowledge"上传功能，用于给对话机器人投喂私有知识，但上传接口对文件名没有任何校验。Laflamme 用路径穿越把文件写进了 bashrunner 的信任目录——那是一个重启后会自动以 root 身份执行脚本的位置。于是整条攻击链缩成：发 5 条 DDS 消息、零认证、等机器人重启、收到 root shell。没有溢出，没有内存破坏，一个 ../../ 就够了。一个给"投喂知识"设计的友好功能，因为信任了文件名，变成了 root 后门。

这条链和 BLE 链的对比很有信息量：BLE 链需要 RSA blob、云端预言机、WiFi 注入、缓冲区溢出四层接力的"技术纵深"，而聊天链只需要一次 HTTP 风格的文件上传漏洞。两条路的终点相同——root——但成本差了一个数量级。这说明 G1 的安全问题不是某处粗心，而是系统性的：每一个服务都默认"内部网络里的请求是可信的"，而蠕虫化能力让"内部"这个概念本身失效了。

三处致命设计点评：

1. 云端所有权校验缺失 = 解密预言机。 加密算法本身没错，错的是云端愿意为任何人解密任何设备的数据。一旦解密服务不验证所有权，再强的加密都只是给合法用户加的锁。这是整条链里最值得架构师失眠的一条：漏洞不在任何一行代码里，而在"谁来调用这个接口"这个从未被回答的问题里。
2. BLE 免配对写。 "靠近即可写"意味着物理边界就是唯一的访问控制，而物理边界在共享办公空间、展会、甚至邻居的蓝牙范围内形同虚设。更糟的是配对本来是 BLE 提供的唯一身份原语，放弃它等于把设备暴露成"广播式 API"。
3. APP 成了密钥搬运工。 密钥的解密、重组、转发全在 APP 里完成，APP 又运行在攻击者完全掌控的手机上。厂商把城堡的钥匙串交给了最不设防的信使——而且这个信使还把自己路上的每一步都写进了可反编译的 Java 代码。

Laflamme 拿到 $5000 赏金（BLE RCE $4000 + chat_go $1000），宇树用 2 个月修完云端。而一条 90 磅的机器人被 root 之后能做什么？关避障、偷拍、替换 ResNet 模型——它有眼睛、有腿、有算力，被黑的不是一台设备，是一个会移动的传感器平台。蠕虫验证把这件事的严重性又抬高了一级：同房间的两台 G1，一台被攻陷后可以自动打另一台，"机器人感染机器人"从科幻叙事变成了 PoC 里的第五步循环。研究员自己总结得很直白："没有用到任何尖端攻击技术——反编译的安卓 APP、几年前就被破解的固件加密、比人形机器人古老几十年的缓冲区溢出。"

赏金数字也值得玩味。一台单价约 20000 美元、可以蠕虫化、可以替换 AI 模型的机器人，整个攻击链的赏金是 5000 美元——四分之一个轮子钱。不是宇树小气，是行业还没给"硬件信任链"类漏洞定过价。对比移动安全里一个中等severity 的 CVE 动辄上万美元，这类需要跨 APP/云/BLE/固件四个领域的综合攻击，赏金平台还没有对应的评级模板。

修复侧的反应速度另说：宇树 2 个月修完云端，这个速度在硬件行业里算快的（很多厂商的 SLA 是半年）。但也注意修复的顺序——先修的是云端校验（便宜、一个接口的事），BLE 溢出与固件侧的整改在时间线上靠后。这与防御清单一节的分析一致：便宜的先修，贵的排队。攻击者显然也懂这个时间差，所以漏洞细节公开前的那几周，永远是受影响设备的至暗时刻。

日常设备：锁与心电贴

TTLock：一行硬编码密钥的代价

CVE-2026-112345：Sciener TTLock 安卓 APP 在 9.8.260718 之前的版本里硬编码了 AES 密钥 defaultKey。这个密钥本该在配对时协商出会话密钥，但写死的 defaultKey 意味着配对过程的对称会话密钥可被推算——且会话密钥在配对生命周期内不变。结果：蓝牙范围内的攻击者无需登录、无需用户确认，直接开锁改权限。CVSS 向量 AV:A/AC:L/PR:N/UI:N，机密性与完整性双高影响。一把锁的防线，塌在 APP 源码里一个字符串常量上。

攻击场景想象一下就够了：攻击者带一部手机走过公寓走廊，每扇 TTLock 门都在蓝牙广播里自报家门；停在某扇门前，跑一个脚本，几秒后门开了，住户全程不知道。没有破坏痕迹，没有撬锁工具，锁的日志里甚至不会有异常记录——因为攻击者用的就是"合法"配对会话。物理世界的入室盗窃，被降维成了一次无线电子交互。

值得停下来体会这个漏洞的"低技术含量"。不是侧信道，不是椭圆曲线缺陷，是一个本该每次配对随机生成、却被开发者写进代码里的默认密钥。为什么会有 defaultKey？大概率是为了"开箱即配"的体验——用户不想输入配对码，厂商就把码写死。每一次产品决策里的"让用户少点一下"，都在悄悄挪动安全边界。TTLock 案例的特殊之处在于它把宇树 G1 的故事压缩成了单变量版本：不需要蠕虫、不需要云端预言机，一个常量就够——因为锁的价值密度太高，一个漏洞等于全部。

家用心电设备：从电波到数据库的完整泄露链

Akinbi 与 Raj 2025 年发表在 Frontiers in IoT 的研究，把三款家用 ECG 设备从无线电层到 APP 存储层完整打穿。做医疗物联网安全，这个研究是绕不开的范本——它的价值不在某个单独的洞，而在完整覆盖了"一台联网医疗设备到底有多少个面"：

• Beurer BM 95：蓝牙 4.0 明文传输心电数据，空中抓包即得原始 ECG；叠加 CVE-2023-24023（中危）与 CVE-2019-9506（KNOB 降级攻击，高危）。
• KardiaMobile 6L 与 OMRON Complete：配对使用 Just Works 模式，无 MITM 防护；KNOB 降级后密钥熵可被暴力破解——心电数据在无线电层裸奔。
• 固件侧的加分项：研究者用 CH341A 编程器从 SST26VF032B 闪存拧出固件，发现 OpenPGP 加密、未能解密。固件加密做对了。
• APP 侧的崩塌：Kardia 的 APP 检测 root（可用 Shamiko 绕过）但 ECG 数据裸存在 SQLite 里；Omron 与 Beurer 的 APP 不检测 root，Realm 数据库直接裸奔。

KNOB（CVE-2019-9506）在这里的角色需要点破：它不是心电设备独有的 bug，而是蓝牙规范层面允许协商熵极低的加密密钥（最低 1 字节），2019 年公布时波及几乎所有 BLE 设备。配对用 Just Works 的设备叠加 KNOB，等于锁芯本来就是纸糊的，现在连门框都可以拆——降级之后密钥暴力破解以分钟计。研究者在论文里把 KNOB 列为高危，不是危言耸听。

四款设备拼出了一条完整的泄露链：无线电层（明文/Just Works/KNOB）→ 配对层（无认证）→ APP 层（root 检测形同虚设，数据库裸存）。任何一环单独看都"不算大问题"，串起来就是：一个能靠近你或拿到你手机的人，可以读出你的完整心电记录。

这个案例的精髓在反差：厂商花成本给固件上了 OpenPGP 加密，却让 APP 把解密后的数据裸存在手机上。 攻击者完全不需要碰那条加密闪存，一台 root 手机加一个文件管理器就够了。硬件安全做得最认真的那一环，被最潦草的那一环整体报废。

对医疗设备这个品类，这个反差还有一层加成：心电数据是《个人信息保护法》意义上的敏感个人信息，能反映心律失常、情绪应激甚至某些药物的摄入。无线电层一次抓包、APP 层一次 SQLite 导出，拿到的不是"数据"，是一段可直接解读的生理档案。而整个攻击链里最难的环节——用 CH341A 拧闪存——攻击者根本不需要做。防御强度是由最弱一环决定的，这一环在手机上。

给做安全研究的人一个实操提示：Kardia 用 Shamiko 绕过 root 检测这个细节，值得单独记下。医疗类 APP 是 root 检测最激进的一类（金融类之外），Shamiko（Zygisk 模块）+ 隐藏 magiskd 的组合是 2025 年前后最稳的通用绕过方案。绕过之后，SQLite/Realm 里的数据就是静态文件——不需要内存 dump，不需要运行时 hook，一个能看到的文件管理器就够了。

三案例对比

把三起案例摆在一起，横轴上有个残酷的规律：设备越贵、越复杂，攻击链反而越长但每一环越松。G1 有五步，但每一步都建立在"没人看守"上；TTLock 一步到位，因为锁没有多余的攻击面可绕；ECG 设备介于两者之间。对防御者，这意味着加固优先级应该跟着"信任链环节数"走，而不是跟着设备单价走——环节越多的系统，越容易出现那个没人记得要校验的接缝。

还有一个容易忽略的维度：三起案例的"发现成本"都在急剧下降。Laflamme 用了 3 个月，但他面对的是人形机器人这个全新品类；TTLock 的 defaultKey 对任何会跑 strings 命令的人可见；ECG 的明文广播一台几十块的 SDR 配件就能收到。攻击门槛越低的漏洞，越会在未来几年被批量复现——下一个 TTLock 不会等太久。

协议层的坏消息：BLERP

如果你读完前面三个案例，得出的结论是"这几家厂商太烂"，NDSS 2026 的 BLERP（Sacchetti 与 Antonioli）会纠正你：这不是某家厂商的问题，是 BLE 标准本身的重配对流程设计缺陷。

先补一个背景：BLE 的配对（pairing）与重配对（re-pairing）是两套信任逻辑。首次配对有密钥协商、有用户确认（理想情况下），但两台之前配对过的设备重新建立连接时，规范走的是一条捷径——默认"我们认识彼此"。BLERP 攻击的正是这条捷径：重配对流程里的角色切换与特性协商环节，没有绑定首次配对建立的身份凭证。

BLE 重配对——两台之前配对过的设备重新建立连接时——存在 6 个漏洞：设备可以冒充中央或外设角色，攻击者可以操纵特性协商。后果是降级攻击、冒充攻击与 MITM。测试覆盖 22 个目标（15 Host / 12 Controller / 16 Central / 9 Peripheral），蓝牙 4.2 到 5.4 全部中招，包括启用了 Secure Connections 的强配置。键盘鼠标场景下可以零点击利用。

这组数字值得逐个看：22 个目标不是小样本，15 个 Host 实现与 12 个 Controller 实现覆盖了市面上主流的协议栈供应商；16 个 Central 与 9 个 Peripheral 意味着无论你的设备扮演哪个角色，都有对应的打击面；蓝牙 4.2 到 5.4 的时间跨度接近十年，Secure Connections 是蓝牙 4.2 引入时被宣传为"终结配对攻击"的强配置。BLERP 证明的是：重配对这个流程本身，从规范写成的那天起就带着这些缺陷，十几年里所有按规范实现的设备全部继承。

对防御者的坏消息是：你能做的非常有限。这是协议栈层的设计问题，不是某款产品配置错了哪个开关。买最贵的锁、选最新蓝牙版本的设备，在 BLERP 面前都没有豁免权。真正的缓解要等芯片厂商与协议标准的长期演化——而在此期间，你的威胁模型里应该假设"重配对流量可被操纵"。

6 个漏洞、四种利用面（降级/冒充/MITM/角色混用），全部指向同一个规范级根因：重配对流程里的身份凭证与角色信息没有密码学绑定。修复这类问题不像修一个 CVE 那样发补丁就行——规范改了，新旧设备互操作性怎么办？十年存量的已售设备怎么办？蓝牙 SIG 面对的是一个"修了标准也修不了世界"的局面。这是协议层漏洞与实现层漏洞最本质的区别：实现层漏洞归厂商，协议层漏洞归整个生态，而生态没有责任人。

BLERP 放回本文主线，还起到一个校准作用：前面三个案例读下来，很容易得出"厂商都不在乎安全"的结论。但 BLERP 的 22 个目标里不乏认真做安全的大厂，Secure Connections 也确实是强配置——他们栽在的是自己无法修改的规范文本上。硬件安全的现实是分层的：厂商能修的（密钥管理、所有权校验）与厂商修不了的（协议设计），你要分开建威胁模型。而攻击者不区分这两层，谁近打谁。

对个人用户，BLERP 时代的实用建议只有三条：敏感场景（门禁、医疗）的蓝牙设备用完断连，别让手机自动重连常年挂着一堆历史配对；设备固件跟着更新，Host 层修复会随手机系统推送，这是你唯一能被动获得的缓解；剩下的交给概率——攻击者需要物理接近和重配对时机，机会型攻击的性价比远低于本文其他案例。

方法论：APP 是硬件最好的攻击面代理

四个案例有一个共同的技术起点：研究者都没有从拆机开始。 Laflamme 反编译 APP、TTLock 的密钥写在 APP 里、ECG 的数据裸存在 APP 数据库里。这正是 IoTFuzzer（Chen、Diao、Lin）在方法论层面早就指出的方向：APP 即硬件代理——在 APP 内存里 mutate 即将发送的数据，不需要碰固件就能 fuzz 出设备的内存破坏漏洞。宇树 G1 的 BLE 溢出，本质上就是这个思路的实战版：在协议流量里找边界，而不是在固件里找函数。

IoTFuzzer 的洞见在于它换了一个问题：不是"设备固件里有什么漏洞"，而是"设备相信 APP 发来的什么"。APP 与设备之间的协议是厂商自定义的，没有规范、没有公开文档，但 APP 里必然存在构造这些报文的代码——密钥怎么算、字段怎么拼、长度怎么填。把这些代码当作设备的"协议说明书"，在内存里 hook 并 mutate 即将发出的报文，设备端的解析器就会替你回答"哪个字段没有做边界检查"。宇树 G1 那个 1050 字节打穿 500 字节缓冲区的 payload，用这个框架看完全不意外：解析器长年只面对"善意"的 APP，从没被喂过脏数据。

这个方法论的适用边界也要说清：IoTFuzzer 式的 mutation 只能发现"解析器会崩"类漏洞（内存破坏），发现不了逻辑漏洞——比如"云端不校验所有权"这种，报文格式完全合法，错的是服务端的业务判断。所以完整的硬件研究是两条腿：fuzz 管内存破坏，人工读 APP 逻辑管信任链。Laflamme 的研究恰好两条腿都用了：BLE 溢出是前者的战果，云端预言机是后者的战果。

传统黑盒固件研究的三大障碍——加密的 flash、锁死的 bootloader、仿真鸿沟——在 2026 年依然坚挺（ECG 研究者面对 OpenPGP 加密固件同样止步）。但这不是死路，而是转向信号：当设备本体越来越难拆，外围就成了主战场。APP、网络指纹、应用层协议，每一层都比闪存芯片更可及，而且每一层都藏着与固件等价的秘密。固件研究这条路本身仍然值得走（串口、编程器、仿真环境的完整搭建可以看这篇嵌入式环境指南，CH341A 和 SST26 系列闪存都在里面），但先从外围切入，性价比高得多。

这三条障碍值得逐个说透，因为它们解释了为什么"外围转向"是理性的而不是偷懒：

• 加密 flash：现代 IoT SoC 普遍启用片上 flash 加密，物理拧出闪存后面对的只是密文。ECG 研究者的 OpenPGP 止步不是个例，是常态。
• 锁死的 bootloader：secure boot 链条验证每一段启动镜像，JTAG 熔丝烧断后连调试口都是死的。老一套"接上 UART 拿 shell"在认真做安全的厂商那里已经走不通。
• 仿真鸿沟：即使拿到固件镜像，外设寄存器的魔数、专有协处理器、缺失的设备树，让 QEMU/Unicorn 路线的工程量常常大于重写一遍业务逻辑。

三条障碍合起来的效果：把研究者从设备本体推开。而外围——APP、云、BLE——没有任何一条障碍挡路。这不是攻击者变聪明了，是防御纵深把攻击者挤到了没设防的那一侧。

宇树 G1 的研究路径把这个方法论走到了极致：从反编译 APP 拿到协议逻辑，到用免费云端账号当解密预言机，再到 BLE 缓冲区溢出收尾——全程没有读取一行固件代码。 一台 2 万美元、跑着复杂运动控制栈的机器人，它的 root 权限是从它自己的安卓客户端和它自己家云端手里接过来的。设备越复杂、固件越难拆，"APP 即代理"的相对优势就越大。

对这个方法论还可以再推一步：APP 不只是"攻击面代理"，它还是信任链的物证。当你想知道"设备到底信不信这条报文"，不需要做实验——反编译 APP 找它构造报文的代码：如果 APP 发某字段前算了 MAC/HMAC，说明设备大概率校验完整性；如果 APP 直接把命令明文塞进特征值，说明设备端八成也没校验。厂商在 APP 里怎么写的，就是他对设备的真实安全认知。代码不会说谎，营销文稿才会。

对有 Android 逆向基础的读者，这就是入场券：jadx 打开厂商 APP 的那一刻，你已经站在硬件攻击面的正门口。云端 API 的路径、BLE 特征的 UUID、密钥协商的算法、root 检测的逻辑——硬件厂商把这一切打包发到了每个用户手机上，还签了名。你多年练的技能，恰好是硬件安全最缺的技能。

收尾：判断与行动清单

回到开头那台 2 万美元的机器人。它被攻陷的方式没有任何一个环节称得上"先进"，但串起整条链的研究视野——从 APP 反编译到云端 API 到 BLE 协议到固件内存布局——恰恰是行业最稀缺的能力组合。2026 年的硬件安全不是攻防军备竞赛升级了，而是战场地图重画了：会 Android 逆向的人在这张新地图上，起点比传统硬件黑客更靠前。

图：三起案例共用同一条失守的信任链。注意底部的三句防御——主语都是"我们自己别做什么"，这是减法思维，不是加法。

三起案例（宇树 G1、TTLock、ECG 设备）共同教训可以压缩成三句话：密钥不落 APP，配对不上 Just Works，云端必须校验所有权。 这三句话分别对应三个案例的根因，也分别是三个最容易在架构评审阶段被忽略的决策。它们的共同前提是一个认知转变——硬件攻击面早就不等于设备攻击面，APP 与云都是硬件攻击面的合法组成部分，谁在设计文档里把它们划出安全边界，谁就是在给攻击者留正门。

注意这三句话的共同句式：主语都不是"攻击者会怎么做"，而是"我们自己别做什么"。传统硬件安全思维是加法——加加密、加认证、加secure boot；这三句是减法——别把密钥放进 APP、别用 Just Works、别让云端裸奔。2026 年的真实案例告诉我们，硬件安全的失守点大多不是"防护不够强"，而是"某些环节根本没被当作防护对象"。加法思维防的是设备被拆，减法思维防的是信任链被串。

展开成一张防御清单，按"写给谁"分类：

这张表按"写给谁"分了三类角色，不是装饰：服务端的修复最便宜（一个中间件中间层就能加所有权校验），协议层的修复最贵（要等标准演化），客户端与 APP 侧居中。安全资源的正确分配顺序应该跟着修复成本反着走——先把便宜的修了。现实里厂商常常反过来：花大钱上 secure boot 和 flash 加密（看起来高级），却留着硬编码密钥不扫（修起来太土）。ECG 案例的 OpenPGP 固件与裸奔 SQLite，就是这个错配的标本。

给读者的三层练手路径：

三层路径的设计逻辑是"每层只需要上一层的结果"：抓包让你认识协议的字节流，密钥提取让你理解字节流里的信任假设，重放与 fuzz 让你亲手验证那些假设什么时候不成立。不要跳层——直接上手 fuzz 而没读过流量的人，写出来的 mutator 连字段边界都切不对。每层都用自己的设备练，一台百元级的手环或门锁足够覆盖前两层，第三层再考虑入一台可刷固件的开发板。

一个提醒：练手设备选自己的、家里的、或者明确授权的。本文所有案例都是负责任披露路径下的研究，TTLock 与宇树的问题能公之于众，前提是研究者先给了厂商修复窗口。这个行当的入场规则不是"能打开多少锁"，而是"打开之后怎么做"——这也是赏金经济（8900 万美元那个池子）能运转的根本前提。

行业面也值得一看：HackerOne 2026 报告显示年度赏金总额 8900 万美元（同比 +18%），85% 的研究员在用 AI 辅助研究，68% 正转向高复杂度高赏金漏洞。硬件与 IoT 恰好处在"高复杂度"与"攻击面外溢到 APP/云"的交汇点上——传统 Web 漏洞越来越卷，而信任链问题的赏金才刚开始定价。对想换赛道的人，这三个数字合起来的含义很直白：钱在往难的方向流，而"难"的定义正在从"挖得深"变成"串得起来"——把 APP、云、BLE、固件四个领域的知识接成一条链的能力，正是 Laflamme 这类研究的溢价来源。

85% 这个数字单独再说一句：AI 辅助研究在硬件领域的杠杆率比 Web 更高。反编译代码的模式识别、协议报文的字段推测、固件字符串的批量归类，恰恰是 LLM 最擅长加速的环节。这意味着后来者的启动成本被大幅压低——三年前需要一个团队干一个季度的静态分析，现在一个人加 AI 两三周就能到同等覆盖度。门槛降低不会让漏洞变少，只会让"有人认真看"的设备越来越多。

这是"Android 硬件安全"系列的开篇。下一篇我们会动手做第一层：BLE 抓包环境搭建，用一台便宜的智能设备把自己的无线电流量拆开看。你会发现，隔着 APP 看硬件的世界，比隔着螺丝刀清楚得多。

系列后续还规划了：Frida hook 一个真实厂商 APP 的 BLE 发包函数、用 nRF Connect 重放并修改配对流量、以及照着 IoTFuzzer 的思路给一台便宜设备写第一个 mutator。工具链不长，每一步都建立在这一篇的案例理解上——知道攻击者为什么能走通，你复现时才知道自己在验证什么。

参考文献

1. Laflamme, O. — Unitree G1 远程 root 研究（CVE-2026-76639 / CVE-2026-76640），Unitree 赏金计划披露
2. NVD — CVE-2026-112345：Sciener TTLock APP 硬编码密钥漏洞条目
3. Sacchetti, M. & Antonioli, D. — BLERP: BLE Re-pairing Vulnerabilities, NDSS 2026
4. Akinbi, A. & Raj, P. P. — 家用 ECG 设备安全分析, Frontiers in IoT, 2025. doi:10.3389/friot.2025.1712430
5. Chen, J., Diao, W., Lin, Z. — IoTFuzzer: Discovering Memory Corruptions in IoT Through App-based Fuzzing
6. HackerOne — 2026 Hacker-Powered Security Report

许可协议

本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。

分享文章