你家的電視和車載系統安全嗎？XCPE 後門的控制端被切斷之後

你家的電視盒，可能不只連上串流服務，也曾讓陌生人的流量從家裡的網路出去。Google 的威脅情報指出，XCPE 後門讓超過 130 萬台 set-top box 加入 botnet，Videostrong 把存取賣給犯罪合作方，再載入對方的模組，讓裝置成為住宅代理出口或用來做廣告詐欺。住宅代理會借用家用裝置的 IP 轉送流量，讓連線看起來來自別處，FBI 的說明解釋了這種運作方式。

切斷控制端，沒有一併清掉裝置上的後門，依 TrendAI的說法，移除伺服器後，操作者已無法連上這些盒子，植入卻仍留在已售裝置。至於車機，目前的證據來自 BADBOX 2.0 的裝置類別描述與 DoFun 個案，兩者涵蓋的範圍不同。資料查核至 2026-11-04 03:11（台北時間）。

四種日期不要混用

這些報告沒有告訴我們每台裝置何時感染，樣本首見與架構改版記錄的是程式的變化，研究者何時買到實機、蒐集遙測或公開報告，也各有自己的時間。

Synthient 的 IoC README把 x.cpe 3.6.5 的 First Seen 列為 2020-12-14；Plume重建的版本史則把 3.4.0 到 3.8.5 放在約 2021 年，兩者差距未解。這些是樣本紀錄，沒有交代每台裝置何時感染。Google所說的至少從 2024 年末起，指的是惡意程式演進為模組化三階段架構的時間下限。

研究者留下的日期也無法確定整起事件的起點，Synthient在 2025 年末購入 MECOOL KM9PRO Max，這是取得研究機器的時間；Plume的 broker 連線快照是 2026-09-08；TrendAI統計的遙測區間為 2026-06-03 至 2026-10-01。

Synthient 規格表把購入那台機器的 Build Date 寫成 2025-04-11，同一台的韌體是 C1.0.8_20250325，Security Patch 落在 2025-02-05，這些只對得上該機的 build 資訊，看不出鑑識何時完成，或同型號其他裝置何時感染。Plume從家用遙測裡的可疑 MQTT 請求追到套件，再分析 150 份以上原廠韌體映像與 100 份額外樣本，這兩個數量指的是研究材料，跟受害台數無關。

公開日上，Synthient跟 TrendAI都是 2026-11-02，Google頁面曾經分別顯示 2026-11-02 和 11-03，落差還沒解。Plume PDF沒有發布日，檔名裡的 10-2026 不能拿來代替發布日。基礎設施處置上，Google 和 TrendAI 都只寫 Last week，單一日期定不下來。

韌體裡的後門

XCPE 後門隨韌體出貨，即使解除安裝，重開機後還會回來。Google指出，它預載於 system partition，以 android.uid.system 身分執行，重開機時會從 /oem/ 裝回；TrendAI則描述為使用製造商金鑰簽署的系統應用。Google提到 x.cpe 在部分 build 以 com.oemservice 執行，Plume用的名稱是 X.CPE，僅憑這些名稱，還無法確定所有樣本都是同一套件改名。

一般的解除安裝也擋不住它，Google記錄，從 /data/app/ 移除後，BootReceiver 會在重開機時把套件裝回。Plume分析的 Nexus 1.7.88 則帶有 INSTALL_PACKAGES，能自行安裝其他應用，後續更新或移除也不必向使用者確認，即使沒按過同意，裝置仍可能加入這些服務。

Google描述的控制流程是先經 HTTP 取得設定，再建立持續的 MQTT 連線，已分析樣本使用單一 broker。程式除了能靜默安裝應用、關閉 Play Protect，也能執行 shell，擷取畫面或偵察網路；研究者實際看過即時畫面擷取與鍵盤輸入注入，也觀察到帳戶與裝置資訊遭竊，以及 reverse shell 的建立。不過，多數互動都用來管理模組，安裝後還能調整設定或移除。

