Eine neue Technologie zum Umgang mit Subversionen – Was Anti-Detect-Entwickler Ihnen über Core-Updates nicht verraten und warum die richtige Variabilität entscheidend ist

Einleitung

Was könnte einfacher und unbedeutender sein als die Versionsnummer Ihres Browsers? Für einen normalen Benutzer ist es nur eine Ziffernfolge, die sich irgendwo im Hintergrund ändert. Aber für moderne Anti-Bot-Systeme ist es einer der wichtigsten Marker, mit denen sie chirurgisch präzise eine echte Person von einem künstlichen Profil unterscheiden.

Viele Benutzer und sogar Entwickler von Anti-Detect-Browsern glauben immer noch, dass es für eine erfolgreiche Maskierung ausreicht, einfach die neueste Chrome-Core-Version zu nutzen. Dies ist ein gefährlicher Irrglaube. In Wirklichkeit ist die Browserversion eine komplexe, dynamische Struktur, und sie inkorrekt zu fälschen, ist zu einer der am weitesten verbreiteten und am leichtesten erkennbaren Schwachstellen auf dem Markt geworden. Ein statischer, „eingefrorener“ Fingerabdruck, selbst wenn er gestern noch aktuell war, ist heute bereits eine Anomalie und ein Warnsignal für Benutzeranalysesysteme.

In diesem Artikel werden wir zunächst die Anatomie der Chrome-Version analysieren und zeigen, wie Anti-Bot-Systeme Spoofing bis in die kleinsten Details erkennen. Anschließend präsentieren wir die Ergebnisse einer groß angelegten Studie zu neun beliebten Anti-Detect-Browsern, die deutlich macht, warum die meisten von ihnen keine digitale Tarnung, sondern ein leicht erkennbares Ziel schaffen. Wenn Sie mit der Theorie bereits vertraut sind, können Sie gerne direkt zum zweiten Teil springen und explore the research results. Zum Schluss zeigen wir natürlich, wie der neue, innovative Ansatz von Linken Sphere dieses Problem löst und einen wirklich lebendigen Fingerabdruck erstellt, der von dem eines echten Benutzers nicht zu unterscheiden ist.

Anatomie der Chrome-Version

Bevor wir uns den Erkennungsmethoden widmen, betrachten wir das Untersuchungsobjekt selbst. Die vollständige Browserversion ist nicht einfach nur eine Reihe von Zahlen; sie ist ein digitaler Pass mit mehreren Schutzschichten. Die Rolle jeder einzelnen zu verstehen, ist der Schlüssel zur korrekten Fingerprint-Ersetzung.

1. 137 — Hauptversion (wird etwa alle ~4 Wochen veröffentlicht).

• Dies ist die wichtigste Zahl in der Zeichenfolge. Ihre Erhöhung signalisiert ein bedeutendes Browser-Update.
• Typischerweise enthält eine neue Hauptversion spürbare Änderungen für die Nutzer: neue Funktionen, UI-Updates, erhebliche Leistungsverbesserungen oder Erweiterungen der Webstandards.
• Größere Updates beinhalten oft auch signifikante Änderungen an der JavaScript-V8-Engine und der Blink-Rendering-Engine.

2. 0 — Nebenversion (ändert sich normalerweise nicht).

• Historisch gesehen wurde diese Zahl für kleine Funktionsupdates verwendet, die zwischen den Hauptversionen veröffentlicht wurden.
• In Chromes modernem Rapid-Release-Modell ist diese Zahl fast immer null.
• Google zieht es vor, alle Änderungen in die nächste Hauptversion (z. B. 138.0.x.x) zu integrieren, anstatt zwischenzeitliche Nebenversionen zu veröffentlichen.

3. 7151 — Build-Nummer.

• Diese Zahl erhöht sich mit jedem neuen Build, der aus dem Quellcode des Chromium-Projekts (der Grundlage von Chrome) kompiliert wird.
• Sie ist direkt an den spezifischen Zustand der Codebasis im Versionskontrollsystem gebunden.
• Jedes Mal, wenn Entwickler Änderungen am Code vornehmen und einen automatisierten Build-Prozess auslösen, wird diese Zahl erhöht.

4. 120 — Patch/Unterversion. Dieser Teil ändert sich am häufigsten, um Schwachstellen zu beheben.

