thermoptic

"Ich glaube es nicht, thermoptische Tarnung!"

Was ist das?

Dies ist ein HTTP-Proxy, der dazu entwickelt wurde, Dienste zu umgehen, die Fingerprinting wie JA4+ verwenden, um bestimmte HTTP-Clients zu blockieren. Mit diesem Proxy können Sie Ihre bevorzugten HTTP-Clients wie curl verwenden und dennoch auf magische Weise ununterscheidbare Fingerabdrücke von einem echten (Chrome/Chromium) Webbrowser haben. thermoptic bietet außerdem einige unterhaltsame Funktionen, um JavaScript-basiertes Fingerprinting abzuschwächen. Es erleichtert auch das hybride Scraping, bei dem sowohl ein Webbrowser als auch Low-Level-HTTP-Clients zusammen verwendet werden.

Selbst wenn Sie mit JA4+-Fingerprinting nicht vertraut sind: Wenn Sie schon einmal gescraped haben, wurden Sie wahrscheinlich schon einmal davon blockiert. Beliebte Dienste wie Cloudflare verwenden solche Techniken (und andere Tricks), um die Verwendung von "nicht-menschlichen" HTTP-Clients zu erkennen und Anfragen zu blockieren. Diese Dienste können dieses Fingerprinting auch dazu nutzen, um zu erkennen, wenn Sie eine Sitzung mit einem echten Browser beginnen und später zu einem Low-Level-Client wie curl wechseln. thermoptic löst all diese Probleme, indem es einen einheitlichen "echten" Browser-Fingerabdruck für alle Scraping-Anfragen präsentiert.

Beispiel

Hier ist ein Beispiel für einen JA4H (HTTP)-Fingerabdruck von curl ohne den Proxy:

$ curl https://ja4db.com/id/ja4h/
ge11nn090000_b6a016211e8a_000000000000_e3b0c44298fc

Dies unterscheidet sich deutlich von dem Fingerabdruck, den Chrome erzeugt, wenn Sie die URL direkt besuchen:

ge11cn19enus_f2808f0d04cf_9a10d4221160_7068f58def6e

Wenn wir jedoch den Proxy verwenden, um die Anfrage zu stellen, ist unser JA4H-Fingerabdruck auf magische Weise identisch:

$ curl --proxy http://thermoptic:1234 https://ja4db.com/id/ja4h/
ge11cn19enus_f2808f0d04cf_9a10d4221160_7068f58def6e

(Dasselbe gilt auch für unseren JA4-TLS-Fingerprint usw.).

Einrichtung

Um einen thermoptic-Proxy zu starten, der deinen Datenverkehr durch eine containerisierte Chrome-Instanz auf Ubuntu 22.04 verschleiert:

Reguläres Docker-Setup (funktioniert auf Hosts ohne GPU-Runtime):

docker compose up --build

Das ist alles, jetzt kannst du den Datenverkehr darüber weiterleiten:

curl --proxy http://127.0.0.1:1234 --insecure https://ja4db.com/id/ja4h/

Wichtige Hinweise:

• Standardmäßig läuft der Proxy ohne Authentifizierung. Wenn du vorhast, den Proxy extern verfügbar zu machen, stelle bitte sicher, dass du die Authentifizierung mit den Umgebungsvariablen PROXY_USERNAME und PROXY_PASSWORD einrichtest.
• Wenn du ---insecure nicht verwenden möchtest, musst du die generierte CA-Datei unter ./ssl/rootCA.crt verwenden. Diese wird beim ersten Ausführen von thermoptic generiert.
• Du kannst thermoptic mit jeder Chrome/Chromium-Instanz verbinden, die mit dem Flag --remote-debugging-port gestartet wurde. Dies ist essenziell, da du in gängigeren Umgebungen einrichten und proxen möchtest, um deinen Fingerprint so unauffällig wie möglich zu halten (z. B. Chrome unter Windows).
• Das GPU-Compose-Override ist für NVIDIA-Hosts gedacht, auf denen bereits die NVIDIA-Runtime/das Toolkit von Docker installiert ist. Es reserviert das GPU-Gerät, bindet /dev/dri ein und ermöglicht dem mitgelieferten Chrome-Container, auf den NVIDIA/Vulkan-Rendering-Pfad umzuschalten. Um dies zu nutzen, führe docker compose -f docker-compose.yml -f docker-compose.gpu.yml up --build aus.

