← Voltar ao blog

Antidetect Gratuito do GitHub: Como Testar a Versão Antes de Usar Proxy

No GitHub, toda semana saem "anti-detectores open-source gratuitos", e em 2026, os criminosos clonam repositórios em tendência em questão de horas e inserem stealers e bots proxy como o GhostSocks. Verificação passo a passo: original ou clone, de onde vem o binário, qual código ler, execução em sandbox, verificação de impressão digital e quais proxies fornecer à nova ferramenta.

📅6 de outubro de 2026
Antidetect Gratuito do GitHub: Como Testar a Versão Antes de Usar Proxy

No outono de 2026, quase toda semana aparece um novo "anti-detect gratuito e open-source" no GitHub: um fork do Chromium com substituição de impressão digital, gerenciador de perfis, uma camada para Playwright para agentes de IA. A tentação é compreensível: um anti-detect pago para 50–100 perfis custa dezenas de dólares por mês, e aqui — de graça. Mas você entrega a esse programa o que há de mais valioso: logins de proxy, cookies de contas de trabalho, às vezes acessos a contas de anúncios e carteiras. Abaixo está um guia passo a passo que vale a pena seguir antes que o primeiro perfil veja seus proxies.

Por que isso não é paranoia: o que está acontecendo no GitHub em 2026

O GitHub se tornou um canal de entrega de malware completo este ano. Várias campanhas documentadas mostram como isso se parece na prática:

  • Clones de projetos populares. Operação SmartLoader + StealC: 109 repositórios falsos em 103 contas. Os criminosos copiavam a estrutura e o README de projetos reais, mas em vez do código-fonte, colocavam um botão "baixar ZIP" com um carregador e um infostealer. A campanha durou mais de sete semanas.
  • Velocidade de reação. Repositórios falsos do DeepSeek TUI apareceram em quatro horas após o anúncio oficial da ferramenta. Tudo o que está em alta é clonado quase instantaneamente.
  • Código oculto. A campanha GlassWorm (433+ componentes infectados no GitHub, npm, VS Code Marketplace e OpenVSX) escondia lógica maliciosa em caracteres Unicode invisíveis, que não são visíveis durante uma visualização normal de diff.
  • Proxy-bot incluído. Na falsa "vazamento" do Claude Code e nas falsificações do DeepSeek TUI, junto com o stealer Vidar, era instalado o GhostSocks — um malware que transforma o computador da vítima em um proxy SOCKS5.

O último ponto é especialmente desagradável para o nosso público. O GhostSocks, segundo a Infrawatch, é distribuído em conjunto com o stealer LummaC2 e vendido como um serviço: ele encapsula o túnel em TLS e fornece ao locatário um IP "limpo" da máquina infectada. Ou seja, o "anti-detect gratuito" pode não apenas roubar suas contas, mas também transformar seu próprio IP em um nó de saída de um botnet alheio. Daqui a algumas semanas, você ficará surpreso ao descobrir por que seu endereço residencial apareceu em bases de dados de spam.

Como os anti-detect open-source se diferenciam uns dos outros

Antes de verificar uma compilação específica, é útil entender a que tipo ela pertence — isso determina o que exatamente observar.

  • Patches no nível do motor. Exemplo — Camoufox: uma compilação do Firefox, onde a impressão digital (navegador, tela, WebGL, fontes, fuso horário, WebRTC) é substituída no código C++, e não por injeção JS. O repositório oficial é daijro/camoufox, o pacote no PyPI é chamado camoufox. Um detalhe importante: segundo o próprio projeto, o código-fonte se tornou completamente aberto apenas a partir da versão v146; nas versões v135.0.1-beta.24 e anteriores, havia componentes fechados. Em 2026, o projeto teve uma longa pausa no suporte, e os analistas da Centinel detectaram no benchmark de setembro do Camoufox.
  • Camadas sobre o Chrome comum. undetected-chromedriver, modo UC no SeleniumBase. Por si só, são transparentes, mas contra Cloudflare, DataDome e Kasada, funcionam cada vez pior: ajustam principalmente a camada JavaScript.
  • Novos forks do Chromium com binários prontos. O grupo mais arriscado: um projeto com algumas dezenas de estrelas que oferece para baixar um .exe ou .dmg com mais de 200 MB. Verificar se o binário foi realmente construído a partir do código publicado não é algo que um usuário comum pode fazer.

