Gepatchte Chromium-Browser erklärt
Wie Scraper den Quellcode von Chromium modifizieren, um Automatisierungs-Fingerprints zu verbergen — und warum navigator.webdriver-Checks sie nicht mehr erwischen.
Was ist ein gepatchter Chromium-Browser?
Ein gepatchter Chromium-Browser ist ein Chromium-Build, dessen Quellcode modifiziert wurde, um die Spuren zu entfernen, die ihn als automatisierten Browser kennzeichnen. Die Änderungen sind einkompiliert. Wenn das Binary startet, sind die verräterischen Signale bereits verschwunden: injizierte Variablen, Flags, ungewöhnliche Runtime-Eigenschaften.
Das unterscheidet sich von Stealth-Plugins wie puppeteer-extra-stealth, die ihre Überschreibungen erst zur Ladezeit der Seite ausführen. Laufzeit-Shims hinterlassen ihre eigenen Spuren. Gepatchte Builds nicht, weil das, was dort sonst überschrieben würde, nie existiert hat.
Die bekanntesten Projekte sind undetected-chromedriver, rebrowser-patches, Patchright (ein Playwright-Fork), nodriver und, auf der Firefox-Seite, camoufox. Das Prinzip ist überall dasselbe: den Leak in C++ beseitigen, nicht in JavaScript. Seit Chrome im November 2022 seine Headful- und Headless-Codebasen vereinheitlicht hat, fängt die Suche nach dem `HeadlessChrome`-User-Agent kaum noch etwas (Castle, 2025).
Warum vanilla Headless Chrome auffliegt
Mit Puppeteer- oder Selenium-Standardeinstellungen verliert man gegen jede ernsthafte Erkennung. `navigator.webdriver` steht per Web-Driver-Spezifikation auf `true`, sobald ein Browser automatisiert gesteuert wird, und eine Zeile JavaScript liest den Wert aus. Der `$cdc_asdjflasutopfhvcZLmcfl_`-String, den ChromeDriver in jede Seite injiziert, ist per Regex ebenso trivial zu finden (DataDome, 2024). Dazu kommen die Laufzeit-Eigenschaften, in denen sich ein gesteuerter Browser von einem echten unterscheidet: fehlende Plugins, leere `navigator.languages`, falsche `screen.colorDepth`, kein `window.chrome`-Objekt.
Jedes dieser Lecks lässt sich mit einer Zeile patchen. Ein zusammengebauter gepatchter Browser ist in etwa einer Stunde fertig — und kommt damit an den Checks eines Bot-Detection-Systems von 2019 vorbei. Mehr nicht.
Das eigentliche Signal liegt im Chrome DevTools Protocol
Puppeteer, Playwright und Selenium kommunizieren alle über dieselbe Schnittstelle mit Chromium: das Chrome DevTools Protocol (CDP), eine WebSocket-API für Debugging. Rund 95 % aller automatisierten Aktionen laufen über `Page.evaluate`, CDPs Weg, JavaScript in der Seite auszuführen (Rebrowser, 2024). `Page.evaluate` setzt voraus, dass die CDP-Runtime-Domain aktiviert ist — und diese Aktivierung sendet Events, die die Seite beobachten kann.
Jahrelang hat Bot-Detection-Code genau diese Events indirekt ausgelesen: ein Error-Objekt mit einem `.stack`-Getter, der ausgelöst wurde, sobald die Runtime das Objekt über den WebSocket serialisierte. Im Mai 2025 haben zwei V8-Commits diesen Trick stillgelegt — "Avoid error side effects in DevTools" am 7. Mai und "Apply getter guard throughout error preview" am 9. Mai. Benutzerdefinierte Getter werden während der Error-Preview nicht mehr ausgeführt (Castle, 2025). Der `console.debug`-Check, bis dahin Standard, wurde nutzlos, und die meisten Anbieter haben das monatelang nicht bemerkt.
Wie die Patches funktionieren und was sie kosten
Das Ökosystem teilt sich in drei Generationen. Die erste patcht die Fingerprint-Oberfläche direkt: undetected-chromedriver benennt `$cdc_`-Variablen im ChromeDriver-Binary um, rebrowser-patches modifiziert Puppeteer- und Playwright-Quellen, damit sie die CDP-Runtime-Domain nicht bei jedem Seitenaufruf aktivieren. Die zweite Generation flickt das Protokoll selbst: Patchright führt JavaScript über `Page.createIsolatedWorld` aus, sodass die Seite die fraglichen Events nie sieht. Die dritte verzichtet komplett auf CDP — nodriver und sein async-Fork zendriver steuern den Browser über Betriebssystem-APIs, camoufox patcht das Juggler-Protokoll in Firefox auf C++-Ebene vor dem Kompilieren.
Der Aufwand ist der Grund, warum fast niemand einen eigenen Chromium-Fork pflegt. Chrome veröffentlicht alle vier Wochen einen neuen Meilenstein (Chromium-Projekt). Jedes Release verschiebt Code, benennt Internes um und öffnet neue Detection-Oberflächen. Die Patches selbst sind klein, aber alle vier Wochen muss der Fork rebased, getestet und neu gebaut werden. Camoufox' fast einjährige Wartungslücke im Jahr 2025 zeigt, was passiert, wenn die Wartung an einer einzelnen Person hängt. Genau deshalb füllen Bright Data, Browserless und ähnliche Dienste die Lücke: sie bieten gepatchtes Chromium als gehostete API an. Der Kompromiss: unabhängige Benchmarks zeigen, dass das CDP-Automation-Flag in jeder Session dieser Dienste aus der Seite heraus lesbar bleibt (ScrapeOps-Benchmark, 2026).
Was gepatchte Browser trotzdem erwischt
Headless-Fingerprint-Erkennung ist einfach zu umgehen. Verhaltenserkennung nicht. Die Signale, die ein Patch nicht ausschaltet, hängen davon ab, *wie* der Browser benutzt wird — nicht davon, wie er beim Seitenaufruf aussieht. Mauspfade auf geraden Linien zwischen Elementen. Identische Tipp-Rhythmen über mehrere Sessions hinweg. Formulare, die schneller ausgefüllt sind, als ein Mensch sie lesen kann. Session-Muster, die sich nach festen Request-Zahlen wiederholen, wie sie kein echter Nutzer produziert.
Der Grund für diese Verlagerung liegt in der Skalierung. Cloudflare hat 2025 rund 30 % des gesamten Internet-Traffics als Bots gemessen, und in der ersten Märzwoche 2025 kamen über 94 % der Authentifizierungs-Requests von Bots (Cloudflare, 2025). Imperva beobachtet pro Tag mehr als 10.000 eindeutige IP-Adressen, die mit Headless Chrome scrapen oder Carding betreiben (Imperva, 2024). Ein Detection-System, das nur einen einzelnen Request isoliert betrachtet, misst auf diesen Mengen nur Rauschen. Puppeteer-extra-stealth, bis dahin der Standard, hat Anfang 2025 aufgehört, Cloudflare zuverlässig zu umgehen (ZenRows, 2025; Castle, 2025).
Was das für Ihren Detection-Stack bedeutet
Für Verteidiger ist die Lehre kurz: `navigator.webdriver` und User-Agent-Substring-Checks taugen nicht mehr als Bot-Detection. Sie erwischen veraltetes Tooling und sonst nichts. Gepatchte Chromium-Builds sind günstig und verfügbar — und verbergen genau die Signale, die diese Checks suchen.
Was funktioniert, ist Multi-Signal-Erkennung: Fingerprints auf Request-Ebene kombiniert mit Verhaltensmustern über eine Session, statt eines einzelnen Flags. Centinel erkennt und blockiert KI-Crawler und Automation-Traffic auf Request-Ebene und kombiniert Runtime-Signale mit Verhaltensanalyse — gebaut für genau die Klasse von Traffic, die gepatchte Browser erzeugen. Wenn 94 % der Authentifizierungs-Requests im Internet automatisiert sind (Cloudflare, 2025), ist die Frage nicht, ob man sie erkennen sollte, sondern welchen Signalen man dabei traut.
Sehen Sie, was Ihre Website gerade crawlt
Starten Sie ein kostenloses Audit und erhalten Sie einen detaillierten Bericht darüber, welche KI-Crawler auf Ihre Inhalte zugreifen.
Kostenloses Audit starten