您客厅里的智能电视是 AIScraping 经济中的一个节点

在 Include Security 的工作让我们日复一日地与 AI 打交道（入侵它、使用它、训练它等等）。

我们都清楚，最近社区层面出现了反对数据中心的声浪，这些数据中心旨在提升 AI 能力。但你可能没有意识到的是，还有一些分布式训练 AI 的尝试，可能正在利用你家里的设备。

在这篇文章中，我们将探讨 Bright Data 公司如何利用其住宅代理网络，为现代 AI 模型从互联网上抓取训练数据提供便利。

Bright Data 是一家数据采集公司，它出售对其所宣传的全球最大住宅代理网络的访问权限，该网络拥有 400M+ 家庭 IP 地址，其客户通过该网络路由网页抓取流量。支撑这一网络的供给来自一个 SDK：一段嵌入消费级应用中的软件，在用户同意的情况下，将他们的手机或智能电视变成其中一个出口节点。

我们将记录作为普通用户的你，应该了解这家公司的 SDK 在你的系统（如手机和智能电视）上做了什么。我们将探讨他们的 SDK 如何运作、哪些平台已经搭载了它，以及为什么你那台联网电视是 AI 模型寻求在从互联网抓取的数据上进行训练时的终极代理。

为什么这件事现在很重要

AI 公司依赖从网络抓取的内容：用于预训练、用于检索、用于智能体的现实锚定、用于搜索。但现代网络无法从数据中心抓取。Cloudflare、DataDome、HUMAN等会限制或封禁来自已知云 IP 的请求。

变通办法是住宅代理。一个通过 Comcast 或 T-Mobile 用户连接路由的抓取任务，抵达目标网站时所用的 IP 属于一位付费的住宅客户。Krebs在 2025 年 10 月报道称，“来自 Aisuru 及其他来源的大量代理，正在为与各类 AI 项目相关的大规模数据采集活动提供动力。”可追溯至 2019 年的学术测量显示，这些网络绝大多数被滥用。FBI 今年早些时候发布了一份正式警告。

现有媒体报道大多聚焦于非法住宅代理供应：僵尸网络（Aisuru、Kimwolf）、被植入木马的应用（HUMAN Security 的 PROXYLIB 披露）、预先被感染的 IoT 硬件（Google/Mandiant 对 IPIDEA 的打击）。这些是恶意行为者。

另一方面，合法供应侧受到的审视要少得多。如今，按 Bright Data 自己的营销说法，它是全球最大的住宅代理网络，宣称通过嵌入合作应用中的同意 SDK 获取了“150M+ IPs”。接下来让我们深入了解该 SDK 的工作原理以及在哪些平台上运行，从而理解为什么联网电视是终极住宅代理。

为什么联网电视（CTV）是理想的代理

联网电视，又称智能电视，是一种近乎完美的住宅代理。与手机相比：

电视永远不会掉到 1% 电量、不会在 WiFi 网络之间跳来跳去，也不会在用户睡着时被锁定。我们发现出版商已在各自的隐私政策中披露了与 Bright Data 的关系，PlayWorks 就是一个例子。从消费者的角度来看，这些通知可能会被忽略，因为在一台用电视遥控器方向键导航的设备上，很难滚动浏览一份法律文件。

Petflix 是一款 Roku 应用，由 The Verge 报道，是一个典型案例。其选择加入界面写道：“要免费享受广告更少的 Petflix，即表示你允许 Bright Data 偶尔使用你设备的空闲资源和 IP 地址，从互联网下载公开网络数据。Bright Data 只会将你的 IP 地址用于经批准的商业相关用途。除你的 IP 地址外，不会访问或收集你的任何个人信息。就是这样。” Petflix 的对话框说的是“偶尔”。而该 SDK 可公开查询的配置设定为 max_bw_monthly_wifi: 200,000,000,000 字节——即默认每月最高 200 GB 的 WiFi 流量上限。

Bright Data 列为合作伙伴的对象

Bright Data 公开了一个合作伙伴清单端点。该端点无需认证，任何人都可以获取。以下是我能够根据公开来源以高置信度识别出的清单中的名称：

其他（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 尤其声称其 CTV 分发覆盖各大电视平台和 ISP，根据其自家营销材料，触达规模达数亿家庭。

Bright Data SDK 是如何把用户设备变成住宅代理出口节点的？

