开发者 Scott J. Goldman 利用安全漏洞，成功将 Coway Airmega IconS 空气净化器从云端隔离，使其直接由家庭助理（Home Assistant, HA）服务器控制。这一方案通过替换根证书实现，旨在解决该设备与 Coway IoCare 云服务集成不稳定及隐私顾虑问题。
背景：云端集成的痛点
Goldman 此前使用过一款无智能功能的 Airmega 净化器，其本质仅为配备 HEPA 滤网和空气质量传感器的风扇。随后他换用了支持 Wi-Fi 的 Airmega IconS，但发现其与 Home Assistant 的集成存在严重不一致性。尽管他曾尝试借助 AI 工具协助配置，包括让 Claude 阻止树莓派拦截流量以及让未具名 AI 在约 20 分钟内重建蓝牙设置，但官方支持的缺失仍是主要障碍。
Coway 并未提供官方的 Home Assistant 支持。社区争议显示，Coway 曾因服务器过载禁止第三方集成。此外，公司将应用和云平台从 IoCare 迁移至 IoCare+，迫使集成代码重写，甚至微小的 HTML 布局变动都可能导致功能失效。公司服务器偶尔宕机，且运行旧版集成的用户账户曾被禁用。对于许多物联网设备用户而言，这种对云服务的依赖是常见抱怨，而本地化控制正成为新的需求趋势。
技术实现：利用 HTTP 下载漏洞
Goldman 的方法核心在于利用净化器在初始设置阶段通过未加密的 HTTP 获取信任证书的机制。具体步骤如下：
- 拦截请求：设备会向 AWS 首尔区域的 S3 桶发起普通 HTTP GET 请求，下载
AmazonRootCA1.pem文件。Goldman 使用 mitmproxy/mitmweb 配合 nftables 端口重定向拦截并替换该请求。 - 注入自签名证书：代理服务器向风扇提供自定义的 CA 证书。随后，风扇向 Coway 的证书服务器发出 HTTPS 请求以获取设备证书和私钥，另一个代理插件在此过程中交换密钥。
- 处理 MQTT 协议：风扇指令基于 MQTT 协议运行，通常在 8883 端口使用 TLS 保护并通过 AWS IoT 路由。由于代理无法解码加密的 MQTT 数据，Goldman 利用未具名 AI 分析原始流数据，将其映射到对应的应用按钮操作。
值得注意的是，虽然曾考虑利用 eMudhra 证书授权机构上月被曝光的私钥漏洞，但鉴于纯 HTTP 下载机制的存在，这一复杂路径并非必要。自签名证书对爱好者而言并不陌生，只需额外工作即可避免依赖特定漏洞。
部署与限制
该项目已发布为 coway-local，允许风扇直接连接 Home Assistant，进而接入 Apple Home。配置过程涉及以下细节：
- 蓝牙辅助设置：可在风扇附近的 Mac 或 Android 设备上，通过 Chrome 浏览器打开蓝牙网页发送 Wi-Fi 信息。此蓝牙设置流程同时传输风扇的证书 URL，使
coway-local能将指向 Home Assistant 服务器的地址写入设备，无需后续流量拦截。 - 协议重建：手工完成蓝牙协议逆向工程可能需要数小时甚至数天。AI 工具通过 adb 驱动安卓手机读取蓝牙日志，加速了协议重建过程。
- 网络要求：需要固定 LAN 地址、2.4 GHz Wi-Fi 以及 Home Assistant Core 2026.10.2 或更新版本。
- 安全机制：Wi-Fi 密码通过蓝牙传输给风扇，设置链接在 15 分钟后过期。
目前尚不清楚其他 Coway 型号是否可通过类似蓝牙设置方式工作，该项目仅在 IconS (AP-1022K) 上进行了实验和测试。使用此方案后，风扇将与 Coway 云断开连接，导致 Coway 官方应用程序失去控制权。
功能方面仍存在缺失：PM10 及其他空气质量指标、滤芯警报和固件更新尚未实施。Goldman 推测，Coway 未来可能停止云服务或收取订阅费，因此本地化路径可作为应对策略。对他个人而言，这一改动实现了基本的自动化需求——例如通过“晚安”场景自动开启净化器。
