A smart TV da sala é um nó na economia de scraping com IA

 (blog.includesecurity.com)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • O Bright Data SDK embutido em apps de consumo, com o consentimento do usuário, transforma o celular ou a smart TV em um nó de saída de proxy residencial e roteia o tráfego de web scraping dos clientes por IPs domésticos
  • Proxies residenciais são um meio de contorno para alcançar sites-alvo usando IPs de clientes residenciais pagantes, em um ambiente em que Cloudflare, DataDome e HUMAN limitam ou bloqueiam solicitações vindas de IPs de nuvem conhecidos
  • TVs conectadas não têm restrições de bateria, ficam sempre conectadas ao Wi‑Fi e operam em espera 24/7, oferecendo condições de proxy com maior persistência e capacidade de ficar sem supervisão do que celulares
  • O SDK para iOS recebe critérios de ociosidade, limites de banda e uma lista de parceiros a partir de um endpoint de configuração sem autenticação, e abre um túnel de pares via WebSocket para processar telemetria do estado do dispositivo e tarefas de scraping cmd_tun
  • A defesa se concentra em bloqueio de DNS de proxyjs.* e clientsdk.*, filtragem de SNI, detecção por impressão digital de certificados TLS e varredura de binários de apps via MDM; no iOS, use_netifs impõe uma limitação que contorna a visibilidade baseada em VPN

Visão geral

  • Independentemente da oposição em nível comunitário à construção de data centers para ampliar capacidades de IA, há uma estrutura em que dispositivos dentro de casa podem ser usados para coleta distribuída de dados para treinamento de IA
  • A Bright Data vende acesso a uma rede de proxies residenciais com mais de 400M de endereços IP domésticos, pelos quais clientes roteiam tráfego de web scraping, e a fonte de suprimento é um SDK embutido em apps de consumo
  • Esse SDK, com o consentimento do usuário, transforma celulares ou smart TVs em nós de saída; a análise examina como o SDK funciona, em quais plataformas é distribuído e por que TVs conectadas à internet são adequadas como proxies de web scraping para modelos de IA

Por que isso importa agora

  • Empresas de IA dependem de conteúdo obtido por web scraping para pré-treinamento, busca e RAG, grounding de agentes e recursos de pesquisa
  • A web moderna é um ambiente que não pode ser raspado facilmente a partir de data centers, e Cloudflare, DataDome, HUMAN limitam ou bloqueiam solicitações de IPs de nuvem conhecidos
  • A alternativa é um proxy residencial que alcança o site-alvo a partir do IP de um cliente residencial pagante, como uma conexão de assinante da Comcast ou da T-Mobile
  • Uma citação da reportagem de outubro de 2025 da Krebs diz que “o excesso de proxies do Aisuru e de outras fontes está alimentando esforços massivos de coleta de dados ligados a vários projetos de IA”
  • Medições acadêmicas, que remontam a 2019, concluíram que essas redes são usadas de forma abusiva de maneira esmagadora, e o FBI também emitiu um alerta oficial no início deste ano
  • A maior parte da cobertura anterior se concentrou no fornecimento ilegal de proxies residenciais, como botnets como Aisuru e Kimwolf, apps trojanizados como PROXYLIB e hardware IoT previamente infectado como IPIDEA
  • O lado da oferta legal recebeu bem menos escrutínio, e a Bright Data, que se apresenta em seu próprio marketing como a maior rede de proxies residenciais do mundo, anuncia “150M+ IPs” com base em um SDK com consentimento embutido em apps parceiros

Por que TVs conectadas são proxies ideais