• Wenn eine kritische Schwachstelle entdeckt wird, kann Google nicht vier Wochen auf die nächste Hauptversion warten.
• Stellen Sie sich vor, in Version 137.0.7151.104 wird eine schwerwiegende Zero-Day-Schwachstelle gefunden. Google wird dringend ein Update 137.0.7151.120 (oder eine andere erhöhte Endnummer) veröffentlichen, das nur die Behebung der Schwachstelle enthält, ohne andere Komponenten zu beeinträchtigen.
• Aus diesem Grund ist es von entscheidender Bedeutung, Ihren Browser immer auf die neueste verfügbare Version zu aktualisieren.

Erkennungsvektoren: Vom User-Agent zu Client Hints

Nachdem wir nun verstanden haben, woraus die vollständige Versionsnummer besteht, müssen wir uns ansehen, wie genau Risikoanalysesysteme diese Daten erhalten. Schließlich ist die Anatomie der Version nur ein Teil des Puzzles; der zweite, ebenso wichtige, sind die Kanäle, über die sie übertragen wird. Lange Zeit war die Hauptquelle der User-Agent-Header, aber im modernen Web-Ökosystem wurde er durch einen neuen, fortschrittlicheren und kontrollierteren Mechanismus ersetzt.

Chrome begann seinen schrittweisen Übergang zur User-Agent Reduction etwa ab Version 95 (Ende 2021), und dieser Prozess wurde in den Versionen 100–110 (während der Jahre 2022–2023) aggressiver. Bis 2025 ist dieser Mechanismus vollständig einsatzbereit.

Zuvor enthielt jede Browser-Anfrage an eine Website einen User-Agent-Header, der ungefähr so aussah:
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.1234.56 Safari/537.36

Dieser String enthielt viele einzigartige Informationen: die genaue Browserversion, das Betriebssystem und dessen Architektur. Dies ermöglichte es Websites, Benutzer leicht zu verfolgen, indem sie deren „passiven“ digitalen Fingerabdruck erstellten.

User-Agent Reduction ist die Initiative von Google, diesen String „einzufrieren“ und zu verkürzen. Standardmäßig sieht eine Website nun eine viel allgemeinere Version:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.0.0 Safari/537.36

Beachten Sie, dass die Minor-Versionen und Build-Nummern durch Nullen ersetzt wurden (93.0.0.0). Dies macht den User-Agent weniger einzigartig und erschwert das passive Tracking. Um genaue Daten zu erhalten, muss sich eine Website nun auf einen neuen, transparenteren Mechanismus verlassen.

Die wichtigste moderne Methode ist die Technologie namens User-Agent Client Hints (UA-CH). Sie funktioniert nach dem Prinzip aktiver Anfragen, die vom Server initiiert werden.

1. Erste Anfrage des Benutzers an die Website

Der Browser sendet zunächst nur grundlegende „Hinweise“ (Low-Entropy Client Hints), die keine besonders einzigartigen Informationen enthalten. Diese werden standardmäßig in neuen Headern gesendet:

• Sec-CH-UA: "Google Chrome";v="137", "Chromium";v="137", "Not/A)Brand";v="24" (Marke und Hauptversion)
• Sec-CH-UA-Mobile: ?0 (Dies ist kein Mobilgerät)
• Sec-CH-UA-Platform: "Windows" (Name des Betriebssystems)

2. Serverantwort mit der Anforderung detaillierter Informationen

Wenn eine Website (z. B. ein Erkennungssystem) genauere Daten benötigt, muss sie einen speziellen Accept-CH-Header in ihre Antwort an den Browser aufnehmen. In diesem Header listet sie auf, welche spezifischen „High-Entropy Client Hints“ sie erhalten möchte. „High Entropy“ (hohe Entropie) bedeutet, dass diese Datenpunkte einzigartiger sind.

Beispiel für einen Server-Header, der die vollständige Version und Architektur anfordert:
Accept-CH: Sec-CH-UA-Full-Version-List, Sec-CH-UA-Arch, Sec-CH-UA-Platform-Version

3. Nachfolgende Anfragen an die Website

Nach Erhalt dieses Headers fügt der Browser des Benutzers die angeforderten Header in alle nachfolgenden Anfragen an dieselbe Website ein.

Beispiel für die Header, die der Browser als Antwort auf die obige Anfrage sendet:

• Sec-CH-UA-Full-Version-List: "Google Chrome";v="137.0.7151.120", "Chromium";v="137.0.7151.120", "Not/A)Brand";v="24.0.0.0"
• Sec-CH-UA-Arch: "x86"
• Sec-CH-UA-Platform-Version: "15.0.0"

