Détecter les émulateurs et les machines virtuelles dans le trafic web

La majeure partie de la fraude à grande échelle tourne sur une infrastructure virtualisée, parce que l'alternative — une pièce remplie de téléphones et d'ordinateurs physiques — ne passe pas à l'échelle et ne se cache pas. Un émulateur ou une machine virtuelle permet à un seul opérateur de créer à la demande des milliers d'appareils apparemment distincts, chacun ressemblant à un point de terminaison grand public tout neuf. Détecter cette virtualisation est l'une des choses les plus rentables que fait une couche d'intelligence des appareils, car elle identifie l'infrastructure de l'abus à grande échelle plutôt que de poursuivre les actions frauduleuses individuelles une par une.

Cet article explique comment les émulateurs et VM se révèlent dans le trafic web et applicatif : les signaux matériels, temporels et de cohérence qu'un environnement virtualisé peine à reproduire, pourquoi aucun signal isolé ne suffit, et comment agir sur la détection sans casser la virtualisation légitime. Le public visé, ce sont les ingénieurs et les équipes anti-fraude qui construisent ou évaluent une détection des bots.

Pourquoi les émulateurs et VM comptent pour la fraude

Les émulateurs et machines virtuelles comptent parce qu'ils constituent le substrat économique de la fraude en volume — ils transforment une seule machine en une flotte d'appareils à l'apparence propre, ce qui est exactement ce qu'exige l'économie de la plupart des fraudes.

Le problème récurrent de la fraude est l'échelle. Un faux compte isolé ou une transaction frauduleuse isolée ne rapporte que rarement ; l'argent est dans la répétition à des milliers d'exemplaires. Le faire des milliers de fois nécessite des milliers d'identités d'appareil, car les plateformes lient de plus en plus l'abus par appareil (voir comment fonctionne l'empreinte numérique d'appareil). Le matériel physique est la façon honnête d'obtenir de nombreuses identités d'appareil, et il est prohibitivement coûteux et lent. La virtualisation est la façon bon marché.

Concrètement, la virtualisation sous-tend :

Les fermes d'appareils. Des racks d'appareils mobiles émulés ou d'instances de navigateurs headless, orchestrés pour créer des comptes, réclamer des promotions, publier de faux avis ou mener du credential stuffing (bourrage d'identifiants) et de l'abus de création de comptes en volume. Chaque instance émulée se présente comme un téléphone ou un ordinateur distinct.

L'émulation d'apps mobiles. Exécuter des apps Android ou iOS dans des émulateurs sur du matériel de bureau ou serveur pour automatiser des parcours applicatifs censés exiger un vrai téléphone — inscriptions mobiles, promotions réservées aux apps, fraude in-app.

Les navigateurs cloud et le browser-as-a-service. Des navigateurs complets s'exécutant dans des VM cloud, automatisés pour le scraping, la fraude publicitaire et l'abus de comptes. Ils sont plus sophistiqués que les bots grossiers parce qu'ils affichent entièrement les pages et exécutent le JavaScript.

Le fil conducteur : une seule machine physique, de nombreuses identités virtuelles. Si vous pouvez détecter la virtualisation, vous ramenez la flotte à sa taille réelle — et « mille utilisateurs » qui ne sont en réalité qu'un seul hôte émulé constituent une décision de risque très différente de mille appareils réels. C'est pourquoi la détection de la virtualisation est un multiplicateur de force : elle s'attaque à la structure de coûts qui rend la fraude en volume viable.

Ce qui trahit une machine virtuelle

Une machine virtuelle se trahit par les signaux physiques qu'elle doit synthétiser plutôt que posséder — le GPU, le comportement temporel, les capteurs et les artefacts bas niveau de l'hyperviseur sur lequel elle tourne. Le vrai matériel grand public produit ces signaux comme un effet secondaire de sa réalité ; une VM doit les feindre, et les feindre tous de façon cohérente est difficile.

