Tous les articles
6 min de lectureglizzykingdreko

Analyse des derniers changements de Datadome

De temps en temps, Datadome implémente vraiment quelque chose de nouveau, et j'espère toujours tomber sur une situation épicée, mais cette fois (encore) ce…

Analyse des derniers changements de Datadome

De temps en temps, Datadome implémente vraiment quelque chose de nouveau, et j'espère toujours tomber sur une situation épicée, mais cette fois (encore) ce ne semble pas être le cas.

Pas de puzzle !

Commençons par parler de l'activation globale (apparemment) du captcha noPuzzle.

Cela faisait partie d'un code dormant placé il y a un moment, mais je ne l'avais en fait jamais vu actif avant il y a quelques semaines.

Pour l'instant, il semble que leur classique « slide captcha » ait été désactivé globalement (donc probablement pas une configuration au niveau du site).

Pro

En réalité, en termes de résolution, rien n'a changé, c'est peut-être même amélioré, puisqu'auparavant il fallait calculer l'emplacement de « l'arrivée du slide » (pour les mouvements et les signaux) alors que maintenant c'est toujours une valeur statique. Le temps de résolution est lui aussi réduit puisqu'il n'y a plus besoin de résoudre et d'analyser les images du défi.

Contre

Je suppose que cela signifie qu'ils sont sur le point d'implémenter un nouveau captcha basé sur des images (je l'espère pour eux).

Virtual Machine — plv3

Cette mise à jour s'est accompagnée de l'implémentation, à la fois sur le captcha et sur l'interstitiel, du paramètre plv3.

Sa génération est entièrement gérée par leur fichier vm-obj.js.

Je vais expliquer cette partie de la façon la plus simple possible afin que n'importe quel lecteur comprenne de quoi on parle.

Qu'est-ce qu'une VM Javascript (Virtual Machine) ?

En quelques mots, Javascript s'exécute normalement dans votre navigateur grâce à son moteur, capable de comprendre spécifiquement Javascript.
Une VM permet d'exécuter d'autre code. Presque comme un petit pc à l'intérieur de la fenêtre de votre navigateur. Cela aide surtout à la protection et à l'obfuscation du code.

Maintenant qu'on comprend les VM en général, voyons comment Datadome implémente spécifiquement la sienne.

La VM de Datadome

La logique suit ces 3 étapes :

┌─────────────────────────────────────────────────────────────┐
│                      BYTECODE                                │
│  (A long string of numbers - the encoded instructions)       │
│  Example: [45, 128, 67, 23, 199, 54, 12, 88, ...]            │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                     THE VM ENGINE                            │
│  - Reads bytecode one instruction at a time                  │
│  - Has a "stack" to store temporary values                   │
│  - Has a "program counter" to track current position         │
│  - Executes ~100 different operation types                   │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                       OUTPUT                                 │
│  A "fingerprint" - a unique signature of your browser        │
│  Example: {"r": "abc123...", "i": 340000, "t": 25}           │
└─────────────────────────────────────────────────────────────┘

Ces instructions bytecode proviennent de cette longue chaîne qu'on trouve à l'intérieur de leur fichier vm-obj.js.

Stack
La VM utilise une « stack » où on ne peut que push ou pop depuis le sommet.

PUSH 5 [5]
PUSH 3 [5, 3]
ADD [8]        (pops 5 and 3, pushes their sum)
PUSH 2     →  [8, 2]
MULTIPLY [16]

**Program Counter (PC)
**Le Program Counter indique à la vm où lire la prochaine instruction.

Bytecode: [PUSH, 5, PUSH, 3, ADD, PUSH, 2, MULTIPLY]
              ↑
              PC = 0 (start here)

After PUSH 5:
Bytecode: [PUSH, 5, PUSH, 3, ADD, PUSH, 2, MULTIPLY]
                    ↑
                    PC = 2 (moved forward)

C'est parce que chaque nombre dans le bytecode représente une opération ; dans celui de Datadome, on va en trouver environ 100 différentes :

| Opcode | Name     | What it does                   |
|--------|----------|--------------------------------|
| 45     | PUSH     | Put a value on the stack       |
| 67     | ADD      | Add two numbers                |
| 89     | JUMP     | Go to a different position     |
| 92     | JUMP_IF  | Jump only if condition is true |
| 23     | GET_PROP | Get a property from an object  |
| 54     | CALL     | Call a function                |
| ...    | ...      | ...                            |

disons que la VM veut vérifier si votre navigateur possède une certaine fonctionnalité, elle va procéder d'une manière comme celle-ci :

Bytecode: [GET_WINDOW, GET_PROP, "navigator", GET_PROP, "userAgent", STORE]

Step 1: GET_WINDOW
   Stack: [window]
   (Gets the browser's window object)

Step 2: GET_PROP "navigator"
   Stack: [navigator]
   (Gets window.navigator)

Step 3: GET_PROP "userAgent"
   Stack: ["Mozilla/5.0 Chrome/120..."]
   (Gets the browser's user agent string)

Step 4: STORE
   Stack: []
   (Saves this value to use in the fingerprint)

Les données de sortie

Après une exécution réussie de la VM (environ 360k instructions pour un captcha, environ 100k de moins pour le défi interstitiel), la sortie ressemblera à :

{
  "r": "aGVsbG...",  # output fingerprint value
  "i": 340580,       # interactions done
  "t": 25            # elapsed time
}

Avec ces données de sortie, on a maintenant r qui sera utilisé comme notre plv3, tandis que les 2 autres vont être utilisées pour le payload de signaux.

Comment peut-on le résoudre ?

Actuellement, les instructions bytecode font plusieurs vérifications avant/pendant l'extraction du fingerprint, qui doivent non seulement correspondre aux détails de votre payload résolu, mais aussi à ceux du défi que vous êtes en train de résoudre.

Cela signifie qu'utiliser un onglet de navigateur pour le résoudre n'est pas seulement la pire solution et la moins scalable, ce sera aussi non fonctionnel. Donc bonne chance aux solutions basées sur selenium qui traînent et essaient de fonctionner avec.

La meilleure approche serait en réalité de comprendre ces instructions, ce que la VM recherche et analyse, afin de créer ensuite un environnement basé sur un script capable d'exécuter correctement le fichier avec les mêmes détails que ceux utilisés pour la construction du payload de signaux.

La clé principale du reverse engineering des antibots est toujours : « avoir une idée de ce qui se passe » ou vous en paierez le prix plus tard !

Je suppose que ce n'est qu'un premier test pour Datadome, voyons si les prochains changements de VM seront vraiment costauds lol.

Besoin d'une solution Datadome stable ?

Prenez contact avec des experts qui comprennent vraiment la technologie, ne partez pas du principe que vous voulez avoir votre projet à l'arrêt à chaque fois que Datadome pousse un changement.

Chez TakionAPI, nous la fournissons. Ne manquez pas de la découvrir, démarrez un essai gratuit puis passez à notre documentation : un appel d'API et Datadome n'est plus un problème dont vous devez vous soucier.

Restons en contact

Si vous avez apprécié cet article, suivez-moi sur GitHub et sur Medium pour recevoir une notification chaque fois que je publie ou que j'ouvre le code de quelque chose.

web-scrapinganti-botreverse-engineeringjavscript-vmdatadome

Sautez l'étape de la rétro-ingénierie.

Takion renvoie des cookies, en-têtes et tokens frais pour tous les grands murs antibot. Un seul POST, aucun navigateur, premier appel dans l'heure.