Obfuscator.io

Obfuscator.io

Documentation
/

Compatibilité d'exécution

Compatibilité d'exécution

Choisissez target selon l'environnement d'exécution réel. Les builds Browser et Node peuvent contenir des défenses différentes ; une cible Browser ne remplace pas Node.

target

  • browser - Chrome, Firefox, Safari, Edge.
  • browser-no-eval - identique à browser, mais la sortie n'utilise pas eval(). À utiliser lorsque la page cible a une Content Security Policy qui interdit eval/unsafe-eval.
  • node - environnement Node.js. Les options propres au navigateur sont désactivées (elles nécessitent window/document et seraient sans effet ou lèveraient une exception dans Node). Certaines défenses de vmSelfDefending qui reposent sur des API propres au navigateur - détection des navigateurs headless, récupération d'un realm sain via une iframe, vérifications anti-inspecteur et DOM - ne sont pas émises pour cette cible.
  • service-worker - contexte de Service Worker. Pas de window, pas de document, et une globale self différente.
  • userscript - bac à sable d'un gestionnaire de scripts utilisateur (par exemple Tampermonkey). Les défenses de vmSelfDefending sont adaptées en conséquence. Nécessite VM Obfuscation (ou Parse HTML) et l'obfuscateur v6.9.0+.
  • bytenode - pour du code qui sera compilé en .jsc avec bytenode. Nécessite VM Obfuscation (ou Parse HTML) et l'obfuscateur v6.13.0+.

Environnement navigateur et domaines

Les déclarations sur l'endroit où le code s'exécute doivent correspondre au déploiement réel. browserEnvironment doit décrire la manière dont le build est réellement servi (voir Browser Environment), et VM Domain Lock doit lister chaque domaine qui le sert (voir VM Domain Lock). Les outils d'automatisation et les débogueurs peuvent déclencher les défenses avancées ; voir Tests et CI.

JavaScript

Les noms de fonctions et le texte source des fonctions peuvent changer avec l'obfuscation. N'utilisez pas .name ni .toString() comme données applicatives stables ; utilisez plutôt des identifiants explicites. Les globales publiques peuvent rester visibles lorsque vos réglages l'exigent.

strictMode

Avec strictMode: null et strictMode: false, les directives explicites, les modules ES et les méthodes de classe sont toujours reconnus comme stricts. strictMode: true traite toute l'entrée comme stricte. Faites correspondre le contexte d'exécution final ; un bundler qui ajoute le mode strict après l'obfuscation peut modifier le comportement.

Chaîne de build

Compilez le TypeScript ou le JSX et générez le bundle de votre application avant l'étape finale d'obfuscation. Conservez les commentaires /* javascript-obfuscator:vm */ tout au long de ce build pour que le mode comment puisse encore les trouver. Ne minifiez pas, ne reformatez pas et ne réécrivez d'aucune autre façon la sortie protégée par Self Defending ou VM Self Defending par la suite. Les source maps ne sont pas disponibles pour l'obfuscation VM et HTML.