Fator Celular Smart TV / CTV
Energia Usa bateria na maior parte do dia Sempre ligada à energia
Rede Wi‑Fi + celular Sempre no Wi‑Fi, alta velocidade
Tempo de atividade Intermitente 24/7 em espera
Limite de banda Baixo, com restrições móveis Praticamente ilimitado
Atenção do usuário Uso ativo Frequentemente sem supervisão
UI de consentimento Texto na tela do celular Texto navegado com as setas do controle remoto da TV
Supervisão corporativa/familiar Maior, com MDM, EDR móvel etc. Praticamente inexistente
  • TVs não chegam a 1% de bateria, não mudam com frequência entre redes Wi‑Fi e não bloqueiam a tela enquanto o usuário dorme
  • Alguns publishers parceiros divulgam a relação com a Bright Data em suas políticas de privacidade, e a política de privacidade da PlayWorks é um exemplo
  • Divulgar isso na política de privacidade não é um ponto de controle adequado para TVs; é difícil rolar documentos legais com as setas do controle remoto, e as caixas de diálogo de consentimento no app não conseguem comunicar que clientes pagantes da Bright Data rotearão tráfego de scraping pela internet doméstica do usuário
  • A tela de opt-in do app Petflix para Roku, documentada pelo The Verge, usa a frase “para reduzir anúncios e aproveitar de graça, permita que a Bright Data use ocasionalmente os recursos ociosos e o endereço IP do seu dispositivo para baixar dados públicos da web na internet”
  • O diálogo do Petflix usa a palavra “ocasionalmente”, mas a configuração do SDK consultável publicamente mostra max_bw_monthly_wifi: 200,000,000,000, um orçamento padrão mensal de Wi‑Fi de 200 GB

Alvos nomeados pela Bright Data como parceiros

  • A Bright Data expõe um endpoint de manifesto de parceiros que qualquer pessoa pode consultar sem autenticação
  • Itens de identificação de alta confiança com base em fontes públicas
Partner ID Entidade Escala
playworks_digital PlayWorks Digital Ltd 400+ títulos de jogos para CTV, alcance de cerca de 250M de lares com TV via Comcast, Sky, Cox, LG, Samsung, Vizio e Roku
cloudtv CloudTV Integrado em mais de 125 marcas de TV e mais de 15 OEMs
longvision_media_hong_kong_co_limited Longvision Media HK (LongTV) 5M de usuários OTT em Hong Kong e na Malásia
viber_media_s_r_l Viber Media S.à r.l. (Rakuten) 250M–820M de usuários mensais do mensageiro Viber
supercent_inc Supercent Maior publisher mobile da Coreia em downloads em 2023
moonfrog_labs_private_limited Moonfrog Labs Só o Teen Patti Gold tem cerca de 10M de MAU; empresa foi adquirida por US$ 90 milhões
hola_networks Hola Networks Empresa-mãe histórica da Bright Data; no pico, o marketing da Hola alegava uma base de usuários na faixa de dezenas de milhões até cerca de 100M+
  • desoline, free_time, ott_studio, global_microtrading, m_m_media, easystaff_lp aparecem no manifest, mas são itens difíceis de identificar em fontes públicas
  • bright_screensavers, bright_videos, brightdata são apps da própria Bright Data
  • O fato de haver nomes nas configurações da Bright Data sugere que pode ter havido integração em algum momento, mas não é evidência direta de que os apps atualmente distribuídos por um determinado publisher incluam o SDK em ambiente de produção
  • O que a lista de parceiros comprova diretamente é que a Bright Data distribui essa relação em um endpoint público sem autenticação e que pelo menos três empresas focadas em CTV, como PlayWorks, CloudTV e Longvision, monetizaram dispositivos de usuários como nós de saída de proxy residencial
  • Segundo os próprios materiais de marketing da PlayWorks, a empresa apresenta números de distribuição de CTV em grandes plataformas de TV e ISPs, com alcance de centenas de milhões de lares
Publicidade

