为了在睡前按一下 Apple Home 晚安按钮,顺便把卧室里的空气净化器调大风量当白噪音机,开发者 Scott J. Goldman 和厂商的云服务缠斗了数年,最终在 2026 年 11 月 11 日选择自己动手把云端彻底拔掉。他开源了遵循 MIT 许可的 Home Assistant 自定义集成 scottjg/coway-local,在不拆机不刷固件的前提下,让已停产的 Coway Airmega IconS(型号 AP-1022K)实现了纯局域网控制。智能家居行业把“风扇加滤网”包装成云端订阅人质的荒诞戏码,被这次逆向工程撕开了一道口子。

调大风扇还要看云端脸色,第三方轮询一年崩两次

2017 年加州山火频发时,旧金山湾区许多没有密封隔热的老房子全靠空气净化器挡烟尘。Goldman 家里那台老款净化器坏掉后,换上了外观像中世纪家具、带 Wi-Fi 功能的 Coway Airmega IconS。硬件本身只是一个带 HEPA 滤网和传感器的盒子风扇,但原厂 App 加载极慢,且几乎每次打开都强制要求修改密码。

为了让这台机器接入 Apple Home,社区此前唯一的办法是使用开源插件 RobertD502/home-assistant-iocare。这个插件伪装成手机客户端,不断向 Coway 云端轮询状态并下发指令,每年至少会崩溃一两次。

翻看该云端插件的历史版本记录,就能看清这种寄生模式有多脆弱。在 v0.6.0 发行说明中,维护者证实一旦初始化设置失败或官方 API 返回不完整数据,Home Assistant 就会陷入重复初始化与登录的死循环,直接触发官方风控机制导致账号被封禁数周,哪怕是临时封禁也至少要等一天才能解封。

维护者不得不打补丁加入跳过官方维护期的逻辑,遇到维护超时只能每小时小心翼翼重试一次;到了 v0.6.5 版本,又得紧急修复因修改密码或新注册账号引发的 invalid_grant 无效授权码报错。加上官方将应用从 IoCare 重写改版为 IoCare+、微调 HTML 网页结构导致抓取失败,或是干脆封杀插件流量,用户的睡眠白噪音随时可能因为远方某台服务器抽风而中断。

云端轮询陷阱 vs 蓝牙配网本地接管 旧路径 · 模拟 App 轮询官方云 插件高频抓取 HTML 与云端 API API 缺损触发死循环登录重试 IoCare+ 改版或维护即全屋断联 封号数周 触发厂商风控限流后的直接代价 新路径 · 蓝牙注入自定义地址 Web Bluetooth 直接改写配网参数 caUrl 与 certSvrUrl 指向内网 本地 9883 端口跑 MQTT/TLS 代理 0 固件改动 保留 MCU V1.0.0.1 原厂状态免拆机

证书劫持引出真后门,蓝牙配网直接改写服务器地址

想要摆脱云端,常规思路是做中间人攻击(MitM)流量劫持,但这通常会撞上设备端的 SSL 证书校验铁板。2026 年 10 月,可信证书颁发机构 eMudhra 曝出私钥参数过弱的安全事件,mitmproxy 甚至直接内置了 --emudhra-old 选项来伪造根证书,这给了 Goldman 动手抓包的契机。

由于树莓派板载 PCB 天线信号太弱,他用笔记本电脑共享 Wi-Fi 转以太网给树莓派供网,并在被 Claude 以网络安全类别拒绝后,改用 ChatGPT 生成了 nftables 防火墙转发规则。

真正抓包后发现的事实比预想中简单得多。净化器根本没有在固件里硬编码任何根证书,而是在配网阶段直接通过明文 HTTP 去亚马逊 S3 服务器下载 AmazonRootCA1.pem。替换掉这个文件看清加密流量后,Goldman 发现日常使用根本不需要维持复杂的路由器防火墙劫持,因为后门就敞开在蓝牙配网阶段。

