Android 可能很快限制设备端 ADB

# Android 可能很快限制设备端 ADB，影响 Shizuku、libadb 和开发者 来源：https://kitsumed.github.io/blog/posts/android-may-soon-restrict-on-device-adb/ ## 早期警告 在深入之前，请注意：**这不是谷歌的官方公告。** 相反，**这是基于近期 Google IssueTracker 上一个持续进行的功能请求**，其中一个核心 ADB 维护者（谷歌员工）的评论提到了限制设备端 ADB 连接，以防范“恶意行为者”。 在你放下手头的事情去该 IssueTracker 线程之前，**请仔细阅读以下内容：** 如果你打算去 issue tracker 只是为了发表低质量评论（例如*“嘿，别这样做，我需要 Shizuku！”*）、抱怨垄断或进行侮辱，**我强烈建议你不要这样做。** 在帖子中刷屏只会导致谷歌开发者锁定该 issue、忽略有价值的社区反馈，或完全停止公开分享关于此变更的更新。 我认为这样的变更可能对谷歌有利，因为它与其新的侧载变更（https://keepandroidopen.org/）方向一致，但我并不认为这就是这里正在发生的事情。**这背后有真实、合理的理由**，我认为可以采取两种不同的方法。我们将在本篇博客文章中讨论。 **你能如何帮助：** - **如果你有独特的用例：** 如果你直接受到影响，并且能够撰写详细、建设性的消息，解释你的工作流程、提供链接或技术解决方案/折衷方案，**请务必在 Google issue 中分享你的反馈。** - **如果你的用例已被提及：** 你无需重复。只需点击 Google IssueTracker 右上角的 **+1 按钮**，让谷歌知道你受到影响，并开启通知以随时了解讨论进展。 我对于写这篇博客文章有些犹豫，因为我担心这会给少数几个负责 ADB 的开发者带来过多负担。我不确定是应该再等一等，看看情况发展，还是再等久一些，看看他们会采取什么方法。等太久也可能不好……截至撰写本文时，我不确定这篇文章何时/是否发布。我看到最近有一些关于任务分配的更新，这些任务被分配给了之前负责 ADB 的主要人员，所以我们拭目以待。 ## 引言 嗨！我是 Kitsumed，ShizuCallRecorder（https://github.com/kitsumed/ShizuCallRecorder）的开发者，这是一个基于 Shizuku 的应用程序。你可能已经猜到了，我会受到这次变更的影响。显然，我非常希望他们不要以阻止回环连接的方式推进此事。 简单介绍一下我自己，我开发 ShizuCallRecorder 是为了帮助自己的一些残障问题。没有它我也可以生活，但有它会方便很多。 你可以说我的用例非常独特，而且我不断发现其他不常见的用例，比如 Reddit 上的这位用户（https://www.reddit.com/r/fossdroid/comments/1uvl4fx），他用我的应用保存了已故亲人的语音邮件。 Android 上的通话录音是一个复杂的话题。有无数用户请求，官方曾在 Android 11 中尝试添加此功能但后来取消，以及许多闭源、侵犯隐私的应用程序使用变通方法。 我过去常听说许多残障用户不得不牺牲隐私来换取更轻松的日常生活。我想这就是人们谈论那些权衡时所指的意思。 更别提那些 OEM 厂商在并未法律要求的地方强制添加音频警告，比如“此通话正在录音”。即使你解释为什么录音，人们通常反应也不好，会留下坏印象。老实说，我可能也会反应不好。 我相信你们大多数人使用 Shizuku 有更多“高级用户”的用途，或者使用回环 ADB 进行开发任务。我也做这些，但我想指出我其中一个独特的用例。 好了，回到主要话题。在我解释拟议的更改是什么之前，我将为非技术背景的用户解释什么是 ADB。 ## 什么是 ADB？ ADB（https://developer.android.com/tools/adb），全称 **A**ndroid **D**ebug **B**ridge，是谷歌创建的一种协议，让开发者可以在 Android 设备上做开发相关的事情…… 基本上，它赋予我们高级权限，让我们能够访问许多敏感命令，以测试手机和应用程序的行为。这对任何开发者或高级用户来说都是有用的工具。 ADB 最初设计为通过 USB 连接工作，但后来扩展了工作方式： - **USB**：原始方式。ADB 通过 USB 线直接通信。 - **TCP/IP**：作为一种通过网络使用 ADB 的方式引入，使用 IP 地址和端口（通常端口为 `5555`）。连接以明文传输 ADB 流量，并提供 YES/NO 提示作为身份验证。**只有在已有活跃 ADB 连接的情况下才能启用。** - **无线调试（Wifi 1.0/2.0）**：在 Android 11 中引入，旨在改进传统的 TCP/IP 工作流程。它需要用户使用配对码或二维码将电脑与设备配对，然后为后续 ADB 会话建立经过身份验证和加密的连接。**不需要已有活跃的 ADB 连接就能启用。** ### 什么是设备端 ADB 连接？ ADB 最初设计用于两台设备（**简化的解释**）：被调试的 Android 设备运行 ADB 守护进程（ADBD），另一台开发者机器运行 ADB 客户端。但在实践中，这种设置有时并不方便。一些开发者直接在他们的 Android 设备上工作，没有第二台机器可用。 这导致了 **设备端 ADB**（这不是官方术语）的使用。通过使用终端模拟器，如 Termux（https://github.com/termux/termux-app），开发者可以在手机上直接运行 ADB 客户端，并通过 **ADB TCP/IP** 或 **无线调试** 建立到本地守护进程（ADBD）服务器的连接。由于客户端和服务器都在同一设备上运行，**连接通过回环地址（`127.0.0.1`）建立**。这就是我所说的设备端 ADB。 虽然与 ADB 的预期使用方式相比，这是一个小众用例，但它催生了像 MuntashirAkon 的 libadb-android（https://github.com/MuntashirAkon/libadb-android）和 RikkaApps 的 Shizuku（https://github.com/rikkaapps/shizuku）这样的项目。这些项目及许多其他项目，形成了一个庞大的开源社区，为开发者和高级用户提供了广泛的工具。 ## 拟议的更改 Google IssueTracker 上创建了一个新功能（https://issuetracker.google.com/issues/526109803），允许开发者选择 ADBD（ADB 服务器守护进程）监听哪个接口。 这个功能是基于一个被识别为 CVE-2026-0073（https://nvd.nist.gov/vuln/detail/CVE-2026-0073）的重大安全问题提出的，该漏洞允许完全绕过无线 ADB 身份验证过程。这个 issue 中提出的想法实际上很不错。 目前，ADBD 会在手机连接的每个网络上暴露自己。**这个功能请求要求让开发者选择监听哪个接口，从而减少暴露面。** ## 问题所在 问题在于 ADB 核心维护者之一的回复： **[email protected]**（https://issuetracker.google.com/issues/526109803#comment3）： > 连接到 localhost 也是应用程序利用该 socket 向 adbd 提升权限的漏洞来源。如果我们始终限制只绑定到 wifi 接口 `wlan0` 怎么样？ 在这里，我们看到这位员工只提到允许 **wlan0**，即 WiFi 连接的接口。这样做会破坏很多功能，包括设备端 ADB、通过 VPN 的 ADB、通过以太网的 ADB，以及许多其他独特的开发者设置。 我看到的另一个问题是他们目前对“设备端 ADB”的立场。他们的评论表明，设备端 ADB 主要被视为恶意行为者用来提升权限的漏洞，然而设备端 ADB 有很多合法用途。**开发者自己**（https://android-review.googlesource.com/c/platform/packages/apps/Settings/+/4118073）在无法访问电脑时也会使用它。 虽然它确实可以用于提升权限，但一个“恶意”应用程序无法单独做到。**它需要由人类*必须*执行的多个操作**。 ## 为什么设备端 ADB 实际上不被恶意行为者使用 一个恶意应用程序可以利用设备端 ADB 连接进行权限提升。**然而，它无法自己建立这样的连接。** 为了说明这一点，我通过几个场景列出了恶意行为者会遇到的一般限制，类似于我在 IssueTracker 上的评论。 ### 场景 1：普通 Android 用户 1. 你安装了一个恶意应用程序。 - ADB 已禁用。ADBD 没有运行，并且该应用程序没有 `WRITE_SECURE_SETTINGS` 权限，因为该权限必须通过 ADB 手动授予。**无法进行漏洞利用尝试。** ### 场景 2：使用无线 ADB 的 Android 11+ 开发者 1. 你安装了一个恶意应用程序。 2. 你启用了 USB 调试，启动了 ADBD。 3. 你启用了无线 ADB。ADBD 现在在你的手机上运行，并监听所有网络接口。 4. 该应用程序需要执行一次性配对过程。这需要用户手动从设置中获取一次性代码并提供。**无法进行漏洞利用尝试。** ### 场景 3：使用 ADB over TCP/IP 的开发者 1. 你安装了一个恶意应用程序。 2. 你启用了 USB 调试，启动了 ADBD。 3. 你通过 USB ADB 连接启用了 TCP/IP，然后断开 USB 线。 4. ADBD 继续运行并监听所有网络接口。 5. 该应用程序发起连接，屏幕上会出现授权提示。如果用户选择**否**，连接被拒绝。**无法进行静默漏洞利用尝试。** ## 结论 **在正常情况下，恶意行为者无法获得 ADB 连接。** 只有在开发者正在设备上积极使用 ADB 时才可能，因为**恶意行为者无法自己启动 ADBD。** 然而，如果我们回到像 **CVE-2026-0073** 这样的场景，那么在场景 2 和 3 中，漏洞利用会成为可能，**但仅*在*用户手动启用了 USB 调试之后**。至于场景 3，还需要开发者**手动**启用 TCP/IP。我能理解默认阻止回环连接的动机，但不应完全阻止它。 默认阻止和永久阻止是有区别的。**我认为这应该是一个用户可以通过持久设置禁用的选项。** 我的意思是，**一个重启后仍然有效的开关**（*否则会使像 Shizuku 这样的工具变得不切实际*），并且理想情况下，第三方应用程序无法读取。否则，每当银行应用或游戏检测到设备端 ADB 可用时，开发者都必须重新禁用它。不过，一旦应用程序被手动授予 **WRITE_SECURE_SETTINGS**，这部分可以解决。 我认为以“人类可能执行操作来允许它”为由证明阻止它是牵强的。人类也可以将恶意应用程序指定为设备管理员或授予其无障碍权限，但我们并没有因此取消这些功能。 **我认为这应该被视为一种假设的风险**——禁用这样的安全特性会启用设备端调试，同时也使设备暴露于未来罕见漏洞的可能性中。对我来说，这里的特性/风险比例是合理的，因为存在真实、合法的用途。 尽管可能并非初衷，但设备端 ADB 已经促成了一个面向开发者和高级用户的小众工具生态系统，包括诸如 App Manager（https://github.com/muntashirakon/appmanager）、libadb-android（https://github.com/MuntashirAkon/libadb-android）、Canta（https://github.com/samolego/Canta）、aShell（https://gitlab.com/sunilpaulmathew/ashell）、ShizuWall（https://github.com/AhmetCanArslan/ShizuWall）、ShizuCallRecorder（https://github.com/kitsumed/ShizuCallRecorder）和 Shizuku（https://github.com/rikkaapps/shizuku）等项目。 最后，我想提一下我在《什么是 Shizuku？它是如何工作的？安全性影响？》（https://kitsumed.github.io/blog/posts/what-is-shizuku_how-does-it-work_security-implications/）中的结论，我曾开玩笑地说： > 我最后的想法是：**我等不及看他们如何证明在非模拟器设备上禁用 TCP/IP 连接的回环 ADB 是合理的，并开始要求使用 Google 账号……** 好吧，我猜他们可能真的会禁用回环 ADB。嗯……我猜我在这件事上几乎 100% 正确了。如果你是一个技术用户，我邀请你在 issue 中提供反馈，链接在此（https://issuetracker.google.com/issues/526109803）。请不要忘记早期警告（https://kitsumed.github.io/blog/posts/android-may-soon-restrict-on-device-adb/#early-warning）。