掃地機器人“叛變”了

電子發燒友網報道（文/黃山明）如今不少家庭都已經習慣了掃地機器人的便捷，相比自己每天親自打掃，有了掃地機器人的清理顯然要方便的多。但是怎么也沒有想到，掃地機器人有一天居然會“叛變”。

初見端倪

近期，美國軟件工程師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設備的真正歸屬權還給消費者。