fzakaria/anubis-fetchComo o curl, mas atravessa as proteções anti-bot do Anubis e do Cloudflare.
$ nix run github:fzakaria/anubis-fetch -- https://lore.kernel.org/linux-mm/some-thread/T/
Um CLI rápido (em Go) para buscar URLs atrás de muros de proof-of-work do Anubis e verificações de impressão digital da Cloudflare — resolvendo o desafio em processo, e só indo para um navegador real quando necessário.
Um número crescente de sites — lore.kernel.org, GNOME, kernel.org e muitos outros — ficam atrás do Anubis, um muro anti-bots que faz o seu navegador resolver um proof-of-work SHA-256 antes de servir qualquer conteúdo. Ele é ótimo para impedir scrapers. Também é ótimo para impedir você quando você só quer usar curl em um tópico de lista de discussão:
$ curl -s https://lore.kernel.org/linux-mm/some-thread/T/ | grep -o '<title>.*</title>'
<title>Making sure you're not a bot!</title> # 🤢
O anubis-fetch traz a página real:
$ anubis-fetch https://lore.kernel.org/linux-mm/some-thread/T/ | grep -o '<title>.*</title>'
<title>[PATCH 0/2] ...</title> # 🥳
Os muros anti-bots vivem em duas camadas diferentes, e o anubis-fetch lida com ambas, começando pelo passo mais barato:
techaro.lol-anubis-auth) depois que você passa uma vez; um navegador não é desafiado novamente na próxima visita, e nós também não. Os cookies são persistidos por host (veja Persistência de cookies).req personificando um Chrome real — mesma impressão digital TLS/JA3 + HTTP/2 — o que também elimina a impressão digital passiva da Cloudflare. Se a resposta for um desafio do Anubis, forçamos o nonce por brute force e o submetemos. Sem navegador, ~0.6s.chromedp, que executa qualquer JavaScript que o site sirva.[!NOTE] O fallback é acionado para: métodos de desafio
preact/metarefreshdo Anubis, um método desconhecido/futuro, uma dificuldade alta demais para brute force, uma solução rejeitada, ou um desafio JS ativo da Cloudflare (Managed Challenge / Turnstile / "I'm Under Attack"). A personificação elimina o Cloudflare passivo; apenas um navegador elimina as camadas JS ativas. Então oanubis-fetchdegrada para "mais lento", nunca "quebrado".
Porque é ~4× mais lento e arrasta um Chromium de ~200 MB em cada busca. O resolvedor em processo é o caso comum; o navegador é a rede de segurança.
| Caminho | Tempo decorrido | Precisa de Chromium |
|---|---|---|
| Resolvedor (proof-of-work do Anubis) | ~0.6s | não |
| Fallback do navegador | ~2.0s | sim |
O Anubis incorpora um desafio como JSON na página:
{"rules":{"algorithm":"fast","difficulty":4},
"challenge":{"id":"…","method":"fast","randomData":"6214bd88…","difficulty":4}}
Resolvê-lo significa encontrar um nonce tal que hex(sha256(randomData ‖ nonce)) comece com difficulty caracteres zero (o nonce é sua string em base 10). Em seguida, devolvemos a resposta:
GET /.within.website/x/cmd/anubis/api/pass-challenge?id=…&response=<hash>&nonce=<n>&redir=<url>&elapsedTime=<ms>
…o que define o cookie de autenticação e redireciona para a página real. A dificuldade 4 (o padrão em lore/kernel.org/GNOME) é ~65 mil hashes — submilissegundo em Go.
Execute diretamente:
$ nix run github:fzakaria/anubis-fetch -- <url>
Instale no seu perfil:
$ nix profile install github:fzakaria/anubis-fetch
Ou adicione ao seu próprio flake:
{
inputs.anubis-fetch.url = "github:fzakaria/anubis-fetch";
# then, e.g. in home.packages / environment.systemPackages:
# inputs.anubis-fetch.packages.${system}.default
}
$ anubis-fetch [flags] URL
| Flag | Descrição |
|---|---|
--text | renderizar texto simples legível em vez de HTML |
--timeout MS | timeout por etapa em milissegundos (padrão 30000) |
--ua STRING | substituir o User-Agent |
--browser | pular o resolvedor; ir direto para o navegador headless |
--no-browser | nunca usar o navegador; sair com 3 se a resolução não puder ser aplicada |
--no-cache | não ler nem gravar o cookie jar persistente |
# HTML to stdout
$ anubis-fetch https://lore.kernel.org/linux-mm/some-thread/T/
# readable plain text
$ anubis-fetch --text https://lore.kernel.org/linux-mm/some-thread/T/
# lean/fast only — useful in scripts; exits 3 if it would need a browser
$ anubis-fetch --no-browser https://example.com/ && echo "got it"
Após uma busca bem-sucedida, o cookie de autenticação é gravado em
$XDG_CACHE_HOME/anubis-fetch/cookies/<host>.json (com fallback para
~/.cache/…). A próxima execução para aquele host passa direto — sem
proof-of-work, sem navegador — exatamente como uma revisita do navegador.
Cookies obtidos pelo fallback do navegador também são salvos, então uma execução
posterior pode usar o caminho rápido HTTP. Use --no-cache para desativar, ou
apenas delete o arquivo para forçar uma nova resolução.
Tudo é configurado através do flake:
$ nix develop # dev shell: go, gopls, chromium, treefmt
$ go test ./... # unit tests (hermetic — no network)
$ nix build # build the wrapped binary
$ nix flake check # build + tests + formatting
$ nix fmt # format Go + Nix via treefmt (gofmt + alejandra)
A implementação do proof-of-work é fixada em relação ao vetor de teste publicado pelo próprio Anubis (sha256("hunter" + "0")), de modo que uma divergência na construção do hash falha em um teste unitário em vez de retornar lixo silenciosamente.