anubis-fetch

$ nix run github:fzakaria/anubis-fetch -- --text https://lore.kernel.org/

Ein Go-CLI zum Abrufen von URLs hinter Anubis-Proof-of-Work-Herausforderungen. Es löst Legacy-SHA-256- und WASM-Herausforderungen prozessintern, mit headless Chromium als Fallback.

Seiten wie lore.kernel.org und kernel.org verwenden Anubis, um vor der Auslieferung einer Seite einen Proof of Work zu verlangen. Ein einfacher HTTP-Client kann anstelle des angeforderten Inhalts die Herausforderungsseite erhalten. anubis-fetch löst die Herausforderung, übermittelt die Antwort und schreibt die resultierende Seite nach stdout.

Funktionsweise

1. Ein gespeichertes Cookie wiederverwenden. Anubis stellt nach einer erfolgreichen Herausforderung ein Auth-Cookie aus. Das Tool speichert Cookies pro Host und sendet sie bei späteren Anfragen mit.
2. Den Proof of Work prozessintern lösen. Der HTTP-Client verwendet req, um Chromes TLS- und HTTP/2-Fingerabdruck zu imitieren. Dies kann bei passiven Bot-Prüfungen helfen, einschließlich der von Cloudflare. Für Anubis' fast- und slow-Methoden berechnet das Tool eine Nonce und übermittelt die Antwort direkt. Für die WASM-Methoden sha256, argon2id und hashx lädt es das Modul der Seite herunter und führt es in Go mit wazero aus.
3. Auf einen Browser zurückgreifen. Headless Chromium, gesteuert von chromedp, führt den von der Seite ausgelieferten Herausforderungscode aus.

Der Browser-Fallback behandelt Anubis' preact- und metarefresh-Methoden sowie Cloudflare-Herausforderungsseiten (Antworten mit cf-mitigated: challenge). Das Tool greift auch dann auf den Fallback zurück, wenn die Legacy-SHA-256-Schwierigkeit sein Limit überschreitet, die WASM-Ausführung fehlschlägt oder ein Timeout auftritt, oder Anubis eine Lösung ablehnt. Verwenden Sie --browser, um mit Chromium zu starten, oder --no-browser, um den HTTP-Pfad zu erzwingen. Alle drei WASM-Methoden funktionieren mit --no-browser.

Warum nicht für alles einen Browser verwenden?

Der native Solver vermeidet es, für jeden Abruf einen Browserprozess zu starten. Chromium ist im Nix-Paket dennoch enthalten, für Herausforderungen, die den Fallback benötigen.

Ungefähre Abrufzeiten für den ursprünglichen SHA-256-Pfad:

Pfad	Wandzeit	Benötigt Chromium
In-Process-SHA-256-Solver	~0,6s	Nein
Browser-Fallback	~2,0s	Ja

WASM-Abrufzeiten gegen einen lokalen Anubis-Server bei Schwierigkeit 2:

WASM-Methode	Median-Wandzeit	Benötigt Chromium
SHA-256	~0,025s	Nein
Argon2id	~0,55s-2,33s	Nein
HashX	~0,041s	Nein

Der Anubis-Proof-of-Work, kurz erklärt

Für die fast- und slow-Methoden bettet Anubis die Herausforderung in die Seite ein:

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

Der Solver sucht eine Nonce, sodass hex(sha256(randomData || nonce)) mit difficulty Nullzeichen beginnt. Die Nonce wird als Dezimalstring kodiert. Die Antwort wird an Anubis übermittelt:

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

Eine erfolgreiche Antwort setzt ein Auth-Cookie und leitet auf die angeforderte Seite weiter. Schwierigkeit 4 erfordert im Durchschnitt etwa 65.536 Hashes.

WASM-Herausforderungen

Für sha256, argon2id und hashx liefert Anubis ein WebAssembly-Modul aus, das den Proof of Work implementiert. anubis-fetch lädt das Modul herunter, dekodiert die Hex-Daten der Herausforderung in Bytes und übergibt die Daten und die Schwierigkeit an das Modul. Das Modul sucht eine Nonce und gibt die Nonce und den Hash zur Übermittlung an denselben Endpunkt oben zurück.

Das Modul läuft mit wazero innerhalb des Go-Prozesses, sodass diese Methoden mit --no-browser funktionieren. Die Ausführung unterliegt Speicher- und Zeitlimits. Das Modul definiert die Schwierigkeitsregeln; WASM-Schwierigkeitswerte sind nicht direkt mit der Legacy-SHA-256-Methode vergleichbar.

Installation

Direkt ausführen:

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

Oder den Input zu Ihrem Flake hinzufügen:

{
  inputs.anubis-fetch.url = "github:fzakaria/anubis-fetch";
}

Fügen Sie inputs.anubis-fetch.packages.${system}.default zu home.packages oder environment.systemPackages hinzu.

Verwendung

anubis-fetch [flags] URL

Flag	Wirkung
--text	HTML in reinen Text umwandeln
--timeout MS	Das Timeout pro Schritt in Millisekunden festlegen; Standard 30000
--ua STRING	Den User-Agent festlegen
--browser	Chromium direkt verwenden
--no-browser	Mit Exit-Code 3 beenden, wenn der HTTP-Solver einen Browser-Fallback benötigt
--no-cache	Das Lesen und Schreiben gespeicherter Cookies deaktivieren
--help, -h	Nutzung ausgeben und beenden

# HTML nach stdout
anubis-fetch https://lore.kernel.org/

# Reiner Text
anubis-fetch --text https://lore.kernel.org/

# Den HTTP-Pfad erzwingen; auf Exit-Status 3 prüfen
anubis-fetch --no-browser https://lore.kernel.org/

Cookie-Persistenz

Cookies werden pro Host in $XDG_CACHE_HOME/anubis-fetch/cookies/<host>.json gespeichert, oder in ~/.cache/anubis-fetch/cookies/<host>.json, wenn XDG_CACHE_HOME nicht gesetzt ist. Ein gültiges Auth-Cookie kann spätere Anfragen die Herausforderung überspringen lassen. Cookies, die über Chromium erhalten wurden, werden ebenfalls gespeichert, zusammen mit Chromiums User-Agent. Cloudflare berücksichtigt cf_clearance nur unter dem User-Agent, der es erworben hat, daher senden spätere HTTP-Anfragen an diesen Host den gespeicherten User-Agent, es sei denn, --ua überschreibt ihn.

Verwenden Sie --no-cache, um ohne gespeicherte Cookies abzurufen, oder löschen Sie die Datei des Hosts, um sie zu verwerfen. Ein abgelaufenes oder abgelehntes Cookie erfordert eine neue Herausforderung.

Entwicklung

$ nix develop          # Go, gopls, Chromium, treefmt
$ go test ./...        # Go-Unit-Tests
$ nix build            # Gepacktes CLI
$ nix flake check      # Builds, Tests und Formatierung
$ nix fmt              # Go und Nix formatieren

Abhängigkeiten

• TecharoHQ/anubis: der Herausforderungsserver.
• imroc/req: der HTTP-Client mit Chrome-Imitation.
• chromedp/chromedp: der Chromium-Treiber.
• tetratelabs/wazero: die Go-WebAssembly-Laufzeit.