crcctcpr/android-call-audio-injection

# 已 root 的 Android 手机能向您的实时通话中注入声音吗？ **简短回答：是的——这是一篇从防御角度探讨其原理及影响的文章。** 在已 root 的 Qualcomm Android 设备上，原本*理应*将普通应用音频隔离在蜂窝语音路径之外的边界是可以被绕过的。一个拥有 root 权限运行的应用可以将合成音频——例如 AI **文本转语音**——路由到**实时通话的上行链路**中，因此**远端用户听到的声音就像真人在对着麦克风说话一样。** 我在自己的设备上证实了这一点，并由真实通话另一端的人类听众进行了验证。 本文档记录了该**发现及其安全影响**。文中特意**没有提供操作指南**：确切的调用路由、设备/输出标识符、使其生效的进程调用细节以及自动化流水线均**被隐去**（参见[负责任的披露](#responsible-disclosure-why-theres-no-poc)）。 ## 结论（如实陈述） - **确实可行。** 预录音频（神经 TTS，8 kHz 单声道）被注入到实时蜂窝通话的上行链路中，并且**被远端手机清晰听到**，该结果可靠，在多天的多次通话中均得到验证——包括一段长达数分钟的语音留言。 - **需要 root 权限。** 这不是一种远程漏洞利用，普通沙盒应用也无法触及。root 权限要求是其作为缓解措施的边界（更多信息见[防御分析](docs/defensive-analysis.md)）。 - **具有平台特异性。** 已在 Motorola Moto G 2023（Qualcomm Bengal，Android 13）上得到验证。该机制依赖于 Qualcomm 的音频路由路径；在不同 SoC/供应商上表现会有所不同。 ## 问题源头（良性的使用场景） 这项研究源于一个普通的个人自动化目标：让我自己的助手**向我的手机拨打警报和提醒电话**——用语音呼叫我，提示*“一个监控警报需要您的关注，”* 或读出日程提醒——让重要的事情通过**电话**传达给我，而不是变成又一条被静音的通知。正是因为想让设备端助手真正*在通话中说话*，才让我深入探究了音频底层架构。 （对于生产环境的构建，带有文本转语音功能的 telephony/VoIP API 是更好、更可靠的工具；而设备端路径则是自包含、离线、零成本的选项。）其良性起源并没有削弱下文所述的安全相关性：**在受损设备上，针对第三方使用同样的能力，这就是一种欺骗手段**——这正是为什么该边界及其被破坏的方式值得被记录下来的原因。 ## 为什么这很重要（威胁模型） 大多数人——以及许多移动威胁模型——都假设应用软件根本*无法*将音频放入电话通话的上行链路；因为通话归 modem 所有。在已 root 或**受损**的设备上，这种假设就不成立了。具体而言，拥有 root 权限的攻击者（或恶意/被劫持的设备端助手）可以： - **向实时通话中注入极具欺骗性的合成语音**，无论是设备主动拨出还是接听的通话，都能让远端用户误以为他们在和真人交谈——这是实施**语音钓鱼、冒充和社交工程欺诈的基础手段**，且在现代语音克隆技术的加持下威胁更大。 - 在此过程中**屏蔽真实的麦克风**，使通话听起来更加清晰自然。 - 将其与设备端 AI 结合，实现**自主**驱动——这正是此类能力的发展趋势。 随着设备端和云**AI 语音代理**的激增，“软件能否触及通话的音频路径？”已成为了移动攻击面中真实存在的一部分。这项研究表明：在已 root 的 Qualcomm 设备上，**答案是肯定的**——因此，真正保护用户的实际上是设备的完整性（而不是通话 API）。 ## 通话音频*理应*如何被隔离 在 Qualcomm Android 设备上，播放音频和蜂窝*通话*音频被刻意分离开来： ``` App ─> AudioTrack ─> AudioFlinger ─> AudioPolicyManager ─> local outputs (earpiece / speaker / media) cellular voice path (owned by the modem, not Android): mic ─> ADSP voice TX ─> ┤ modem ├ ─> remote party (uplink / TX) ``` `AudioPolicyManager` 将普通应用音频仅路由到**本地输出设备。** 即使是请求使用语音通话流或 VoIP 风格用途的应用，也只能获取本地扬声器——*而不是* modem 上行链路。上行链路的音频来自麦克风，并通过正常应用音频永远不会涉足的 **ADSP 内部语音路径**馈入。这种隔离正是安全边界所在。 这里有一个供应商的例外情况：Qualcomm 的音频策略定义了一个**未公开的“通话中音乐”输出**（旨在用于运营商的等待音乐/回铃音等），它指向 telephony-TX 设备。在正常使用中，普通应用是无法访问它的。**此处的发现是，从 root 上下文中，该路径可以被用来将任意应用音频传输到 modem 上行链路**——这违背了该边界本应具备的隔离行为。 *有关如何选择和驱动该路径的具体细节已被隐去。* ## 哪些方法**不起作用**（以及为什么边界通常能保持稳固） 一长串“显而易见”的方法都无法触达上行链路——它们只能在本地播放，被 ADSP 的回声消除功能滤除，遇到 HAL 设备锁，或者根本没有连接到 modem 路径。这些阴性结果（在安全的前提下）记录在 [`docs/approaches-that-fail.md`](docs/approaches-that-fail.md) 中。它们之所以重要，是因为它们表明该边界对于随意的尝试具有鲁棒性；而真正可行的路径不仅需要 root 权限，**而且**还需要一种并不直观的、耗时数月才摸索出的调用方式——这绝不是普通应用偶然就能碰对的。 值得注意的是，某些尝试会使框架**报告成功，但实际上并没有任何音频传达到远端用户。** 这种*框架报告的路由情况*与*实际情况*之间的脱节是移动音频领域反复出现的陷阱——这也正是为什么如果没有真人在真实通话中进行确认，那些天真地宣称“成功了”的说法（包括我早先的一个版本）就不能被轻信的原因。 ## 防御分析 蓝队视角的审视——包括谁面临风险、需要注意什么、如何缓解以及 AI 语音代理的角度——记录在 **[`docs/defensive-analysis.md`](docs/defensive-analysis.md)** 中。简要总结如下： - 真正的保护措施是**设备完整性**——这需要 root 权限，因此任何保持设备不被 root/不受损的手段（如验证启动、证书认证、MDM 状态监控、应用完整性检查）才是起决定性作用的控制措施。 - 应将**“应用音频进入通话上行链路”**纳入已 root/受损设备的威胁模型中，特别是对于高保障级别的语音工作流（如银行业务、高管通信）以及被授予了电话访问权限的 AI 助手。 ## 负责任的披露（为什么没有提供 PoC） 本文档刻意省略了可工作的漏洞利用代码。这项能力——在静音麦克风的条件下，将合成/AI 音频极具欺骗性地播放到真实人类的实时通话中——直接就能被用于语音钓鱼和冒名顶替欺诈，因此提供一份可以直接复制使用的配方只会弊大于利。本文公开的只是该绕过**方式的存在及其形式，以及相关的防御影响**，而不是具体的操作细节。 由于该技术**需要对您已经掌控的设备拥有 root 权限**，因此它不构成可远程利用的漏洞，也没有处于风险中的第三方系统需要协调披露的时间表。如果供应商（Qualcomm / Google / Motorola）为了强化防御希望获取完整的技术细节，我很乐意私下分享。 ## 研究完整性 本项目曾两次改变了结论。诚实的记录如下： 1. 一个早期版本基于框架报告了 telephony-TX 路由而**宣称成功**。 2. 后来的一项系统性重新测试**似乎失败了**——并且当时记录下的结论是“这行不通”。 3. 通过在**真实通话中进行实际情况倾听**化解了这一矛盾，并确立了真实的结论：**它是可行的**，但只能通过早期测试未能持续使用的特定调用方式来实现。 经验教训——*即使框架提示“已路由”，也不能证明音频已经通过手机传输出去*——这适用于任何移动音频、检测或控制验证工作：**用实际情况来闭环验证。** ## 道德与范围 - **自己的硬件，自己的 SIM 卡，自己的二号线路。** 每次测试通话都是从我的设备拨向我控制的号码。没有任何第三方参与或成为目标；也没有记录任何其他人的信息。 - **不提供武器化工具。** 这是一篇关于边界的防御性分析文章，而不是一个工具。 - **不披露任何运营商/供应商机密**——仅公开在零售设备上观察到的框架行为。 ## 法律、许可与合规使用 - 授权的、针对个人设备的研究，测试均在个人拥有的已 root 设备上进行。没有拦截他人的通信；没有对任何系统进行未经授权的访问（不涉及违反 CFAA/反窃听法）。 - 对个人拥有的手机进行 root 以进行合法研究，符合现行的 DMCA §1201 智能手机豁免条款。 - 不重新分发任何固件、供应商 blob 或平台二进制文件。 - **非法律建议**——这是为个人研究发表而进行的善意审查；法律因管辖区而异。 **许可：** 文档遵循 **CC BY 4.0** 协议；任何代码遵循 **MIT** 协议（参见 [`LICENSE`](LICENSE)）。 ## 敏感信息处理 已移除个人昵称/账号、测试电话号码、内部项目/助手代号、个人文件路径、运营商会话标识符以及完整的基带/固件分析。确切可行的调用方式、标识符和自动化流水线均被刻意隐去（如前文所述）。保留了通用的公开硬件标识符（型号、SoC、操作系统版本）以提供背景信息。 *基于个人拥有硬件的原创研究。作为防御性案例研究发表；不包含漏洞利用代码。*

标签：安卓, 目录枚举, 移动安全, 防御分析, 防御加固, 音频路由, 高通平台