fzakaria/anubis-fetchWie curl, aber es überwindet Anubis- und Cloudflare-Botwalls.
$ nix run github:fzakaria/anubis-fetch -- https://lore.kernel.org/linux-mm/some-thread/T/
Ein schnelles (Go-)CLI zum Abrufen von URLs hinter Anubis-Proof-of-Work-Wänden und Cloudflare-Fingerprint-Prüfungen — löst die Challenge prozessintern und greift nur dann auf einen echten Browser zurück, wenn es nötig ist.
Immer mehr Websites – lore.kernel.org, GNOME, kernel.org und viele weitere – liegen hinter Anubis, einer Bot-Wand, die deinen Browser ein SHA-256-Proof-of-Work lösen lässt, bevor sie Inhalte ausliefert. Sie ist großartig darin, Scraper zu stoppen. Sie ist auch großartig darin, dich zu stoppen, wenn du nur schnell einen Mailinglisten-Thread mit curl abrufen willst:
$ curl -s https://lore.kernel.org/linux-mm/some-thread/T/ | grep -o '<title>.*</title>'
<title>Making sure you're not a bot!</title> # 🤢
anubis-fetch liefert dir die tatsächliche Seite:
$ anubis-fetch https://lore.kernel.org/linux-mm/some-thread/T/ | grep -o '<title>.*</title>'
<title>[PATCH 0/2] ...</title> # 🥳
Bot-Wände agieren auf zwei verschiedenen Ebenen, und anubis-fetch behandelt beide – den günstigsten Schritt zuerst:
techaro.lol-anubis-auth) aus; ein Browser wird beim nächsten Besuch nicht erneut herausgefordert, und wir auch nicht. Cookies werden pro Host gespeichert (siehe Cookie-Persistenz).req gesendet, das ein echtes Chrome imitiert – gleicher TLS/JA3- + HTTP/2-Fingerprint –, was auch Cloudflares passives Fingerprinting umgeht. Wenn die Antwort eine Anubis-Challenge ist, erzwingen wir die Nonce per Brute-Force und übermitteln sie. Kein Browser, ~0.6s.chromedp, das das gesamte JavaScript ausführt, das die Website ausliefert.[!NOTE] Der Fallback greift bei: Anubis‘
preact- /metarefresh-Challenge-Methoden, einer unbekannten/zukünftigen Methode, einer zu hohen Schwierigkeit für Brute-Force, einer abgelehnten Lösung oder einer aktiven JS-Challenge von Cloudflare (Managed Challenge / Turnstile / „I'm Under Attack“). Die Nachahmung umgeht passives Cloudflare; nur ein Browser umgeht die aktiven JS-Stufen.anubis-fetchwird also langsamer, aber nie unbrauchbar.
Weil das ~4× langsamer ist und bei jedem Abruf ein ~200 MB großes Chromium mitzieht. Der prozessinterne Solver ist der Normalfall; der Browser ist das Sicherheitsnetz.
| Pfad | Dauer | Benötigt Chromium |
|---|---|---|
| Solver (Anubis-Proof-of-Work) | ~0.6s | nein |
| Browser-Fallback | ~2.0s | ja |
Anubis bettet eine Challenge als JSON in die Seite ein:
{"rules":{"algorithm":"fast","difficulty":4},
"challenge":{"id":"…","method":"fast","randomData":"6214bd88…","difficulty":4}}
Zum Lösen muss eine Nonce gefunden werden, sodass hex(sha256(randomData ‖ nonce)) mit difficulty Nullen beginnt (die Nonce ist ihre Base-10-Zeichenkette). Anschließend übergeben wir die Antwort:
GET /.within.website/x/cmd/anubis/api/pass-challenge?id=…&response=<hash>&nonce=<n>&redir=<url>&elapsedTime=<ms>
…das setzt das Auth-Cookie und leitet zur echten Seite weiter. Schwierigkeitsgrad 4 (Standard auf lore/kernel.org/GNOME) sind ~65k Hashes – in Go unter einer Millisekunde.
Direkt ausführen:
$ nix run github:fzakaria/anubis-fetch -- <url>
In dein Profil installieren:
$ nix profile install github:fzakaria/anubis-fetch
Oder zu deiner eigenen Flake hinzufügen:
{
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 | Bedeutung |
|---|---|
--text | lesbaren Klartext statt HTML ausgeben |
--timeout MS | Zeitlimit pro Schritt in Millisekunden (Standard 30000) |
--ua STRING | User-Agent überschreiben |
--browser | Solver überspringen; direkt zum Headless-Browser gehen |
--no-browser | niemals den Browser verwenden; mit 3 beenden, wenn das Lösen nicht anwendbar ist |
--no-cache | den persistenten Cookie-Jar weder lesen noch schreiben |
# 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"
Nach einem erfolgreichen Abruf wird das Auth-Cookie unter $XDG_CACHE_HOME/anubis-fetch/cookies/<host>.json gespeichert (Fallback: ~/.cache/…). Der nächste Lauf für diesen Host wird direkt durchgelassen – kein Proof-of-Work, kein Browser – genau wie bei einem erneuten Browserbesuch. Auch per Browser-Fallback erhaltene Cookies werden gespeichert, sodass ein späterer Lauf den schnellen HTTP-Pfad nehmen kann. Mit --no-cache deaktivierst du das, oder lösche einfach die Datei, um ein erneutes Lösen zu erzwingen.
Alles ist über die Flake verdrahtet:
$ 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)
Die Proof-of-Work-Implementierung ist an Anubis' eigenen veröffentlichten Testvektor (sha256("hunter" + "0")) gekoppelt, sodass eine Abweichung in der Hash-Konstruktion einen Unit-Test fehlschlagen lässt, anstatt stillschweigend Müll zurückzugeben.