当电视在熄屏后仍在“倾听“：拆解智能终端侧信道采集的架构陷阱-北京尧图网络

我是AI时代的无业游民我游荡在现实与意念之间当电视在熄屏后仍在倾听拆解智能终端侧信道采集的架构陷阱背景与痛点一个典型的家庭网络拓扑里智能电视往往是权限最高、审计最弱的那个节点。它常年在线、持有麦克风与摄像头、能扫描局域网、还搭载了一个几乎不受用户控制的固件更新通道。当安全研究者发现某些型号的电视在屏幕关闭状态下依然持续采集音频、并主动探测同网段设备时问题的性质已经不再是某个 App 越权而是整机层面的数据采集管线脱离了用户可观测的状态机。这件事的工程代价是什么对用户是隐私边界被静默突破对开发者是一个更普遍的教训任何低功耗待机状态都不等于功能停止。嵌入式系统里关机和熄屏是两个完全不同的语义。熄屏通常只切断显示子系统的供电或背光主 SoC、协处理器、网络栈仍在运行。如果音频前端的 DMA 通道没有被显式关闭采集链路就会继续把 PCM 数据写进环形缓冲区等待某个后台服务消费。真正棘手的地方在于这类行为往往不是单一 bug而是多个合理设计叠加后的副作用。语音唤醒需要常驻监听、内容推荐需要观看行为画像、设备互联需要局域网发现——每一条单独看都有产品理由合在一起就构成了一个用户无法关闭的采集面。方案设计要理解为什么这样设计得先看厂商在架构上的几个关键取舍。取舍一唤醒词检测放在哪里常见方案有三类主 SoC 软件检测、专用低功耗 DSP、以及外挂 always-on 协处理器。软件检测成本最低但功耗高DSP 方案如 Cadence Tensilica HiFi 系列能在毫瓦级持续运行代价是算法灵活性差。多数中高端电视选了 DSP 常驻主 SoC 按需唤醒的混合方案。问题就出在DSP 常驻这个前提——它的供电域独立于屏幕熄屏对它没有任何影响。取舍二局域网发现协议用什么mDNS/DNS-SD 是标准答案但它的组播特性会暴露设备存在感。替代方案是 SSDPUPnP 的发现层或私有 UDP 广播。很多厂商为了兼容性同时开启多套导致熄屏后仍在周期性发包。取舍三音频数据落盘还是流式上传出于带宽和成本考虑通常先本地环形缓冲命中唤醒词或触发条件后再上传。这个设计本身合理但它意味着原始音频在本地是存在的哪怕只有几秒。维度纯软件检测专用 DSP 常驻协处理器方案待机功耗高低极低熄屏后仍工作是易被忽视是设计如此是可审计性中低黑盒固件低用户可关闭通常可常被隐藏常被隐藏明确放弃的替代方案是完全依赖主 SoC 在熄屏时断电——这在语音唤醒场景下不可行因为唤醒本身就是熄屏时发生的。所以真正的问题不是要不要常驻而是常驻链路的可观测性和可关闭性。核心实现子节一状态机与电源域的错位问题的根源可以抽象成一个状态机错位。用户视角的状态是ON / STANDBY / OFF而硬件的电源域是Display / SoC / DSP / Network / AudioFrontend。当用户按下遥控器关闭屏幕实际只翻转了Display域其余四个域维持原状。// 伪代码一个典型的、有隐患的熄屏处理voidon_screen_off(void){display_power_down();// 只关显示backlight_disable();// 缺失audio_capture_suspend();// 缺失mdns_announce_stop();// 缺失wake_word_dsp_set_mode(LOW_POWER_ONLY);}看起来能跑线上会炸的点就在这里on_screen_off的语义被实现成了显示关闭而不是用户会话结束。正确的做法是引入一个显式的用户会话状态让采集链路订阅这个状态而不是订阅显示状态。子节二采集链路的可审计性设计要让采集行为可被验证关键是给音频前端加一个硬件级的采集指示与门控。软件层面再优雅也不如一个物理断路的麦克风可靠。工程上可落地的折中是在 ALSA/ASoC 层暴露一个capture_active的 kcontrol并让它与一个不可被固件静默覆盖的 GPIO 指示灯联动。// ASoC 层把采集状态暴露为可观测的 kcontrolstaticconststructsnd_kcontrol_newcapture_led_ctlSOC_DAPM_SINGLE(Capture LED Switch,SND_SOC_NOPM,0,1,0);// 关键DAPM 路由必须在熄屏时真正切断 ADC - DMA 的通路staticconststructsnd_soc_dapm_routeaudio_map[]{{Capture,NULL,MIC},{Capture LED,NULL,Capture},// 采集即亮灯{DMA,NULL,Capture},};这样做的价值在于任何绕过 DAPM 路由的采集都会导致指示灯亮起用户和审计者都能察觉。代价是增加了 BOM 成本和一个 GPIO且需要固件不持有覆盖该路由的特权。子节三局域网探测的收敛对于 mDNS/SSDP 的持续发包思路是让发现服务跟随用户会话状态降级。熄屏后应停止主动 announce仅保留被动响应或干脆进入静默。voidon_user_session_end(void){mdns_set_mode(MDNS_PASSIVE);// 不再主动广播ssdp_stop_advertising();// 保留必要的入站响应避免破坏投屏等已授权功能}这里要明确边界完全关闭发现会破坏手机投屏自动发现这类体验所以取舍是停止主动暴露、保留被动响应。这是一个可辩论的平衡点但至少比熄屏继续广播更符合最小暴露原则。效果验证验证这类改动是否有效不能只看功能是否正常而要看熄屏后的网络与音频行为。可复现的步骤将电视接入一个可控交换机镜像口用 tcpdump 抓取熄屏后 10 分钟的流量统计 mDNS/SSDP 包数量。改动前通常能看到周期性 announce改动后应显著下降。在音频前端串联一个电流探头或直接读取capture_activekcontrol 的状态确认熄屏后 ADC 通路电流归零。用已知的唤醒词与随机语音分别测试确认唤醒功能未被破坏——这是防止为了隐私把功能砍废的回归测试。对比数据上合理的预期是熄屏后组播包从每分钟数次降到仅被动响应音频前端待机电流从数十毫安降到个位数毫安。如果改完发现投屏发现变慢说明被动响应保留得不够需要调整而非回退。边界与演进这套思路的局限很明确。第一它依赖固件不持有更高权限——如果厂商在 TrustZone 或独立协处理器里跑采集逻辑Linux 侧的 DAPM 路由根本管不到。第二物理指示灯可以被拆掉或遮挡它不是密码学保证。第三完全静默的局域网发现会牺牲部分互联体验这是一个产品决策而非纯技术决策。不适用的场景包括需要 7x24 语音唤醒的医疗或安防设备此时常驻采集是功能刚需重点应转向数据本地化与加密而非关闭采集。下一步的演进方向一是把采集状态纳入可远程证明的度量如基于 TPM 的启动时度量让用户能验证固件没有偷偷开启额外通路二是推动发现协议支持静默模式的标准扩展让被动响应成为默认。核心始终是同一个问题在用户看不见的状态下系统到底还在做什么以及用户能否验证它没做别的。

当电视在熄屏后仍在“倾听“：拆解智能终端侧信道采集的架构陷阱

相关推荐

TBTool新版实测：零代码构建数据分析看板的免费平台

技术项目文档三要素：标题、关键词与摘要的写法

重新认识Selenium：从WebDriver机制到自动化测试的稳定落地

更多资讯

CE318太阳光度计数据处理：AOD与WV反演实战指南

C++排序选型指南：sort、stable_sort与partial_sort

环境模拟中的木马程序分析：从渗透测试到防御反推

练得够不够狠？openGym的RIR/RPE努力度评分及统计功能详解

样章-第01讲-MCU选型方法论

SpringBoot+Vue私人诊所管理系统：协同过滤推荐算法实战解析

今日更新

再见，SSE！你好，Streamable HTTP！轻松开发 Streamable HTTP MCP Server 并接入 TaoToken

工业软件标准化路线图：国产替代的落地施工图

VCMI安卓版实操指南：原生运行英雄无敌3的3步技术落地

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？