研究者也看到了這些裝置如何被拿來賺錢，Google記錄到廣告詐欺模組，還看見 Spirit 載入更多模組，以及 Moyu 初始化，單機最多出現三個住宅代理 SDK。這些觀察仍不能套到每台裝置：TrendAI的約 133 萬台是被排程安裝代理與廣告詐欺模組，Plume某批設定則只有 linkfog 啟用。

TrendAI觀察到的營利行為，包括沒有同意畫面就加入的商用頻寬共享程式，以及製造虛假廣告曝光的模組，也有腳本在大量裝置上關閉 Play Protect。研究者沒有觀察到特定買家，因此仍不知道誰購買了這批代理容量。

模組還可能另外連線，Plume描述 Linkfog 的通道獨立於 MQTT，從家庭網路看來只是多一條近似影片串流的出站連線，但這段架構描述無法告訴我們，處置後還有多少裝置可被存取。該報告把變現功能移出本體的時間列為 2024 年 11 月，Google則寫 2024 年末另做 com.abc.nexus。避開稽核或回應 BadBox 執法，都只是報告提出的可能動機。

數字各自的口徑

報告中的三個主要數字涵蓋不同範圍，不能相加，也無法用來判斷現在有多少台在線。

Google講的超過 130 萬台，是加入 botnet 的 set-top box，統計起迄日沒有寫出來。TrendAI的 1,472,554 台，是 2026-06-03 至 2026-10-01 觀測到的受感染裝置，涵蓋 206 個型號、超過 170 個國家，這組數字都是下限，類型包括電視盒與投影機。合作方一起採用超過 130 萬，是因為各自的觀測時間和範圍不同。表裡的 3,849,226 則是 IP 數，不能當成裝置台數。

Google的至少 1,000 萬台額外裝置則是評估：犯罪合作方還有 XCPE 以外的散布管道，移除其 C2 將切斷對這些裝置的存取。這個數字不能全部算成 XCPE 電視盒，更沒有表示清理完成。

連線快照記錄的則是 broker 當時的連線，Plume在 2026-09-08 記錄的 424,108 與 26,477 是不同 broker 的連線，超過 130 萬台不重複裝置則是另一份估計；Synthient的約 50 萬台在線或每日通訊也屬估計，沒有提供可重現的方法。

認證測試留下的缺口

認證測試漏掉了惡意程式，問題出在哪裡仍不清楚。Google寫 Videostrong 用混淆手法利用「a gap in our tests」，在裝置首次開機後載入惡意程式，並表示已調整審查流程，卻沒說是哪一項測試，也沒說送測映像與量產映像不同。

Google禁止 Videostrong 及日後的子公司或關係企業製造、銷售認證 Android 裝置，或向其他認證廠商供應軟體，並改善認證 Android TV 的韌體完整性檢查。這些措施沒有附上已售裝置的修復映像。

只看認證狀態，也無法判斷裝置是否感染，認證頁要求裝置出貨時沒有預載惡意程式，支援頁則區分裝置認證與 Play Protect 防護。未認證不等於已感染，認證也不保證日後不被植入。Plume描述的裝置群混有 AOSP 與 Google-certified，報告沒有受害型號的完整認證對照，不能推成 130 萬台全都通過認證。

購買或維護裝置時，認證仍有參考價值，Google 說明頁提醒，未認證裝置可能不安全、可能拿不到系統或應用更新，上面的 Google 應用也未獲授權。認證頁另說，Google 沒有確保這類裝置的基本安全功能，Google 應用與 Play 商店可能無法正常運作。這些風險值得考慮，但確認某台裝置是否感染，仍需要該裝置的證據。

研究歸因與司法文件

Google 對 Videostrong 的歸因屬於高信心的研究判斷，XCPE 報告沒有提供對該公司的司法認定。Google以 assess with high confidence 寫道，Videostrong 為了獲利而有意開發後門，並負責部署與營運，個別內部人員擅自行事或開發疏失都沒辦法解釋這件事。Synthient同樣給出高信心歸因，依據包括簽署信箱、基礎設施 IP 重疊，以及公開目錄裡的一份文件。Google 說的法律行動是取下網域與伺服器，沒有寫是哪個法院，也沒有列出案號或起訴書。

