Solving Anubis's SHA-256 Proof-of-Work Challenge

A developer documented how to solve the SHA-256 proof-of-work challenge used by Anubis, the open-source reverse-proxy anti-bot gate deployed by sites including Startpage, entirely server-side without a headless browser. The writeup derives the algorithm from Anubis's public source, showing that at difficulty 6 the winning nonce typically lands under 1000 and the search completes in low single-digit milliseconds, and notes the deployment-specific verification cookie must be captured and replayed on the pass-challenge request.

Anubis TecharoHQ/anubis is an open-source reverse-proxy anti-bot gate an increasing number of sites put in front of themselves Startpage among them . When it decides to challenge a client, it serves a page embedding a PoW puzzle that the browser's JS solves in a Web Worker, then replays the answer as a query string against a fixed API path. Replicating that server-side unlocks the real page instead of the "Just a moment..." wait screen — no headless browser needed. Everything below is derived directly from Anubis's own public source lib/challenge/proofofwork/proofofwork.go for the server-side validator, web/js/worker/sha256.ts and wasm/pow/sha256/src/lib.rs for the two reference client implementations, which agree exactly — not reverse-engineered from obfuscated code. HTTP 200 Content-Type: text/html < doctype html <html lang="en" <head <script id="anubis version" type="application/json" "v1.26.4"</script <script id="anubis challenge" type="application/json" {"rules":{"algorithm":"fast","difficulty":6},"challenge":{"issuedAt":"2026-10-09T10:58:18.167975774Z","metadata":{"User-Agent":"...","X-Real-Ip":"..."},"id":"01a12050-55b7-7ed8-ac01-8ca29fcefe62","method":"fast","randomData":"da5eb566735ccae8db7d506e96d18dbfb6790c4bcde8600cf0cd21e9e5c71d7ccd74745509dbfb71c97a74d33f5e4bab60ee58dd704ce318322516afbe9d7272","policyRuleHash":"ac980f49c4d35fab","difficulty":6,"spent":false}}</script <script id="anubis base prefix" type="application/json" ""</script <script id="anubis public url" type="application/json" ""</script ... </head ... </html The response also sets a Set-Cookie header — a verification cookie whose name is deployment-specific Anubis's own default differs from what a site may configure; Startpage uses spchal-cookie-verification=<uuid . This cookie must be captured and replayed on the solve request , or the server rejects it outright. The anubis challenge element's text content, parsed as JSON: { "rules": { "algorithm": "fast", "difficulty": 6 }, "challenge": { "id": "<uuid ", "randomData": "<hex string, ~128 chars ", "difficulty": 6 } } The task: find the smallest non-negative integer nonce such that SHA256 randomData as utf8 bytes + nonce.to string .as bytes — hex-encoded — has difficulty leading '0' hex digits. That's difficulty / 2 leading zero bytes, plus one more leading-zero nibble if difficulty is odd checking raw digest bytes rather than the hex string avoids re-encoding on every attempt . At difficulty = 6 , the winning nonce typically lands under 1000 — the whole search takes low single-digit milliseconds. A plain GET not a POST — the browser does window.location.replace ... , so query params alone are enough to a fixed path: GET {origin}/.within.website/x/cmd/anubis/api/pass-challenge ?id=<challenge.id &response=<hex hash &nonce=<nonce &redir=<original request URL, url-encoded &elapsedTime=<ms spent solving — with the challenge page's Set-Cookie attached. The response is either the real page directly or a redirect to it; base prefix / public url are empty in practice, so redir is just the exact original URL and the path above is used unprefixed off the origin's root. use sha2::{Digest, Sha256}; /// Returns nonce, hex hash . fn solve anubis pow random data: &str, difficulty: usize - u64, String { let zero bytes = difficulty / 2; let odd nibble = difficulty % 2 = 0; let mut nonce: u64 = 0; loop { let mut hasher = Sha256::new ; hasher.update random data.as bytes ; hasher.update nonce.to string .as bytes ; let digest = hasher.finalize ; let leading zero bytes ok = digest ..zero bytes .iter .all |&b| b == 0 ; let next nibble ok = odd nibble || digest zero bytes 4 == 0; if leading zero bytes ok && next nibble ok { let hex hash = digest.iter .map |b| format "{b:02x}" .collect::<String ; return nonce, hex hash ; } nonce += 1; } } Submission, with any HTTP client carrying a cookie jar reqwest / rquest with .cookie store true : let nonce, response hash = solve anubis pow &challenge.random data, rules.difficulty ; let pass response = client .get "https://TARGET/.within.website/x/cmd/anubis/api/pass-challenge" .query & "id", challenge.id.as str , "response", response hash.as str , "nonce", &nonce.to string , "redir", original request url.as str , "elapsedTime", &elapsed ms.to string , .send .await?; Gotcha : if this runs inside a shared async codebase, don't hold an HTML-parser Document / Selection in scope across the .await on the solve-submit request. Some HTML parsers e.g. nipper , built on tendril aren't Send — a value merely left in scope at an .await point, even unused, poisons the whole generated future's Send -ness. Scope the parsing step in a block that ends before the await.