VM Self Defending

L'option vmSelfDefending ajoute au runtime de la VM une détection des altérations à plusieurs niveaux, des contrôles d'intégrité du code, une protection contre le hooking et une protection contre la rétro-ingénierie. Combinée à vmDebugProtection, elle rend l'analyse manuelle comme l'analyse assistée par IA nettement plus difficiles.

Cette option force l'activation de vmBytecodeArrayEncoding et ajoute un surcoût à l'exécution de la VM. Mesurez-le sur vos propres chemins critiques.

La réaction à chaque détection - et la manière de remonter les détections vers votre backend au lieu de simplement tout casser - est traitée dans Télémétrie et réactions des défenses VM ; vmSelfDefending émet des détections dans les catégories de réaction automation, debugger, tamper et integrity.

Recommandé : utilisez-la avec vmDebugProtection, vmBytecodeArrayEncodingKey et vmBytecodeArrayEncodingKeyGetter pour une protection maximale.

Compatibilité d'exécution

Détection des environnements sensibles

Cette option lie le code obfusqué à son environnement d'exécution cible et utilise une prise d'empreinte avancée du navigateur pour détecter les outils d'automatisation. Le code protégé par cette option cessera volontairement de fonctionner lorsqu'il est exécuté dans :

• des navigateurs headless (Chrome/Chromium headless, PhantomJS)
• des outils d'automatisation de navigateur (Puppeteer, Playwright, Cypress, Selenium/ChromeDriver, Nightmare)
• Node.js (lorsque target vaut browser)
• jsdom ou d'autres émulations du DOM côté serveur
• des environnements où des fonctions natives du navigateur ont été interceptées ou remplacées (sauf si c'est déclaré avec browserEnvironment.hookedBuiltins)

Le code fonctionnera correctement dans les navigateurs classiques (Chrome, Firefox, Safari, Edge), y compris lorsqu'il est chargé dans des iframes, des extensions de navigateur (content scripts) et des Web Workers.

Choisissez la target correspondant à l'environnement d'exécution réel. Les builds Browser et Node contiennent des défenses différentes : la cible node omet celles qui reposent sur des API propres au navigateur, et un build browser exécuté sous Node cesse de fonctionner comme indiqué ci-dessus.

Lorsque browserEnvironment.hookedBuiltins vaut true (v7.15.0+), Self Defending tolère un environnement d'exécution qui remplace légitimement des fonctions natives par des wrappers JavaScript au lieu de le traiter comme une altération, de sorte que le code protégé s'y exécute quand même. Cela assouplit volontairement la détection des interceptions de fonctions natives ; la virtualisation par la VM, l'anti-débogage et les protections d'intégrité ne sont pas affectés. Le champ transport de la même option lie le build au schéma par lequel il est servi.

Self Defending vérifie l'intégrité de sa propre sortie : ne minifiez pas, ne reformatez pas et ne réécrivez d'aucune autre manière le code obfusqué après coup. Appliquez ces outils à votre source avant l'étape d'obfuscation.

Tests et CI

Ces défenses agissent aussi contre vos propres agents, outils d'automatisation et débogueurs. Elles peuvent arrêter l'exécution, lever des erreurs sans rapport ou produire des résultats incorrects. Cette option est conçue pour empêcher l'analyse automatisée et ne peut être utilisée sans risque avec aucun framework d'automatisation : exécutez donc les tests fonctionnels sur un build de test distinct avec vmSelfDefending désactivé. Tests et CI liste l'ensemble des surcharges de ce build.