花266美元讓AI接管自有Fire平板
一台原價114.26美元的 Amazon Fire HD 10，因系統反覆自動關機，最後讓作者多花266.15美元請四款 AI 接力找解法。Claude 協助診斷，Kimi K3 從實際韌體找出未修補的 Mali GPU 漏洞 CVE-2022-38181，GLM-5.2 揪出設計錯誤，GLM-5.3 再修正核心位址與頁表格式，成功取得 root。最終不是只秀出權限，而是移除約100個 Amazon 套件，讓 Fully Kiosk Browser 能持續顯示 Home Assistant 儀表板。
現實應用
這類能力適合維護停產裝置、企業 kiosk、智慧家庭面板與無法取得原廠支援的嵌入式設備。資安研究員也能讓模型比對韌體、公開 CVE 與驅動程式，快速排除已修補漏洞。一般使用者則不適合直接照做：過程包含核心崩潰、反覆重開機與變磚風險，而且只對特定硬體、韌體版本成立。
期望評估
我認為低標期望不是「AI 一天自動破解設備」，而是把數月的資料蒐集、二進位比對與失敗紀錄整理成可交接的研究成果，協助人類更快確認問題在哪。高標期望則像這次案例：多模型互相審查並延續前一棒，最後把既有漏洞調整成特定裝置可用的 exploit。不過成功仍高度依賴舊韌體、操作者判斷與大量試錯，不能視為穩定服務。
商業策略分析
我認為最值得注意的不是哪個模型「比較敢破解」，而是 coding agent 已能把漏洞研究拆成數百步並實際操作工具。這會影響裝置商、資安顧問與 AI 平台：裝置商不能再假設冷門硬體沒人研究；AI 業者若安全政策過度粗糙，可能連合法的自有設備研究也一起擋掉；模型供應商則能靠長時間代理任務與交接能力形成差異。我猜企業值得跟進受控的韌體稽核流程，但必須加入所有權確認、隔離測試及人工核准，不能只靠模型自行判斷授權範圍。
實作細節
作者透過 ADB 連接平板，使用 opencode、OpenRouter 與 Z.ai 的 ZCode 操作模型，並從 Amazon OTA 映像抽出核心分析。漏洞利用 use-after-free 取得 GPU 寫入實體記憶體的能力，再修改 SELinux 與程序憑證取得 root，最後以 pm uninstall --user 0 可逆地停用套件。已知問題包括成功率低、曾累積逾500次失敗與 kernel panic；Amazon 已在 Fire OS 7.3.2.9 修補漏洞，因此這不是通用 root 方法。