返回
原文
Hacker News 热门（buzzing.cc 中文翻译）
精选
70AI 编辑部评分，满分 100

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

2026-06-06 21:47· 71天前· nikcub
AI 导读

智能电视被描述为 AI 抓取经济中的节点，客厅设备可能被用于大规模数据采集网络。该观点来自一篇安全博客，揭示了家庭联网设备在 AI 训练数据供应链中的潜在角色。

推荐理由

这篇把智能电视变成 AI 数据抓取节点的黑箱拆开了，逆向工程细节让人后背发凉，建议所有用智能电视或做 AI 数据的人都读一遍。

正文 · AI 翻译

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

我们都知道，近期社区层面出现了针对数据中心建设的反对声音，这些数据中心旨在提升 AI 能力。但你可能不知道的是，那些可能正在利用你家中的设备来训练 AI 的分布式努力。

在这篇文章中，我们将探讨 Bright Data 公司如何利用其住宅代理网络，促进现代 AI 模型从互联网抓取训练数据。Bright Data 是一家数据收集公司，它销售其号称全球最大的住宅代理网络的访问权限，该网络拥有超过 4 亿个家庭 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 披露报告）、预感染恶意软件的物联网硬件（Google/Mandiant 对 IPIDEA 的打击行动）。这些都是作恶者。

另一方面，合法供应端受到的关注则少得多。如今，Bright Data 自称是全球最大的住宅代理网络，宣称通过嵌入在合作伙伴应用中的同意 SDK 获取了“1.5 亿多个 IP 地址”。现在，我们来深入了解该 SDK 的工作原理及其运行的平台，从而理解为什么联网电视会成为终极住宅代理。

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

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

因素手机智能电视 / 联网电视
电源一天中大部分时间靠电池始终插电
网络WiFi + 蜂窝网络始终连接 WiFi，高速
运行时间间歇性全天候待机
带宽上限低（蜂窝网络流量限制）实际上无限制
用户注意力被主动使用通常无人看管
同意界面手机屏幕上的文字通过电视遥控器方向键导航的文字
企业/家庭监管较高（移动设备管理、移动端点检测与响应）几乎为零

电视永远不会电量降到 1%，不会在 WiFi 网络之间切换，也不会在用户睡觉时被锁定。我们发现，发布商已在其隐私政策中披露了与 Bright Data 的关系，PlayWorks 就是一个例子。从消费者的角度来看，这些通知可能会被忽略，因为通过电视遥控器上的方向键来滚动浏览法律文件非常困难。

Petflix 是 The Verge 报道过的一个 Roku 应用，它是一个典型案例。其选择加入界面写道：“为了免费享受 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_digitalPlayWorks Digital Ltd400 多款 CTV 游戏；通过 Comcast、Sky、Cox、LG、Samsung、Vizio、Roku 覆盖约 2.5 亿电视家庭
cloudtvCloudTV已集成到 125 多个电视品牌和 15 多个 OEM 厂商
longvision_media_hong_kong_co_limitedLongvision Media HK（LongTV）在香港和马来西亚拥有 500 万 OTT 用户
viber_media_s_r_lViber Media S.à r.l.（Rakuten）Viber 即时通讯软件月活跃用户 2.5 亿至 8.2 亿
supercent_incSupercent（韩国）2023 年韩国下载量排名第一的手机游戏发行商
moonfrog_labs_private_limitedMoonfrog Labs（Stillfront 子公司）仅 Teen Patti Gold 一款游戏就有约 1000 万月活跃用户；以 9000 万美元被收购
hola_networksHola NetworksBright 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，根据其自身营销材料，其 CTV 分发覆盖了主要电视平台和互联网服务提供商，覆盖家庭数量达数亿级别。

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

Bright Data SDK 是一个公开文档化的商业产品，通过 Bright Data 的 SDK 集成文档（提供适用于网页的 JavaScript 版本）提供给发布者。以下内容基于该公开信息，并结合对 iOS 框架进行逆向工程以及对其 30 天运行时流量进行检测的发现。

该 SDK 以 iOS 框架（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（应用包名，可在合作伙伴应用的 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 将其作为 HTTP 请求执行，以用户的住宅 IP 作为源地址，访问第三方网站。

WebSocket 上的每个帧都是纯 JSON，具有固定的封装格式：

