Fortress patches Chromium's C++ to make bot detectors see a human

The open-source project Fortress ships a Chromium fork that corrects the browser fingerprint inside the engine’s C++ instead of layering JavaScript patches on top. The result: CreepJS, Sannysoft, BrowserScan, and live Cloudflare Turnstile all read the browser as a human, according to the project’s published test results. For AI agents that need to scrape protected pages, this changes the economics of evasion.

Fortress is not a stealth plugin or a patched Puppeteer script. It is a fork of Chromium with 34 single-surface C++ patches applied in-tree. The patches modify getters for canvas, WebGL, audio, fonts, navigator, and about 30 other surfaces that bot detectors read. Because the corrections live in the engine binary, toString() on any spoofed getter returns [native code]. A detector that grabs the same property from a main frame, an iframe, and a Web Worker sees identical values across every realm. JavaScript stealth patches, by contrast, leave an extra layer that a page can detect by comparing results across realms or by inspecting the getter source.

The project’s published gauntlet results show 0 percent headless detection on CreepJS, all-green passes on Sannysoft, and “Normal” reads on BrowserScan. Unedited captures show the Fortress binary clearing a live Cloudflare Turnstile challenge and loading pages behind Akamai Bot Manager that a stock headless browser gets blocked from. The same residential IP that produced “Access Denied” on a stock browser loads the real page on Fortress, and Akamai issues its _abck sensor cookie. The variable is the fingerprint, not the IP.

This matters for AI agents because the bot-detection arms race has escalated faster than the tooling that agents depend on. Most browser automation frameworks ship with JavaScript stealth patches that are themselves detectable. The patches add an extra function call to a getter; a detector can compare the getter against a known-good implementation, or re-grab the property from a fresh iframe and see the unpatched value. Fortress eliminates that detection surface by making the spoofing invisible to JavaScript entirely.

The project ships as a drop-in CDP endpoint. Point Playwright, Puppeteer, or any CDP client at http://localhost:9222 and existing automation code runs unchanged. The SDK auto-fetches a prebuilt binary verified by SHA-256, or the engine can be rebuilt from source using the patches in the patches/ directory. A Docker image pulls at about 302 MB and exposes the same CDP endpoint. The project targets two Chromium bases: stable (version 149) for best blend-in with the Chrome version most real users run, and latest (version 151) for newer engine features.

Fortress also ships a Model Context Protocol server that exposes 29 stealth-browser tools to agents. An agent with the Fortress MCP can call fetch_protected_page when a direct HTTP fetch returns a 403, and the tool returns the rendered page through the stealth engine. The project demonstrates this with a real run against StockX, which uses PerimeterX: a stock browser gets “Access denied”, while the MCP tool returns clean JSON from the same site.

The project is open-source under a BSD-3 license, with reproducible builds and provenance verification. The patches are 34 single-purpose diffs, each small enough to read in a minute. The coherence model ties the engine, user-agent string, and JA3/JA4 TLS fingerprint together so a Windows persona runs on a matching TLS stack. Tunable --uxr-* flags override any surface: GPU, screen, timezone, language, hardware concurrency, Client-Hints.

The hard question Fortress raises is whether patching the engine is a sustainable approach. Bot detection vendors can react to known engine forks by adding fingerprint checks for the fork’s specific binary signatures. The project addresses this by rebasing monthly against upstream Chromium and gating releases on the full gauntlet, but the cat-and-mouse game continues. What Fortress changes is the cost of participation: instead of reverse-engineering detection heuristics and writing JavaScript patches, a developer can fork the engine and rebuild. The detection surface shifts from the JavaScript layer to the binary layer, where the cost of detection is higher for both sides.

For AI builders who need to scrape protected sites for training data, monitoring, or agent tasks, Fortress offers a path that does not depend on closed-source anti-detection browsers or residential proxy networks. The project’s documentation is explicit that blocked requests that trace to a datacenter IP rather than the fingerprint still require a residential or mobile proxy. The fingerprint fix is necessary but not sufficient.

The project’s README includes a section titled “Why patch the engine, not the page” that articulates the self-revealing-JS thesis clearly. The three detection layers it describes — JavaScript surface inspection, realm-invariant comparison, and getter introspection — are all addressed by moving the spoofing into native code. The thesis is testable: run the gauntlet, inspect the results, rebuild the engine from source. The project provides the tools to verify every claim.

Fortress does not solve the proxy problem, the rate-limiting problem, or the CAPTCHA problem. It solves one specific problem: the browser fingerprint. For agents that were getting blocked at the fingerprint layer, that one fix is enough to turn a blocked run into a successful one. The project’s demos show it working against real Akamai, Cloudflare, and PerimeterX deployments. The question is how long the fix holds before the detection vendors adapt.

The answer is in the patches directory. Thirty-four small diffs, each correcting one surface. When a vendor adapts, the project adds patch 35.