Somit erhält die Website die genaue Browserversion – jedoch erst, nachdem sie diese ausdrücklich angefordert hat. Dies macht den Datenerfassungsprozess transparenter.

Verteilung echter Nutzer über Chrome-Versionen

Entgegen der landläufigen Meinung verwenden echte Nutzer zu einem bestimmten Zeitpunkt nicht alle eine einzige „aktuelle“ Chrome-Version. Stattdessen beobachten wir eine dynamische Verteilung über mehrere Versionen hinweg, angetrieben durch Googles official release strategy.

Wie in der Entwicklerdokumentation beschrieben, verwendet das Unternehmen ein gestaffeltes Rollout-Modell. Dieser Ansatz minimiert das Risiko: Das Update wird zunächst für 1–5 % der Nutzer freigegeben, und erst nach Bestätigung der Stabilität und dem Fehlen kritischer Probleme wird der Rollout über mehrere Tage oder sogar Wochen schrittweise auf 100 % erhöht.

Infolgedessen sind zu jedem Zeitpunkt mindestens zwei oder drei stabile Chrome-Versionen aktiv im Einsatz, jede mit unterschiedlichen prozentualen Anteilen – eine Tatsache, die durch Dienste wie Chromium Dash deutlich veranschaulicht wird. Weitere Schlüsselfaktoren beeinflussen ebenfalls das endgültige Verteilungsmodell:

• Automatische Updates — Chrome lädt Updates im Hintergrund herunter und wendet sie nach dem Neustart des Browsers an. Die Mehrheit der Nutzer mit aktivierten automatischen Updates bildet die Spitze bei den neuesten Versionen.
• Nutzergewohnheiten — ein erheblicher Anteil der Nutzer (insbesondere auf Desktops) lässt seinen Browser wochenlang laufen, ohne ihn zu schließen, und nutzt den Ruhe- oder Energiesparmodus. Diese Nutzer bleiben auf der Version, die beim letzten Start ihres Browsers aktuell war. Dies erzeugt einen beträchtlichen „Nachlauf“ an Nutzern bei der vorherigen stabilen Version.
• Unternehmenssegment — in Geschäftsumgebungen werden häufig Long-Term-Support-Versionen (LTS) oder festgelegte Versionen verwendet, die weitaus seltener aktualisiert werden.

Um zu verstehen, was einen „normalen“ Fingerprint ausmacht, reicht es nicht aus, einfach nur die neueste Version zu kennen. Es ist unerlässlich zu verstehen, wie sich die Nutzer auf die neuesten Builds verteilen. Es ist wichtig, sich daran zu erinnern, dass sich diese Verteilung ständig ändert. Die Momentaufnahme, die wir am 2. Juli 2025 aufgezeichnet haben, wird schon eine Woche später anders aussehen. Zum Zeitpunkt unserer Untersuchung stellte sich die Situation wie folgt dar:

1. 138.0.7204.97 — Dies ist die neueste stabile Version, die erst vor zwei Tagen veröffentlicht wurde. Dank der gestaffelten Rollout-Richtlinie gewinnt sie schnell an Popularität und wird bereits dominant. Anti-Bot-Systeme beginnen, sie als primären Indikator für „Normalität“ zu verwenden.

• Veröffentlichungsdatum: 30. Juni 2025
• Nutzeranteil: 48 %

2. 137.0.7151.120 — Die letzte stabile Version der 137er-Engine. Google lässt sie zugunsten der neueren Version allmählich auslaufen, sodass ihr Anteil stetig sinkt. Dennoch ist sie nach wie vor eine sehr beliebte Version.

• Veröffentlichungsdatum: 18. Juni 2025
• Nutzeranteil: 32 %

3. 138.0.7204.50 — Die erste stabile Version der 138er-Engine, die den Nutzern seit etwa einer Woche zur Verfügung steht. Die Nutzer warten nun auf das nächste kleinere Update auf Version .97, was eine völlig normale und natürliche Phase im Update-Lebenszyklus ist.

• Veröffentlichungsdatum: 24. Juni 2025
• Nutzeranteil: 17 %

4. Frühere Versionen — Eine statistische Fehlermarge. Dazu gehören Geräte, die lange Zeit offline waren, oder Systeme, bei denen automatische Updates zwangsweise deaktiviert wurden. Eine Konzentration von Fingerprints auf diesen Versionen ist ein klares Zeichen für einen künstlichen Fingerprint.

• Veröffentlichungsdatum: Mai 2025 und früher
• Nutzeranteil: < 3 %