{"type": "ipc_call"|"ipc_post"|"ipc_result"|"ipc_error","cmd": <command>, "cookie": <correlation-id>,"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将诊断日志发送到服务器

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

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

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

"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 的阈值范围内。一个正在通话中、并积极阅读屏幕的用户，对于中继目的而言被视为空闲。

跨平台身份关联

配置文件中还附带了一个 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` 接口。即使应用的其他 HTTPS 流量会经过用户配置的 VPN，对等隧道也不会经过它。

我们通过实验观察到了这一点。我的研究环境包含透明的 TLS 拦截。它捕获了 SDK 发出的每一个 HTTPS 调用，除了发往 `proxyjs.brdtnet.com:443` 的对等隧道，尽管端口 443 已被明确重定向到检测工具。该绕过利用了苹果官方文档中的 `NWParameters.requiredInterface` API。

值得强调的是，该 SDK 使用了两种独立的检测绕过方式，每种方式对应一个平面：

  • 控制平面（配置获取、遥测 ping）：基于 CFNetwork 的 `CFHTTPMessage` 原语构建，而非 `URLSession`/`NSURLConnection`。这绕过了移动应用安全工具中常用的 URLSession 级检测手段（方法混淆、网络扩展、URLProtocol 子类），同时仍然遵循系统代理设置，因此对 TLS 拦截的研究人员仍然可见。
  • 数据平面（对等隧道）：基于 `NWConnection` 构建，并将 `requiredInterface` 设置为物理接口。这正是绕过 VPN 并确保爬取流量来自住宅 IP 地址的方式。

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

地理层级

该配置设定了按国家划分的带宽阈值。有四个国家采用了明确的非默认策略：

国家中继所需最低电量每日上限每月上限
乌兹别克斯坦1%1 GB30 GB
阿曼1%1 GB30 GB
卡塔尔20%40 MB250 MB
阿联酋20%40 MB250 MB
默认（全球）20%50 MB500 MB

查看配置可知，乌兹别克斯坦和阿曼的设备允许在电量低至1%时进行中继，其每日上限是默认值的20倍，每月上限是默认值的60倍。卡塔尔和阿联酋的设备则被限制在默认值以下。我们只能推测为何会划分出这样的层级。一种解读是刻意的市场细分：在电网供电稳定的地区放宽限制，在移动数据费用昂贵的地区进行限速。全球默认的配额仍然允许用户通过自家宽带每月为他人流量贡献500 MB。

测试设置与方法论

数据来源：

  1. 从运行已获同意安装的合作伙伴应用（包括嵌入了 Bright SDK 的 XYO COIN）的 iOS 设备上，采集了三十天经过 TLS 检查的代理捕获数据。
  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绕过行为是一个漏洞，且已被修复。”

防御方法

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

方法一：DNS拦截（简单，对网络路由设备有效）：

proxyjs.brdtnet.comproxyjs.luminatinet.comproxyjs.bright-sdk.comclientsdk.bright-sdk.comclientsdk.brdtnet.com

拦截 proxyjs.* 可阻止对等隧道，且不会影响任何在另一域名上合法使用Bright Data面向客户代理服务的用户。

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

方法三：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 合作撰写的。

数据/训练现象/趋势

来源：Hacker News 热门（buzzing.cc 中文翻译） · blog.includesecurity.com

导出 Markdown
返回
精选AI 评分 70/100打开原文
导出 Markdown

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

Hacker News 热门（buzzing.cc 中文翻译）·2026-06-06 21:47·71天前·nikcub
AI 导读

智能电视被描述为 AI 抓取经济中的节点，客厅设备可能被用于大规模数据采集网络。该观点来自一篇安全博客，揭示了家庭联网设备在 AI 训练数据供应链中的潜在角色。

正文 · AI 翻译

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

我们都知道，近期社区层面出现了针对数据中心建设的反对声音，这些数据中心旨在提升 AI 能力。但你可能不知道的是，那些可能正在利用你家中的设备来训练 AI 的分布式努力。

在这篇文章中，我们将探讨 Bright Data 公司如何利用其住宅代理网络，促进现代 AI 模型从互联网抓取训练数据。Bright Data 是一家数据收集公司，它销售其号称全球最大的住宅代理网络的访问权限，该网络拥有超过 4 亿个家庭 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 披露报告）、预感染恶意软件的物联网硬件（Google/Mandiant 对 IPIDEA 的打击行动）。这些都是作恶者。

另一方面，合法供应端受到的关注则少得多。如今，Bright Data 自称是全球最大的住宅代理网络，宣称通过嵌入在合作伙伴应用中的同意 SDK 获取了“1.5 亿多个 IP 地址”。现在，我们来深入了解该 SDK 的工作原理及其运行的平台，从而理解为什么联网电视会成为终极住宅代理。

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

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

因素手机智能电视 / 联网电视
电源一天中大部分时间靠电池始终插电
网络WiFi + 蜂窝网络始终连接 WiFi，高速
运行时间间歇性全天候待机
带宽上限低（蜂窝网络流量限制）实际上无限制
用户注意力被主动使用通常无人看管
同意界面手机屏幕上的文字通过电视遥控器方向键导航的文字
企业/家庭监管较高（移动设备管理、移动端点检测与响应）几乎为零

电视永远不会电量降到 1%，不会在 WiFi 网络之间切换，也不会在用户睡觉时被锁定。我们发现，发布商已在其隐私政策中披露了与 Bright Data 的关系，PlayWorks 就是一个例子。从消费者的角度来看，这些通知可能会被忽略，因为通过电视遥控器上的方向键来滚动浏览法律文件非常困难。

Petflix 是 The Verge 报道过的一个 Roku 应用，它是一个典型案例。其选择加入界面写道：“为了免费享受 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_digitalPlayWorks Digital Ltd400 多款 CTV 游戏；通过 Comcast、Sky、Cox、LG、Samsung、Vizio、Roku 覆盖约 2.5 亿电视家庭
cloudtvCloudTV已集成到 125 多个电视品牌和 15 多个 OEM 厂商
longvision_media_hong_kong_co_limitedLongvision Media HK（LongTV）在香港和马来西亚拥有 500 万 OTT 用户
viber_media_s_r_lViber Media S.à r.l.（Rakuten）Viber 即时通讯软件月活跃用户 2.5 亿至 8.2 亿
supercent_incSupercent（韩国）2023 年韩国下载量排名第一的手机游戏发行商
moonfrog_labs_private_limitedMoonfrog Labs（Stillfront 子公司）仅 Teen Patti Gold 一款游戏就有约 1000 万月活跃用户；以 9000 万美元被收购
hola_networksHola NetworksBright 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，根据其自身营销材料，其 CTV 分发覆盖了主要电视平台和互联网服务提供商，覆盖家庭数量达数亿级别。

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

Bright Data SDK 是一个公开文档化的商业产品，通过 Bright Data 的 SDK 集成文档（提供适用于网页的 JavaScript 版本）提供给发布者。以下内容基于该公开信息，并结合对 iOS 框架进行逆向工程以及对其 30 天运行时流量进行检测的发现。

该 SDK 以 iOS 框架（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（应用包名，可在合作伙伴应用的 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 将其作为 HTTP 请求执行，以用户的住宅 IP 作为源地址，访问第三方网站。

WebSocket 上的每个帧都是纯 JSON，具有固定的封装格式：

{"type": "ipc_call"|"ipc_post"|"ipc_result"|"ipc_error","cmd": <command>, "cookie": <correlation-id>,"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将诊断日志发送到服务器

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

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

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

"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 的阈值范围内。一个正在通话中、并积极阅读屏幕的用户，对于中继目的而言被视为空闲。

跨平台身份关联

配置文件中还附带了一个 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` 接口。即使应用的其他 HTTPS 流量会经过用户配置的 VPN，对等隧道也不会经过它。

我们通过实验观察到了这一点。我的研究环境包含透明的 TLS 拦截。它捕获了 SDK 发出的每一个 HTTPS 调用，除了发往 `proxyjs.brdtnet.com:443` 的对等隧道，尽管端口 443 已被明确重定向到检测工具。该绕过利用了苹果官方文档中的 `NWParameters.requiredInterface` API。

值得强调的是，该 SDK 使用了两种独立的检测绕过方式，每种方式对应一个平面：

  • 控制平面（配置获取、遥测 ping）：基于 CFNetwork 的 `CFHTTPMessage` 原语构建，而非 `URLSession`/`NSURLConnection`。这绕过了移动应用安全工具中常用的 URLSession 级检测手段（方法混淆、网络扩展、URLProtocol 子类），同时仍然遵循系统代理设置，因此对 TLS 拦截的研究人员仍然可见。
  • 数据平面（对等隧道）：基于 `NWConnection` 构建，并将 `requiredInterface` 设置为物理接口。这正是绕过 VPN 并确保爬取流量来自住宅 IP 地址的方式。

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

地理层级

该配置设定了按国家划分的带宽阈值。有四个国家采用了明确的非默认策略：

国家中继所需最低电量每日上限每月上限
乌兹别克斯坦1%1 GB30 GB
阿曼1%1 GB30 GB
卡塔尔20%40 MB250 MB
阿联酋20%40 MB250 MB
默认（全球）20%50 MB500 MB

查看配置可知，乌兹别克斯坦和阿曼的设备允许在电量低至1%时进行中继，其每日上限是默认值的20倍，每月上限是默认值的60倍。卡塔尔和阿联酋的设备则被限制在默认值以下。我们只能推测为何会划分出这样的层级。一种解读是刻意的市场细分：在电网供电稳定的地区放宽限制，在移动数据费用昂贵的地区进行限速。全球默认的配额仍然允许用户通过自家宽带每月为他人流量贡献500 MB。

测试设置与方法论

数据来源：

  1. 从运行已获同意安装的合作伙伴应用（包括嵌入了 Bright SDK 的 XYO COIN）的 iOS 设备上，采集了三十天经过 TLS 检查的代理捕获数据。
  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绕过行为是一个漏洞，且已被修复。”

防御方法

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

方法一：DNS拦截（简单，对网络路由设备有效）：

proxyjs.brdtnet.comproxyjs.luminatinet.comproxyjs.bright-sdk.comclientsdk.bright-sdk.comclientsdk.brdtnet.com

拦截 proxyjs.* 可阻止对等隧道，且不会影响任何在另一域名上合法使用Bright Data面向客户代理服务的用户。

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

方法三：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 合作撰写的。

来源：Hacker News 热门（buzzing.cc 中文翻译）· blog.includesecurity.com