厂商为了自身开发或测试便利,在蓝牙配网协议里直接允许客户端动态下发服务器地址。设备通过蓝牙特征值 FFA0 读取身份信息,向 FFA2 发送 P001 密钥消息,随后发送以 P002 为前缀、经 protobuf 封装和 PKCS#7 填充的 AES 加密配置。这套加密的AES 密钥规则完全固定,由 20 个随机小写字母与设备 12 位大写 MAC 地址直接拼接而成。

只要通过 Web Bluetooth 在配网配置里修改 caUrl 和 certSvrUrl 两个字段,就能名正言顺地把设备的证书注册重定向到用户自己的内网服务器。这台 MCU 固件版本为 V1.0.0.1、Wi-Fi 固件版本为 000011 的 AP-1022K 净化器,就这样心甘情愿地连上了本地运行的 MQTT-over-TLS 代理。

coway-local 免拆机本地接管四步管线 1. 蓝牙握手 读 FFA0 身份信息 向 FFA2 发 P001 无需拆机焊线 2. 密钥合成 20 位随机小写字母 拼 12 位大写 MAC 生成 AES 密钥 3. 地址重定向 发 P002 加密配置 改写 caUrl 字段 指向内网服务器 4. 端口全面接管 8080 / 9443 发证书 9883 跑 MQTT/TLS 原厂 App 彻底失效

智能家电去云端化的三条路线与隐性代价

在本地跑起 coway-local 后,服务端默认占用 8080、9443 和 9883 三个本地端口,分别处理 HTTP、HTTPS 和 MQTT/TLS 通信。实测下来,电源开关、3 档手动风速、智能与睡眠模式、灯光开关、定时、传感器灵敏度、滤网设置,以及 PM2.5 和滤网寿命读取全部恢复正常,唯一的代价是配网后原厂 App 彻底失效。

厂商锁死云端不是因为技术上做不到本地通信,而是不愿交出设备控制权。

把视野拉宽到整个空气净化器品类,消费者想要拿回本地控制权,目前面临着截然不同的技术门槛与硬件限制:

品牌与代表型号本地化接入方式功能完整度与核心能力隐性代价与硬件限制
Coway Airmega IconS蓝牙配网注入自定义 URL电源、3 档风速、模式、灯光、PM2.5原厂 App 失效;250S 与 MightyS 待验证
宜家 STARKVINDZigbee2MQTT 原生直连支持 off、auto 及 1 至 9 档风速调节仅在风扇运转时才会测量 PM2.5 数据
小米空气净化器系列xiaomi_miio 局域网轮询或刷 ESPHome本地局域网状态读取与档位控制排除 4 Compact 与国行 4 Lite 两个型号
Coway Airmega 150拆机焊接刷入 ESPHome 固件彻底脱离原厂协议实现完全自定义破坏硬件保修,需具备电烙铁动手能力

对比之下,宜家 STARKVIND 直接采用标准 Zigbee 协议,开箱就能融入本地智能家居,省去了逆向折腾;小米虽有局域网方案,但 4 Compact(型号 zhimi.airp.cpa4)和国行 4 Lite(型号 zhimi.airp.rma3)被排除在支持列表之外;而同品牌的 Coway Airmega 150 此前要想本地化,只能靠拆机焊线硬刷 ESPHome。

coway-local 走出了一条零硬件破坏的中间道路,证明许多看似严密设防的物联网设备,完全可以通过配网协议层面的引导实现免刷机赎身。

  • 提醒.对于手里握有已停产 AP-1022K 净化器的存量用户,这套方案是防止厂商日后关停服务器导致设备智能功能变砖的救生艇;但如果你手里是在售的 Airmega 250S 或 MightyS,目前尚不确定它们是否共用同一套未设防的蓝牙配网协议,更需要警惕 Coway 在后续固件更新中封堵自定义 caUrl 接口。