Como o SDK da Bright Data transforma dispositivos de usuários em nós de saída de proxy residencial

  • O SDK da Bright Data é um produto comercial documentado publicamente, com documentação de integração do SDK para publishers e uma variante em JavaScript para web

  • A análise foi baseada em engenharia reversa de um framework iOS em distribuição e em 30 dias de instrumentação de tráfego em tempo de execução

  • O SDK é distribuído dentro de apps parceiros na forma do framework iOS brdsdk.framework

  • Configuração sem autenticação

    • O SDK faz a seguinte requisição a cada execução
    • GET https://clientsdk.bright-sdk.com/sdk_config_ios.json/…;
    • O endpoint funciona sem autenticação significativa, e o servidor só verifica dois parâmetros de consulta: appid, que é o bundle ID do app, e ver, que é a string da versão do SDK
    • Se forem fornecidos o bundle ID encontrado na listagem da App Store de um app parceiro, a string da versão do SDK e um UUID gerado arbitrariamente, ele retorna a mesma configuração que um dispositivo real recebe
    • A resposta inclui flags de recurso, limiares de detecção de inatividade como nível de bateria, teto de CPU/memória e regras de Wi‑Fi/celular, classes de largura de banda por país e uma estrutura com o manifesto do parceiro
    • Dentro da configuração existem regras de inatividade que qualificam o dispositivo para retransmitir tráfego, flags para rotear tráfego de pares ao redor de VPN, um map que conecta instalações entre plataformas a uma única identidade e limites de largura de banda por país

  • Túnel de pares

    • Depois de buscar a configuração, o SDK abre um WebSocket persistente para o endereço abaixo
    • wss://proxyjs.brdtnet.com:443
    • No momento da escrita, esse nome de host resolve para os IPs do AWS Global Accelerator 3.33.193.183, 15.197.193.114
    • O certificado TLS é CN=*.luminatinet.com, e Luminati Networks era o nome da empresa da Bright Data antes de 2018
    • Mesmo após o rebranding de 2018, a infraestrutura ativa do SDK usa certificados legacy, e tráfego para luminatinet.com ou brdtnet.com não é um indício de uso de Bright Data pelo cliente, mas sim um indício de identificação do plano do túnel de pares
    • Como o serviço de proxy voltado ao cliente hoje opera em domínios da marca brightdata.com, tráfego de rede para luminatinet.com e brdtnet.com corresponde ao plano do túnel de pares
    • O servidor se identifica como uWebSockets: 20
    • O endpoint de pares não exige autenticação no upgrade, aceita um upgrade WebSocket válido via TLS e então envia imediatamente um frame em camada de aplicação devolvendo o IP público do cliente
    • Fluxo de handshake
      1. servidor → cliente tunnel_init: cria a sessão e retorna o IP público do cliente
      1. servidor → cliente cid_set: atribui um identificador de rastreamento de sessão no formato <IP>-<token>/ls<N>c<M>p443_<IP>_<counter>, confirmado como correspondente ao campo cid na telemetria de dispositivos reais
      1. servidor → cliente status_get: consulta inatividade, bateria, tipo de rede e largura de banda disponível do dispositivo, e o dispositivo responde com telemetria contínua como idle, wifi_connected, mobile_connected, mobile_type, roaming, battery_level, using_battery, screen_on, on_call, cpu_usage, mem_usage, raw_bw, bw, ipv6_supported, appid, sdk_version, platform, cid
      Publicidade
      1. depois que o handshake termina, se o dispositivo reportar um estado favorável, a camada de matching de tarefas do servidor pode enviar frames cmd_tun, e o SDK os executa como requisições HTTP a sites de terceiros usando o IP residencial do usuário como origem
    • Todos os frames do WebSocket são JSON puro com um envelope fixo
    • {"type": "ipc_call"|"ipc_post"|"ipc_result"|"ipc_error","cmd": <command>, "cookie": <correlation-id>,"err_code": 0, "msg": { ...payload... }}
    • Comandos extraídos do binário e confirmados em comunicações reais
    • | direção | cmd | propósito |
    • |---|---|---|
    • | Server → Client | tunnel_init | abertura da sessão, echo do IP público |
    • | Server → Client | cid_set | atribuição do identificador de sessão |
    • | Server → Client | status_get | consulta de inatividade, bateria e largura de banda do dispositivo |
    • | Server → Client | cmd_tun / tun | entrega de tarefa de scraping |
    • | Server → Client | dns | solicitação de resolução DNS do alvo |
    • | Server → Client | consent | solicitação do estado de consentimento |
    • | Client → Server | status_send | heartbeat periódico do estado do dispositivo |
    • | Client → Server | tun_report / tun_ack / tun_fin | respostas do ciclo de vida da tarefa de retransmissão |
    • | Client → Server | tunnel_init_decline | recusa da sessão |
    • | Client → Server | logs | envio de logs de diagnóstico ao servidor |
    • Não há assinatura de mensagens, HMAC, certificado de cliente nem atestação do dispositivo, e os únicos fatores que separam os pares que recebem trabalho real são a camada TLS e os filtros de reputação de IP do servidor
    • Para leitores familiarizados com design de protocolos de malware comercial, o nível de segurança é, na prática, inferior ao de um C2 típico

  • O que o SDK considera “inativo”

    • A configuração especifica regras de estado do dispositivo que permitem retransmitir tráfego de outras pessoas
    "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
}
    • Por causa das flags ignore_screen_on e ignore_on_call, “inativo” não significa que o usuário esteja longe do dispositivo, mas sim que CPU, memória e bateria estão dentro dos limiares do SDK
    • Mesmo se o usuário estiver em uma ligação ou lendo ativamente a tela, isso pode ser considerado estado inativo para fins de retransmissão

  • Vinculação de identidade entre plataformas

    • A configuração contém o seguinte map dual_pairing
    Publicidade
    "dual_pairing": {
  "ios_com.brd.earnapp": ["win_earnapp.com", "mac_com.earnapp"]
}
    • Esse map é uma estrutura de ligação do lado do servidor que agrupa instalações de iOS, Windows e macOS da mesma marca em uma única entidade
    • O campo http3_enabled: true é uma flag para transporte de pares baseado em QUIC, e versões futuras podem mover o túnel de pares de TCP/443 para UDP/443
    • Defensores que detectam WebSocket por rastreamento de conexões TCP podem ter seu método de detecção quebrado se houver migração para UDP/443

  • Evasão de inspeção

    • A flag use_netifs: true na configuração do SDK é a condição que faz o código binário do SDK construir NWConnection com uma interface obrigatória específica, em vez da rota padrão do sistema
    • As interfaces obrigatórias são en0 para Wi‑Fi ou pdp_ip0 para celular
    • No iOS, esse método contorna completamente a interface tun0 de uma VPN configurada, e, mesmo que outro tráfego HTTPS do app passe pela VPN, o túnel de pares não passa pela VPN configurada pelo usuário

  • O ambiente de pesquisa com interceptação transparente de TLS capturou todas as chamadas HTTPS do SDK, mas não conseguiu capturar o túnel peer proxyjs.brdtnet.com:443, mesmo com a porta 443 explicitamente redirecionada ao interceptador

    • O desvio usa a API documentada da Apple NWParameters.requiredInterface
    • O SDK usa dois desvios independentes de inspeção
    • Plano de controle: a obtenção de configuração e os pings de telemetria são baseados nas primitivas CFHTTPMessage do CFNetwork, e não em URLSession ou NSURLConnection, neutralizando instrumentação em nível de URLSession, swizzling, extensões de rede e subclasses de URLProtocol, comuns em ferramentas de segurança para apps móveis, ao mesmo tempo em que respeita proxies do sistema para manter visibilidade a pesquisadores de interceptação TLS
    • Plano de dados: o túnel peer é baseado em NWConnection, com a interface física definida como interface obrigatória, desativando VPNs e garantindo que o scraping rode a partir de IPs residenciais
    • Para equipes de segurança que usam MDM, inspeção de tráfego baseada em VPN corporativa e controles parentais em roteadores domésticos, o canal mais sensível foi projetado para contornar a camada de visibilidade