Es gibt keine einzelne „richtige“ Chrome-Version. Stattdessen sehen wir ein gesundes, dynamisches Ökosystem, in dem mindestens drei verschiedene Builds (.97, .120, .50) gleichzeitig in signifikanten Anteilen koexistieren und zusammen 97 % aller Nutzer abdecken.

Diese Verteilung ist lediglich eine Momentaufnahme. Vor einer Woche sah sie noch anders aus, und in nur wenigen Tagen – wenn sich Version .97 weiter ausbreitet – wird sie sich erneut ändern: Die Anteile von .120 und .50 werden weiter sinken. Genau diese natürliche, dynamische Verteilung macht den „gesunden“ Fingerprint aus, der von Risikomanagementsystemen erwartet wird.

Reaktion von Vertrauens- und Sicherheitssystemen

Bei der Bewertung eines Nutzers achten moderne Plattformen für prädiktive Analysen auf eine Vielzahl von Parametern – und die Browserversion ist einer davon. Ihre Bedeutung nimmt drastisch zu, wenn sie mit anderen Anomalien innerhalb einer Gruppe von Konten korreliert.

Der genaue Algorithmus kann je nach spezifischem System variieren, aber es gibt eine Reihe gemeinsamer verdächtiger Muster, die sich oft negativ auf den Erfolg Ihrer Operationen auswirken. Schauen wir uns Beispiele für Warnsignale an, die bei Versionsprüfungen erkannt werden können.

Veraltete Hauptversion

Eines der offensichtlichsten Anzeichen dafür, dass mit dem Nutzer etwas nicht stimmt.

> Beispiel: Die aktuelle stabile Version von Chrome ist 138, aber der Nutzer verwendet Version 135.

Die überwiegende Mehrheit der Browser wird automatisch und im Hintergrund aktualisiert. Das Deaktivieren von automatischen Updates ist für einen durchschnittlichen Nutzer keine triviale Aufgabe. Ein erheblicher Rückstand (um 2 oder mehr Versionen) deutet fast immer entweder auf eine Unternehmensumgebung mit strengen Richtlinien oder auf die Verwendung alter Software zur Automatisierung oder zum Fingerprint-Spoofing hin.

Das System vergleicht die erkannte Version mit der aktuellen, weltweit stabilen Version. Wenn die Differenz einen bestimmten Schwellenwert überschreitet (z. B. 2–4 Hauptversionen), steigt die Risikobewertung stark an.

Verwendung nicht existierender Versionen

Ein direkter Hinweis auf Spoofing und eines der stärksten Signale für das System.

> Beispiel: Ein Nutzer verwendet die Version 134.0.6984.1, aber in Wirklichkeit hat es nie ein stabiles Chrome-Release mit dieser Versionsnummer gegeben.

Dies ist ein direkter Beweis dafür, dass die Version manuell geändert oder von einem minderwertigen Tool generiert wurde. Ein echter Browser würde niemals eine Version senden, die nie existiert hat (z. B. 134.0.6984.1, 134.0.6990.0 usw.).

Anti-Bot-Systeme pflegen eine Datenbank aller öffentlich veröffentlichten Builds für beliebte Browser. Die erkannte Version wird einfach mit dieser Liste abgeglichen. Eine fehlende Übereinstimmung ist praktisch ein 100%iges Warnsignal, das zu einer sofortigen Sperrung oder der Aufforderung zu einer zusätzlichen Verifizierung (CAPTCHA, SMS, KYC) führen kann.

Verwendung einer veralteten oder unpopulären Unterversion

Dies ist eine subtilere, aber äußerst effektive Erkennungsmethode.

> Beispiel: Die aktuelle Version von Chrome 137 ist 137.0.7151.120 (17. Juni 2025), aber der Nutzer verwendet 137.0.7151.56 (27. Mai 2025), ein Rückstand von mehr als drei Wochen.

Google veröffentlicht recht häufig Sicherheitsupdates und Patches für stabile Chrome-Zweige. Das bedeutet, dass innerhalb weniger Wochen nach der Veröffentlichung der Version 137.0.7151.56 die Mehrheit der echten Nutzer automatisch auf .69, .104, .120 und so weiter aktualisiert haben wird. Wenn das System einige Zeit nach der Veröffentlichung von .120 einen Anstieg der Registrierungen mit der Version .56 feststellt, ist das eine Anomalie.

