Como Funcionam as Ferramentas Grey-Hat do Facebook: Tokens, Cookies e RPA

As ferramentas grey-hat do Facebook não são magia. Elas exploram três mecanismos técnicos específicos para controlar contas publicitárias do Facebook fora do framework de autorização oficial do Meta. Compreender como funcionam as ferramentas grey hat do facebook a nível técnico é essencial para qualquer media buyer — quer as utilize, quer concorra contra pessoas que as utilizam, quer precise avaliar as implicações de segurança para as suas próprias contas.

Este é um mergulho técnico aprofundado. Vamos cobrir os mecanismos exatos, os fluxos de dados e os vetores de deteção para cada método. Sem comentário moral — apenas a realidade da engenharia.

Os Três Pilares do Acesso Grey-Hat

Toda ferramenta grey-hat de publicidade no Facebook depende de um ou mais destes três métodos de acesso:

1. Extração e abuso de tokens — Utilização de tokens EAAB para chamar a Marketing API do Facebook sem autorização OAuth oficial
2. Injeção de cookies — Importação de cookies de sessão para sequestrar sessões de navegador autenticadas
3. RPA (Robotic Process Automation) — Controlo da interface web do Facebook através de ações automatizadas do navegador

Algumas ferramentas utilizam um único método. As mais sofisticadas combinam os três. Vamos examinar cada um em detalhe.

Pilar 1: Tokens EAAB

O Que São os Tokens EAAB

Quando inicia sessão no Facebook e acede ao Gestor de Anúncios, a sessão do seu navegador gera tokens de acesso que autorizam pedidos à API. O mais valioso destes é o token EAAB (Extended Access) — um token de longa duração que começa com a string literal "EAAB" seguida de um payload codificado em base64.

Um token EAAB codifica:

• O ID do utilizador do utilizador do Facebook autenticado
• O ID da aplicação que gerou o token (normalmente a própria app do Gestor de Anúncios do Facebook)
• Escopos de permissões — o que o token está autorizado a fazer (ads_management, ads_read, business_management, etc.)
• Um timestamp de expiração — tipicamente 60-90 dias para tokens de longa duração
• Uma assinatura criptográfica que o Meta valida em cada chamada à API

Com um token EAAB válido, pode fazer as mesmas chamadas à API que o próprio Gestor de Anúncios do Facebook faz. Criar campanhas, modificar orçamentos, carregar criativos, extrair insights, gerir métodos de pagamento — tudo.

Como os Tokens São Extraídos

Método 1: Extração via Extensão Chrome

O método de extração mais comum utiliza extensões Chrome que intercetam pedidos de rede dentro do navegador. Quando abre o Gestor de Anúncios, o seu navegador faz chamadas à API para graph.facebook.com com o token EAAB no cabeçalho Authorization ou como parâmetro de URL.

Uma extensão Chrome com permissões webRequest pode intercetar estes pedidos e extrair o token. O fluxo:

Utilizador abre Gestor de Anúncios → Navegador faz chamada API → Extensão interceta pedido →
Token extraído do cabeçalho/URL → Armazenado localmente ou enviado para servidor externo

Extensões como "Facebook Token Extractor" (vários nomes, frequentemente removidas da Chrome Web Store) automatizam este processo. Algumas ferramentas grey-hat incluem as suas próprias extensões de marca.

Método 2: Conversão Cookie-to-Token

Os cookies de sessão do Facebook podem ser utilizados para gerar tokens programaticamente. O processo:

1. Extrair os cookies c_user e xs de uma sessão autenticada
2. Fazer um pedido ao endpoint OAuth do Facebook usando esses cookies como autenticação
3. Solicitar a geração de token para o ID da app do Gestor de Anúncios
4. Receber um token EAAB novo

Este método é como as ferramentas que trabalham com importação de cookies (ver Pilar 2) convertem o acesso à sessão em acesso à API.

Método 3: Abuso de OAuth

Algumas ferramentas registam-se como aplicações legítimas de desenvolvimento do Facebook e depois abusam do fluxo OAuth para solicitar permissões excessivas. O utilizador autoriza a app pensando que é uma ferramenta legítima, e a app armazena e utiliza o token para fins não autorizados.