Camadas por país

  • As configurações incluem limites de largura de banda por país
Publicidade
País Bateria mínima para relay Limite diário Limite mensal
Uzbekistan 1% 1GB 30GB
Oman 1% 1GB 30GB
Qatar 20% 40MB 250MB
UAE 20% 40MB 250MB
padrão, mundial 20% 50MB 500MB
  • Dispositivos de Uzbekistan e Oman podem fazer relay até 1% de bateria, com limite diário 20 vezes maior que o padrão e limite mensal 60 vezes maior
  • Dispositivos de Qatar e UAE são restringidos a limites mais baixos que o padrão
  • Não é possível confirmar por que as camadas por país foram configuradas dessa forma; só é possível especular
  • Mesmo a cota padrão global permite 500MB por mês de tráfego de outras pessoas pela internet residencial do usuário

Configuração de teste e metodologia

  • Durante 30 dias, foi feita captura por proxy de interceptação TLS em dispositivos iOS executando apps parceiros instalados com consentimento; um app de exemplo é o XYO COIN com Bright SDK embutido
  • Análise estática realizada sobre brdsdk.framework version 1.532.120, binário iOS arm64
  • Os nomes de host específicos da Bright Data, as impressões digitais de certificado e a infraestrutura TLS são observáveis publicamente por qualquer pessoa que faça as mesmas requisições
  • O documento não contém dados de identificação por sessão da frota de pesquisa nem dos clientes de pesquisa