Verificação passo a passo antes da instalação

Passo 1. Certifique-se de que é o original, e não um clone

  1. Encontre o projeto no site oficial ou na documentação, e não na busca do GitHub. Clones frequentemente têm o mesmo nome e uma cópia do README.
  2. Compare a data de criação do repositório, o número de commits e autores. Um clone geralmente foi criado recentemente, tem 1–3 commits ("Initial commit", "Update README"), e as estrelas são inflacionadas em poucos dias.
  3. Observe os Issues e Discussions. Um projeto ativo tem relatórios de bugs de várias pessoas e respostas do mantenedor. Issues fechados em um projeto "popular" são um sinal vermelho.
  4. Forks do tipo random-nick/camoufox não são iguais ao original, mesmo que na descrição esteja indicado "oficial".

Passo 2. Verifique de onde vem o binário

  1. O link para download deve levar à aba Releases do mesmo repositório, e não para um serviço de compartilhamento de arquivos, Google Drive ou "espelho" no README. O botão "Download ZIP" na descrição é o mesmo truque da campanha SmartLoader.
  2. Verifique se o release é construído através do GitHub Actions a partir do código público. Existe um workflow de construção, os tags coincidem? Se o projeto publica certificações de construção, verifique-as com o comando gh attestation verify.
  3. Confirme a soma de verificação do arquivo (SHA-256) com a indicada no release. Se as somas não estiverem indicadas — isso é um motivo para ficar alerta, e não para pular essa etapa.
  4. Carregue o arquivo no VirusTotal. Zero detecções não garante nada: novos stealers costumam estar limpos nos primeiros dias. Mas detecções com as etiquetas stealer, Lumma, Vidar ou proxy — são motivo para parar imediatamente.

Passo 3. Leia o código onde escondem surpresas

Não é necessário ler todo o Chromium. Basta observar os pontos pelos quais o programa se conecta à rede e executa algo:

  • scripts de instalação e pós-instalação (postinstall em package.json, setup.py, install.sh, scripts PowerShell);
  • módulo de "atualizações" e "telemetria": para onde vão as requisições e o que é transmitido;
  • quaisquer chamadas a URLs externas, strings base64, carregamento de código de um endereço remoto e sua execução;
  • caracteres invisíveis: passe os códigos-fonte por uma busca de caracteres fora do ASCII. Foi assim que o GlassWorm se escondeu.

Se o projeto for um "launcher", que ao ser iniciado pela primeira vez baixa o motor de seu próprio servidor, os códigos-fonte do launcher quase não dizem nada sobre o que estará no seu disco.

Passo 4. Primeiro lançamento — apenas em sandbox

  1. Execute o programa em uma máquina virtual separada ou em um VPS limpo sem seus dados de trabalho.
  2. Não conecte proxies e contas de trabalho. Para a primeira execução, um proxy de teste com baixo volume de tráfego é suficiente.
  3. Observe as conexões de rede do processo (Little Snitch, Wireshark, netstat/ss). O anti-detect precisa de conexões para os sites que você abre e para o seu proxy. Conexões constantes para IPs e portas desconhecidas, especialmente conexões TLS de entrada ou "penduradas" para um único endereço, são um sinal de backdoor ou proxy-bot.
  4. Verifique a inicialização automática e o agendador de tarefas após a instalação: surgiram novos serviços, tarefas cron ou LaunchAgents que você não instalou.

Passo 5. Verifique se a própria impressão digital não o entrega

