客厅里的智能电视成为AI爬取经济的一个节点

# 你家客厅的智能电视是AI抓取经济中的一个节点 - Include Security 研究博客 来源：https://blog.includesecurity.com/2026/06/the-smart-tv-in-your-livingroom-is-a-node-in-the-aiscraping-economy/ Include Security 的工作让我们日复一日地与 AI 打交道（破解它、使用它、训练它等）。我们都很清楚最近针对数据中心建设发生的社区层面抵制，这些建设旨在提升 AI 能力。但你可能不知道的是，那些可能正在利用你家中的设备来训练 AI 的分布式努力。在这篇文章中，我们将探讨 Bright Data 公司如何通过其住宅代理网络，促进现代 AI 模型从互联网上抓取训练数据（https://brightdata.com/blog/web-data/web-scraping-for-machine-learning）。 Bright Data 是一家数据收集公司，出售其号称全球最大的住宅代理网络的访问权限，该网络拥有超过 4 亿个家庭 IP 地址，其客户通过这些地址路由网络抓取流量。该网络的供应端来自一个 SDK：一个嵌入在消费者应用中的软件，经用户同意后，将用户的手机或智能电视变成那些出口节点之一。我们将记录普通用户应该了解的关于该公司 SDK 在你的系统（如手机和智能电视）上做了什么的内容。我们将探讨他们的 SDK 如何工作，哪些平台已经搭载了它，以及为什么你的联网电视成为那些希望从互联网抓取数据来训练 AI 的模型的终极代理。 ### **为何此事现在重要** AI 公司依赖网络抓取的内容：用于预训练、检索、助手接地、搜索。但现代网络无法从数据中心内被抓取。Cloudflare、DataDome、HUMAN（https://datadome.co/bot-management-protection/how-proxy-providers-get-residential-proxies/）以及其他服务会限制或阻止来自已知云 IP 的请求。解决办法是住宅代理。通过 Comcast 或 T-Mobile 订阅者连接路由的抓取任务，会以属于付费住宅客户的 IP 到达目标网站。Krebs 在 2025 年 10 月报道（https://krebsonsecurity.com/2025/10/aisuru-botnet-shifts-from-ddos-to-residential-proxies/）称，“来自 Aisuru 和其他来源的大量代理正在推动与多个 AI 项目相关的大规模数据收集工作。”早在 2019 年的学术测量（https://ieeexplore.ieee.org/document/8835239）就显示这些网络绝大多数被滥用。FBI 在今年早些时候发布了一份正式建议（https://www.fbi.gov/investigate/cyber/alerts/2026/evading-residential-proxy-networks-protecting-your-devices-from-becoming-a-tool-for-criminals）。 现有的大多数报道集中在**非法**住宅代理供应：僵尸网络（Aisuru（https://krebsonsecurity.com/2025/10/aisuru-botnet-shifts-from-ddos-to-residential-proxies/），Kimwolf（https://krebsonsecurity.com/2026/01/the-kimwolf-botnet-is-stalking-your-local-network/）），木马化应用（HUMAN Security 的 PROXYLIB 披露（https://www.humansecurity.com/learn/blog/satori-threat-intelligence-alert-proxylib-and-lumiapps-transform-mobile-devices-into-proxy-nodes/）），预感染的 IoT 硬件（Google/Mandiant 的 IPIDEA 取缔行动（https://cloud.google.com/blog/topics/threat-intelligence/disrupting-largest-residential-proxy-network））。这些是恶意行为者。另一方面，合法供应方受到的审查要少得多。如今，Bright Data 凭借其自身宣传，声称是全球最大的住宅代理网络，广告中称“超过 1.5 亿个 IP”来自嵌入在合作伙伴应用中的同意 SDK。这项研究记录了该 SDK 如何工作，哪些平台已经搭载了它，以及为什么联网电视成为终极住宅代理。 ### **为什么联网电视（CTV）是理想的代理** 联网电视，即智能电视，几乎是完美的住宅代理。与手机相比： | **因素** | **手机** | **智能电视 / CTV** | |----------|----------|---------------------| | 电源 | 大部分时间靠电池 | 始终插电 | | 网络 | WiFi + 蜂窝网络 | 始终使用 WiFi，高速 | | 在线时间 | 间歇性 | 7x24 小时待机 | | 带宽上限 | 低（蜂窝网络流量限制） | 实际上无限 | | 用户注意力 | 活跃使用中 | 通常无人看管 | | 同意界面 | 手机屏幕上的文字 | 通过电视遥控器方向键导航的文字 | | 公司/家庭监管 | 较高（MDM、移动 EDR） | 几乎为零 | 电视永远不会电量低于 1%，不会在 WiFi 网络之间跳转，也不会在用户睡觉时被锁屏。一些合作发行商确实在其隐私政策中披露了 Bright Data 的关系——PlayWorks 就是其中一个例子（https://play.works/privacy-policy）。但对于电视来说，隐私政策披露是错误的控制界面。通过遥控器上的方向键滚动法律文件很困难，而且应用内的同意对话框并没有告知用户，一个付费的 Bright Data 客户即将通过用户的家庭互联网路由其抓取流量。 Petflix，一个由 The Verge 报道的 Roku 应用（https://www.theverge.com/column/885244/smart-tv-web-crawler-ai），是一个典型案例。其选择加入界面显示： > “为了免费享受 Petflix 并减少广告，你允许 Bright Data 偶尔使用你设备的空闲资源和 IP 地址，从互联网下载公共网络数据。Bright Data 仅会将你的 IP 地址用于经批准的商业相关用例。除了你的 IP 地址之外，不会访问或收集你的任何个人信息。句号。” Petflix 的对话框说“偶尔”。但 SDK 的公开可查询配置设定了 `max_bw_monthly_wifi: 200,000,000,000` 字节——每月默认 WiFi 预算高达 200 GB。 ### **Bright Data 列出的合作伙伴** Bright Data 公开了一个合作伙伴清单端点。该端点无需身份验证，任何人都可以获取。从公开来源我能高度确认的清单中的实体： | **合作伙伴 ID（来自配置）** | **实体** | **规模** | |----------------------------|----------|-----------| | playworks_digital | **PlayWorks Digital Ltd** | 超过 400 款 CTV 游戏；通过 Comcast、Sky、Cox、LG、Samsung、Vizio、Roku 覆盖约 2.5 亿电视家庭（https://play.works/） | | cloudtv | **CloudTV** | 集成到超过 125 个电视品牌和 15 个以上 OEM（https://www.cloudtvos.com/applications.php） | | longvision_media_hong_kong_co_limited | **Longvision Media HK（LongTV）** | 覆盖香港和马来西亚的 500 万 OTT 用户（https://hk.long.tv/） | | viber_media_s_r_l | **Viber Media S.à r.l.（Rakuten）** | Viber 即时通讯应用月活用户 2.5 亿至 8.2 亿（https://earthweb.com/viber-statistics/） | | supercent_inc | **Supercent（韩国）** | 2023 年韩国下载量排名第一的移动发行商（https://en.supercent.io/about） | | moonfrog_labs_private_limited | **Moonfrog Labs（Stillfront 子公司）** | 仅 Teen Patti Gold 就有约 1000 万月活用户；以 9000 万美元收购（https://inc42.com/buzz/sweden-based-stillfront-acquires-teen-patti-creator-moonfrog-labs/） | | hola_networks | **Hola Networks** | Bright Data 的祖辈公司；根据 Hola 自身历史上的宣传，用户基数高峰期在数千万到约 1 亿以上 | 其他（`desoline, free_time, ott_studio, global_microtrading, m_m_media, easystaff_lp`）存在但难以从公开来源识别。`bright_screensavers, bright_videos` 和 `brightdata` 是 Bright Data 自己的应用。 关于合作伙伴列表的说明：出现在 Bright Data 的配置中意味着某个集成可能曾在某个时间点存在。它本身并不能证明某个特定发行商当前正在发布的应用在生产环境中包含了该 SDK。对于任何列出的发行商，都需要逐个应用进行验证。合作伙伴列表**直接**证明的是： 1. Bright Data 通过一个**无需身份验证的公共端点**提供这份名单。 2. 至少三个专注于 CTV 的实体（PlayWorks、CloudTV、Longvision）将用户设备货币化为住宅代理出口节点。特别是 PlayWorks，根据其自身宣传材料，声称在主要电视平台和 ISP 上具有 CTV 分发能力，覆盖数亿家庭。 ### **Bright Data SDK 如何将用户设备变成住宅代理出口节点？** Bright Data SDK 是一个公开文档化的商业产品，通过 Bright Data 的 SDK 集成文档（https://docs.brightdata.com/api-reference/SDK）（以及面向网页的 JavaScript 变体（https://docs.brightdata.com/api-reference/SDK-JS））提供给发行商。以下内容基于该公开接口，并结合对已发布的 iOS 框架进行逆向工程以及对其运行时流量进行 30 天检测的结果。 该 SDK 以 iOS 框架（brdsdk.framework）的形式嵌入在合作伙伴应用内。我对二进制文件进行了逆向工程，并从运行该 SDK 的、在经同意安装的合作伙伴应用内的研究设备群中捕获了 30 天的流量。 #### **无需身份验证的配置** 在每次启动时，SDK 会调用： `GET ?appid=&ver=&uuid=sdk-ios-<32hex>` 该端点在任何有实际意义的层面上都无需身份验证。服务器仅根据两个查询参数 `appid`（应用包 ID，可在合作伙伴应用的 App Store 列表中找到）和 `ver`（SDK 版本字符串）进行筛选。提供它们以及任何随机生成的 UUID，服务器就会返回与真实设备相同的响应：功能标志、空闲检测阈值（电池百分比、CPU/内存上限、WiFi 与蜂窝网络规则）、按国家/地区的带宽层级，以及我上面展示的合作伙伴清单。每个分支都值得单独审视：决定你的设备何时有资格进行中继的空闲规则、一个会将对等流量绕开你的 VPN 的标志、一个将你不同平台上的安装整合为一个身份的地图，以及按国家/地区的带宽限制。 #### **对等隧道** 配置获取完成后，SDK 会打开一个持久的 WebSocket 连接到： `wss://proxyjs.brdtnet.com:443` 该主机名解析为 AWS Global Accelerator IP 地址（本文撰写时为 3.33.193.183, 15.197.193.114）。TLS 证书是 `CN=*.luminatinet.com`——这是 Luminati Networks（Bright Data 在 2018 年之前的公司名称）的域名。品牌重塑在 2018 年公开宣布（https://brightdata.com/blog/why-brightdata/why-we-changed-our-name-from-luminati-networks-to-bright-data）。活跃的 SDK 基础设施仍然运行在旧的证书上，这是一个有用的检测切入点：当前面向客户的代理服务位于 brightdata.com 品牌的域名上，因此你网络上任何 luminatinet.com / brdtnet.com 的流量都专门是对等隧道层面，而不是客户端的 Bright Data 使用。 服务器标识为 `uWebSockets: 20`。对等端点无需身份验证即可升级。服务器接受任何 TLS 有效的 WebSocket 升级，并立即向连接客户端推送一个应用层帧，其中包含客户端的公网 IP 回显。从那里开始，握手机制展开： 1. **服务器 → 客户端：tunnel_init** 建立会话，返回客户端的公网 IP。 2. **服务器 → 客户端：cid_set** 服务器为客户端分配一个会话跟踪标识符，格式为 `-/lscp443__`。我们确认该格式与来自真实设备 SDK 捕获的遥测流量中存在的 cid 字段匹配。 3. **服务器 → 客户端：status_get** 服务器轮询设备的空闲状态、电池、网络类型和可用带宽。设备响应一个持续的遥测流：`idle, wifi_connected, mobile_connected, mobile_type`（LTE/5G）、`roaming, battery_level, using_battery, screen_on, on_call, cpu_usage, mem_usage, raw_bw, bw, ipv6_supported, appid`（宿主应用）、`sdk_version, platform` 以及分配的 `cid`。这是一个将物理设备状态持续发送给第三方的数据流，通过一个由宿主应用发行商选择文本的同意对话框提供。 4. **握手完成。**一旦设备报告有利状态，服务器的任务匹配层就可以自由推送 `cmd_tun` 帧：单个抓取任务指令，SDK 将其作为 HTTP 请求针对第三方网站执行，并使用用户的住宅 IP 作为源地址。 WebSocket 上的每个帧都是纯 JSON，带有一个固定信封： ```json {"type": "ipc_call"|"ipc_post"|"ipc_result"|"ipc_error", "cmd": , "cookie": , "err_code": 0, "msg": { ...payload... }} ``` 从二进制文件中提取并在线路上验证的完整命令词汇表： | **方向** | **cmd** | **目的** | |----------|---------|----------| | 服务器 → 客户端 | tunnel_init | 打开会话，回显公网 IP | | 服务器 → 客户端 | cid_set | 分配会话标识符 | | 服务器 → 客户端 | status_get | 轮询设备空闲/电池/带宽 | | 服务器 → 客户端 | cmd_tun / tun | 分发抓取任务 | | 服务器 → 客户端 | dns | 请求对目标进行 DNS 解析 | | 服务器 → 客户端 | consent | 请求同意状态 | | 客户端 → 服务器 | status_send | 周期性心跳，包含设备状态 | | 客户端 → 服务器 | tun_report / tun_ack / tun_fin | 中继任务生命周期响应 | | 客户端 → 服务器 | tunnel_init_decline | 拒绝会话 | | 客户端 → 服务器 | logs | 向服务器发送诊断日志 | 没有消息签名、HMAC、客户端证书或设备认证。只有 TLS 层和服务器基于 IP 信誉的过滤器来控制哪些对等端实际接收任务。对于熟悉商业恶意软件协议设计的读者来说：这在安全性上远不如典型的 C2。 #### **SDK 何时认为你“空闲”** 配置中附带了一套明确的规则，规定设备何时有资格中继他人的流量： ```json "idle_metrics": { "ignore_screen_on": true, // 即使屏幕亮着也进行中继 "ignore_on_call": true, // 即使用户正在通话也进行中继 "max_bw_ratio": 1, "min_battery": 0.2, "wifi_on_battery": true, "min_battery_wifi": 0.2, "max_cpu_usage": 70, "max_mem_usage": 90, "mem_screen_off": true, "idle_timeout": 30, "not_idle_timeout": 10 } ``` `ignore_screen_on` 和 `ignore_on_call` 标志值得注意的是：“空闲”并不意味着用户不在设备旁。它意味着设备的 CPU、内存和电池处于 SDK 的阈值之内。正在通话、正在阅读屏幕的用户被视为可用于中继的“空闲”状态。 #### **跨平台身份关联** 配置中还包含一个双配对映射： ```json "dual_pairing": { "ios_com.brd.earnapp": ["win_earnapp.com", "mac_com.earnapp"] } ``` 这是一个服务器端的映射，将用户在同一品牌下的 iOS、Windows 和 macOS 安装关联为一个实体。这是一个记录在公共配置文件中的跨平台身份拼接。 还有一个更前瞻的字段：`http3_enabled: true`。SDK 已经包含了用于基于 QUIC 的对等传输的标志。未来的版本可能将对等隧道从 TCP/443 移至 UDP/443，这将破坏任何依赖 TCP 连接跟踪来检测 WebSocket 的防御者。 #### **检测绕过** SDK 的配置中有一个标志 `"use_netifs": true`。该标志触发 SDK 二进制文件中的代码，使用特定的必需接口（`en0`（WiFi）或 `pdp_ip0`（蜂窝网络））构建其 NWConnection，而不是使用系统默认路由。 **在 iOS 上，这会完全绕过任何已配置的 VPN 的 tun0 接口。**对等隧道不会经过用户配置的 VPN，即使应用的其他 HTTPS 流量会经过。我们通过实验观察到了这一点。我的研究设置包括透明 TLS 拦截。它捕获了 SDK 发出的所有 HTTPS 调用，但连接到 proxyjs.brdtnet.com:443 的对等隧道除外，尽管端口 443 被明确重定向到检查器。该绕过使用了 Apple 文档化的 NWParameters.requiredInterface API。 值得强调的是，SDK 使用了**两个独立的检测绕过机制**，每个层面一个： - **控制层面**（配置获取、遥测 ping）：基于 CFNetwork 的 CFHTTPMessage 原语，而不是 URLSession/NSURLConnection。这击败了 URLSession 级别的检测工具（swizzling、network extensions、URLProtocol 子类），这些工具常用于移动应用安全研究，同时仍然遵循系统代理，因此对 TLS 拦截的研究人员仍然可见。 - **数据层面**（对等隧道）：基于 NWConnection，并将 requiredInterface 设置为物理接口。这就是击败 VPN 并确保对等流量即使在企业部署中也无法被拦截的方式。