品牌背後可能涉及多家公司，製造硬體或簽署軟體，都不足以證明誰在營運後門。Synthient研究的 MECOOL 裝置，其製造欄為 SkyworthDigital，後門由 Skyworth Digital Technology 簽署；Plume則把 Videostrong 描述為韌體與管理平台供應者，Nexus 使用其平台憑證，載入的函式庫是第三方元件。這些資料不足以確定 Skyworth 的角色，更不能把各層公司都當成營運者。

型號可以協助辨識裝置，Synthient README明確提醒，只有型號名稱不足以確認感染，仍須核對 IoC。截至 2026-11-04，Videostrong 首頁與公司新聞第 1 頁未見本案聲明。

README列出的 KM9PRO、KM9PRO_MAX、KM6、STV-3000_Plus、PRO-M2，是這次行動中觀察到的型號字串。Videostrong 首頁仍列出 Google Certified 產品類別，那也只是產品目錄，無法代替對指控的承認或否認。判斷個別裝置是否感染，需要裝置本身的證據，盒子上的品牌或認證宣稱都無法代替。

與 BADBOX 的關聯

XCPE 與 BADBOX 的已知連結停在模組層，不能據此認定是同一個營運者。Google把 Moyu、Bird 連到先前的 BadBox 體系；TrendAI也提到 Kaspersky 將 com.abc.nexus 連到 IPMoyu。

較早的 BADBOX 行動也公布過受影響規模，HUMAN 原案報告超過 74,000 台裝置有感染跡象；BSI在 2024-12-12 公布轉走德國境內最多 30,000 台裝置的通訊，沒有表示已移除惡意程式。HUMAN 的 BADBOX 2.0 報告估計截至 2025 年 1 月超過 100 萬台，Google 2025-07-17 的部落格則稱超過 1,000 萬台未認證 AOSP 裝置。這些數字不能加進 XCPE，未認證 AOSP 的描述也不能套用到其混合裝置群。

BADBOX 2.0 的民事案為紐約南區聯邦地院 1:25-cv-04503，被告是 Does 1-25。2025-09-18 缺席判決認定被告違反 CFAA 與 RICO，並發出永久禁制令，文件未點名 Videostrong，不能寫成法院已對該公司作出認定。

車機案例的範圍

相關報告確實提到車機，範圍限於 BADBOX 2.0 列出的裝置類別，以及 DoFun 個案，不能擴大到所有車載系統。HUMAN與 FBI 2025-06-05 公告都列出售後車載資訊娛樂系統，沒有交代車機的廠牌與型號，也未提供台數。FBI 的感染途徑包括購買前預載，以及設定時下載含後門的必要應用。

DoFun 這起有具體的感染鏈。Securelist在 2026 年 6 月發現惡意程式，2026-08-21 公布研究，惡意程式經 Android 車機韌體的內建更新器散布，用來做廣告詐欺與 proxy botnet。研究以高信心把這起行動歸因於與 BADBOX 有關的 MoYu Group，廠商獲通知後回報已處理。報告沒有把 DoFun 歸為售後或原廠車機，也沒有感染台數；Kaspersky 部落格寫的超過 3,000 萬車主，轉引的是 DoFun 官網的服務規模。

這個服務規模無法用來估計有多少車機感染，Securelist記錄的是裝置出貨後經內建更新器散布的途徑，沒有將惡意程式寫成預載。車機經更新器感染的過程，與電視盒的出廠韌體後門不同。

Plume明確連到這份車機研究，指出同一個 Nexus 套件也出現在該行動中，這是套件層的關聯，仍不足以證明那些車機加入 XCPE botnet。Google 的 XCPE 受害清單以 Android TV set-top box 為主，也列出了遠距健康裝置和卡拉 OK 機，還有數位看板，沒有車機。