Funktionen

• 🕵️ Browser-paritätskonformes Proxying, das Anfragen durch eine echte Chrome-Sitzung wiedergibt, um JA4-Fingerprints bytegenau abzugleichen.
• 🤝 Kaum bis gar kein eigener Code erforderlich, um deinen HTTP-Client (z. B. curl, requests usw.) mit thermoptic zu integrieren – setze einfach den Proxy, und deine Fingerprints werden übernommen.
• 🪝 Hook-Framework für Before-Request-/After-Request-/On-Start-Automatisierung, damit du den gesamten Browser steuern kannst, um Challenges zu lösen oder Artefakte zu erfassen.
  • 📘 Ein Beispiel für einen Cloudflare-Turnstile-Lösungs-Hook findest du in ./hooks/onstart.js.
• 🖥️ Webbrowser-Steuerungs-UI (unter http://127.0.0.1:14111), um das dockerisierte Chrome-Browserfenster zu steuern. Nützlich, um sich manuell bei Websites anzumelden und dann nahtlos den Proxy zu verwenden, um Anfragen als deine angemeldete Sitzung zu stellen (und zum Debuggen).
• 🔌 Lege eine Upstream-HTTP- oder SOCKS-Proxy-URI über die Umgebungsvariable UPSTREAM_PROXY in docker-compose.yml fest.
• 🛡️ Integrierte Health-Checks und Neustart-Kontrollschleife, um eingefrorene Browser zu erkennen und automatisch wiederherzustellen, ohne dass ein Operator eingreifen muss.
• ⚡ Unterstützt HTTP/1.1 und HTTP/2, sodass Datenverkehr über beide Protokolle proxied werden kann. (Beachte, dass du mit dem Proxy über HTTP/1.1 sprechen kannst, während das gesteuerte Chrome mit der Zielseite möglicherweise über ein anderes Protokoll verhandelt.)

Wie funktioniert dieses Cloaking genau?

• Eine HTTP-Anfrage wird mit einem HTTP-Client wie curl gestellt, wobei thermoptic als Proxy festgelegt ist.
• thermoptic analysiert die Anfrage, um bestmöglich zu bestimmen, um welche Art von Browser-Anfrage es sich eigentlich handeln soll (z. B. manueller URL-Besuch? Formularübermittlung? Eine fetch()-Anfrage?).
• thermoptic verwendet das Chrome Debugging Protocol (CDP), um den Browser zu steuern und eine Seite einzurichten, die die Anfrage genau so nachbildet, wie sie normalerweise in einem echten Webbrowser auftreten würde.
• thermoptic löst die Anfrage über den nachgebildeten Kontext aus und erfasst die HTTP-Antwort.
• thermoptic sendet die HTTP-Antwort an den Client zurück.

Da der Browser die Anfrage tatsächlich mit seinem vollständigen Stack stellt, sind die resultierenden JA4-Fingerprints identisch.

HINWEIS: Da viele WAFs JavaScript-basiertes Fingerprinting von Webbrowsern einsetzen, stellt thermoptic auch Hooks bereit, um den Browser für Schlüsselschritte des Scraping-Prozesses zu nutzen. Weitere Informationen dazu findest du in diesem Abschnitt.

Warum dieser Ansatz im Vergleich zu anderen Lösungen?

Um es direkt zu sagen: Andere Ansätze haben grundlegende Schwächen, die sie daran hindern, eine praktikable langfristige Lösung für das Problem des Browser-Fingerprintings zu sein.

Viele andere Versuche, Browser-JA4+-Fingerprinting zu „besiegen“, tun dies, indem sie die verschiedenen Schichten des Browser-Stacks neu implementieren. Dieser Ansatz hat eine Reihe ernster Nachteile, wie zum Beispiel: