Android 自動化軟體 #
Android 自動化/容器 #
| 軟體 | 作用 |
|---|---|
ReDroid (redroid/redroid) | Docker 容器中的 Android 作業系統 |
| Waydroid | 透過 LXC 和 Wayland 在 Linux 桌面上執行 Android |
| Anbox | 最初的 Android 容器化概念驗證專案;Waydroid 和 ReDroid 的祖先 |
Waydroid 與 ReDroid #
Waydroid 和 ReDroid 使用相同的底層理念:不執行完整虛擬機器,而是在主機 Linux 核心上執行 Android 使用者空間。Android 本身以 Linux 為基礎,但高度依賴 Binder IPC 和共享記憶體等 Android 專用核心功能。因此,兩者都要求主機支援binder_linux以及共享記憶體,例如ashmem_linux或較新的基於memfd的替代方案。
兩者的主要差異在於目標環境。Waydroid面向希望在Wayland工作階段中將Android應用程式顯示為類似原生視窗的Linux桌面使用者。ReDroid面向伺服器、CI、自動化和雲端手機場景,在這些場景中,Android以Docker容器形式執行,並透過ADB、scrcpy、自動化工具或插樁進行遠端控制。
| 領域 | Waydroid | ReDroid |
|---|---|---|
| 主要目標 | Linux 桌面 | 伺服器、CI、自動化、雲端手機 |
| 容器執行環境 | LXC | Docker / OCI 容器 |
| 顯示模型 | 與主機 Wayland 合成器整合 | 預設為無頭;透過 ADB/scrcpy 或瀏覽器包裝器檢視 |
| 主機依賴 | 需要 Waydroid 套件、LXC 和 Wayland 工作階段整合 | 需要 Docker 和 Android 核心模組 |
| 部署方式 | 透過套件管理器進行系統層級安裝 | 可重現的docker run / docker-compose.yml工作流程 |
| 拆除方式 | 移除套件並清理殘留的主機設定 | 移除容器和磁碟區 |
| 適用場景 | 在 Linux 桌面上執行 Android 應用程式 | 為自動化、爬取、擷取執行 Android 應用程式 |
對於此使用情境,LXC並沒有比Docker更高的實際效率。兩者都是對相同Linux核心原語的介面:命名空間、cgroups、掛載、網路和裝置存取。Docker早期在內部使用LXC,之後轉移到libcontainer/runc。Android容器的效能瓶頸通常來自Binder IPC、圖形/顯示合成、GPU直通,以及渲染是否使用硬體加速,而不是LXC與Docker之間的差異。
Waydroid可能選擇LXC,是因為LXC更適合桌面整合,特別是將主機Wayland通訊端繫結掛載並暴露給Android容器。ReDroid選擇Docker,則是因為Docker更適合部署、可重現性、編排和無頭自動化。
對於自動化或爬蟲系統,ReDroid通常更容易部署。可以使用Docker映像檔和compose檔案描述執行環境,在連接埠5555上公開ADB,持久化/data,並連接scrcpy、uiautomator2、Frida或mitmproxy等工具。主機層級的必要條件仍然是核心支援Android的Binder和共享記憶體:
sudo modprobe binder_linux devices="binder,hwbinder,vndbinder"
sudo modprobe ashmem_linux部分Linux核心預設不提供這些模組,因此主機可能需要額外的核心模組或不同的核心套件。即使存在此限制,ReDroid通常仍比安裝Waydroid更少侵入,因為它不需要桌面Wayland工作階段或系統層級的Android桌面整合堆疊。
ReDroid的隱蔽性 #
預設情況下,ReDroid並不能躲避Android應用程式的環境偵測。ReDroid是容器化的AOSP環境,因此除非進行自訂,許多識別碼都會呈現為通用值。對於基本偵測,應用程式可能會檢查Android建置屬性、可用硬體功能、感測器、電信狀態、電池行為、已安裝服務和執行階段痕跡。
常見的偵測面包括:
| 偵測面 | 顯眼原因 |
|---|---|
| 建置屬性 | 預設的AOSP/ReDroid值可能看起來像通用環境,而不像真實裝置 |
| 硬體功能 | 感測器、相機、電信功能、電池、Bluetooth和GPS可能缺失或被簡化 |
| CPU/原生架構 | 在x86_64主機上執行ARM應用程式需要轉譯,可能留下指紋 |
| Google Play Services | ReDroid通常是純AOSP,預設不包含GMS |
| 執行階段工具 | 對於主動掃描程序表、連接埠、記憶體對映或已載入函式庫的應用程式,Frida等插樁工具可能會被看見 |
| 圖形/顯示路徑 | 容器化渲染和虛擬顯示行為可能不同於實體手機 |
簡單檢查通常基於靜態屬性,因此較容易通過。中等強度的偵測SDK會結合建置屬性、套件清單、缺少的硬體、root狀態、Play Services狀態和原生環境檢查。激進的應用程式可能使用專有的反濫用或反作弊系統,將多個訊號與伺服器端信譽評分結合。
對於類似微信的應用程式,實際評估如下:
| 偵測等級 | ReDroid前景 |
|---|---|
| 簡單的模擬器檢查 | 使用更真實的環境設定後,通常可以應對 |
| 常見商業SDK檢查 | 可行,但需要仔細維持裝置、服務和執行階段的一致性 |
| 激進的應用程式專用反濫用 | 困難且不穩定;可能演變成持續的攻防競賽 |
對於自動化或爬取,實際做法通常不是讓ReDroid與手機完全無法區分,而是確保應用程式能夠安裝、登入並穩定執行;將/data持久化為Docker磁碟區;並盡量減少不必要的插樁。曾經使用過且穩定的帳戶,以及持久化的Android資料目錄,往往比追蹤每一種模擬器指紋訊號更重要。
如果目標是擷取流量或狀態,而不是建立帳戶或規避反濫用機制,更安全的架構是執行一般的ReDroid執行個體,在需要時手動互動,持久化工作階段,並且僅在授權除錯或研究確有需要時加入Frida或mitmproxy等工具。
螢幕串流/遠端顯示 #
| 軟體 | 作用 |
|---|---|
scrcpy (Genymobile/scrcpy) | 透過 ADB 串流 Android 螢幕 |
| ws-scrcpy | 圍繞 scrcpy 的瀏覽器/WebRTC 包裝器 |
| TigerVNC | 先前 Playwright 容器設計使用的 VNC 伺服器 |
| DroidVNC-NG | Android 的 VNC 伺服器應用程式 |
| openbox | 先前 Playwright 容器設計使用的最小 X11 視窗管理員 |
VNC為何不是Android上的常用方案 #
Android上存在VNC,但使用不便,也不常見。通常對應Android的方案是scrcpy,它透過ADB使用Android自身的視訊編碼路徑傳輸Android螢幕。實際上,當人們希望以類似VNC的方式檢視和控制Android裝置時,通常會使用scrcpy。
核心差異在於傳輸的內容:
| 領域 | VNC | scrcpy |
|---|---|---|
| 串流類型 | 幀緩衝/螢幕擷取式像素串流 | 編碼後的H.264/H.265視訊串流 |
| 傳輸 | VNC TCP協定 | USB或TCP上的ADB |
| 伺服器要求 | Android上需要VNC伺服器應用程式或root層級的幀緩衝存取權限 | 不需要Android端應用程式;使用ADB |
| 輸入 | 透過VNC伺服器轉換滑鼠/鍵盤 | 透過ADB傳送觸控/鍵盤事件 |
| 延遲 | 通常較高 | 通常較低 |
| 自動化適用性 | 獨立的遠端桌面層 | 自然適用於ADB自動化 |
Android不像Linux桌面那樣提供一般桌面幀緩衝。現代Android應用程式透過SurfaceFlinger、硬體合成、安全表面和應用程式沙箱進行渲染。VNC伺服器要麼必須使用受限的MediaProjection螢幕擷取API,要麼依賴root層級存取權限來擷取較低層的顯示緩衝區。
因此會產生以下實際問題:
| 問題 | 影響 |
|---|---|
| 安全表面可能被顯示為黑色 | 應用程式可以設定FLAG_SECURE,導致登入畫面、QR碼或敏感檢視在擷取API中顯示為黑色 |
| 輸入轉換具有損耗 | VNC滑鼠事件不是Android的原生控制模型;Android需要觸控、手勢、IME輸入和無障礙事件 |
| 需要額外應用程式/程序 | 必須在Android內部安裝並持續執行VNC伺服器 |
| 延遲和頻寬表現較差 | VNC未針對Android原生顯示管線進行最佳化 |
| 不適合容器 | ReDroid已經暴露ADB,因此scrcpy更簡單、更可靠 |
Android存在DroidVNC-NG等VNC伺服器應用程式,Termux也可以透過VNC暴露Linux桌面,但這些屬於小眾場景。它們不是控制Android本身的常規方式。對於ReDroid或自動化用途,scrcpy加ADB是標準的遠端顯示路徑。如果需要瀏覽器存取,應使用ws-scrcpy等scrcpy包裝器,而不是加入VNC。
插樁/流量擷取 #
| 軟體 | 作用 |
|---|---|
| Frida | 執行階段Hook和動態插樁 |
| objection | 基於Frida的CLI,用於常見行動應用程式Hook,例如解除SSL釘選和root繞過 |
| mitmproxy | HTTP/S攔截代理伺服器 |
| Charles Proxy | mitmproxy的HTTP/S攔截代理替代方案 |
| apk-mitm | 用於停用SSL釘選的APK修補工具 |
Android自動化/UI #
| 軟體 | 作用 |
|---|---|
| uiautomator2 | 基於Python的Android UI自動化 |
| airtest | Android UI自動化框架 |
FlowBot (xlrpa/FlowBot) | 透過Android無障礙API進行微信/Android自動化 |
| ADB | 用於主機控制Android的Android Debug Bridge |
微信專用 #
| 軟體 | 作用 |
|---|---|
| WeChatFerry | 支援Python/Node SDK的PC版微信DLL Hook |
| WTAPI | 第三方iPad協定微信API/SaaS |
瀏覽器自動化 #
| 軟體 | 作用 |
|---|---|
| Playwright | 瀏覽器自動化框架 |
| Chromium | 由Playwright驅動的瀏覽器 |
| tini | 容器的init程序 |
容器/系統 #
| 軟體 | 作用 |
|---|---|
| Docker | 容器執行環境 |
| LXC | Waydroid使用的容器執行環境 |
| Magisk | Android root管理和root隱藏工具 |
| binder_linux | 用於Android Binder IPC的Linux核心模組 |
| ashmem_linux | 用於Android共享記憶體的Linux核心模組 |
評論
在 GitHub 上閱讀或評論(發表評論需要登入)