Um anti-detect honesto, mas ruim, também é perigoso — simplesmente de outra forma: contas são banidas devido a inconsistências. Passe o perfil por vários verificadores e verifique vazamentos de rede. A ordem detalhada foi discutida no material "Vazamentos WebRTC e DNS: 7 verificações antes de entrar no perfil". O mínimo para qualquer nova compilação:

  • WebRTC não deve revelar o IP local e o real externo, apenas o IP do proxy;
  • As requisições DNS devem passar pelo proxy, e não pelo provedor;
  • o fuso horário, idioma e geolocalização devem coincidir com o país do proxy;
  • User-Agent e Client Hints devem corresponder à versão real do motor (um fork do Chromium 151 que se apresenta como Chrome 153 é detectado imediatamente).

Armadilhas que são esquecidas

  • Licença. "Código aberto" nem sempre significa "pode ser usado para negócios". Por exemplo, o Damru tem a licença PolyForm Noncommercial: o uso comercial não é permitido.
  • Projetos abandonados. Um anti-detect sem atualizações envelhece em meses: a versão base do navegador fica desatualizada, e os detectores aprendem com seus artefatos. A história do Camoufox mostra que mesmo um projeto forte pode ficar fora da corrida por um ano.
  • Sincronização de perfis "na nuvem". Se a compilação gratuita oferece armazenamento em nuvem para perfis, seus cookies e senhas de proxy estão em um servidor alheio. Descubra de quem é exatamente.
  • Chaves e senhas de proxy em texto claro. Muitos gerenciadores caseiros armazenam logins de proxy em JSON não criptografado ao lado do perfil. O stealer os pegará primeiro.
  • Anti-detects pagos hackeados. "Crackeados" Multilogin, Dolphin e similares são uma isca clássica para stealers. Isso é pior do que qualquer open-source: não há código algum, e o distribuidor já sabe que a vítima trabalha com contas.

Quais proxies fornecer a um novo anti-detect

Separe o teste do trabalho. Na fase de verificação, use um proxy separado com um mínimo de tráfego restante: se a compilação for maliciosa, você perderá centavos, e não um pool de trabalho. Para perfis de produção, são necessários proxies que não estraguem a impressão digital: proxies residenciais fornecem IPs de provedores domésticos e são adequados para a maioria dos cenários de multi-contas, enquanto para redes sociais e contas de anúncios com forte anti-fraude, proxies móveis com endereços de operadoras funcionam melhor.

Uma regra separada: para cada nova ferramenta — sua sub-conta ou seu login de proxy. Se o programa acabar sendo "com surpresa", você mudará uma senha e não precisará se lembrar de onde mais inseriu a comum. O mesmo princípio de isolamento de segredos salvou equipes de campanhas como Flooding Dropper no npm, que caçavam exatamente as credenciais de equipes de scraping de proxies.

Lista de verificação curta

  1. Encontrei o projeto através do site oficial, e não pela busca; não é um clone ou um fork aleatório.
  2. O binário está em Releases, construído no CI, e a soma de verificação coincide.
  3. Verifiquei os scripts de instalação, atualizações e telemetria, procurei caracteres invisíveis.
  4. Primeiro lançamento — em uma máquina virtual, com um proxy de teste, sob monitoramento da rede e inicialização automática.
  5. A impressão digital passou pelas verificações de WebRTC, DNS, fuso horário e Client Hints.
  6. A licença permite meu uso, o projeto foi atualizado nos últimos meses.
  7. Para a nova ferramenta — logins de proxy separados.

Conclusão

Um anti-detect gratuito do GitHub pode ser uma ótima ferramenta, mas apenas após verificação. Em 2026, os atacantes clonam repositórios em alta em horas, escondem código em caracteres invisíveis e inserem proxies-bots junto aos stealers, que transformam seu computador em um nó de saída de outra pessoa. Meia hora de verificação com a lista de verificação custa menos do que um conjunto de cookies roubados de uma conta de anúncios. E um proxy de teste separado com pouco tráfego restante torna essa verificação quase gratuita.