Isto tornou-se menos viável à medida que o Meta apertou os processos de revisão de apps, mas apps legadas com permissões amplas ainda existem.

Como as Ferramentas Utilizam os Tokens

Uma vez extraído, o token é utilizado para fazer chamadas diretas à API de Marketing do Facebook:

Criação de Campanha:

POST /act_{ad_account_id}/campaigns
Authorization: Bearer EAAB...
Content-Type: application/json

{
  "name": "Campaign Name",
  "objective": "OUTCOME_SALES",
  "status": "ACTIVE",
  "special_ad_categories": []
}

Criação de Conjunto de Anúncios:

POST /act_{ad_account_id}/adsets
Authorization: Bearer EAAB...

{
  "campaign_id": "123456",
  "name": "Ad Set Name",
  "targeting": { ... },
  "billing_event": "IMPRESSIONS",
  "bid_amount": 1000,
  "daily_budget": 5000
}

Upload de Criativo:

POST /act_{ad_account_id}/adcreatives
Authorization: Bearer EAAB...

{
  "name": "Creative Name",
  "object_story_spec": { ... }
}

As chamadas à API são idênticas às que as ferramentas legítimas fazem. A diferença está no caminho de autorização — as ferramentas legítimas obtiveram o token através do fluxo oficial OAuth do Facebook com consentimento do utilizador e revisão da app. As ferramentas grey-hat extraíram-no de uma sessão de navegador.

Duração e Rotação de Tokens

Os tokens EAAB têm uma expiração incorporada, tipicamente 60-90 dias. No entanto, vários fatores podem invalidar um token mais cedo:

• Mudança de palavra-passe — Todos os tokens da conta são imediatamente invalidados
• Checkpoint de segurança — Os sistemas de segurança do Facebook podem invalidar tokens quando atividade suspeita é detetada
• Término de sessão — O utilizador encerrar todas as sessões invalida os tokens associados
• Desautorização de app — Remover permissões da app invalida os tokens emitidos para essa app

As ferramentas grey-hat lidam com a expiração de tokens através de:

• Re-extração automática — Extensões Chrome em execução em segundo plano extraem continuamente tokens novos
• Endpoints de renovação de token — Algumas ferramentas utilizam endpoints não documentados do Facebook para estender a duração do token
• Fallback para cookies — Quando um token expira, a ferramenta recorre ao acesso à sessão baseado em cookies para gerar um novo token

Sinais de Deteção para Abuso de Tokens

O Meta deteta a utilização não autorizada de tokens através de vários sinais:

1. Desajuste de ID da app — Os tokens gerados pelas próprias apps do Facebook (Gestor de Anúncios, Business Suite) carregam IDs de app específicos. O Meta consegue detetar quando estes tokens são utilizados de origens inesperadas
2. Análise de padrões de pedidos — Utilizadores humanos do Gestor de Anúncios criam uma campanha de cada vez com pausas. As ferramentas criam dezenas em rápida sucessão
3. Correlação de IP — O token foi gerado a partir de um IP (o navegador do utilizador) mas as chamadas à API vêm de outro IP (o servidor da ferramenta)
4. Contexto de navegador em falta — As chamadas legítimas à API do Gestor de Anúncios incluem cabeçalhos de navegador, padrões de timing e conexões web socket associadas. As chamadas API brutas das ferramentas carecem deste contexto
5. Anomalias de volume — Criar 50 campanhas em 50 contas em 5 minutos a partir de uma única assinatura de aplicação

Pilar 2: Injeção de Cookies

Os Cookies Relevantes

Quando inicia sessão no Facebook, o seu navegador recebe vários cookies de autenticação. Os dois críticos:

c_user — Contém o ID numérico do utilizador no Facebook. Diz ao Facebook a que conta pertence a sessão.

xs — O token de sessão. Esta é a credencial de autenticação real. É uma string codificada complexa que inclui metadados da sessão e uma assinatura criptográfica.

Juntos, estes dois cookies constituem uma sessão completa do Facebook. Qualquer navegador que apresente estes cookies ao facebook.com será reconhecido como o utilizador autenticado — sem necessidade de palavra-passe.

