Como remover o cartão de detecção do site: auditoria de scripts de fingerprint

```html

No dia 20 de agosto de 2026, o desenvolvedor Matt Callaghan (blog laserphile) publicou uma análise de um bug estranho: seus fones de ouvido Bluetooth com multipoint paravam de alternar entre o computador e o telefone. Sempre que uma aba do AliExpress estava aberta. Ele não ficou adivinhando — instrumentou as APIs do navegador e viu o que estava acontecendo dentro da página. Descobriu que dois scripts ofuscados do stack anti-fraude da Alibaba estavam levantando um contexto de áudio e coletando impressões do dispositivo através de um som que ninguém ouve.

Esta é uma ilustração perfeita do que quase ninguém faz antes de configurar perfis ou iniciar um parser: não lê o stack de detecção da plataforma, mas tenta adivinhar. Abaixo está um método prático de como mapear a detecção de um site específico com suas próprias mãos, em uma hora, sem reverter a ofuscação e sem serviços pagos.

Por que mapear a detecção

O ciclo típico é assim: contas são banidas — ajustamos as configurações do navegador anti-detect com base em palpites — mudamos o proxy — banidos novamente. Entre "banidos" e "configurações" não há dados: não está claro o que exatamente a plataforma lê e em qual camada ela captura.

O mapa de detecção fecha essa lacuna. É uma lista: qual fornecedor de proteção está em uso, quais scripts o implementam, quais APIs eles tocam e para onde o resultado vai. A partir daí, fica claro onde está realmente o ponto crítico — no IP, na impressão de rede ou na camada de hardware do navegador. Isso é igualmente útil para três públicos:

Multi-contas — entender qual sinal faz os perfis se fundirem. Os IPs são diferentes, mas o stack de áudio, o renderizador WebGL e o hardwareConcurrency costumam ser os mesmos para toda a fazenda.
Scraping — entender se vale a pena levantar o navegador ou se a tarefa pode ser resolvida com um cliente HTTP com uma impressão TLS correta.
Privacidade — ver o que exatamente a loja ou serviço coleta sobre seu dispositivo além dos cookies.

Passo 1. Identificar o fornecedor de proteção pela rede

A primeira coisa que você faz é abrir o DevTools na aba Network, carregar a página e olhar os cabeçalhos e cookies do primeiro documento. Os sinais de identificação são conhecidos e estáveis:

CF-RAY nos cabeçalhos de resposta e cookie cf_clearance — Cloudflare.
Cookie _abck e script com a função bmak — Akamai Bot Manager.
Variáveis e cookies com o prefixo _px — PerimeterX (HUMAN).
Cookie datadome e um JS separado do domínio do fornecedor — DataDome.
Código de status 429 sem corpo de resposta — assinatura característica da Kasada.

Se você não quiser fazer isso manualmente, existem detectores abertos como microlinkhq/is-antibot (30+ provedores) e extensões de navegador que detectam 26+ fornecedores. Eles fornecem uma resposta rápida inicial, mas não respondem à pergunta principal — o que exatamente está sendo medido no seu navegador. Para isso, você precisa ir mais longe.

Passo 2. Extrair a lista de scripts suspeitos

Filtre a aba Network pelo tipo JS e anote tudo que é carregado de um domínio diferente ou está em diretórios de serviço. No caso do AliExpress, foram dois arquivos com caminhos claramente de serviço:

assets.aliexpress-media.com/g/AWSC/uab/1.140.0/collina.js
assets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/fireyejs.js

Sinais de um script anti-fraude: código ofuscado, versão no caminho, subdomínio separado para estática, ausência de qualquer ligação com a parte visual da página. Não é necessário abrir e ler a ofuscação — no próximo passo, o script contará sobre si mesmo.

Passo 3. Instrumentar o fingerprint-API

Este é o núcleo do método e exatamente o que Callaghan fez: ele envolveu o construtor AudioContext e AudioNode.prototype.connect(), após o que viu dois contextos de áudio ativos na página, onde não há nenhum elemento de mídia e nenhuma chamada play().

A lógica é simples: você substitui o método que lhe interessa pela sua própria função, que registra a chamada com a pilha e passa o controle para o original. A pilha de chamadas mostra qual script exatamente acionou a API. Inserir esse snippet é mais fácil através do DevTools Sources → Snippets ou através de uma extensão que executa código no document-start — é importante fazer isso antes de carregar o script anti-fraude.

Um conjunto mínimo de armadilhas que cobre a maioria dos sinais:

HTMLCanvasElement.prototype.toDataURL e getImageData — impressão de canvas.
WebGLRenderingContext.prototype.getParameter — modelo da placa de vídeo e driver, precisão dos shaders.
AudioContext / OfflineAudioContext e AudioNode.prototype.connect — impressão de áudio.
Getters navigator.hardwareConcurrency, navigator.deviceMemory, navigator.plugins, navigator.webdriver.
RTCPeerConnection — WebRTC e endereços locais.
screen.width/height, devicePixelRatio, Intl.DateTimeFormat().resolvedOptions() — tela e fuso horário.
navigator.mediaDevices.enumerateDevices — lista de dispositivos de áudio e vídeo.

Após a execução, você terá uma lista: quais dessas APIs foram realmente chamadas, quantas vezes e por quem. No caso analisado, os scripts da Alibaba acessaram o canvas e toDataURL, o renderizador WebGL e a precisão dos shaders, áudio através de oscilador e analisador, tamanhos de tela e devicePixelRatio, hardwareConcurrency e deviceMemory, plugins, suporte a codecs, WebRTC, tempos de desempenho, padrões de movimento do mouse e toques, sensores de movimento do dispositivo e propriedades indicadoras de automação.

O que exatamente o áudio gráfico fez

É útil entender como a medição se parece para reconhecê-la em outros lugares. O gráfico era assim: oscilador dente de serra → AnalyserNode → ScriptProcessorNode, que lê o resultado da análise → GainNode com ganho zero → destination. Não há som, o volume não importa — ele simplesmente não existe. Mas a conexão com destination, na formulação do autor, faz o navegador processar ativamente o gráfico, embora o volume final seja zero. Foi exatamente o caminho de áudio ativo que manteve o Bluetooth aberto, quebrando a alternância multipoint dos fones de ouvido.

As diferenças no processamento desse sinal dependem do processador, hardware de áudio, sistema operacional, navegador e drivers — daí o identificador estável, que sobrevive à troca de IP e limpeza de cookies. A análise detalhada exatamente dessa camada e a configuração de perfis para ela estão no artigo sobre proteção contra Audio Context Fingerprinting.

Passo 4. Capturar o envio do resultado

A coleta sem envio é inútil, portanto o próximo passo é encontrar para onde vai a impressão coletada. Filtre a aba Network por XHR/Fetch e veja separadamente as solicitações do tipo ping — elas são geradas por navigator.sendBeacon, que os scripts de telemetria adoram usar, pois sobrevive à saída da página.

Praticamente sempre é útil envolver fetch, XMLHttpRequest.prototype.send e navigator.sendBeacon — assim você verá o corpo da solicitação antes que ele saia. Prepare-se para que o conteúdo seja serializado e criptografado: no caso do AliExpress, os dados foram criptografados antes de serem enviados para a telemetria da Alibaba. Mas mesmo assim, você obtém dois fatos: o endereço do receptor e o momento do envio em relação às suas ações.

Se o site funciona não apenas no navegador, mas através de um aplicativo móvel ou cliente separado, a mesma questão é resolvida no nível do tráfego, e não do DOM — a metodologia de interceptação e análise está descrita na análise da auditoria de tráfego via mitmproxy.

Passo 5. Comparar o mapa com seu perfil

Agora você tem uma lista de sinais que a plataforma realmente lê. Resta verificar o que seu perfil de trabalho está enviando por esses sinais. A ordem é a seguinte: você coleta os valores em um navegador comum, depois em cada perfil de anti-detect e compara.

Duas coisas são importantes ao mesmo tempo: os valores devem diferir entre os perfis e ser estáveis dentro de um único perfil entre as sessões. Um perfil cujo fingerprint muda a cada inicialização parece para o anti-fraude tão suspeito quanto dez perfis com impressões idênticas.

Verifique separadamente se a substituição realmente existe na camada necessária. Aqui, a variação entre navegadores é significativa: o Firefox a partir da versão 118 fornece uma saída constante de WebAudio, e de acordo com a análise, 99,24% dos usuários se resumem a três valores; o Brave insere dados aleatórios e desde 22 de agosto de 2026 bloqueia especificamente esses scripts do AliExpress, lembrando que a proteção contra impressão de áudio está ativada por padrão há mais de seis anos; o Safari insere erros nos buffers de áudio; o Chrome não possui proteções agressivas.

Armadilhas

O script já teve tempo de agir. Bloquear o arquivo não elimina um contexto de áudio já criado — o autor observa diretamente que as abas abertas devem ser fechadas. O mesmo se aplica à sua instrumentação: se a função envolvente foi inserida após o script, você não verá nada.
O bloqueio quebra a funcionalidade. O stack anti-fraude frequentemente responde por coisas legítimas — autenticação, pagamento, proteção contra bots de abusos reais. Mapear a detecção e cortar scripts são tarefas diferentes; a segunda quebra o site.
Não há uma única versão de detecção. O stack pode variar por geolocalização, tipo de dispositivo e grupo A/B. Faz sentido mapear a partir do IP e do dispositivo que você realmente usa, caso contrário, você está descrevendo uma configuração de outra pessoa.
A própria instrumentação é detectável. Métodos nativos redefinidos perdem o toString correto, e um depurador conectado deixa rastros. Para exploração, isso não é crítico, mas não confunda um perfil de exploração com um de combate — as técnicas de mascaramento de automação estão detalhadas no guia sobre mascaramento de navegador headless.

Que proxy é necessário para o resultado

A principal conclusão prática desse mapa é quase sempre uma: o IP é apenas a primeira camada, e ele é verificado antes de todas as outras. Se o anti-fraude já na etapa de solicitação vê o endereço do host, o áudio gráfico e o canvas simplesmente não chegarão — você receberá um desafio ou uma saída vazia e estará consertando a coisa errada.

Portanto, a lógica de escolha é a seguinte. Para plataformas com um stack sério (Akamai, DataDome, PerimeterX, desenvolvimentos próprios de nível Alibaba), a base são proxies residenciais — endereços de provedores reais que não são filtrados no primeiro filtro. Para aplicativos móveis e plataformas onde a principal audiência está usando smartphones, os proxies móveis se aproximam mais do perfil natural: o CGNAT do operador torna o endereço compartilhado entre muitos usuários reais.

E o inverso também é verdadeiro: se o mapa mostrou que a plataforma se limita a cabeçalhos e cookies, e não há um fingerprint JS pesado, — uma fazenda de navegadores é excessiva, a tarefa é resolvida com um cliente HTTP comum e endereços de data center.

Conclusão

O caso dos fones de ouvido é valioso não pelo próprio fato da impressão de áudio — isso já é conhecido há anos. É valioso pelo método: a pessoa não se deixou levar por suposições, mas envolveu dois métodos da API do navegador e em uma noite obteve uma lista completa do que está sendo coletado e o endereço para onde isso vai. Esse mesmo truque leva uma hora em qualquer plataforma com a qual você trabalha e substitui meses de ajustes aleatórios. Mapeie a detecção antes de consertar os bans — caso contrário, há o risco de gastar orçamento em proxies onde o problema estava no mesmo renderizador WebGL em todos os perfis.