扫地机器人“叛变”了

如今不少家庭都已经习惯了扫地机器人的便捷，相比自己每天亲自打扫，有了扫地机器人的清理显然要方便的多。但是怎么也没有想到，扫地机器人有一天居然会“叛变”。

初见端倪

近期，美国软件工程师Harishankar Narayanan在其个人博客上发布了一篇《The Day My Smart Vacuum Turned Against Me》（扫地机器人背叛了我）的文章。

之所以发布这样一篇文章，是因为在2024年，Harishankar购买了一台iLife A11智能扫地机器人，平时都挺好用，能自动规划路线、绘制房间地图。

但有一天，Harishankar发现这台扫地机器人突然停止了工作，无论充电、重启都毫无反应，送去检修，厂商却表示这台设备“一切正常”。但奇怪的是，拿回家后，用了几天它又自己“死机”了。

Harishankar怀疑，这台设备出现问题，可能与自己近期的做的一项事情有关，那便是此前在路由器上屏蔽了这台扫地机器人与外部服务器的通信。

将扫地机器人重启之后发现，只要允许它访问互联网，便会立刻恢复正常。而一旦断网，又陷入到了死机状态，就像是被远程“锁死”了一样。就这样重复了3-4次后，由于保修过期，厂商拒绝了维修。因此，Harishankar决定把这台扫地机器人拆开看看。

一探究竟

拆开后发现这台扫地机器人的内部结构还是比较复杂的，主控板是一颗全志A33 SoC，常见于平板电脑。系统运行的是TinaLinux，全志在嵌入式设备上使用的一个轻量版Linux发行版。

旁边还有一颗GD32F103 MCU，负责管理传感器数据，包括激光雷达、陀螺仪、编码器以及一些红外与碰撞传感器传输的数据。

这套系统结构很像一个“小型机器人平台”，A33运行主逻辑和地图构建算法，而GD32F103控制运动与传感器输入。

与此同时，Harishankar还从主控芯片中提取出固件镜像，并在文件系统中发现了几个令人警觉的东西。一个是rtty守护进程，这是一个远程终端工具，允许厂商通过云端直接接入设备终端。换句话说，这个进程可以让厂商在不经过用户的同意，进入系统执行命令。

还有ADB（Android Debug Bridge）端口也是开放的，也让设备对外暴露了一个root权限的调试接口，无需认证。只需要通过ADB connect，就能够获得设备完全的控制权，这也意味着任何能够发现设备IP的人都能够做到这一点。

有趣的是，Harishankar还在系统日志中发现了一条异常的指令“RS_CTRL_REMOTE_EVENT”，在设备停止工作的那一刻，这条指令便出现在了日志当中，随后扫地机器人便彻底停止了响应。对此，该工程师推测这是一个厂商的远程控制命令，用于“远程禁用”。

水落石出

为了验证自己的推测，Harishankar恢复了这台扫地机器人的联网，并对所有流量进行监控，结果发现它每隔几分钟就向3irobotix服务器（非iLife官方服务器）上传数据。

这些数据包括完整的3D室内地图，使用Google Cartographer SLAM（即时定位与地图构建技术）技术生成，精确到家具位置、入口/出口、盲点，还有移动路径、清洁模式、家居布局、用户生活习惯，以及遥测日志、传感器数据等。

而当Harishankar使用路由器屏蔽了这些上传行为后，设备突然停止了工作，并再次显示了那条代码。因此可以断定，当扫地机器人检测到无法上传数据时，便触发了远程停用。

随后，工程师在固件中发现了一段脚本，确实包含了“远程关闭”逻辑。对该脚本进行修改后，让设备忽略远程停用指令，具体就是在/usr/bin/cloudctl中，注释掉disable_device()调用，并手动删除远程服务启动项，最后重新打包固件，写回系统，果不其然，该扫地机器人又重新复活了。

当前，Harishankar还在GitHub中持续更新调查，包括反编译固件、自定义Python脚本（实现离线控制，如手动导航、传感器接口）。他构建了备用控制系统：用Raspberry Pi或自定义硬件替换主板，绕过云依赖，实现纯本地运行（无需App，靠脚本管理电机/传感器）。

同时在拆解分析过程中，扫地机器人系统运行了系统运行了Google Cartographer（一种用于SLAM的开源算法），它会根据雷达数据实时绘制房间地图，并将地图文件上传到云端进行融合或优化。这意味着厂商实际上在远程同步用户家中的地图副本。

至于为何每次去维修之后扫地机器人都会重新恢复工作，一方面在于维修时扫地机器人会重新联网，另一方面售后也会将机器人固件重置，无意中清除了那条远程关闭的指令。而拿回来工作几天后，发现还是无法将数据重新上传给厂商，因此再次触发了“宕机”指令。

后续与厂商回应

对于此次的发现，Harishankar表示，原以为自己购买的是一台机器人清洁工具，但实际上却是一个由厂商远程管理、可被停用的网络节点，这让他感到非常的不安。

这一事件也引起了欧美的广泛报道，有安全研究者表示这是“典型云强制案例”，呼吁欧盟GDPR/美国CCPA进行调查。

后续，Harishankar也在近期联系到了iLife，但尚未获正式回复。主控SoC供应商全志则表示，仅提供硬件参考设计，并不参与终端用户软件开发。

IoT设备的远程控制和隐性数据上传也并非iLife独有，类似架构在多个品牌的智能设备中普遍存在。包括智能电视、路由器/摄像头、电动车等。

知名网络安全企业Forescout今年4月发布了一份报告显示，全球平均设备风险指数同比上涨15%至8.98，创历史新高。网络攻击面已从传统IT设备向OT、IoMT领域快速扩张，路由器仍占据高风险设备总量的53%，而医疗物联网设备首次成为风险增长最快的类别。

IDC 预测，今年连接的物联网设备将超过800亿个。据IDC的数据显示，具有互联网接入能力的设备（如构成物联网的计算机、传感器和摄像头）的数量正稳步增长。IDC还指出，当41.6亿个物联网设备连接时，将产生79.4泽字节的数据，这其中包括了来自数万亿传感器的各项输出。物联网对企业和消费者均有深远的影响。

如何界定网络数据安全的边界，以及如何限制设备厂商对卖出设备的过度联网权，明确这台设备归属权到底是谁，需要整个行业都进行仔细的考量。

总结

Harishankar通过自身工程师的习惯，察觉到了扫地机器人的异常情况，并抽丝剥茧发现真相，最后实现了真正的离线运行。但对于许多普通消费者而言，并没有这样的工程能力，还是需要行业制定更严格的标准，将IoT设备的真正归属权还给消费者。