跳转至

Analysis of Always-Listening Services on Android

(1) 研究背景与核心问题

  • 现代 Android 设备广泛配备了“始终监听”服务（如关键词唤醒、Now Playing 音乐识别和自适应声音），这些服务通常在专用的低功耗数字信号处理器（DSP）上运行，以监控环境音频
  • 尽管这些服务非常普遍，但它们对用户而言极不透明：用户无法获知何时录音、音频在何处被处理以及如何被使用
  • 现有研究大多关注将数据发送到云端的“完全误激活”现象，却忽略了设备本地的“局部误激活”（local misactivations）问题
    • "局部误激活"是指: 低功耗芯片触发 HostOS 开始处理音频，但事件仅停留在本地，且没有任何指示或通知告知用户

(2) 研究方法: 逆向工程

alt text

  • 由于这些服务运行在主操作系统之外的封闭式 DSP 运行时环境中，常规的动态或静态分析很难直接介入
  • 作者开发了首个系统性的逆向工程方法，包含三个关键步骤：
    • 架构分析: 勾勒 服务的总体架构, 识别操作系统（OS）和 DSP 之间的关键交互（如加载模型、触发回调、获取音频等）
    • 底层函数识别: 利用静态分析工具（如 Ghidra 和 JADX）, 定位处理这些 交互的关键原生库和进程
    • 功能重建：使用动态插桩工具(Frida)截获 运行时行为, 例如提取传输给 DSP 的模型、解码音频格式以及记录捕获的音频内容

(3) 主要发现

  • 模型提取与动态加载：

    • 研究人员成功提取了驱动关键词唤醒（Google Assistant、Bixby）和音乐识别（Now Playing）的机器学习模型。他们发现模型的大小和权重会因设备型号和语言设置的不同而改变
    • 令人意外的是，Now Playing 模型在每次识别出歌曲或用户唤醒屏幕后，都会被频繁地重新加载到 DSP 上

  • 未记录的触发机制与音频捕获：

    • 每次发生局部误激活时，Google Assistant 会在无通知的情况下记录 3 秒的音频，而 Now Playing 会记录 8 秒的音频
    • 发现了未公开的录音触发器：当用户长按电源键试图唤醒 Bixby 时，设备在 Bixby 启动前就开始录制音频（多次按键可累积泄露约 1.5 秒音频）；Now Playing 在手机屏幕被唤醒时也会主动拉取前 8 秒的音频流

  • 局部误激活的频率极高：

    • alt text
    • 针对关键词唤醒模型（Google Assistant），在连续语音环境下，每小时最高可发生 58 次局部误激活。此外，不同语言的误激活率差异显著，例如西班牙语的误激活率是中文的三倍
    • 针对 Now Playing 音乐识别模型，在连续的非音乐环境音（如人群喧闹、节拍声等）下，每小时会发生 18.9 次误激活；即使在录音棚质量的纯语音环境下，每小时也会发生 2.8 次误激活

  • 资源消耗代价：

    • 通过测量发现，局部误激活给设备带来了显著的资源开销
    • 每次误激活会导致设备的功耗比空闲状态增加 18% 至 81%（其中 CPU 消耗占额外功耗的 79.4%）
    • 且每次事件会在应用处理器上消耗 305 到 454 毫秒的 CPU 时间

(4) 结论与意义

  • 该研究揭示了智能手机上“始终监听”服务在设计和实现上的不透明性
    • 证明了: 应用在不通知用户的情况下频繁地记录并处理环境音频
  • 这种行为不仅存在潜在的隐私隐患（与用户的心理预期不符），还带来了可量化的电池和 CPU 消耗
    • 作者强调: 移动设备上的始终监听服务需要更高的透明度，并赋予用户更多的控制权