Cookies adicionais relevantes:

• fr — Cookie de rastreamento entre sites do Facebook
• datr — Cookie de identificação do navegador (persiste entre sessões)
• sb — Identificação do navegador, semelhante ao datr
• presence — Indicador de presença de chat/mensagens

Como Funciona a Injeção de Cookies

O processo de injeção:

1. Exportação: Os cookies são extraídos da sessão do navegador de origem. Isto pode ser feito através das ferramentas de desenvolvimento do navegador, extensões, ou acesso programático ao armazenamento de cookies. O resultado está tipicamente em formato de cookies Netscape ou JSON:

{
  "name": "c_user",
  "value": "100012345678",
  "domain": ".facebook.com",
  "path": "/",
  "httpOnly": true,
  "secure": true,
  "sameSite": "None",
  "expirationDate": 1742515200
}

2. Transferência: Os dados dos cookies são transferidos para o ambiente alvo — um perfil de navegador anti-detect, uma base de dados de contas da ferramenta, ou um repositório partilhado de equipa.

3. Importação: O navegador recetor carrega os cookies no seu armazenamento de cookies para o domínio facebook.com. Isto é tipicamente feito antes de navegar para o Facebook, para que o primeiro carregamento de página já esteja autenticado.

4. Validação de Sessão: O navegador navega para facebook.com. Os servidores do Facebook validam os cookies e servem a experiência de utilizador autenticado.

Porque é que a Injeção de Cookies é Popular

A injeção de cookies serve vários propósitos no ecossistema grey-hat:

Gestão de Contas Sem Palavras-Passe: Media buyers que compram contas em marketplaces recebem cookies, não palavras-passe. A palavra-passe original pode ser desconhecida ou alterada. A injeção de cookies é a única forma de aceder a essas contas.

Operações Multi-Conta: Gerir mais de 50 contas do Facebook exigiria mais de 50 combinações de email/palavra-passe. Os cookies são mais portáveis — cole uma string de cookies e o perfil está pronto.

Evitar Gatilhos de Login: Cada login no Facebook a partir de um novo dispositivo/localização aciona verificações de segurança — códigos de verificação, CAPTCHA, verificação de identidade. A injeção de cookies salta completamente o processo de login, evitando estes gatilhos.

Persistência de Sessão: Os cookies mantêm sessões entre reinícios do navegador. Um perfil de navegador anti-detect corretamente configurado com cookies injetados pode manter uma sessão do Facebook durante semanas sem re-autenticação.

Formatos de Cookies e Ferramentas

As ferramentas grey-hat aceitam cookies em vários formatos:

• Formato Netscape: O formato de exportação de cookies mais antigo. Texto simples, um cookie por linha. Compatibilidade universal.
• Formato JSON: Estruturado, usado pela maioria das ferramentas modernas. Cada cookie é um objeto JSON com todos os atributos.
• String codificada em Base64: Alguns marketplaces vendem cookies como uma única string codificada que as ferramentas descodificam automaticamente.
• Exportação de perfil de navegador: Navegadores anti-detect podem exportar perfis inteiros incluindo cookies, localStorage e IndexedDB.

Ferramentas para Gestão de Cookies:

• EditThisCookie (extensão Chrome) — Exportação/importação manual de cookies
• Cookie-Editor — Funcionalidade semelhante, mais mantida
• Importadores de navegadores anti-detect — AdsPower, GoLogin, Multilogin todos têm diálogos de importação de cookies integrados
• Scripts personalizados — A API page.setCookie() do Puppeteer permite a injeção programática de cookies

Segurança e Riscos dos Cookies

A injeção de cookies acarreta riscos de segurança significativos:

Roubo de Cookies: Se alguém obtiver os seus cookies do Facebook, tem acesso total à sua conta. Os cookies vendidos em marketplaces podem ter sido roubados via malware, phishing ou violações de dados — não exportados voluntariamente pelos proprietários das contas.

Sequestro de Sessão: O Facebook não consegue distinguir entre o utilizador original e alguém que injetou os seus cookies. Não há checkpoint de autenticação de dois fatores para acesso à sessão baseado em cookies.

