最近我读到关于 LG 和三星 ACR 追踪的报道：智能电视会提取屏幕上显示的内容（以及音频）的特征，并向厂商服务器发送数量惊人的数据，即便你只是把电视当作普通 HDMI 显示器使用。三星那部分内容让我印象更深：网络上的音频式内容识别，读起来很像电视在“监听”你正在看什么。我客厅里有一台小米电视。我想知道，当我不打开 Netflix 或 YouTube 时，它到底在和谁通信。

于是我把电视接在 Mac 的 Internet Sharing 热点后面，用 Wireshark 抓包，并从 DNS 和 TLS SNI 中列出目标地址。这就是下面的第 1 部分。更有意思的后半部分——第 2 部分——还在我的待办清单上：强制流量走代理，并尝试用 mitmproxy 和 ADB 解密 HTTPS 报文内容。这部分我还没做。等哪天晚上客厅设备空闲、我有空的时候，这就是下一步。

被测设备：Xiaomi MiTV4-ANSM0（DHCP 主机名）。电视在抓包局域网中的 IP：192.168.2.2。抓包文件已链接在表格中，你可以自行打开查看。

我的第一直觉是错的。我连在家庭 SSID 上，把 Wireshark 指向 Wi-Fi 接口，以为能看到电视的流量。普通 AP 只会把单播转发到真正的目的地。笔记本永远收不到那些 HTTPS 会话。你必须把抓包机放在流量路径上。

Internet → iPhone 蜂窝网络 ↓ USB 网络共享（Mac 上的 en7） Mac ↓ Internet Sharing Wi-Fi AP（bridge100，网关 192.168.2.1） 小米电视

几个让我折腾了一晚上的 Mac 坑：

为了在不解密 TLS 的情况下提取主机名，我用了： dns tls.handshake.type == 1 第二个过滤器是 Client Hello。SNI 在这一步仍然是明文，所以即使会话其余部分已加密，你也能看到电视请求的主机名。

我故意开了两个窗口：先停在 Wi-Fi 设置界面什么都不做，然后切换到有线机顶盒的 HDMI 输入，像平常晚上一样看电视。

两段抓包的时长并不相等，所以我比较的是主机名，而不是原始计数。发往 239.255.255.250（SSDP）和 224.0.0.251（mDNS）的大部分字节只是 Sharing 子网内的局域网发现流量。在考察小米云通信问题时，我忽略这些。

这是过滤到电视的 HDMI 抓包文件。你可以看到发往互联网的 TLS，以及一大堆 SSDP/mDNS 噪声。报文内容仍然不可见，主机名可见。

切换到 HDMI 并没有让 tracking.miui.com 安静下来。它还额外增加了 Gitv 的统计流量。

我无法断言 TLS 内部 JSON 的内容：事件名、ACR 哈希、麦克风采样、截图指纹。握手之后，Wireshark 看到的只是密文。

读取主机名也不等于导出载荷。tracking、mistat、gstat、tracker 这类名字指向分析端点。商店和 CDN 的名字说服力较弱；那些可能是更新和资源。access.speech.xiaomixiaoai.com 意味着语音栈被访问过。这不能证明麦克风在那个时间段录了音。

第 1 部分的结论：我目前还读不了加密的报文内容，但我可以证明，电视在空闲时和处于 HDMI 输入时，都会持续与小米的追踪及相关云主机通信。对我来说，这足以否定“只有打开智能应用时才会用网络”的说法。

如果你想重建主机名列表： TSHARK=/Applications/Wireshark.app/Contents/MacOS/tshark BASE=assets/captures # 或者你保存下载文件的任何位置 $TSHARK -r $BASE/xiaomi-tv-baseline.pcapng -Y 'dns.flags.response == 0'
-T fields -e dns.qry.name | sort | uniq -c | sort -nr $TSHARK -r $BASE/xiaomi-tv-baseline.pcapng -Y 'tls.handshake.type == 1'
-T fields -e tls.handshake.extensions_server_name | sort | uniq -c | sort -nr 对 xiaomi-tv-hdmi.pcapng 执行同样的命令。

目标地址回答的是“和谁通信”。它们不回答“传了哪些字段”。为此，我需要让电视与我自己控制的代理进行 TLS 通信，这样我就能记录请求，然后再向真实服务器建立一个全新的 TLS 会话。计划：在 Mac 上运行 mitmproxy，把电视的 HTTP 代理指向它，在电视上安装 mitmproxy CA（如果可以就用 ADB），看看实际能解密多少。

我还没有在客厅这台电视上端到端跑过这套流程。下面是我打算遵循的操作手册，以及我已经知道会很关键的 Android 信任陷阱。

从 Android 7 开始，应用默认不信任用户安装的 CA。大多数应用使用的是系统 CA 存储。

ADB 有助于安装和配置代理。它不能消除证书固定，而且没有 root 的话，通常也无法获得系统信任。

保持 Internet Sharing 开启（bridge100 = 192.168.2.1）：

一次：brew install mitmproxy

mitmweb --listen-host 192.168.2.1 --listen-port 8080 mitmweb UI 默认在 http://127.0.0.1:8081。CA 文件位于 ~/.mitmproxy/ 下（mitmproxy-ca-cert.pem / .cer）。

在电视上启用 ADB（关于 → 连点版本号，然后开发者选项 → USB / 网络调试），然后： adb connect 192.168.2.2:5555 adb devices adb shell settings put global http_proxy 192.168.2.1:8080

稍后清除：

adb shell settings put global http_proxy :0

adb push ~/.mitmproxy/mitmproxy-ca-cert.cer /sdcard/Download/mitmproxy-ca-cert.cer 在电视上从存储安装证书（措辞不一：安全、隐私、凭据）。如果电视忽略 http_proxy，改为在 Wi-Fi 界面中为 Sharing SSID 手动设置代理。

如果我 somehow 获得可写的 /system（在零售小米电视上不太可能）： HASH=$(openssl x509 -inform PEM -subject_hash_old -in ~/.mitmproxy/mitmproxy-ca-cert.pem | head -1) cp ~/.mitmproxy/mitmproxy-ca-cert.pem /tmp/${HASH}.0 adb root adb remount adb push /tmp/${HASH}.0 /system/etc/security/cacerts/ adb shell chmod 644 /system/etc/security/cacerts/${HASH}.0 adb reboot 成功的标志是：对于使用代理、信任该 CA 且未做证书固定的流量，在 mitmweb 中能看到请求路径和 JSON。我还会导出软件包列表，把主机名映射到应用： adb shell pm list packages | grep -iE 'miui|mistat|xiaoai|mitv|gitv|analytics'

如果解密失败 症状 可能原因 mitmproxy 中没有电视流量 代理未生效；电视绕过了全局 HTTP 代理 TLS 错误 / 在线功能失效 CA 未受信任，或存在证书固定 只有 CONNECT 隧道，没有报文内容 TLS 未被拦截 只有浏览器能解密 仅用户 CA 受信任；应用排除了用户 CA

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）