Signatures de GPU virtualisé. C'est l'un des indices les plus forts. Le rendu graphique dépend du GPU réel, de son pilote et de son comportement en virgule flottante. Les VM utilisent généralement des graphismes virtualisés ou rendus par logiciel — SwiftShader, llvmpipe, GPU virtuels VMware/VirtualBox/QEMU, ou un GPU en passthrough qui rapporte quand même des chaînes révélatrices. Le moteur de rendu WebGL et les chaînes de fournisseur nomment fréquemment la virtualisation directement (« SwiftShader », « llvmpipe », « VMware SVGA », « Google SwiftShader »), et même lorsque ces chaînes sont falsifiées, la sortie de rendu du canvas et de WebGL elle-même diffère des GPU physiques de manières subtiles et difficiles à falsifier. Un vrai GPU restitue une scène complexe avec des artefacts caractéristiques propres au pilote ; le rendu logiciel produit une signature différente.

Une temporisation trop propre. Le vrai matériel est bruité. La compilation JIT, le ramasse-miettes, la limitation thermique, les interruptions du système d'exploitation et les effets de la hiérarchie mémoire introduisent une gigue continue dans les mesures de temps. Les environnements virtualisés — surtout ceux hébergés dans le cloud sur une infrastructure de haute qualité — tournent souvent trop régulièrement, avec une variance temporelle inférieure à celle des appareils grand public physiques. Une temporisation à haute résolution de motifs de calcul spécifiques peut révéler un environnement dont le profil de performance est anormalement uniforme. Paradoxalement, la « propreté » d'une VM de datacenter est elle-même le signal.