上述報告也沒有原廠 Android Automotive 或 Google built-in 車輛受害的證據。Android 文件說明 Android Automotive 開源，Google Automotive Services 可由汽車 OEM 選擇授權；開發者文件則說明 Google built-in 車輛使用 Android Automotive OS。這些平台關係不能用來推定車機感染或認證狀態。

控制端切斷之後

對符合 IoC 或有具體可疑跡象的裝置，先斷網停用，再找可信且適用的修正；無法確認修正有效，就更換。TrendAI指出，清理需要廠商採取行動，也可能透過平台防護處理，或選擇換機，Synthient也建議拔掉可疑裝置。Google 與 TrendAI 沒有提供已售裝置可用、可驗證的乾淨韌體。僅與清單上的裝置同型號，仍須依 Synthient 的提醒另核對感染指標。

斷網只能隔離網路行為，後門仍留在韌體裡，Plume雖建議 factory reset，卻也描述 dw1 設計上會在還原後保留裝置身分，沒有驗證還原能清掉 X.CPE。這些報告沒有證明「130 萬台仍受控」，對「130 萬台已經乾淨」也沒有提供證據。

恢復使用前，還是得確認修正適用於手上那台裝置，Plume建議還原的理由，是後續模組可能已放下額外後門；Synthient建議更換 Wi-Fi 密碼，並更新路由器與裝置韌體，以降低再次感染風險。這些措施都沒有附上清除植入的驗證結果，僅僅完成還原或更新，還不足以恢復使用。

認證可另行查詢：Google 支援頁說明，可在 Play 商店點選個人圖示，開啟設定，再查看「關於」；若顯示「裝置未經認證」，再對照認證裝置清單。Google也建議向可信製造商購買，使用時保持 Play Protect 開啟，並留意分享頻寬換錢的應用。對企業而言，TrendAI提醒，遠端員工家中的未管理裝置也是暴露面，線上服務不能只靠 IP 信譽判斷信任。

若準備換機，Google 認證頁建議購買時留意 Play Protect 標誌；手上的裝置未認證時，可聯絡製造商或零售商，要求提供通過認證的裝置。這是挑選替代品的依據，沒有解決原裝置上的後門。Google 的消費者建議還包括使用可信的應用商店、檢查第三方 VPN 與代理的權限，尤其留意以閒置頻寬或分享網路換取報酬的應用。即使表面上只是分享頻寬，仍應弄清楚應用取得了哪些權限。

零售商也有責任要求供應商改善，Google建議零售商要求 ODM 提供獨立安全稽核，並下架涉及這類濫用的製造商；TrendAI則要求白牌電視盒的賣方取得認證韌體。對有遠端員工的組織，其建議是讓公司存取經過受管理的端點，將家用網路上的消費裝置納入風險評估。

仍待確認的事項

XCPE 報告尚未交代感染批次、出廠區間、受害型號與認證的完整對照，也未列出法律文件。Synthient的樣本資訊仍不足以確定 Skyworth 的角色，Videostrong 官網亦未見回應。對已售裝置，還缺乏可信的修復管道與實際清理台數；犯罪合作方所涉至少 1,000 萬台後來如何，也仍需有資料才能確認。

補充筆記

控制端切斷後，已售裝置上的植入仍在，報告沒有提供可驗證的乾淨韌體。
超過 130 萬台、1,472,554 台與至少 1,000 萬台額外裝置，口徑不同，不能相加；3,849,226 是 IP 數。
Google 對 Videostrong 的高信心歸因是研究判斷，BADBOX 2.0 缺席判決未點名該公司。
與 BADBOX 的關聯停在模組層，未認證 AOSP 的舊案描述也不能套到 XCPE。
車機有 BADBOX 2.0 類別與 DoFun 個案，Nexus 套件關聯不足以證明車機加入 XCPE，亦無原廠 Android Automotive 受害證據。
同型號不等於感染，斷網不等於清除，恢復使用前仍需確認修正有效。