Bright Data SDK 是一款公开文档化的商业产品，通过 Bright Data 的SDK 集成文档提供给发布方（网页端还有一个JavaScript 版本）。以下内容在这一公开信息的基础上，结合了对已发布 iOS framework 进行逆向工程的发现，以及对其运行时流量进行 30 天插桩监测的结果。

该 SDK 以 iOS framework（brdsdk.framework）的形式打包在合作方应用内。我对该二进制文件进行了逆向工程，并从一支研究设备集群中采集了 30 天的流量，这些设备在经用户同意安装的合作方应用内运行该 SDK。

未经身份验证的配置

每次启动时，该 SDK 都会调用：

GET <https://clientsdk.bright-sdk.com/sdk_config_ios.json>?appid=<bundle>&ver=<sdk-version>&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 年公开宣布。活跃的 SDK 基础设施仍运行在旧证书上，这是一个有用的检测切入点：当前面向客户的代理服务位于 brightdata.com 品牌的域名下，因此你网络上任何 luminatinet.com / brdtnet.com 的流量都具体属于对等隧道平面，而非客户侧的 Bright Data 使用。服务器自报身份为uWebSockets: 20。

对端端点无需任何认证即可升级。服务器接受任何 TLS 有效的 WebSocket 升级请求，并立即向连接的客户端推送一个应用层帧，其中回显了客户端的公网 IP。由此展开一次握手：

1. 服务器 → 客户端：tunnel_init 建立会话，返回客户端的公网 IP。
2. 服务器 → 客户端：cid_set 服务器为客户端分配一个会话跟踪标识符，格式为 <IP>-<token>/ls<N>c<M>p443_<IP>_<counter>。我们已确认该格式与 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 会以用户的住宅 IP 作为来源，将其作为 HTTP 请求对第三方网站执行。

WebSocket 上的每一帧都是带有固定信封的纯 JSON：

{"type": "ipc_call"|"ipc_post"|"ipc_result"|"ipc_error",
"cmd":  <command>, "cookie": <correlation-id>,
"err_code": 0, "msg": { ...payload... }}

从二进制文件中提取并在实际网络传输中验证的完整命令词汇表：

对等 websocket 连接使用 TLS，但它并未包含消息签名、HMAC、客户端证书或设备证明。服务器的 IP 信誉过滤器决定哪些对等节点接收抓取任务。

当 SDK 认为你处于“空闲”状态时

该配置附带了一份明确的规则手册，规定了设备何时有资格中继他人的流量：

