Environnement de navigateur

Section

Pro

v7.9.0+

Déclarez la manière dont votre build de production est servi pour que le code protégé puisse y lier son intégrité.

L'option browserEnvironment déclare des faits sur l'environnement dans lequel votre build de production est servi, afin que le code protégé puisse s'y lier ou y réagir. C'est un petit objet, et chaque champ n'a d'effet qu'avec une protection précise — seule, l'option ne fait rien :

browserEnvironment: { transport: 'https', hosting: 'remote' }

`transport`

Le schéma par lequel votre production sert le bundle — 'http' ou 'https'. Prend effet avec vmSelfDefending.

Avec 'https', une copie qu'un rétro-ingénieur sert en HTTP simple ne fonctionnera pas correctement. 'http' ou un champ non défini n'ajoute pas cette protection.

Un build déclaré transport: 'https' ne fonctionne correctement que là où il est réellement servi via https:. Tout autre schéma le corrompt : ne le déclarez donc que si tous les contextes qui chargent votre build de production sont en HTTPS. Cela exclut :

le http:// simple, y compris http://localhost en développement ;
file:// — Electron, Cordova et autres applications empaquetées ;
les intégrations blob: et about: — un bundle exécuté dans une iframe about:blank ou srcdoc.

Une redirection HTTP→HTTPS côté client affiche tout de même d'abord la page HTTP : le bundle ne doit donc pas s'exécuter avant la fin de la redirection.

`hosting`

L'endroit d'où votre bundle de production est servi — 'remote' ou 'local'. Prend effet avec vmDebugProtection, et uniquement pour les cibles browser et browser-no-eval. Nécessite la version 7.14.0 ou ultérieure de l'obfuscateur.

Avec 'remote', une copie qu'un rétro-ingénieur extrait et exécute dans son propre environnement local est traitée comme une incohérence de l'environnement d'exécution, et les défenses anti-automatisation réagissent selon la configuration de vmDefenseReaction. 'local' ou un champ non défini n'ajoute pas cette protection.

Un build déclaré hosting: 'remote' ne fonctionne correctement que lorsqu'il est chargé depuis un hôte distant. Un bundle ouvert depuis un environnement local — localhost, un serveur de développement, file:// — est traité comme une incohérence, par conception : ne le déclarez donc que si tous les contextes qui chargent votre build de production sont servis à distance, et laissez-le hors des builds utilisés pour le développement local, les tests et la CI.

`hookedBuiltins`

Définissez-le sur true pour déclarer que le runtime dans lequel s'exécute votre build de production remplace légitimement les fonctions natives (builtins) par des wrappers JavaScript : l'anti-tamper de l'application elle-même, la page hôte ou d'autres extensions de navigateur partageant le même realm. Prend effet avec vmSelfDefending. Nécessite la version 7.15.0 ou ultérieure de l'obfuscateur.

Normalement, Self Defending considère une fonction native remplacée comme une altération et empêche le build de s'exécuter. Avec hookedBuiltins: true, il tolère un tel environnement et le code protégé continue de s'exécuter. false ou un champ non défini conserve le comportement strict.

browserEnvironment: { hookedBuiltins: true }

hookedBuiltins assouplit délibérément la détection des altérations : une fois défini, un analyste qui enveloppe ces mêmes fonctions natives pour inspecter votre code n'est plus arrêté non plus. La virtualisation de la VM, les protections anti-débogage et les contrôles d'intégrité ne sont pas affectés. Activez-le uniquement lorsque votre runtime de production est connu pour intercepter des fonctions natives et que cette garantie plus faible est acceptable.

Cibles prises en charge

browserEnvironment ne s'applique qu'aux cibles browser, browser-no-eval et service-worker. Pour node, userscript et bytenode, l'option est rejetée : l'obfuscation échoue avec une erreur de validation au lieu d'ignorer silencieusement le réglage. hosting est encore plus restreint : il est accepté pour un service worker, mais n'y lie rien.

Dans le tableau de bord, les contrôles Transport, Hosting et Hooked Builtins se trouvent dans le panneau Protection avancée. Chacun ne devient modifiable qu'une fois la protection associée activée — VM Self Defending pour Transport et Hooked Builtins, VM Debug Protection pour Hosting — et la cible compatible.

Prérequis

transport et hookedBuiltins prennent effet avec vmSelfDefending, hosting avec vmDebugProtection ; sans cela, aucun d'eux ne fait rien.
Une cible browser, browser-no-eval ou service-worker (browser ou browser-no-eval pour hosting).
Version de l'obfuscateur 7.9.0 ou ultérieure pour transport, 7.14.0 ou ultérieure pour hosting, 7.15.0 ou ultérieure pour hookedBuiltins.

Exemple

JavaScriptObfuscator.obfuscate(code, {
    vmObfuscation: true,
    vmSelfDefending: true,
    vmDebugProtection: true,
    target: 'browser',
    browserEnvironment: { transport: 'https', hosting: 'remote' }
});

Verrouillage par domaine de la VM

Utiliser le paquet NPM