Compromisso em Cascata: Se a base de dados de uma ferramenta for violada, cada cookie armazenado torna-se acessível a atacantes. A violação do AdsPower em dezembro de 2024 demonstrou este risco — a extensão Chrome comprometida acedeu aos dados de sessão dos utilizadores em múltiplas plataformas.

Expiração e Invalidação: Os cookies expiram. O Facebook roda periodicamente os tokens de sessão. Um cookie que funciona hoje pode não funcionar amanhã, criando uma necessidade constante de cookies novos — e um mercado constante de fornecedores de cookies.

Pilar 3: RPA (Robotic Process Automation)

O Que Significa RPA Neste Contexto

RPA na publicidade do Facebook significa software que controla a interface web do Facebook simulando ações humanas. Em vez de chamar APIs com tokens, as ferramentas RPA abrem um navegador, navegam para o Gestor de Anúncios, clicam em botões, preenchem formulários e submetem campanhas — exatamente como um humano faria, mas mais rápido.

A Stack Tecnológica

Frameworks de Automação de Navegador:

• Puppeteer — Biblioteca Node.js para controlar Chromium. O framework mais comum para automação do Facebook
• Playwright — Biblioteca de automação multi-navegador da Microsoft. Suporta Chromium, Firefox e WebKit
• Selenium — Framework mais antigo, ainda utilizado em algumas ferramentas. Mais lento mas maduro

Integração com Navegadores Anti-Detect:

Os navegadores anti-detect expõem interfaces de automação às quais Puppeteer/Playwright se podem conectar. O fluxo:

Navegador Anti-Detect (fingerprint único) → Puppeteer conecta via CDP →
Script navega UI do Facebook → Ações executadas como se fosse um utilizador humano

O AdsPower, por exemplo, expõe um endpoint Chrome DevTools Protocol (CDP) para cada perfil. Um script Puppeteer conecta-se a este endpoint e tem controlo total sobre a sessão do navegador — com o fingerprint anti-detect intacto.

Como Funciona o Autolaunch via RPA

O workflow de "autolaunch" (автозалив) através de RPA:

1. Seleção de perfil: O script seleciona um perfil de navegador anti-detect com uma sessão ativa do Facebook
2. Navegação: O navegador abre facebook.com/adsmanager/creation
3. Configuração de campanha: O script preenche objetivo, orçamento, calendário
4. Configuração do conjunto de anúncios: Segmentação, posicionamento, objetivo de otimização
5. Upload de criativo: Upload de imagem/vídeo, texto do anúncio, URL, CTA
6. Revisão e publicação: Submeter a campanha para revisão
7. Ciclo: Repetir para a próxima conta/perfil

Cada passo envolve:

• Deteção de elementos: Encontrar o botão, campo de entrada ou dropdown correto por seletor CSS, XPath ou label ARIA
• Interação humanizada: Adicionar atrasos aleatórios entre ações (200-2000ms), mover o rato naturalmente, fazer scroll até aos elementos antes de clicar
• Tratamento de erros: Detetar popups, desafios CAPTCHA, restrições de conta e tratar cada caso
• Verificação: Confirmar que cada passo foi concluído com sucesso antes de prosseguir

Vantagens do RPA Face ao Acesso por Token

Menor Risco de Deteção: O RPA gera eventos de navegador genuínos — movimentos do rato, entrada de teclado, eventos de scroll, mudanças de foco. Os sistemas de deteção do Meta veem uma sessão de navegador que parece humana.

Sem Dependência de Token: O RPA não precisa de um token EAAB. Funciona com qualquer sessão de navegador autenticada (incluindo sessões baseadas em cookies).

Resiliência a Mudanças de UI: Ferramentas RPA avançadas utilizam reconhecimento visual de elementos em vez de seletores CSS fixos. Se o Facebook mover um botão, a ferramenta ainda consegue encontrá-lo pela sua aparência visual.

Acesso Completo a Funcionalidades: A UI do Facebook expõe funcionalidades que a Marketing API não oferece — certas opções de segmentação, ferramentas de criativos e definições de conta são exclusivas da UI.

Desvantagens do RPA