Ein Analysesystem sammelt Statistiken nicht nur für die Hauptversion, sondern für vollständige Versionszeichenfolgen. Das System weiß, dass >95 % der Nutzer von Chrome 137 derzeit Builds xxxx.120 und neuer verwenden. Ein Konto mit der Version xxxx.56 fällt in die restlichen 5 %, und wenn es viele solcher Konten gibt, ist dies ein fast garantiertes Zeichen für eine Farm, die dasselbe veraltete „Snapshot“-Profil verwendet.

Anomale Konzentration auf eine bestimmte Version

Diese Methode ermöglicht es Systemen, ganze Kontenfarmen zu erkennen. Dieses Muster hat zwei Hauptvarianten:

> 1. Konzentration auf eine seltene oder veraltete Version.
> Beispiel: Das System stellt fest, dass in der vergangenen Stunde 200 Konten erstellt wurden, die alle die Version Chrome/137.0.7151.68 melden – ein Zwischen-Release, das weniger als eine halbe Stunde lang aktuell war. Die Wahrscheinlichkeit eines solchen Zufalls bei echten Nutzern ist gleich null. Dies ist ein direkter Beweis für die Verwendung desselben „eingefrorenen“ und in Bezug auf die Verbreitung fehlerhaften Fingerprints.
> 2. Konzentration auf die aktuelle Version.
> Beispiel: Stand 2. Juli ist die aktuelle Version 138.0.7204.97. Wenn das System aufzeichnet, dass 50 neue Registrierungen von einer einzigen IP-Adresse oder innerhalb einer einzigen Affiliate-Kampagne stammen, alle mit exakt derselben Version, ist dies ebenfalls ein starkes Signal. Selbst echte Nutzer, die zeitnah aktualisieren, verteilen sich aufgrund von gestaffelten Rollouts auf mehrere aktuelle Builds (.97, .50 und Überreste von .120). Perfekt identische Versionen sind ein Zeichen für Multi-Accounting.

Das Risikobewertungssystem verfolgt die gesamte Release-Historie mit hoher Präzision, einschließlich des Zeitpunkts der Veröffentlichungen und ihrer Rollouts. Manchmal gibt es zwischen zwei öffentlichen Builds einen oder mehrere Zwischen-Builds (transiente Builds), die zwar kompiliert, aber entweder nie an die Nutzer ausgerollt wurden oder nur für einen sehr kurzen Zeitraum – von wenigen Minuten bis zu ein paar Stunden – über das automatische Update verfügbar waren, bevor sie durch den nächsten, stabileren Build ersetzt wurden.

Untersuchung: Wie beliebte Anti-Detect-Browser die Browserversion fälschen

Theorie ist gut – aber wie sieht das in der Praxis aus? Um ein objektives Bild des Marktes zu erhalten, haben wir eine umfassende Studie von neun beliebten Anti-Detect-Browsern durchgeführt, wobei wir eine Methodik angewandt haben, die jeder nachvollziehen kann.

Wie testen Sie Ihren Anti-Detect-Browser?

Datenerfassung

1. Erstellen Sie eine Sitzung/ein Profil mit der neuesten verfügbaren Engine
2. Gehen Sie zu https://browserleaks.com/client-hints
3. Suchen Sie nach dem Parameter uaFullVersion (oder Sec-CH-UA-Full-Version) und notieren Sie dessen Wert
4. Wiederholen Sie den Vorgang und sammeln Sie Daten aus fünf verschiedenen Sitzungen/Profilen

Am Ende sollten Sie eine Liste mit fünf Versionen haben, zum Beispiel:

``
138.0.7204.50
138.0.7204.97
138.0.7204.50
138.0.7204.97
138.0.7204.97
``

Analyse

Sie haben nun also fünf Chrome-Versionen aus Ihrem Anti-Detect-Browser gesammelt. Woher wissen Sie, ob diese echt sind? Dafür benötigen wir eine Referenz. Alle Informationen über echte Chrome-Versionen, deren Veröffentlichungsdaten und Zielplattformen (Windows, macOS, Linux, Android) werden im offiziellen Google Chrome Releases Blog veröffentlicht.

Um zu beurteilen, wie gut Ihr Anti-Detect-Browser fälscht, vergleichen Sie Ihre gesammelten Daten mit dieser Quelle, indem Sie die Fragen in der folgenden Checkliste beantworten. Je mehr „Ja“-Antworten Sie erhalten, desto schwieriger wird es für Anti-Bot-Systeme sein, Sie von einem echten Benutzer zu unterscheiden.

• Verwendet der Browser die Engine der aktuellen Version?
• Existieren die Versionen tatsächlich?
• Sind die Versionen aktuell (nicht älter als 1,5–2 Wochen)?
• Sind die Versionen dynamisch (gibt es mindestens zwei verschiedene)?

