Android、デバイス上でのADB接続を制限する可能性

早期警告 このブログ記事を読む前に、これはGoogleの公式発表ではないことをご理解ください。これはGoogle IssueTrackerで進行中の機能リクエストに基づいています。その中で、ADBの主要メンテナーの一人（Google社員）が、「悪意のあるアクター」から保護するためにデバイス上でのADB接続を制限することについて言及しました。 このIssueTrackerのスレッドを見に行きたい方は、まずこの記事を注意深くお読みください。 もし、単に「Shizukuが必要だからやめてくれ！」といった質の低いコメント、独占に関する不満、あるいは侮辱を投稿するためにIssueTrackerを訪れるつもりなら、そうしないことを強くお勧めします。スレッドをスパム化すると、Googleの開発者は問題をロックしたり、貴重なコミュニティのフィードバックを無視したり、この変更に関する公開アップデートを完全に停止したりするだけです。 このような変更は、Googleが新しいサイドローディングの変更と連携させる上でGoogleに利益をもたらす可能性があると考えていますが、これが今回の変更の真の理由であるとは積極的に信じていません。そこには真実で有効な理由があり、2つの異なるアプローチが取れると考えています。このブログ記事ではそれについて話します。 どのように協力できるか： ユニークなユースケースがある場合：もしあなたが直接影響を受けるのであれば、あなたのワークフローを説明する詳細で建設的なメッセージを書いたり、リンクを提供したり、技術的な解決策/妥協案を提案したりしてください。Google Issueでフィードバックを共有してください。 ユースケースがすでに言及されている場合：繰り返す必要はありません。代わりに、Google IssueTrackerの右上にある+1ボタンをクリックして、あなたが影響を受けていることをGoogleに知らせ、通知をオンにして議論の最新情報を入手してください。 私はこのブログ記事を作成することに躊躇しています。なぜなら、ADBに取り組んでいる少数の開発者に過負荷をかけることを恐れているからです。もっと待って様子を見るべきか、それとももっと長く待って彼らがどのようなアプローチを取るかを見るべきか、私にはわかりません。あまり長く待つことも悪い結果を招く可能性があります…この記事を書いている時点では、この記事がいつリリースされるか、あるいはリリースされるかどうかも不明です。ADBで以前働いていた主要な担当者に割り当てられた最近の更新を見ましたが、どうなるか見てみましょう。 はじめに こんにちは！私はKitsumedです。ShizukuベースのアプリケーションであるShizukuCallRecorderの開発者です。お察しの通り、私はこの変更の影響を受けるでしょう。明らかに、ループバック接続を妨げない方法で彼らが進めることを望みます。 私自身について簡単に話すと、私は自分の障害に対処するためにShizukuCallRecorderを作成しました。それなしでもやっていけますが、それがある方がはるかに簡単です。 私のユースケースは非常にユニークだと言えるでしょう。Redditで見つけたこの人（故人の愛する人のボイスメールを保存するために私のアプリケーションを使用した）のように、他の珍しいユースケースも発見し続けています。 Androidでの通話録音は複雑なトピックです。無数のユーザーリクエストがあり、Android 11で機能を追加しようとした公式の試みが後にキャンセルされ、多くのクローズドソースでプライバシーを侵害するアプリケーションが回避策を使用しています。 私は、多くの障害を持つユーザーが、より簡単な日常生活のためにプライバシーを犠牲にしなければならないと聞いていました。それこそが、人々がトレードオフについて話すときに意味することだと思います。 OEMが、法的に必要とされていない場所でさえ、「この通話は録音されています」のようなオーディオ警告を強制することについては、私に話させないでください。人々はそれに良く反応しません。通話を録音している理由を説明しても、悪い印象を与えます。正直に言って、私も良く反応しないでしょう。 ほとんどの皆さんは、Shizukuのより「パワーユーザー」な使い方をしているか、あるいは開発タスクのためにループバックADBを使用していることでしょう。私もそれらを行いますが、私のユニークなユースケースの1つを指摘したかったのです。 さて、本題に戻りましょう。提案されている変更が何であるかを説明する前に、技術に詳しくないユーザーのためにADBとは何かを説明します。 ADBとは？ ADB、またはAndroid Debug Bridgeは、Googleが開発者向けにAndroidデバイスで開発者向けの作業を行えるように作成したプロトコルです… 基本的に、それは私たちに高いレベルの権限を与え、電話やアプリケーションの動作をテストするための多くの機密性の高いコマンドへのアクセスを提供します。開発者やパワーユーザーにとって役立つものです。 ADBは元々USB接続で動作するように設計されていましたが、後に動作方法を拡張しました： USB：オリジナルの方法。ADBはUSBケーブルを介して直接通信します。 TCP/IP：IPアドレスとポート（通常はポート5555）を使用してネットワーク経由でADBを実行する方法として導入されました。接続はプレーンテキストでADBトラフィックを運び、認証としてYES/NOプロンプトを提供します。アクティブなADB接続が確立された後にのみ有効化できます。 ワイヤレスデバッグ（Wifi 1.0/2.0）：Android 11で導入され、レガシーTCP/IPワークフローを改善することを目指しています。ペアリングコードまたはQRコードを使用してコンピューターとデバイスをペアリングする必要があり、その後、後続のADBセッションのために認証および暗号化された接続を確立します。有効化するためにアクティブなADB接続は必要ありません。 デバイス上でのADB接続とは？ ADBは元々2つのデバイス（簡略化された説明）で使用されることを意図していました：デバッグされるAndroidデバイスはADBデーモン（ADBD）を実行し、別の開発者マシンはADBクライアントを実行します。しかし、実際には、このセットアップは常に便利ではありません。一部の開発者はAndroidデバイスから直接作業しており、2台目のマシンにアクセスできません。 これにより、デバイス上でのADB（これは公式の用語ではありません）が使用されるようになりました。Termuxのようなターミナルエミュレータを使用すると、開発者はADBクライアントを電話上で直接実行し、ADB TCP/IPまたはワイヤレスデバッグを使用してローカルデーモン（ADBD）サーバーへの接続を確立できます。クライアントとサーバーの両方が同じデバイス上で実行されているため、接続はループバックアドレス（127.0.0.1）を介して行われます。これが私がデバイス上でのADBと呼ぶものです。 これはADBが意図されていた使用方法と比較するとニッチなユースケースですが、MuntashirAkonによるlibadb-androidやRikkaAppsによるShizukuのようなプロジェクトの作成につながりました。これらのプロジェクトや他の多くのプロジェクトは、開発者やパワーユーザー向けの幅広いツールを作成した大規模なオープンソースコミュニティを生み出しました。 提案されている変更 Google IssueTrackerに、開発者がADBD（ADBサーバーデーモン）がリッスンするインターフェースを選択できるようにする新しい機能が追加されました。 この機能は、ワイヤレスADB認証プロセスを完全にバイパスできたCVE-2026-0073として特定された重大なセキュリティ問題を受けて提案されました。この問題で提案されていることは、実際には良いアイデアです。 現在、ADBDは電話が接続されているすべてのネットワークで利用可能になっています。この機能リクエストは、開発者が選択されるインターフェースを選択できるようにし、露出を減らすことを求めています。 問題 問題は、ADBの主要メンテナーの一人からの応答にあります： sa…@google.com： 接続 localhost も、アプリがそのソケットをadbdに接続して権限を昇格させるエクスプロイトの原因となっています。 常にwifiインターフェース wlan0 のみにバインドすることを許可するのはどうでしょうか？ ここで、従業員がwifi接続のインターフェースであるwlan0のみを許可することについて話していることがわかります。そうすると、デバイス上でのADB、VPN経由のADB、イーサネット経由のADB、およびその他の多くのユニークな開発者のセットアップなど、多くのものが壊れてしまいます。 私がここで見るもう一つの問題は、「デバイス上でのADB」に対する彼らの現在のスタンスです。彼らのコメントは、デバイス上でのADBは主に悪意のあるアクターが権限昇格に使用できるエクスプロイトと見なされていることを示唆していますが、デバイス上でのADBには多くの正当な用途があります。開発者自身がコンピューターにアクセスできない場合に使用します。 確かに権限昇格に使用できるかもしれませんが、「悪意のある」アプリケーションは単独では実行できません。それには、人間が実行しなければならない複数のアクションが必要です。 なぜデバイス上でのADBは悪意のあるアクターによって実際には使用されないのか 悪意のあるアプリケーションは、デバイス上でのADB接続を使用して権限昇格を実行できます。H