Android自動化ソフトウェア #

Android自動化 / コンテナ #

WaydroidとReDroidの比較 #

WaydroidとReDroidは、同じ基礎概念を使用します。つまり、完全な仮想マシンを実行するのではなく、ホストのLinuxカーネル上でAndroidユーザー空間を動作させます。Android自体はLinuxベースですが、Binder IPCや共有メモリなど、Android固有のカーネル機能に大きく依存します。そのため、どちらのシステムもホスト側でbinder_linuxと、ashmem_linuxまたは新しいmemfdベースの代替機構などの共有メモリをサポートする必要があります。

主な違いは対象環境です。Waydroidは、Waylandセッション内でAndroidアプリをネイティブに近いウィンドウとして表示したいデスクトップLinuxユーザー向けに構築されています。ReDroidは、AndroidをDockerコンテナとして実行し、ADB、scrcpy、自動化ツール、または計装を通じてリモート制御するサーバー、CI、自動化、クラウドフォンの用途向けに構築されています。

この用途では、LXCがDockerより有意に効率的というわけではありません。どちらも、名前空間、cgroups、マウント、ネットワーク、デバイスアクセスという同じLinuxカーネルプリミティブのインターフェースです。Dockerは初期には内部でLXCを使用していましたが、その後libcontainer/runcに移行しました。Androidをコンテナ内で動作させる際の性能ボトルネックは、通常、LXCとDockerの違いではなく、Binder IPC、グラフィックス／ディスプレイ合成、GPUパススルー、レンダリングがハードウェアアクセラレーションされているかどうかです。

WaydroidがLXCを選択したのは、特にホストのWaylandソケットをAndroidコンテナにバインドマウントして公開するなど、デスクトップ統合に適しているためと考えられます。ReDroidは、デプロイ、再現性、オーケストレーション、ヘッドレス自動化に適した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カーネルでは、これらのモジュールがデフォルトで提供されないため、ホストに追加のカーネルモジュールまたは別のカーネルパッケージが必要になることがあります。この注意点を考慮しても、WaylandデスクトップセッションやシステムレベルのAndroidデスクトップ統合スタックを必要としないため、ReDroidは通常、Waydroidのインストールより侵襲性が低くなります。

ReDroidのステルス性 #

ReDroidは、デフォルトではAndroidアプリによる環境検出に対してステルスではありません。コンテナ化されたAOSP環境であるため、多くの識別子はカスタマイズしない限り汎用的に見えます。基本的な検出では、アプリはAndroidビルドプロパティ、利用可能なハードウェア機能、センサー、テレフォニー状態、バッテリーの挙動、インストール済みサービス、ランタイムアーティファクトなどを調べることがあります。

一般的な検出面には次のものがあります。

単純な検査は通常、静的プロパティに基づくため、通過させるのが容易です。中程度の検出SDKは、ビルドプロパティ、パッケージ一覧、不足しているハードウェア、root状態、Play Servicesの状態、ネイティブ環境の検査を組み合わせます。攻撃的なアプリでは、複数のシグナルとサーバー側のレピュテーションスコアリングを組み合わせた独自の不正利用防止またはチート対策システムを使用することがあります。

WeChatに類似したアプリについて、現実的な評価は次のとおりです。

自動化またはクローリングで実用的なアプローチは、通常、ReDroidを端末と完全に見分けられない状態にすることではありません。代わりに、アプリのインストール、ログイン、安定動作を実現し、/dataをDockerボリュームとして永続化し、不要な計装を最小限にします。過去に使用された安定したアカウントと永続化されたAndroidデータディレクトリは、すべてのエミュレーター指紋シグナルを追跡することより重要な場合があります。

目的がアカウント作成や不正利用防止の回避ではなく、通信または状態のキャプチャである場合、より安全なアーキテクチャは、通常のReDroidインスタンスを実行し、必要に応じて手動で操作し、セッションを永続化し、承認済みのデバッグまたは研究に必要な場合にのみFridaやmitmproxyなどのツールを追加することです。

画面ストリーミング／リモート表示 #

AndroidでVNCが一般的でない理由 #

VNCはAndroidにも存在しますが、扱いにくく、一般的ではありません。通常のAndroid相当の方式はscrcpyです。scrcpyは、Android独自のビデオエンコード経路を使用して、ADB経由でAndroid画面をストリーミングします。実際、Androidデバイスを「VNCのように」表示・操作したい場合、通常はscrcpyが使用されます。

核心的な違いは、送信されるデータです。

Androidは、Linuxデスクトップのような通常のデスクトップフレームバッファを公開しません。最新のAndroidアプリは、SurfaceFlinger、ハードウェア合成、セキュアサーフェス、アプリサンドボックスを介してレンダリングします。VNCサーバーは、制限のあるMediaProjection画面キャプチャAPIを使用するか、低レベルのディスプレイバッファをキャプチャするためにrootレベルのアクセスに依存する必要があります。

これにより、次のような実用上の問題が生じます。

DroidVNC-NGなどのAndroid VNCサーバーアプリは存在し、TermuxでLinuxデスクトップをVNC経由で公開することもできますが、これらは限定的な用途です。Android自体を制御する通常の方法ではありません。ReDroidまたは自動化用途では、scrcpyとADBが標準的なリモート表示経路です。ブラウザアクセスが必要な場合は、VNCを追加するのではなく、ws-scrcpyなどのscrcpyラッパーを使用します。

計装／通信キャプチャ #

Android自動化／UI #

WeChat固有 #

ブラウザ自動化 #

コンテナ／システム #