Ergebnisse unserer Untersuchung

Um den aktuellen Zustand des Marktes objektiv zu beurteilen, haben wir am 2. Juli 2025 unsere eigene Untersuchung von neun beliebten Anti-Detect-Browsern durchgeführt. Die Ergebnisse waren gemischt und offenbarten mehrere grundlegende Ansätze zur Versionsfälschung, von denen jeder seine eigenen Vorteile und kritischen Schwachstellen aufweist.

Anstatt jedes Produkt im Detail zu analysieren, haben wir sie nach ihren typischen Problemen gruppiert, was es einfacher macht, die allgemeinen Trends und Fehler der Entwickler zu verstehen.

Gruppe 1: „Ein ganzes Zeitalter im Rückstand“

Veraltete Browser-Engine

Beginnen wir mit dem gröbsten und unverzeihlichsten Fehler. Zum Zeitpunkt der Untersuchung war die aktuelle stabile Version von Chrome die 138. GoLogin bietet den Nutzern jedoch einen Kern, der auf Version 135 basiert, und MoreLogin verwendet sogar Version 134. Jedes ernstzunehmende Trust-System stuft einen solchen Browser sofort als anomal ein, da 99 % der echten Nutzer dank automatischer Updates längst auf neuere Versionen umgestiegen sind.

MoreLogin verdient besondere Aufmerksamkeit, da es nicht nur einen veralteten Kern verwendet, sondern auch Build- und Patch-Nummern generiert, die nie existiert haben. Dies ist der ineffektivste Ansatz, da er einen einzigartigen, künstlichen Fingerabdruck erzeugt, der nicht nur veraltet ist, sondern auch nie mit einem echten, jemals veröffentlichten Browser übereingestimmt hat.

Gruppe 2: „In der Vergangenheit steckengeblieben“

Veraltete Browserversionen

Diese Produktgruppe (Adspower, Multilogin X) zeigt ein subtileres, aber ebenso bedeutsames Problem. Technisch gesehen verwenden sie die Hauptversion 137, die bei einigen echten Nutzern noch anzutreffen ist (zum Beispiel hat 137.0.7151.120 einen Anteil von 32 %). Der Teufel steckt jedoch im Detail: Die spezifischen Unterversionen, die sie verwenden (.55, .56, .68), sind seit über einem Monat veraltet.

Für Anti-Bot-Systeme, die Versionsverteilungen analysieren, ist dies eine klare Anomalie. Die meisten echten Nutzer, die die Version 137 verwenden, haben längst auf den neuesten Sicherheitspatch aktualisiert, während diese Browser weiterhin Fingerabdrücke von Builds generieren, die nicht mehr aktiv genutzt werden. Die Situation wird durch die statische Natur von Multilogin X verschlimmert, bei dem alle Profile mit exakt derselben veralteten Version erstellt werden. Darüber hinaus verlassen sich Adspower (.55) und Multilogin X (.68) auf Zwischenversionen, die unter echten Nutzern nie weit verbreitet waren, was die Fokussierung auf sie noch anomaler macht.

Gruppe 3: „Aktuell, aber statisch“

Statische Browserversion über alle Profile hinweg

Undetectable und Vision sowie seit Kurzem auch Dolphin Anty stellen einen bedeutenden Fortschritt dar. Alle drei Produkte verwenden die aktuelle Engine-Version (138) und setzen echte und aktuelle Unterversionen für das Spoofing ein. Ein oder zwei Profile, die in einem solchen Browser erstellt wurden, erscheinen absolut plausibel. Ihr Hauptfehler ist jedoch ihre statische Natur. Analysiert man 10–15 Profile, zeigen sie alle exakt dieselbe Browserversion (.97 im Fall von Undetectable, .50 bei Vision und Dolphin Anty). In Kombination mit einzigartigen Verhaltensfaktoren – die wir im Artikel über menschenähnliche Tippfunktion besprochen haben – wird dies zu einem klassischen Muster, durch das Analysesysteme Account-Farmen erkennen.

Die Anfälligkeit dieses Ansatzes wird durch unsere vorläufigen Tests vom 26. Juni deutlich veranschaulicht. Zu diesem Zeitpunkt boten Undetectable und Vision den Nutzern die Version 137.0.7151.104 an. Diese Veröffentlichung fand am 11. Juni statt und war tatsächlich für etwa eine Woche aktuell. Zu dem Zeitpunkt, als wir unsere Tests durchführten, hatten die meisten echten Nutzer jedoch entweder auf einen neueren Build innerhalb derselben Hauptversion (137.0.7151.120) aktualisiert oder waren auf die neue Version 138 umgestiegen.