Linha do tempo

  • Em 11 de maio de 2026, foi enviado um e-mail de aviso prévio de publicação para privacy@brightdata.com
  • Até o momento da publicação, não houve resposta a esse aviso

Abordagens de defesa

  • O tráfego deixa fingerprints claros no perímetro da rede, e o SDK é estruturado para deixar símbolos identificáveis no binário do app
  • Abordagem 1: bloqueio por DNS, uma forma simples e eficaz para dispositivos roteados pela rede
    • proxyjs.brdtnet.com
    • proxyjs.luminatinet.com
    • proxyjs.bright-sdk.com
    • clientsdk.bright-sdk.com
    • clientsdk.brdtnet.com
  • Bloquear proxyjs.* interrompe os túneis de peer e não afeta clientes que usam legitimamente serviços de proxy da Bright Data para clientes em outros domínios
  • Abordagem 2: filtragem de TLS SNI, bloqueando ou alertando sobre handshakes TLS em que server_name corresponda a *.brdtnet.com, *.luminatinet.com, *.luminati.io
  • A filtragem por SNI funciona no perímetro da rede sem inspeção de TLS
  • Abordagem 3: detecção por impressão digital de certificado TLS, com bloqueio ou alerta com base nas seguintes impressões
    • .brdtnet.com → SHA256 313ce4ec7d5a51e5…
    • .luminatinet.com → SHA256 5028612e625befea…
  • As impressões digitais dos certificados permanecem estáveis até a troca dos certificados da Sectigo, e os certificados atuais são válidos até meados de 2026
  • Por causa das restrições relacionadas a use_netifs, as três camadas só funcionam quando o tráfego passa pelo perímetro da rede
  • Quando um dispositivo iOS usa rede celular, o binding use_netifs do SDK cria uma condição em que o tráfego de peer contorna completamente o Wi‑Fi corporativo
  • Um controle compensatório para frotas de dispositivos gerenciados é a varredura do binário do app via MDM, procurando os símbolos Swift BrdWebSocketFacade e BrdNetwork.DNSResolver nos apps instalados e proibindo em dispositivos corporativos os apps que contêm esses símbolos
  • Usuários domésticos preocupados com determinada smart TV ou app móvel podem bloquear os nomes de host acima nas configurações de DNS do roteador
  • Exemplos de ferramentas de bloqueio: Pi-hole, NextDNS, Cloudflare Gateway ou recurso equivalente do ISP

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Comentários do Lobste.rs

  • Falando desse protocolo, talvez desse para criar um honeypot reverso que voluntariamente devolve dados lixo gerados aleatoriamente em todas as requisições, o que poderia virar um projeto divertido de vibe coding para alguém com tokens sobrando

    • Nem parece necessário implementar o protocolo. Pelos logs, uma boa parte desses proxies residenciais falha completamente em se esconder, então dá para simplesmente despejar dados lixo neles com facilidade
      Nem precisa de vibe coding, e já existem dezenas de ferramentas capazes de fazer isso. Muitas delas já vêm fornecendo dados lixo infinitos para esses proxies há mais de um ano

  • Eu realmente não entendo por que conectar uma TV ou qualquer outro eletrodoméstico à internet. Não há um bom motivo para fazer isso

    • As pessoas assistem a serviços de streaming na TV. Conectar a TV à internet é a forma mais fácil de fazer isso