"idle_metrics": {
  "ignore_screen_on": true,      // relay even with the screen on
  "ignore_on_call": true,        // relay while the user is on a phone call
  "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 的阈值之内。一个正在通话、正在主动阅读屏幕的用户，在中继用途上会被视为空闲。

跨平台身份关联

该配置还附带了一个 dual_pairing 映射：

"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 二进制文件中的代码，使其在构建 NWConnection 时指定一个特定的必需接口：en0 （WiFi）或 pdp_ip0 （蜂窝网络），而非使用系统默认路由。

在 iOS 上，这会完全绕过任何已配置 VPN 的 tun0 接口。对等隧道不会经过用户配置的 VPN，即使该应用的其他 HTTPS 流量会经过。

我们通过实证观察到了这一点。我的研究环境包含透明 TLS 拦截。它捕获了该 SDK 发出的每一次 HTTPS 调用，唯独没有捕获到发往 proxyjs.brdtnet.com:443 的对等隧道，尽管 443 端口被明确重定向到了检查器。该绕过使用了 Apple 文档中记载的 NWParameters.requiredInterface API。

值得强调的是，该 SDK 使用了两个独立的检查绕过，每个平面各一个：

• 控制平面（配置获取、遥测心跳）：构建在 CFNetwork 的 CFHTTPMessage 原语之上，而非 URLSession/NSURLConnection。这击败了移动应用安全工具中常用的 URLSession 级别插桩（swizzling、网络扩展、URLProtocol 子类），同时仍然遵循系统代理，因此对进行 TLS 拦截的研究人员仍然可见。
• 数据平面（对等隧道）：基于 NWConnection 构建，并将 requiredInterface 设置为物理接口。这正是它能够绕过 VPN 并确保抓取行为从住宅 IP 发起的原因。

这两个选择都是合法的 Apple API。有意思的是它们的组合：数据平面对基于 VPN 的检测不可见，而控制平面对基于 URLSession 的钩子不可见。仅依赖其中任何一种单一技术的研究人员，只能看到该 SDK 行为的一半。

地理分级

该配置按国家提供了带宽阈值。有四个国家获得了明确的非默认策略：

查看配置可以发现，乌兹别克斯坦和阿曼的设备被允许中继到低至 1% 电量，每日上限为默认值的 20 倍，每月上限为默认值的 60 倍。卡塔尔和阿联酋的设备则被限速至低于默认值。至于为何如此划分层级，我们只能推测。一种解读是有意的市场细分：在电网供电稳定的地区放宽限制，在移动数据昂贵的地区加以限速。全球默认额度仍然允许通过用户家庭互联网消耗他人每月 500 MB 流量。

测试环境与方法论

数据来源：

1. 来自 iOS 设备的三十天 TLS 检测代理抓包，设备上运行着经同意安装的合作方应用（包括内嵌 Bright SDK 的 XYO COIN）。
2. 对 SDK 二进制文件的静态分析（brdsdk.framework，版本 1.532.120，iOS arm64）。

本文所述的所有特定 Bright Data 主机名、证书指纹和 TLS 基础设施，任何发出相同请求的人都可以公开观察到。本文档中不包含来自研究设备群或研究客户端的任何会话特定身份识别数据。

沟通与行动时间线

• 2026 年 5 月 11 日 – 向 privacy@brightdata.com 发送了邮件通知（该邮箱地址在其法律隐私声明页面及其信任与安全门户中均有提及），告知其团队本博文即将发布。截至本文发布时，尚未收到对该通知的任何回复。
• 2026 年 6 月 5 日 – 博文发布
• 2026 年 6 月 8 日 – 收到来自 Bright Data 公关与传播部门的邮件，其中包含对本博文内容的反馈。邮件中还附有一份由 PwC 编写的报告的链接。基于他们提供的补充信息，IncludeSec 对博文做了一处适当的小修改。
• 2026 年 6 月 11 日 – IncludeSec 又做了一些小修改，使表述更加具体。
• 2026 年 6 月 17 日 – 补充 Bright Data 公关负责人 Jennifer Burns 提供的以下回应：“Bright Data 是一个基于同意的网络，每一位节点用户都在专门的通俗语言页面上明确选择加入，每一个合作方应用都通过了强制合规审查，每一位客户都经过实时 KYC 审核，我们的做法也受到独立审计机构和安全公司的审查。我们有意保持可被发现，因此也愿意承担责任。我们想直接承认一项发现：本研究中指出的 iOS VPN 绕过行为是一个 bug，现已修复。”

防御方法

这些流量在网络边界留下了清晰的指纹，而 SDK 在应用二进制文件中留下了可识别的符号。以下方法可以让你在网络层面或设备本身上检测并阻断对等隧道。三种方法，按部署难易程度排序：

方法 1：DNS 屏蔽（非常简单，对走网络路由的设备有效）：

proxyjs.brdtnet.com
proxyjs.luminatinet.com
proxyjs.bright-sdk.com
clientsdk.bright-sdk.com
clientsdk.brdtnet.com

屏蔽 proxyjs.* 可以切断对等隧道，同时不会影响任何在另一个域名上合法使用 Bright Data 面向客户代理服务的客户。

方法 2：TLS SNI 过滤：对 server_name 匹配 *.brdtnet.com、*.luminatinet.com 或 *.luminati.io 的 TLS 握手进行丢弃或告警。无需 TLS 检查即可在网络边界生效。

方法 3：TLS 证书指纹：

• .brdtnet.com → SHA256 313ce4ec7d5a51e5…
• .luminatinet.com → SHA256 5028612e625befea…

在 Sectigo 证书轮换之前保持稳定（当前证书有效期至 2026 年中）。

use_netifs 的注意事项： 这三层都只对跨越你网络边界的流量生效。SDK 的 use_netifs 绑定意味着，在 iOS 上，当设备使用蜂窝网络时，对等流量会完全绕过企业 WiFi。对于受管理的设备群，互补的控制手段是基于 MDM 的应用二进制扫描：在已安装的应用中搜索 Swift 符号 BrdWebSocketFacade 和 BrdNetwork.DNSResolver，并在企业配发的设备上禁止包含这些符号的应用。

对于担心某台特定智能电视或移动应用的家庭用户：在路由器的 DNS 设置中屏蔽上述主机名（Pi-hole、NextDNS、Cloudflare Gateway，或你的 ISP 提供的同类服务）。

——

这篇博文是与我们的客座作者、独立安全研究员 Buchodi 合作撰写的。