Die Situation bei Dolphin Anty vor dem jüngsten Update war noch aufschlussreicher. Auch hier wurde eine statische Version verwendet, allerdings eine noch ältere – 137.0.7151.56 (veröffentlicht am 28. Mai). Ende Juni war dieser Fingerabdruck nicht nur veraltet, sondern anomal alt. Dieses Beispiel veranschaulicht perfekt den grundlegenden Fehler eines statischen Ansatzes: Selbst ein anfangs gültiger Fingerabdruck wird im Laufe der Zeit unweigerlich zu einer leicht erkennbaren Anomalie, wodurch das gesamte Netzwerk von Konten den Risikobewertungssystemen ausgesetzt wird.

Gruppe 4: „Fortschrittlich, aber fehlerhaft“

Anomale Verteilung über seltene Versionen

Octo Browser zeigt den fortschrittlichsten, aber paradoxerweise fehlerhaften Ansatz. Er verwendet korrekterweise den aktuellen Kern (138) und stellt vor allem dynamische Versionsänderungen über verschiedene Profile hinweg sicher. Auf den ersten Blick scheint dies die perfekte Strategie zu sein.

Eine genauere Analyse offenbart jedoch einen kritischen Fehler. Die Entwickler haben alle Chrome-Unterversionen in ihren Spoofing-Pool aufgenommen, einschließlich:

• Zwischen-Builds (z. B. .96, .49, .51), die echten Nutzern nur für eine sehr kurze Zeit (manchmal weniger als 20 Minuten) zur Verfügung standen, bevor der nächste Patch veröffentlicht wurde.
• „Early Stable“-Versionen (z. B. .35), die vor der vollständigen Bereitstellung nur auf einem sehr begrenzten Prozentsatz von Geräten ausgerollt wurden.

Der Hauptfehler besteht darin, dass die Verteilung dieser Versionen ihren tatsächlichen Marktanteil nicht berücksichtigt. Man hat in etwa die gleiche Chance, einen weit verbreiteten, stabilen Build (.50 oder .97) zu erhalten, wie eine sehr seltene „Early Stable“-Version, die in der Realität von weniger als 1 % der Nutzer gesehen wurde.

Für jedes Anti-Bot-System ist dies ein eklatantes Merkmal. Während der echte Traffic von ein oder zwei der am weitesten verbreiteten Unterversionen dominiert wird, erzeugt Octo Browser eine anomale Konzentration seltener Builds. Es ist, als würde man versuchen, seine „Normalität“ zu beweisen, indem man ständig mit seltenen Sammlermünzen bezahlt: Ja, sie sind echt, aber sie regelmäßig im Alltag zu verwenden, ist eine offensichtliche Anomalie, die sofort Aufmerksamkeit erregt. Somit erzeugt der fortschrittlichste Ansatz in der Praxis ein leicht erkennbares Muster, das den künstlichen Ursprung der Fingerabdrücke offenbart.

Linken Sphere: Wie ein idealer Mechanismus zur Versionsersetzung funktionieren sollte

Unsere Untersuchung zeigt deutlich, dass der Markt für Anti-Detect-Browser voller Kompromisslösungen ist. Anstelle eines umfassenden Schutzes sehen sich die Nutzer mit einer Reihe kritischer Schwachstellen konfrontiert – von der Verwendung hoffnungslos veralteter Browser-Kerne bis hin zum Spoofing nicht existierender oder längst veralteter Unterversionen. Selbst fortschrittliche Lösungen leiden entweder unter statischen Fingerabdrücken, die es einfach machen, Nutzerprofile zu clustern, oder unter der Erzeugung einer anomalen Konzentration auf seltene Versionen, was ebenfalls ein Warnsignal für Trust-Plattformen ist.

Genau um diese Probleme umfassend zu lösen, wurde mit dem neuesten Update von Linken Sphere ein grundlegend neuer, innovativer Mechanismus für den Umgang mit Browserversionen eingeführt. Sein Ziel ist es nicht nur, einen plausiblen Fingerabdruck zu erstellen, sondern die natürliche Evolution des digitalen Fingerabdrucks eines echten Nutzers zu simulieren.

Er basiert auf drei Grundprinzipien:

1. Relevanz und Realismus

