anubis-fetch

$ nix run github:fzakaria/anubis-fetch -- https://lore.kernel.org/linux-mm/some-thread/T/

Un CLI rapide (en Go) pour récupérer des URLs derrière les murs de preuve de travail Anubis et les contrôles d'empreinte Cloudflare — résolvant le défi en interne, et ne faisant appel à un vrai navigateur qu'en dernier recours.

Un nombre croissant de sites — lore.kernel.org, GNOME, kernel.org, et bien d'autres — se trouvent derrière Anubis, un mur anti-bots qui oblige votre navigateur à résoudre une preuve de travail SHA-256 avant de servir le moindre contenu. C'est très efficace pour bloquer les scrapers. C'est aussi très efficace pour vous bloquer vous, quand vous voulez simplement curl une discussion de liste de diffusion :

$ curl -s https://lore.kernel.org/linux-mm/some-thread/T/ | grep -o '<title>.*</title>'
<title>Making sure you&#39;re not a bot!</title>   # 🤢

anubis-fetch vous donne la page réelle :

$ anubis-fetch https://lore.kernel.org/linux-mm/some-thread/T/ | grep -o '<title>.*</title>'
<title>[PATCH 0/2] ...</title>                     # 🥳

Comment ça fonctionne

Les murs anti-bots opèrent à deux niveaux différents, et anubis-fetch gère les deux, de l'étape la moins coûteuse à la plus lourde :

1. Réutiliser un cookie sauvegardé. Anubis délivre un cookie d'authentification signé (techaro.lol-anubis-auth) après un premier passage réussi ; un navigateur n'est pas re-soumis au défi lors de la visite suivante, et nous non plus. Les cookies sont conservés par hôte (voir Persistance des cookies).
2. Résoudre la preuve de travail en interne. La requête part via req en imitant un vrai Chrome — même empreinte TLS/JA3 + HTTP/2 — ce qui franchit également la détection passive d'empreinte de Cloudflare. Si la réponse est un défi Anubis, nous forçons la recherche du nonce et le soumettons. Pas de navigateur, ~0,6 s.
3. Repli sur un vrai navigateur. Pour tout ce que le chemin rapide ne peut pas faire, nous pilotons Chromium headless via chromedp, qui exécute tout JavaScript servi par le site.

[!NOTE] Le repli se déclenche pour : les méthodes de défi preact / metarefresh d'Anubis, une méthode inconnue ou future, une difficulté trop élevée pour être forcée, une solution rejetée, ou un défi JavaScript actif de Cloudflare (Managed Challenge / Turnstile / « I'm Under Attack »). L'usurpation d'identité franchit le Cloudflare passif ; seul un navigateur franchit les niveaux JavaScript actifs. Ainsi, anubis-fetch dégrade en « plus lent », jamais en « cassé ».

Pourquoi ne pas simplement utiliser un navigateur pour tout ?

Parce que c'est ~4× plus lent et que cela entraîne un Chromium d'environ 200 Mo à chaque récupération. Le solveur en interne est le cas courant ; le navigateur est le filet de sécurité.

La preuve de travail d'Anubis, en bref

Anubis intègre un défi au format JSON dans la page :

{"rules":{"algorithm":"fast","difficulty":4},
 "challenge":{"id":"…","method":"fast","randomData":"6214bd88…","difficulty":4}}

Le résoudre consiste à trouver un nonce tel que hex(sha256(randomData ‖ nonce)) commence par difficulty caractères nuls (le nonce est sa représentation en chaîne base-10). Nous renvoyons ensuite la réponse :

GET /.within.website/x/cmd/anubis/api/pass-challenge?id=…&response=<hash>&nonce=<n>&redir=<url>&elapsedTime=<ms>

…ce qui définit le cookie d'authentification et redirige vers la vraie page. La difficulté 4 (la valeur par défaut sur lore/kernel.org/GNOME) représente ~65k hachages — moins d'une milliseconde en Go.

Installation

Exécution directe :

$ nix run github:fzakaria/anubis-fetch -- <url>

Installation dans votre profil :

$ nix profile install github:fzakaria/anubis-fetch

Ou ajoutez-le à votre propre flake :

{
  inputs.anubis-fetch.url = "github:fzakaria/anubis-fetch";
  # then, e.g. in home.packages / environment.systemPackages:
  #   inputs.anubis-fetch.packages.${system}.default
}

Utilisation

$ anubis-fetch [flags] URL

# HTML vers stdout
$ anubis-fetch https://lore.kernel.org/linux-mm/some-thread/T/

# texte brut lisible
$ anubis-fetch --text https://lore.kernel.org/linux-mm/some-thread/T/

# minimal/rapide uniquement — pratique dans les scripts ; sort avec 3 si un navigateur serait nécessaire
$ anubis-fetch --no-browser https://example.com/ && echo "got it"

Persistance des cookies

Après une récupération réussie, le cookie d'authentification est écrit dans $XDG_CACHE_HOME/anubis-fetch/cookies/<host>.json (avec repli sur ~/.cache/…). L'exécution suivante pour cet hôte passe directement — ni preuve de travail, ni navigateur — exactement comme une revisite de navigateur. Les cookies obtenus via le repli navigateur sont également sauvegardés, afin qu'une exécution ultérieure puisse emprunter le chemin HTTP rapide. Utilisez --no-cache pour désactiver, ou supprimez simplement le fichier pour forcer une nouvelle résolution.

Développement

Tout est câblé via le 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)

L'implémentation de la preuve de travail est épinglée sur le vecteur de test publié par Anubis lui-même (sha256("hunter" + "0")) afin qu'une dérive dans la construction du hachage fasse échouer un test unitaire plutôt que de renvoyer silencieusement des données incohérentes.

Références & remerciements

• TecharoHQ/anubis — le mur anti-bots avec lequel il négocie poliment.
• imroc/req — le client HTTP dont l'usurpation Chrome franchit la détection passive d'empreinte Cloudflare.
• chromedp/chromedp — pilote le repli vers le navigateur headless.