Android 或将限制设备端 ADB 连接
早期预警#
在深入探讨之前,请注意:这不是谷歌的官方公告。 相反,这是基于谷歌 IssueTracker 上一个近期仍在进行的功能请求,其中一位核心 ADB 维护者(谷歌员工)在评论中提到了限制设备端 ADB 连接,以防止“恶意行为者”。
在你放下手头的事直奔那个 IssueTracker 讨论串之前,请仔细阅读以下内容:
如果你打算去 IssueTracker 只是为了发一些低质量的评论(比如 “嘿,别这么做,我需要 Shizuku!”)、抱怨垄断或人身攻击,我强烈建议你不要这么做。 刷屏只会导致谷歌开发者锁定该问题、忽略有价值的社区反馈,或者完全停止公开分享此次变更的进展。
我认为这样的改动对谷歌有利,因为它与谷歌新的 侧载变更 方向一致,但我并不认为这就是当前的意图。这背后有一个真正合理的理由,我认为可以采取两种不同的做法。我们将在本篇博文中讨论。
你可以如何帮助:
- 如果你有独特的使用场景: 如果你直接受到影响,并且能写出详细、有建设性的留言,说明你的工作流程、提供链接,或提出技术方案/折中办法,请务必在谷歌问题中分享你的反馈。
- 如果你的使用场景已被提及: 无需重复。只需点击谷歌 IssueTracker 右上角的 +1 按钮 让谷歌知道你受影响,并开启通知以关注讨论进展。
我犹豫是否要写这篇博文,因为我担心它会加重那几位 ADB 开发者的负担。我不确定是该再等等看看情况,还是再拖一拖看看他们采取什么做法。等太久也可能不好……写这篇文章时,我不确定它何时(或是否)会发布。我最近看到了一些任务分配更新,交给了之前负责 ADB 的主要开发者,所以我们会看看接下来会发生什么。
引言#
你好!我是Kitsumed,ShizuCallRecorder(一款基于Shizuku的应用)的开发者。你可能已经猜到,这个变化会影响到我。显然,我非常希望他们不会以阻止回环连接的方式推进此事。
简单介绍一下自己:我开发ShizuCallRecorder是为了帮助自己应对一些身体上的不便。没有它我也能凑合,但有了它方便得多。
可以说我的使用场景非常独特,而且我不断发现其他不寻常的用例,比如Reddit上的这位用户,他用我的应用保存了已故亲人的语音留言。
Android上的通话录音是个复杂的话题。用户诉求层出不穷,官方曾在Android 11中尝试添加此功能但后来取消,还有大量闭源、侵犯隐私的应用通过各种变通方案来实现。
我曾听说许多残障用户不得不以隐私换取更便利的生活。我想这就是人们所说的权衡吧。
更别提那些在法律不要求的地方强制播放“此通话正在录音”语音提示的OEM厂商了。人们通常对此反应不佳——即便你解释了录音原因,也会留下不好的印象。说实话,我可能也一样反感。
我相信你们大多数人使用Shizuku都更偏向“高级用户”用途,或者用回环ADB完成开发任务。我也做这些,但我想强调的是我那个独特的用例。
好了,回到正题。在解释这个拟议的变更之前,我先为不太懂技术的用户介绍一下ADB是什么。
什么是ADB?#
ADB,全称Android Debug Bridge(安卓调试桥),是Google创建的一种协议,让开发者可以在Android设备上执行各种开发操作……
简而言之,它赋予我们高级权限,能执行大量敏感命令,用于测试手机和应用的运行情况,对开发者和高级用户来说非常实用。
ADB 最初设计为通过 USB 连接工作,但后来扩展了连接方式:
- USB:原始方式,通过 USB 线直接通信。
- TCP/IP:通过 IP 地址和端口(通常为
5555)在网络中运行 ADB。连接以明文传输 ADB 流量,身份验证仅提供 YES/NO 提示。必须已有活跃的 ADB 连接才能启用。 - 无线调试(Wifi 1.0/2.0):Android 11 引入,旨在改进传统的 TCP/IP 工作方式。需要用配对码或二维码将电脑与设备配对,之后建立经过认证和加密的连接,用于后续 ADB 会话。启用时无需已有活跃的 ADB 连接。
什么是设备端 ADB 连接?#
ADB 最初设计用于两台设备(简化说明):被调试的 Android 设备上运行 ADB 守护进程(ADBD),另一台开发机上运行 ADB 客户端。但在实际使用中,这种配置并不总是方便。有些开发者会直接在 Android 设备上工作,没有第二台机器可用。
因此出现了设备端 ADB(非官方术语)。通过 Termux 这类终端模拟器,开发者可以在手机上直接运行 ADB 客户端,并通过 ADB TCP/IP 或无线调试连接到本地守护进程(ADBD)。由于客户端和服务端都在同一设备上,连接通过回环地址(127.0.0.1)建立。这就是我所说的设备端 ADB。
虽然这相对于 ADB 的典型用途来说比较小众,但它催生了像 MuntashirAkon 的 libadb-android 和 RikkaApps 的 Shizuku 这样的项目。这些项目与其他许多项目一起,形成了一个庞大的开源社区,为开发者和高级用户提供了大量工具。
拟议的变更#
Google IssueTracker 上出现了一个新功能,允许开发者选择 ADBD(ADB 服务器守护进程)监听哪个网络接口。
这一功能是在一个被标记为 CVE-2026-0073 的重大安全问题之后提出的,该问题允许完全绕过无线 ADB 的认证过程。这个 issue 中提出的方案其实是个不错的主意。
目前,ADBD 会在手机连接的每个网络上暴露自己。这个功能请求要求让开发者选择监听哪个接口,从而减少暴露面。
问题所在#
问题在于 ADB 核心维护者之一给出的回应:
localhost 连接同样曾是漏洞利用的来源,应用程序通过该 socket 连接 ADBD 来提升权限。
如果我们限制只绑定到 WiFi 接口
wlan0呢?
这里可以看到,这位员工提到了只允许 wlan0(WiFi 连接接口)。这样做会破坏很多功能:设备端 ADB、通过 VPN 的 ADB、通过以太网的 ADB,以及许多其他开发者特有的配置。
我看到的另一个问题是,他们目前对“设备端 ADB”的立场似乎有些偏颇。他们的评论暗示,设备端 ADB 主要被视为恶意攻击者提升权限的漏洞利用工具,但实际上设备端 ADB 有很多合法用途。开发者自己在无法使用电脑时也会用到它。
虽然 ADB 确实可以用来提升权限,但一个“恶意”应用单靠自己是做不到的。它需要一系列必须由人类手动完成的操作。
为什么设备端 ADB 实际上很少被恶意利用#
恶意应用可以通过设备端 ADB 连接进行权限提升。但问题在于,它无法自己建立这个连接。
为了说明这一点,我结合之前在 IssueTracker 上的评论,列举了几个场景中恶意行为者会面临的主要限制。
场景一:普通 Android 用户#
- 你安装了一个恶意应用。
- 此时 ADB 处于禁用状态,ADBD 未运行,应用也没有
WRITE_SECURE_SETTINGS权限(该权限必须通过 ADB 手动授予)。根本无法尝试利用。
- 此时 ADB 处于禁用状态,ADBD 未运行,应用也没有
场景二:Android 11+ 开发者使用无线 ADB#
- 你安装了一个恶意应用。
- 你开启了 USB 调试,从而启动了 ADBD。
- 你开启了无线 ADB。此时 ADBD 已在手机上运行,并在所有网络接口上监听。
- 应用需要完成一次性配对流程。这要求用户手动从设置中获取一次性代码并输入。根本无法尝试利用。
场景三:开发者使用 TCP/IP 方式的 ADB#
- 你安装了一个恶意应用。
- 你开启了 USB 调试,启动了 ADBD。
- 你通过 USB ADB 连接并启用 TCP/IP 模式,然后拔掉 USB 线。
- ADBD 继续运行,并在所有网络接口上监听。
- 应用发起连接请求,屏幕上会弹出授权提示。如果用户选择否,连接被拒绝。任何静默利用的尝试都不可能成功。
结论#
在正常情况下,恶意攻击者无法获得 ADB 连接,只有在开发者主动在设备上使用 ADB 时才可能,因为恶意攻击者无法自行启动 ADBD。
然而,回到类似 CVE-2026-0073 的场景,漏洞利用在场景 2 和场景 3 中将成为可能,但前提是用户已手动启用 USB 调试。至于场景 3,还需要开发者手动启用 TCP/IP。我能理解默认阻止回环连接的动机,但无法认同完全禁止它。
默认阻止和永久阻止是有区别的。我认为这应该是一个用户可以通过持久化设置来关闭的选项。具体来说,就是一个重启后依然有效的开关(否则会使得像 Shizuku 这样的工具无法使用),而且最好不能被第三方应用读取。否则,每当银行应用或游戏检测到设备端 ADB 可用时,开发者就得反复关闭它。不过,一旦应用被手动授予了 WRITE_SECURE_SETTINGS 权限,这部分问题就可以绕开。
我认为,以“人类可以手动操作允许它”为由而禁止它,这个理由很牵强。人类也可以手动将恶意应用设为设备管理员或授予无障碍权限,但我们并没有因此删除这些功能。
我认为这应该被视为一种可接受的风险:关闭这项安全功能虽然启用了设备端调试,但同时也让设备在未来面临极低的漏洞风险。在我看来,功能与风险的权衡是合理的,因为确实存在真实的合法用途。
虽然可能并非初衷,但设备端 ADB 确实催生了一个小众的开发者与高级用户工具生态,包括 App Manager、libadb-android、Canta、aShell、ShizuWall、ShizuCallRecorder 和 Shizuku 等项目。最后,我想提一下我在 《What Is Shizuku? How Does It Work? Security Implications?》 一文中做的结论,当时我开玩笑说:
我的收尾想法是:我迫不及待想看看他们如何为在非模拟器设备上禁用基于 TCP/IP 的回环 ADB 并开始要求 Google 账号找借口……
嗯,我猜他们确实可能禁用回环 ADB。哈……看来我几乎百分百说对了。如果你是个技术用户,欢迎在 这个 issue 里反馈。别忘了之前的 预警。
显示评论需要 JavaScript 才能加载评论。仅当您按下按钮时才会加载 JavaScript 小部件。本博客使用 Giscus 通过 GitHub Discussions 管理评论。(隐私政策在此)。如果您不想允许第三方应用评论,也可以直接访问 GitHub 上的讨论:点击这里。