Wir verwenden nicht einfach nur die neueste Engine-Version. Unser System überwacht kontinuierlich die offiziellen stabilen Versionen von Google Chrome und analysiert deren tatsächliche prozentuale Verteilung im Web. Wir wählen nur weit verbreitete, existierende Versionen aus.

2. Dynamische Generierung

Bei der Erstellung einer neuen Sitzung (Profil) wird dieser eine zufällige, aber garantiert existierende und aktuell relevante Unterversion aus einem Pool gültiger Versionen zugewiesen. Dies beseitigt das Problem statischer Fingerabdrücke, die Anti-Bot-Systeme verwenden können, um Ihre Profile zu gruppieren. Ebenso erhält die Sitzung bei einem Upgrade der Engine (z. B. von v137 auf v138) eine zufällig ausgewählte neue, relevante Unterversion.

3. Automatische Evolution des Fingerabdrucks

Und das Wichtigste: Wenn Google neue Patches veröffentlicht, werden die Unterversionen in Ihren bestehenden Profilen automatisch und im Hintergrund aktualisiert, was das natürliche Nutzerverhalten nachahmt.

Angenommen, Sie haben eine Sitzung erstellt, als die Version .56 aktuell war. Dann veröffentlicht Google den nächsten Patch .69; Ihre Sitzung wird nicht sofort aktualisiert, was das Verhalten echter Nutzer simuliert. Sobald jedoch ein weiteres Release herauskommt – zum Beispiel .104 – und die Lücke zwischen der Version Ihrer Sitzung und der aktuellen Version signifikant wird, löst das System den Evolutionsmechanismus aus. Zu diesem Zeitpunkt beginnen sich Ihre älteren Sitzungen zu aktualisieren, jedoch nicht einheitlich: Einige wechseln zur Zwischenversion .69, während andere direkt zur neuesten Version .104 springen, wodurch eine äußerst natürliche und vielfältige Verteilung entsteht.

Somit müssen Sie nicht auf ein Client-Update warten, damit Ihre Sitzungen aktuelle Unterversionen erhalten. Dieser Prozess läuft in Linken Sphere nahtlos und automatisch ab, während die Aktualisierung des Clients selbst nur für globale Übergänge zur nächsten Chrome-Engine-Version erforderlich ist.

Dies erzeugt nicht nur einen statischen „Schnappschuss“, sondern einen lebendigen, sich entwickelnden digitalen Fingerabdruck, der konsequent dem Verhalten echter Nutzer im Internet entspricht.

Fazit

Das Wettrüsten zwischen Erkennungssystemen und Anonymisierungstools hat längst eine neue Ebene erreicht. Die Zeiten, in denen eine aktuelle Engine-Version für einen erfolgreichen Betrieb ausreichte, sind endgültig vorbei. Wie unsere Untersuchungen gezeigt haben, analysieren moderne Risikobewertungssysteme nicht nur die Hauptversion, sondern deren gesamte Struktur und achten dabei besonders auf die letzten Ziffern – die Build- und Patch-Nummern. Genau in diesen Details, in der Dynamik ihrer Updates und ihrer Verteilung unter echten Nutzern, liegt der Schlüssel zu einem natürlichen Fingerprint.

Die meisten Anti-Detect-Browser auf dem Markt bieten den Nutzern eine statische Version – eine „eingefrorene“ Momentaufnahme, die, selbst wenn sie zum Zeitpunkt der Erstellung aktuell war, unweigerlich veraltet und sich in einen weiteren Erkennungsvektor verwandelt. Linken Sphere bietet einen grundlegend anderen, proaktiven Ansatz. Es ist nicht bloß Tarnung – es ist eine vollständige Mimikry. Ihre Sitzungen sehen nicht nur echt aus – sie leben und entwickeln sich parallel zum Chrome-Ökosystem und erhalten automatisch und unsichtbar die neuesten Sicherheitspatches, genau wie bei Millionen von normalen Nutzern. Ihr Fingerprint ist kein statisches Ziel mehr, sondern wird zu einem nicht unterscheidbaren Teil der natürlichen digitalen Landschaft.

Verlassen Sie sich nicht länger auf in der Zeit eingefrorene Fingerprints. In einer Welt, in der sich alles ständig aktualisiert, ist jedes statische Muster eine Anomalie. Und bei jeder Anomalie ist es nur eine Frage der Zeit, bis sie erkannt und blockiert wird. Fragen Sie sich selbst: Schafft Ihr Tool eine digitale Tarnung – oder ein digitales Ziel?