Artefacts d'hyperviseur. La virtualisation laisse des traces bas niveau : des indicateurs de fonctionnalités CPU et des particularités de temporisation d'instructions qui diffèrent sous un hyperviseur, un comportement spécifique du TSC (compteur d'horodatage), et — quand c'est observable — des valeurs de concurrence matérielle et de mémoire qui se regroupent autour de configurations typiques des VM plutôt que du grand public. Un appareil rapportant un nombre de cœurs et un profil mémoire très proches d'un serveur tout en prétendant être un ordinateur portable grand public est incohérent.

Empreintes audio et autres empreintes matérielles. L'empreinte AudioContext dépend du sous-système audio ; un matériel audio virtualisé ou absent produit une sortie en virgule flottante qui diffère d'un vrai matériel sonore. Faible en soi, utile en combinaison.

Contexte réseau. Les flottes d'émulateurs et de VM tournent fréquemment dans des datacenters, donc la couche réseau — ASN de datacenter, IP d'hébergeur — corrobore les signaux du point de terminaison. Une signature de VM et une IP de datacenter forment un motif bien plus fort que l'un ou l'autre seul. (Les opérateurs sophistiqués placent leurs VM derrière des proxys résidentiels pour masquer le côté réseau, ce qui est précisément pourquoi la détection de VM au niveau du point de terminaison compte indépendamment — elle survit au proxy.)

Comment les émulateurs mobiles se révèlent

Les émulateurs mobiles se révèlent par le même principe appliqué aux téléphones : ils doivent synthétiser les caractéristiques matérielles, de capteurs et de rendu spécifiques d'un appareil physique, et la synthèse est incomplète. Une app Android ou iOS s'exécutant dans un émulateur sur du matériel de bureau n'est pas un téléphone, et une douzaine de signaux le disent.

Chaînes d'identité matérielle. Les émulateurs portent des valeurs caractéristiques de modèle d'appareil, d'empreinte de build et de nom de matériel. Les émulateurs Android rapportent historiquement « generic », « goldfish », « ranchu », « sdkgphone » et des identifiants de build similaires, ainsi que des noms de modèle typiques des émulateurs. Même lorsqu'ils sont corrigés pour imiter un vrai appareil, la _combinaison de modèle, de carte, d'ABI CPU et d'empreinte de build ne correspond souvent à aucun appareil réel commercialisé — un prétendu téléphone haut de gamme avec une ABI x86 (les vrais téléphones sont en ARM) est révélateur.

Capteurs absents ou factices. Les vrais téléphones ont des accéléromètres, des gyroscopes, des magnétomètres, des capteurs de lumière ambiante et des baromètres, et — surtout — ces capteurs produisent des données continues, corrélées et bruitées à mesure que l'appareil est tenu et déplacé. Les émulateurs, soit n'ont pas ces capteurs, soit rapportent des valeurs statiques, soit rejouent des motifs synthétiques dépourvus de la variance naturelle et de la corrélation inter-capteurs d'un appareil tenu par une main humaine. Un « téléphone » dont l'accéléromètre affiche une constante parfaite, ou dont le gyroscope et l'accéléromètre ne bougent pas ensemble comme la physique l'exige, est émulé.

Différences de rendu et de GPU. Comme sur ordinateur de bureau, la signature de rendu du GPU mobile diffère entre le GPU mobile d'un téléphone physique (Adreno, Mali, Apple GPU) et un GPU émulé ou rendu par logiciel. La densité d'écran, la résolution et les artefacts de rendu censés correspondre à un modèle de téléphone précis revendiqué ne correspondent souvent pas.

Profil de temporisation et de performance. Une app de téléphone s'exécutant sur du matériel de classe serveur dans un émulateur se comporte différemment de la même app sur le SoC réel du téléphone — souvent plus vite et plus fluide que ne le ferait l'appareil réel, une autre instance de l'indice « trop propre ».

Le cas mobile est celui où les données des capteurs deviennent décisives, parce qu'elles sont réellement difficiles à bien falsifier. Reproduire la sortie continue et physiquement cohérente des capteurs de mouvement d'un vrai téléphone — accéléromètre et gyroscope s'accordant sur un même mouvement, avec la micro-gigue réaliste d'une main humaine — représente bien plus de travail que d'éditer une chaîne de nom de modèle, et la plupart des configurations d'émulation ne le font pas de façon convaincante.

Pourquoi aucun signal isolé ne suffit

Aucun signal isolé ne détecte de façon fiable la virtualisation, car n'importe quel signal peut être falsifié par un opérateur qui le connaît — c'est pourquoi une détection robuste dépend de la cohérence inter-signaux plutôt que d'une vérification individuelle. C'est le même principe qui régit la détection des navigateurs anti-détection : les indices individuels sont corrigeables ; la cohérence entre tous ne l'est pas.

Un opérateur déterminé va :

• Falsifier les chaînes de fournisseur/moteur de rendu WebGL pour nommer un vrai GPU.
• Corriger l'empreinte de build Android et le modèle pour correspondre à un vrai téléphone.
• Injecter des valeurs de capteur synthétiques pour falsifier les données de mouvement.
• Placer la VM derrière un proxy résidentiel pour nettoyer le signal réseau.

Chacune de ces mesures met en échec un détecteur qui s'appuie sur ce seul signal. Un système qui ne vérifie que la chaîne du moteur de rendu WebGL est vaincu par une modification de chaîne. Un système qui ne vérifie que les empreintes de build est vaincu par un correctif.

Ce qui est difficile, c'est de faire tout cela de façon cohérente à la fois. L'opérateur qui falsifie la chaîne WebGL pour revendiquer un GPU Adreno produit quand même une sortie de rendu de canvas qui ne correspond pas à un vrai Adreno. Celui qui falsifie le nom du modèle rapporte quand même une ABI x86, ou un nombre de cœurs qu'aucun tel téléphone ne possède, ou des données de capteur sans corrélation inter-capteurs réaliste, ou une temporisation trop propre pour le SoC qu'il revendique. Chaque falsification ajoutée est une surface de plus qui doit rester cohérente avec toutes les autres, et les contraintes se multiplient.

C'est le principe de cohérence environnementale : la détection ne consiste pas à demander « cette valeur unique semble-t-elle virtualisée », mais « toutes ces valeurs décrivent-elles un appareil unique, réel et physiquement possible ». Un prétendu iPhone dont le GPU rend comme du logiciel, dont les capteurs affichent une constante, dont l'ABI est x86 et dont la temporisation est lisse comme un datacenter n'est pas incohérent d'une seule manière — il l'est de quatre, et réconcilier ces quatre simultanément est la partie coûteuse. Le coût du maintien d'une cohérence complète sur chaque signal est ce qui fait tenir la détection fondée sur la cohérence là où les vérifications à signal unique échouent. La course à l'armement plus large et son état actuel sont couverts dans l'état du trafic de bots.

Comment agir sur la détection de la virtualisation

Ne bloquez pas la virtualisation par réflexe — pondérez-la comme un signal de risque en contexte, car la virtualisation légitime existe et un blocage général cause des faux positifs. La bonne réponse dépend de ce qui est vrai par ailleurs à propos du trafic.

Il existe de vraies raisons légitimes pour lesquelles un utilisateur peut se trouver dans une VM ou un émulateur : développeurs testant sur émulateurs, chercheurs en sécurité, utilisateurs soucieux de leur vie privée qui exécutent des navigateurs dans des VM, infrastructure de bureau virtuel d'entreprise, configurations d'accessibilité. Bloquer purement et simplement toute virtualisation pénalise ces utilisateurs. La virtualisation est un signal de risque, pas un verdict.

L'approche productive la traite comme une entrée parmi d'autres dans une décision graduée :

• Virtualisation seule, contexte par ailleurs normal : risque faible à modéré. Un simple développeur sur un émulateur n'est pas de la fraude. Notez-le, ne le bloquez pas.
• Virtualisation + réseau de datacenter + compte tout neuf + forte vélocité : risque élevé. C'est la signature d'une ferme d'appareils — un point de terminaison émulé, sur une infrastructure d'hébergement, créant des comptes rapidement. Les signaux se corroborent mutuellement pour former un verdict confiant.
• Virtualisation + violations de cohérence (chaînes falsifiées qui ne correspondent pas au rendu, combinaisons matérielles impossibles) : risque élevé. La virtualisation associée à des tentatives actives de la dissimuler est en soi le signal le plus fort — les utilisateurs légitimes de VM ne corrigent pas leurs empreintes de build pour usurper des téléphones haut de gamme.
• Corrélation de flotte : lorsque de nombreux appareils « distincts » partagent la signature révélatrice de virtualisation et se comportent de façon coordonnée, la détection de flotte les ramène à leur origine réelle, ce qui est décisif quelle que soit l'apparence d'un compte individuel.

Le schéma est cohérent avec la détection des navigateurs headless et la détection des bots en général : le signal individuel informe le score, la combinaison de signaux produit le verdict, et la réponse est graduée — autoriser, défier ou bloquer — plutôt qu'un blocage brutal de la virtualisation en tant que telle. La détection des émulateurs et des VM est la plus précieuse non pas comme un portail autonome, mais comme un signal fortement pondéré qui, combiné au contexte réseau et comportemental, révèle l'infrastructure derrière la fraude en volume.

Tracio détecte la virtualisation dans le cadre de son intelligence des appareils sur plus de 130 signaux — signatures de GPU et de rendu, vérifications de temporisation et de cohérence matérielle, analyse des capteurs mobiles et de l'identité de build — combinés au contexte réseau de l'IP intelligence et à des vérifications de cohérence inter-signaux qui attrapent les tentatives de falsification que les détecteurs à signal unique manquent. Elle passe par la couche de détection des bots et renvoie un verdict, avec les signaux sous-jacents joints, en moins de 50ms.

Vous voulez voir comment la détection de la virtualisation se comporte face au trafic de fermes d'appareils et d'émulateurs dans votre propre tunnel ?

Démarrez votre essai gratuit — 2 500 vérifications gratuites, sans carte bancaire. Réservez une démo pour passer en revue la détection des émulateurs et des VM face à votre modèle de menace spécifique.