Velocidade: O RPA é inerentemente mais lento que chamadas à API. Criar uma campanha via API demora 1-3 segundos. Via RPA, demora 30-120 segundos incluindo os atrasos humanizados.

Fragilidade: A UI do Facebook muda frequentemente. Uma alteração de nome de classe, um deslocamento de layout ou um novo diálogo modal pode quebrar os scripts. A carga de manutenção é elevada.

Limitações de Escala: Cada operação RPA requer uma instância de navegador. Executar 50 criações de campanhas simultâneas requer 50 instâncias de navegador — consumo significativo de CPU e RAM.

Recuperação de Erros: Quando algo corre mal a meio do processo (popup inesperado, falha no carregamento de página, elemento não encontrado), a recuperação é complexa. As chamadas à API baseadas em tokens falham de forma limpa com códigos de erro. As falhas de RPA podem deixar sessões de navegador em estados desconhecidos.

Abordagens Híbridas

As plataformas grey-hat mais sofisticadas combinam os três métodos:

1. Injeção de cookies para estabelecer sessões em perfis de navegador anti-detect
2. Extração de tokens dessas sessões para operações rápidas via API
3. Fallback para RPA para operações que requerem interação com o navegador ou quando os tokens são sinalizados

Esta abordagem em camadas proporciona flexibilidade máxima. O Dolphin Cloud, por exemplo, pode criar campanhas via chamadas à API por token para velocidade, recorrer ao RPA quando os padrões de API acionam a deteção, e utilizar injeção de cookies para manter sessões persistentes em dezenas de contas.

A Corrida Armamentista da Deteção

O Meta investe fortemente na deteção do uso não autorizado de ferramentas. Os sinais de deteção abrangem os três métodos de acesso:

Análise Comportamental

• Padrões de criação de campanhas demasiado uniformes (mesma estrutura, timing, convenções de nomenclatura)
• Horários de atividade que não correspondem aos padrões históricos da conta
• Atividade simultânea em múltiplas contas correlacionada (mesmos criativos, mesma segmentação, mesmo timing)

Sinais Técnicos

• Pedidos à API sem assinaturas de app adequadas
• Fingerprints de navegador que são estatisticamente demasiado únicos (ironicamente, os navegadores anti-detect podem criar fingerprints demasiado perfeitos)
• Strings de renderizador WebGL que não correspondem ao hardware reportado
• Desajustes de fuso horário entre fingerprint, IP e definições da conta

Análise de Rede

• Múltiplas contas acedidas a partir do mesmo intervalo de IPs
• Padrões de utilização de proxy (proxies residenciais de fornecedores conhecidos por fraude publicitária)
• Impossibilidades geográficas (conta com sessão iniciada em dois continentes em minutos)

Análise de Criativos e Conteúdo

• Criativos publicitários idênticos ou quase idênticos entre contas
• Páginas de destino que correspondem a padrões de cloaking conhecidos
• Agrupamento por similaridade de texto publicitário entre contas sinalizadas

Cada melhoria de deteção pelo Meta desencadeia contramedidas dos desenvolvedores de ferramentas — novas técnicas de fingerprinting, simulação comportamental melhorada, ofuscação mais sofisticada. Esta corrida armamentista é contínua e está a acelerar.

A Alternativa Oficial

Para media buyers que querem as capacidades de automação sem os riscos técnicos, ferramentas como AdRow fornecem acesso oficial à Marketing API com:

• Autenticação baseada em OAuth — sem tokens para extrair, sem cookies para injetar
• Operações de campanha em bulk — criar e gerir campanhas em escala através da API documentada
• Regras automatizadas — lógica condicional que atua nas campanhas com base em dados de desempenho
• Zero risco de deteção — todas as operações são autorizadas e esperadas pelos sistemas do Meta

O mapa completo do ecossistema fornece contexto mais amplo sobre onde estas ferramentas se encaixam, e o explicador de autolaunch cobre os workflows específicos de criação de campanhas em detalhe.

Compreender como as ferramentas grey-hat funcionam não é um endosso da sua utilização. É literacia técnica que todo media buyer sério deveria ter — porque os seus concorrentes certamente têm.