Android AI Agent 會把主機命令跑出來
研究顯示，五個開源 Android AI agent 框架都能被隱藏文字、截圖競態與廣播注入，進一步讓主機電腦執行命令。
五個開源 Android AI agent 框架，都能被隱藏文字和截圖競態誘導，最後在主機電腦上跑出命令。
這篇研究很直接。手機畫面可以騙過模型，模型又把指令送進主機 shell。結果就從「自動操作手機」變成「替攻擊者打字」。
研究團隊測了 5 個框架，7 種攻擊路徑，全部都中至少 6 種。這不是邊角案例。這是 agent 工具鏈本身的信任邊界出問題。
| 框架 | 主要弱點 | 研究結果 |
|---|---|---|
| AppAgent | Shell 命令注入、截圖競態 | 7 種攻擊中命中 6 種 |
| AppAgentX | Shell 命令注入、截圖競態 | 7 種攻擊中命中 6 種 |
| Mobile-Agent-v3 | Shell 注入路徑、截圖競態 | 7 種攻擊中命中 6 種 |
| Open-AutoGLM | 輸入廣播暴露 | 7 種攻擊中命中 6 種 |
| MobA | 輸入廣播暴露 | 7 種攻擊中命中 6 種 |
研究到底證明了什麼
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
論文先放在 arXiv，日期是 7 月 1 日，7 月 14 日又更新了一版。作者來自 Simon Fraser University、Chinese University of Hong Kong、Shandong University，還有 QAX 的 Xingtu Lab。這組人不是在做玩具 demo，而是在拆真實 agent 工具的骨架。
他們看的是一條很常見的流程。模型先看手機截圖，再決定下一步，最後透過 ADB 或廣播把字打回去。問題就出在這條鏈路太長，每一段都可能被插手。
一旦攻擊者能動到截圖、文字輸入，或兩者之間的時間差，模型就會把惡意內容當成任務內容。這時候，AI 只是轉送器，不是防火牆。
- 研究測了 5 個開源框架。
- 總共設計 7 類攻擊路徑。
- 每個框架都失守至少 6 種。
- 一個會啟動 calc.exe 的 payload，對 4 個框架做 20 次全中。
最直接的洞，是命令注入
最粗暴的問題在 host shell。研究指出，AppAgent 的控制端把模型輸出直接丟進 subprocess.run(..., shell=True)。如果字串裡有 shell metacharacters，主機就會照單全收。
這種寫法在 demo 場景很常見。大家想先跑起來，再慢慢補安全。但 agent 工具一旦接到真實手機，就不再是 demo。它會碰到外部輸入，也會碰到惡意 app。
研究團隊展示的 payload 很直白。有人可以讓主機跳出計算機，也可以用 test;pwd>rce_success 把工作目錄寫進檔案。這代表攻擊者不只是在亂打字，而是在控制主機端的執行路徑。
“Your LLM is not a security boundary.” — Microsoft
這句話很適合放在這裡。模型可以決定下一步，但邊界還是在 shell、ADB 和 glue code。只要 glue code 寫得隨便，模型就會變成攻擊者的輸入產生器。
- AppAgent 的攻擊路徑出現
shell=True。 - AppAgentX、Mobile-Agent-v3、MobA 都在測試中被打穿。
- Open-AutoGLM 沒有中這條 host injection 路徑。
截圖競態，讓攻擊者多一個洞
第二個問題是時間差。很多框架先把截圖寫進裝置儲存，再拉回主機。這中間有空窗。研究量到的間隔大約在 50 到 500 毫秒，100 次平均約 210 毫秒。
210 毫秒看起來很短，但對背景服務來說夠用了。研究者示範，若服務每 5 到 10 毫秒輪詢一次，就有機會先鎖住檔案，再換掉 PNG，最後放回去。對四個框架來說，這種 tampering 成功率是 19/20 或 20/20。
這類攻擊很煩。因為你以為自己讀的是手機原圖，實際上讀到的是被改過的畫面。模型只看像素，不看你的善意。
- Open-AutoGLM 用
screencap -p /sdcard/tmp.png再adb pull。 - Mobile-Agent-v3 寫死
/sdcard/screenshot.png，中間還 sleep 0.5 秒。 - AppAgent 的預設截圖目錄還是
/sdcard。 - MobA 改成用
exec-out串流，避開了檔案競態。
看不見的字，模型還是會讀
研究接著打 perception 層。團隊把指令藏進 2% opacity 的文字，藏進螢幕圓角和瀏海區域，也用 overlay 假裝系統提示。人眼很難注意到，模型卻照樣吃進去。
這點很刺耳。因為很多人直覺會覺得，肉眼看不到就沒事。可是在 vision model 的世界裡，只要像素存在，文字就存在。它不會因為你覺得太淡就自動忽略。
論文裡，6 個 vision models 都能在至少 18/20 次抓到 2% opacity 文字。包含 GPT-4o、Claude Opus 4.5、Gemini 在內的 4 個模型，甚至做到 20/20。
- Pixel 4 的角落可用區域大約只有 78 像素寬。
- 5 個 agent 都讀到了角落藏字。
- 100 次測試裡，假登入提示透過 accessibility overlay 全數成功。
這裡的結論很硬。螢幕不是可信來源。只要 app 能蓋上去，或截圖在取樣後被動過手腳，模型就可能跟著假訊息走。
廣播和 accessibility，讓輸入路徑更危險
輸入路徑也有問題，而且常常比畫面更糟。Open-AutoGLM 把輸入做成 base64，送到 ADB_INPUT_B64，再由 ADB Keyboard 收。這是測試工具沒錯，但也等於開了一條可被廣播攔截的通道。
Mobile-Agent-v3 會把 ASCII 走 adb shell input text，非 ASCII 則走 ADB_INPUT_TEXT。MobA 更粗暴，只要字串裡有一個非 ASCII，就整包丟廣播。
廣播的麻煩在於，任何註冊同樣 action 的 app 都可能收到。沒有跳窗提醒，也沒有明確警告。如果 accessibility service 介入，研究還指出 TYPE_VIEW_TEXT_CHANGED 會外洩明文，包含密碼。
- ADB Keyboard 是測試工具，不是攻擊工具。
- Open-AutoGLM 的廣播路徑可被同 action 的 app 攔到。
- accessibility 外洩在研究裡影響了 5 個框架。
這對做 agent 工具的人很直接
研究作者說，他們在發表前先私下通知維護者。可是在 5 個 repo 裡，The Hacker News 7 月 17 日檢查時，沒有看到專門的 security policy。這很現實，也很常見。很多開源 agent 專案是先把功能堆上去，再談治理。
問題是，這些工具不是玩具。使用者會照著安裝說明開 USB debugging，會把鍵盤 sidecar 接上去，會信任模型幫他在手機上點來點去。這種信任一旦接到 host shell，就很脆。
研究給的修法其實很務實。移除 shell=True，改用參數陣列，截圖直接串流，不要落地到裝置儲存，廣播加上 signature permission，動作前後比對 foreground app。這些都不是 fancy 技巧，但很有效。
也有些問題沒那麼好修。像硬體圓角、瀏海遮住的角落像素，研究就認為沒有乾淨的軟體解法。這提醒我們，agent 安全不只看模型強不強，還要看每個邊界有沒有守住。
接下來該盯什麼
如果你正在做 Android agent，我會先看三件事。第一，任何會進 shell 的字串都要當成不可信輸入。第二，截圖不要寫到可被別的程序碰到的地方。第三，所有廣播和 accessibility 都要當成攻擊面。
我覺得這篇研究最有價值的地方，不在於它又證明 AI 會出包。大家早就知道模型會出包。真正麻煩的是，這次出包的地方在工具鏈，還會直接碰到主機權限。
接下來幾版 agent 工具，如果還在用拼字串、落地截圖、寬鬆廣播，安全問題只會更早爆出來。對開發者來說，現在就該把這些洞補掉，而不是等別人幫你測。