So entfernen Sie die Website-Detektor-Karte: Finden Sie die Fingerprint-Skripte selbst

```html

Am 20. August 2026 veröffentlichte der Entwickler Matt Callaghan (Blog laserphile) eine Analyse eines seltsamen Fehlers: Seine Bluetooth-Kopfhörer mit Multipoint wechselten nicht von seinem Computer auf sein Telefon. Jedes Mal, wenn ein Tab von AliExpress geöffnet war. Er begann nicht zu spekulieren — er instrumentierte die Browser-APIs und schaute, was auf der Seite geschah. Es stellte sich heraus, dass zwei obfuskierten Skripte aus dem Anti-Fraud-Stack von Alibaba den Audiokontext anforderten und das Gerät über einen unhörbaren Ton fingerprinteten.

Dies ist eine perfekte Veranschaulichung dessen, was fast niemand vor der Konfiguration von Profilen oder dem Start eines Parsers tut: den Detektions-Stack der Plattform nicht zu lesen, sondern zu erraten. Im Folgenden finden Sie eine praktische Methode, wie Sie selbst innerhalb einer Stunde die Detektionskarte einer bestimmten Website erstellen können, ohne Reverse-Obfuskation und ohne kostenpflichtige Dienste.

Warum eine Detektionskarte erstellen

Ein typischer Zyklus sieht so aus: Konten werden gesperrt — wir drehen die Einstellungen des Anti-Detect-Browsers nach dem Zufallsprinzip — ändern die Proxys — werden erneut gesperrt. Zwischen „gesperrt“ und „Einstellungen“ gibt es keine Daten: Unklar bleibt, was genau die Plattform liest und auf welcher Ebene sie fängt.

Die Detektionskarte schließt diese Lücke. Es ist eine Liste: Welcher Schutzanbieter verwendet wird, welche Skripte ihn implementieren, welche APIs sie berühren und wohin das Ergebnis geht. Dann wird deutlich, wo tatsächlich der Engpass liegt — in der IP, im Netzwerk-Fingerprint oder in der Hardware-Schicht des Browsers. Dies ist für drei Zielgruppen gleichermaßen nützlich:

• Multi-Accounting — zu verstehen, welches Signal die Profile zusammenführt. Ihre IPs sind unterschiedlich, aber der Audio-Stack, der WebGL-Renderer und hardwareConcurrency sind oft für die gesamte Farm gleich.
• Scraping — zu verstehen, ob es überhaupt sinnvoll ist, den Browser zu starten oder ob die Aufgabe mit einem HTTP-Client und einem korrekten TLS-Fingerprint gelöst werden kann.
• Privatsphäre — zu sehen, was genau der Shop oder Dienst über Ihr Gerät neben Cookies sammelt.

Schritt 1. Den Schutzanbieter über das Netzwerk identifizieren

Das Erste, was Sie tun, ist, die DevTools auf dem Tab „Netzwerk“ zu öffnen, die Seite zu laden und die Header und Cookies des ersten Dokuments zu überprüfen. Die Erkennungszeichen sind bekannt und stabil:

• CF-RAY in den Antwort-Headern und das Cookie cf_clearance — Cloudflare.
• Cookie _abck und ein Skript mit der Funktion bmak — Akamai Bot Manager.
• Variablen und Cookies mit dem Präfix _px — PerimeterX (HUMAN).
• Cookie datadome und ein separates JS von der Domain des Anbieters — DataDome.
• Ein leerer 429 ohne Antwortkörper — ein typisches Zeichen von Kasada.

Wenn Sie es manuell nicht tun möchten, gibt es öffentliche Detektoren wie microlinkhq/is-antibot (30+ Anbieter) und Browsererweiterungen-Detektoren für 26+ Anbieter. Sie geben eine schnelle erste Antwort, beantworten jedoch nicht die Hauptfrage — was genau in Ihrem Browser gemessen wird. Dafür müssen Sie weiter gehen.

Schritt 2. Eine Liste verdächtiger Skripte extrahieren

Filtern Sie das Netzwerk nach dem Typ JS und notieren Sie alles, was nicht von der Hauptdomain geladen wird oder in Dienstverzeichnissen liegt. Im Fall von AliExpress waren dies zwei Dateien mit eindeutig dienstlichen Pfaden:

• assets.aliexpress-media.com/g/AWSC/uab/1.140.0/collina.js
• assets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/fireyejs.js

Zeichen eines Anti-Fraud-Skripts: obfuskierten Code, Versionsnummer im Pfad, separate Subdomain für Statische Inhalte, keine Verbindung zum visuellen Teil der Seite. Es ist nicht nötig, die Obfuskation zu öffnen und zu lesen — im nächsten Schritt wird das Skript selbst über sich erzählen.

Schritt 3. Fingerprint-API instrumentieren

Dies ist der Kern der Methode und genau das, was Callaghan getan hat: Er hat den Konstruktor AudioContext und AudioNode.prototype.connect() umwickelt, nachdem er zwei aktive Audiokontexte auf der Seite sah, wo es kein einziges Medienelement und keinen einzigen Aufruf von play() gab.

Die Logik ist einfach: Sie ersetzen die Methode, die Sie interessiert, durch Ihre eigene Wrapper-Funktion, die den Aufruf mit dem Stack protokolliert und die Kontrolle an das Original übergibt. Der Aufruf-Stack zeigt, welches Skript die API tatsächlich aufgerufen hat. Es ist am bequemsten, einen solchen Snippet über DevTools Sources → Snippets oder über eine Erweiterung, die den Code beim document-start ausführt, einzufügen — es ist wichtig, dies vor dem Laden des Anti-Fraud-Skripts zu tun.

Das minimale Set an Fallen, das die meisten Signale abdeckt:

1. HTMLCanvasElement.prototype.toDataURL und getImageData — Canvas-Fingerprint.
2. WebGLRenderingContext.prototype.getParameter — Modell der Grafikkarte und Treiber, Genauigkeit der Shader.
3. AudioContext / OfflineAudioContext und AudioNode.prototype.connect — Audio-Fingerprint.
4. Getter navigator.hardwareConcurrency, navigator.deviceMemory, navigator.plugins, navigator.webdriver.
5. RTCPeerConnection — WebRTC und lokale Adressen.
6. screen.width/height, devicePixelRatio, Intl.DateTimeFormat().resolvedOptions() — Bildschirm und Zeitzone.
7. navigator.mediaDevices.enumerateDevices — Liste von Audio- und Video-Geräten.

Nach dem Durchlauf haben Sie eine Liste: welche dieser APIs tatsächlich aufgerufen wurden, wie oft und von wem. Im analysierten Fall berührten die Skripte von Alibaba das Canvas und toDataURL, den WebGL-Renderer und die Genauigkeit der Shader, Audio über Oszillator und Analyzer, Bildschirmgrößen und devicePixelRatio, hardwareConcurrency und deviceMemory, Plugins, Codec-Unterstützung, WebRTC, Leistungszeitmessungen, Mausbewegungsmuster und Berührungen, Bewegungssensoren des Geräts und Automatisierungsindikatoren.

Was genau die Audio-Grafik gemacht hat

Es ist nützlich zu verstehen, wie die Messung aussieht, um sie an anderen Orten zu erkennen. Die Grafik war so: sägezahnförmiger Oszillator → AnalyserNode → ScriptProcessorNode, der das Analyseergebnis liest → GainNode mit null Verstärkung → destination. Es gibt keinen Ton, die Lautstärke spielt keine Rolle — sie ist einfach nicht vorhanden. Aber die Verbindung zu destination, so der Autor, zwingt den Browser, die Grafik aktiv zu verarbeiten, obwohl die endgültige Lautstärke null beträgt. Genau dieser aktive Audioweg hielt den Bluetooth-Pfad offen und störte das Multipoint-Umschalten der Kopfhörer.

Die Unterschiede in der Verarbeitung dieses Signals hängen vom Prozessor, der Audio-Hardware, dem Betriebssystem, dem Browser und den Treibern ab — daher der stabile Identifikator, der den IP-Wechsel und das Löschen von Cookies übersteht. Eine detaillierte Analyse genau dieser Schicht und die Anpassung von Profilen dafür finden Sie im Artikel über Schutz vor Audio Context Fingerprinting.

Schritt 4. Den Versand des Ergebnisses abfangen

Das Sammeln ohne Versand ist sinnlos, daher besteht der nächste Schritt darin, herauszufinden, wohin der gesammelte Fingerabdruck geht. Filtern Sie das Netzwerk nach XHR/Fetch und sehen Sie sich separat Anfragen vom Typ ping an — diese werden von navigator.sendBeacon erzeugt, das von Telemetrieskripten gerne verwendet wird, da es das Verlassen der Seite übersteht.

Es ist praktisch immer nützlich, zusätzlich fetch, XMLHttpRequest.prototype.send und navigator.sendBeacon zu umwickeln — dann sehen Sie den Anfrageinhalt, bevor er gesendet wird. Bereiten Sie sich darauf vor, dass der Inhalt serialisiert und verschlüsselt wird: Im Fall von AliExpress wurden die Daten vor dem Versand an die Telemetrie von Alibaba verschlüsselt. Aber selbst so erhalten Sie zwei Fakten: die Adresse des Empfängers und den Zeitpunkt des Versands in Bezug auf Ihre Aktionen.

Wenn die Website nicht nur im Browser, sondern auch über eine mobile Anwendung oder einen separaten Client funktioniert, wird dieselbe Frage auf der Ebene des Datenverkehrs und nicht des DOM gelöst — die Methode des Abfangens und der Analyse ist im Artikel über Traffic-Audit über mitmproxy beschrieben.

Schritt 5. Die Karte mit Ihrem Profil abgleichen

Jetzt haben Sie eine Liste von Signalen, die die Plattform tatsächlich liest. Es bleibt zu überprüfen, was Ihr Arbeitsprofil zu diesen Signalen zurückgibt. Die Reihenfolge ist wie folgt: Sie erfassen die Werte in einem normalen Browser, dann in jedem Profil des Anti-Detect-Browsers und vergleichen.

Es sind zwei Dinge gleichzeitig wichtig: Die Werte müssen zwischen den Profilen unterschiedlich sein und innerhalb eines Profils zwischen den Sitzungen stabil sein. Ein Profil, dessen Fingerabdruck bei jedem Start springt, sieht für Anti-Fraud nicht weniger verdächtig aus als zehn Profile mit identischem Fingerabdruck.

Überprüfen Sie außerdem, ob die Substitution überhaupt auf der benötigten Ebene existiert. Hier ist die Streuung zwischen den Browsern aufschlussreich: Firefox ab Version 118 gibt einen konstanten WebAudio-Ausgang zurück, und laut Analyse reduzieren sich 99,24 % der Benutzer auf drei Werte; Brave mischt zufällige Daten ein und blockiert seit dem 22. August 2026 genau diese Skripte von AliExpress, was daran erinnert, dass der Schutz vor Audio-Fingerprinting bei ihm standardmäßig seit über sechs Jahren aktiv ist; Safari mischt Fehler in die Audiopuffer; Chrome hat keinen aggressiven Schutz.

Fallstricke

• Das Skript hat bereits gearbeitet. Das Blockieren der Datei löscht den bereits erstellten Audiokontext nicht — der Autor weist ausdrücklich darauf hin, dass offene Tabs geschlossen werden müssen. Das gilt auch für Ihre Instrumentierung: Wenn der Wrapper nach dem Skript geladen wurde, sehen Sie nichts.
• Das Blockieren beeinträchtigt die Funktionalität. Der Anti-Fraud-Stack ist oft auch für legitime Dinge verantwortlich — Autorisierung, Zahlung, Anti-Bot-Schutz vor echtem Missbrauch. Eine Detektionskarte zu erstellen und Skripte zu entfernen, sind unterschiedliche Aufgaben; die zweite zerstört die Website.
• Es gibt nicht nur eine Version der Detektion. Der Stack kann je nach Geo, Gerätetyp und A/B-Gruppe variieren. Es macht Sinn, die Karte von der IP und dem Gerät zu erstellen, von dem aus Sie tatsächlich arbeiten, sonst beschreiben Sie eine fremde Konfiguration.
• Die Instrumentierung selbst wird erkannt. Überschriebene native Methoden verlieren das korrekte toString, und ein angeschlossener Debugger hinterlässt Spuren. Für die Erkundung ist das nicht kritisch, aber verwechseln Sie nicht das Erkundungsprofil mit dem Produktionsprofil — die Techniken zur Maskierung von Automatisierung sind im Leitfaden zur Maskierung von Headless-Browsern behandelt.

Welcher Proxy für das Ergebnis benötigt wird

Die wichtigste praktische Erkenntnis aus einer solchen Karte ist fast immer die gleiche: Die IP ist nur die erste Schicht, und sie wird früher als alle anderen überprüft. Wenn der Anti-Fraud bereits auf der Anfrageebene die Adresse des Hostings sieht, wird es einfach nicht zu dem Audio-Graphen und dem Canvas kommen — Sie erhalten eine Herausforderung oder eine leere Ausgabe und reparieren das Falsche.

Deshalb ist die Logik der Auswahl wie folgt. Für Plattformen mit ernsthaftem Stack (Akamai, DataDome, PerimeterX, eigene Entwicklungen auf Alibaba-Niveau) dienen residential Proxies als Basis — Adressen echter Anbieter, die nicht beim ersten Filter ausgeschlossen werden. Für mobile Anwendungen und Plattformen, auf denen die Hauptzielgruppe mit Smartphones arbeitet, erweisen sich mobile Proxies als näher am natürlichen Profil: Der Betreiber-CGNAT macht die Adresse von vornherein zwischen vielen aktiven Nutzern geteilt.

Und umgekehrt gilt das auch: Wenn die Karte gezeigt hat, dass die Plattform sich auf Header und Cookies beschränkt und kein schweres JS-Fingerprinting vorhanden ist, ist eine Browserfarm überflüssig, die Aufgabe kann mit einem normalen HTTP-Client und Rechenzentrumsadressen gelöst werden.

Fazit

Der Fall mit den Kopfhörern ist nicht wegen des Faktums des Audio-Fingerprints wertvoll — darüber ist seit Jahren bekannt. Wertvoll ist die Methode: Der Mensch glaubte nicht den Vermutungen, sondern wickelte zwei Methoden der Browser-API und erhielt an einem Abend eine vollständige Liste dessen, was von ihm erfasst wird, und die Adresse, wohin es geht. Dieselbe Technik dauert eine Stunde auf jeder Plattform, mit der Sie arbeiten, und ersetzt Monate des zufälligen Einstellens. Erstellen Sie die Detektionskarte, bevor Sie die Sperren beheben — andernfalls besteht das Risiko, das Budget für Proxys auszugeben, wo das Problem im identischen WebGL-Renderer auf allen Profilen lag.