JavaScript obfuscator
Renommé, chiffré, toujours fonctionnel
Ce JavaScript obfuscator réécrit un programme pour que les noms cessent de vouloir dire quelque chose et que la forme du code cesse de pointer vers la logique. Cochez les transformations, gardez le préfixe de nom qui vous plaît, et l'obfuscator vérifie que la sortie s'analyse encore. Rien de ce que vous collez ne quitte le navigateur.
- GratuitPrix
- 4Transformations
- JamaisExécute le code
- AucunEnvois
JavaScript obfuscator
Collez votre code ou déposez vos fichiers — rien n’est envoyé
Résultat obscurci
- Original
- —
- Obscurci
- —
- Changement de taille
- —
- Noms renommés
- —
- Chaînes cachées
- —
- Durée
- —
Prêt. Collez votre JavaScript, puis cliquez sur Obscurcir.
Ce que fait un JavaScript obfuscator
Le code source livre deux choses à la fois : ce qu'un programme fait, et comment il le fait. Donc un lecteur qui reçoit un module obtient le raisonnement gratuitement.
Un obfuscator sépare les deux. Ce JavaScript obfuscator garde le comportement et retire les noms, les chaînes littérales et les nombres simples.
Il travaille depuis l'arbre de syntaxe, pas depuis le texte. Comme l'arbre sait déjà quel nom est une variable et lequel est une propriété, le renommeur peut travailler par portée plutôt que globalement.
Quatre transformations vivent derrière un seul éditeur, et chacune est une case. Ainsi vous pouvez renommer un programme seul, ou toutes les lancer pour une lecture bien plus dure.
Rien ne s'exécute et rien ne s'envoie. Comme le lecteur ne fait qu'analyser et réécrire le module, un programme sous une clause de confidentialité ne diffère pas ici d'un programme public.
Comment un JavaScript obfuscator réécrit un script
La première passe construit l'arbre de syntaxe, comme un validateur. Le règlement est ECMA-262, donc l'arbre correspond à ce qu'un moteur construirait.
Depuis l'arbre, le renommeur parcourt chaque portée à son tour. Un paramètre, un local, un nom de fonction et un nom de classe reçoivent chacun un nouveau nom opaque, tiré d'une plage qui ne peut pas entrer en conflit avec un nom déjà en usage.
Deux choses sont laissées exprès. Une propriété d'un objet n'est pas une variable, donc obj.userName garde son orthographe. Un nom qui dépasse le module, comme un nom exporté ou un global que la page appelle, est gardé aussi, sauf si vous activez le renommage de haut niveau.
Chaque passe produit son propre arbre plutôt que d'éditer le texte. L'écrivain ne tourne qu'à la fin, donc un programme qui ne s'analyse pas n'est jamais réécrit à moitié.
La dernière étape réanalyse la sortie. Comme l'obfuscator relit son propre résultat avant de le montrer, une passe qui a produit du code invalide vous rend votre fichier original.
Les quatre transformations, dans l'ordre où elles tournent
Le renommage tourne d'abord. Paramètres, locaux, noms de fonction et de classe deviennent de courts noms opaques comme _0x1a2b, avec portée pour que deux fonctions utilisent le même nom sans risque. Les noms exportés et de haut niveau sont gardés sauf si vous les demandez aussi.
La passe des chaînes tourne ensuite. Chaque chaîne littérale passe dans un tableau en haut, et chaque usage devient une recherche par index via un petit accesseur qui tourne l'ordre. Comme les chaînes ne sont plus à côté du code qui les lit, une recherche d'un message cesse de trouver quoi que ce soit d'utile.
L'encodage des nombres suit. Chaque entier simple est imprimé en hexadécimal, ainsi 1000 devient 0x3e8. La valeur ne change pas ; les chiffres cessent juste de se lire comme un nombre familier.
Le compactage vient en dernier. Tout le module passe par le minifieur, qui retire les commentaires et l'espacement, ainsi le résultat est un bloc dense plutôt que des lignes soignées.
Ce que l'obscurcissement ne fait pas
Il ne cache pas votre code d'un lecteur déterminé. Chaque transformation ici est réversible en principe, et un outil existe pour la plupart.
Il ne garde pas un secret en sûreté. Une clé compilée dans un script du navigateur est une clé que le navigateur a, et quiconque charge la page peut la lire. Comme l'obscurcissement n'élève que l'effort, une clé d'API va sur un serveur.
De plus, il n'empêche pas la copie. Quelqu'un peut toujours enregistrer un fichier réécrit, le servir et l'exécuter. La licence et le contrat sont ce qui traite cela, et aucun n'est une étape de build.
Ainsi, il ne rend pas un module plus rapide, et il peut le ralentir. Comme les recherches de chaînes coûtent un peu de travail à l'exécution, l'échange est la lisibilité contre quelques millisecondes.
Il ne protège pas non plus un script sur le serveur. Quiconque a accès à la machine a le fichier original, quoi que le navigateur ait reçu.
Le préfixe de nom et garder la sortie valide
Le préfixe de nom est le seul réglage au-delà des cases, et il existe pour éviter un conflit. Un générateur qui émet un assistant nommé a ou b peut entrer en conflit avec un global de la page, donc un préfixe court et distinctif comme _0x retire le risque.
Le renommage de haut niveau reste désactivé par défaut. Le code collé est souvent un module classique, où une fonction de haut niveau devient une propriété de window qu'un autre fichier appelle par nom, et la renommer là casserait un appelant que l'obfuscator ne voit pas.
Dans un module ou une IIFE rien de l'extérieur n'atteint ces noms, donc activer le renommage de haut niveau là est sûr et cache bien plus.
Chaque lancement finit par une analyse de sa propre sortie. Comme l'obfuscator relit son propre résultat avant de le montrer, il signale une transformation qui a produit du code invalide plutôt que de rendre le code.
Sur cette page
- L’outil
- Ce que fait un JavaScript obfuscator
- Comment utiliser le JavaScript obfuscator
- Pourquoi utiliser ce JavaScript obfuscator
- Des habitudes qui gardent le code obscurci fonctionnel
- Six façons dont l'obscurcissement casse un build
- Questions sur le JavaScript obfuscator
- Des outils qui vont avec celui-ci
Continuer
Le JavaScript obfuscator en action
Une courte vidéo montre chaque étape. Ensuite, choisissez votre langue ci-dessous et activez les sous-titres si vous le souhaitez.
Comment utiliser le JavaScript obfuscator
Quatre étapes, et aucune ne nécessite de compte.
- 1
Collez le module
Collez un fichier entier ou un module. Comme le lecteur construit un arbre de syntaxe, vous devez d'abord compiler une extension comme JSX ou une annotation de type.
- 2
Cochez les transformations
Puis choisissez quelles passes tournent. Renommer les locaux et cacher les chaînes sont la paire sûre ; le renommage de haut niveau est celui à laisser éteint quand un autre fichier appelle vos noms.
- 3
Posez le préfixe de nom
Puis donnez aux noms générés un préfixe court et distinctif comme _0x. Ainsi un global de la page ne peut pas entrer en conflit avec un assistant généré.
- 4
Vérifiez la taille, puis testez
Enfin, lisez la ligne de taille et copiez la sortie. Ensuite, lancez-la sur une vraie page, car seul le programme faisant son travail prouve qu'un renommage est sûr.
Pourquoi utiliser ce JavaScript obfuscator
Cinq raisons, et chacune porte sur la lecture plutôt que sur le verrou.
Le renommage travaille par portée
En effet, comme le renommeur travaille depuis l'arbre de syntaxe, deux fonctions peuvent utiliser le même nom court sans conflit. Ainsi un gros fichier sort petit et correct plutôt que cassé.
Chaque passe est un choix
Quatre cases plutôt qu'un seul bouton. Donc vous pouvez renommer un module seul, ce qui est la transformation au moindre risque et au plus grand bénéfice.
L'obfuscator réanalyse sa propre sortie
Comme la dernière étape relit son propre résultat, il signale une transformation qui a produit du code invalide. Ainsi un build cassé est pris ici plutôt que dans la console du navigateur.
Rien ne s'envoie
Toute la réécriture tourne dans cet onglet. Ainsi un fichier client sous une clause de confidentialité ne diffère pas ici d'un fichier public.
La ligne de taille est honnête
L'obscurcissement rend un programme généralement plus gros, et la ligne dit de combien. Ainsi l'échange est visible avant que vous vous y engagiez.
Des habitudes qui gardent le code obscurci fonctionnel
Six habitudes qui gardent un fichier réécrit fonctionnel en production.
- Gardez le fichier lisible en gestion de versions Ainsi, ainsi le build tourne dans un seul sens. Comme personne ne devrait éditer un fichier obscurci à la main, un dépôt qui ne garde que la sortie a perdu sa source.
- N'obscurcissez jamais une bibliothèque que vous livrez De plus, un consommateur atteint vos exports par nom, donc un renommage casse chaque appelant. D'où un paquet publié garde ses vrais noms et ses types.
- Laissez le renommage de haut niveau désactivé par défaut Renommer un nom de haut niveau casse tout autre fichier qui l'appelle, et un module classique met ses fonctions sur window où les appelants les atteignent. Comme cela n'apparaît qu'à l'exécution, gardez-le optionnel et réservez-le aux modules.
- Gardez la source map hors de la production Une source map est une annulation parfaite, et en livrer une à côté du programme annule tout le travail. Donc stockez la map pour le rapport de plantage et servez-la de nulle part en public.
- Testez après l'obscurcissement, pas avant En effet, seul le module faisant la bonne chose prouve qu'un renommage est sûr. Donc le passage se fait sur la sortie plutôt que sur l'entrée.
- Dites ce que c'est dans les notes de build Un futur mainteneur qui tombe sur un fichier obscurci ne devrait pas deviner. Ainsi une ligne dans le readme sur les passes qui tournent épargne un après-midi.
Six façons dont l'obscurcissement casse un build
Chacune de celles-ci passe une analyse et échoue en production.
La traiter comme de la sécurité
Attention ici. Chaque transformation est réversible, et un lecteur déterminé récupérera la logique. Ainsi l'obscurcissement élève le coût de lecture, et il ne protège rien à lui seul.
Renommer un nom que quelqu'un d'autre lit
Un global que la page appelle, un callback qu'un hôte passe, ou un nom dans un modèle côté serveur. Comme le monde extérieur utilise encore l'ancienne orthographe, l'appel tombe sur rien.
Renommer des noms qu'un autre fichier appelle
Par conséquent, une fonction de haut niveau qu'un autre fichier appelle par nom cesse d'exister sous ce nom. Ainsi l'appel échoue à l'exécution, bien après que le renommage ait eu l'air bon.
Laisser une source map sur le serveur
Une requête à la map annule tout le build. Comme un débogueur lit la map, c'est une annulation complète et exacte.
Compter sur elle pour cacher un secret
Une clé ou un jeton dans le module est encore dans le programme ; le navigateur doit le lire pour l'utiliser. D'où l'obscurcissement n'élève que l'effort pour le trouver et rien de plus, donc le secret va sur un serveur.
Obscurcir au lieu de minifier
Les deux ne sont pas un choix entre mieux et pire, car ils visent des choses différentes. Lancez le minifieur pour les octets et l'obfuscator pour l'effort de lecture, dans cet ordre.
Questions sur le JavaScript obfuscator
Ce JavaScript obfuscator est-il gratuit ?
Oui. Il n'y a pas de compte, pas de limite et pas d'offre payante. Ainsi vous obscurcissez autant de scripts que vous voulez.
L'obscurcissement rend-il mon code sûr ?
Non, et aucun outil ne le peut. Il augmente l'effort de lecture d'un module et ne cache rien à un lecteur déterminé. Donc un secret va sur un serveur, jamais dans un programme du navigateur.
Que change-t-il vraiment ?
Quatre choses au plus : ce que deviennent les noms, où vivent les chaînes, comment les nombres sont imprimés, et si l'espacement est retiré. Le comportement reste exactement tel qu'il était.
Exécute-t-il mon code ?
Jamais. L'obfuscator analyse et réécrit le module, et n'appelle aucune fonction. Ainsi un extrait inconnu ne peut pas agir pendant que vous l'avez ouvert.
La sortie fonctionnera-t-elle encore ?
Elle s'analyse, et la dernière étape le prouve. Le comportement est une autre question, donc passez la sortie par vos propres tests avant qu'elle parte.
Dois-je renommer les noms de haut niveau ?
Seulement quand rien hors du script ne les appelle. Dans un module ou une IIFE c'est sûr ; un script classique dont les fonctions sont sur window ne l'est pas, car un autre fichier les appelle par leur nom.
Rend-il le script plus petit ?
En général non ; déplacer les chaînes dans un tableau et épeler les noms peut ajouter des octets. La ligne de taille signale le changement de toute façon, et le compactage en récupère une part.
Que fait l'encodage des nombres en hexadécimal ?
Il imprime chaque entier simple en hexadécimal, ainsi 1000 s'affiche en 0x3e8. La valeur est identique ; les chiffres cessent juste de se lire comme un nombre familier au premier coup d'œil.
Pourquoi y a-t-il un champ de préfixe de nom ?
Parce qu'un assistant généré nommé a peut entrer en conflit avec un global de la page. Ainsi un préfixe court et distinctif retire ce risque.
Puis-je annuler l'obscurcissement ?
Pas d'ici. Un lecteur peut ranger à la main un fichier renommé, et replier un tableau de chaînes, mais aucune tâche n'est automatique. C'est justement pour cela qu'il ralentit un lecteur.
Mon script est-il envoyé quelque part ?
Non. Toute la réécriture tourne dans cet onglet du navigateur. Ainsi un fichier client sous une clause de confidentialité reste sur votre machine.
Puis-je coller un fragment plutôt qu'un script entier ?
Oui. Une seule fonction marche, et le renommage reste à l'intérieur. Ainsi vous pouvez essayer un extrait avant de vous engager sur le script entier.
Gère-t-il JSX ou TypeScript ?
Pas directement, car tous deux ajoutent de la syntaxe au-dessus de JavaScript. Donc lancez d'abord le compilateur et obscurcissez ce qu'il produit.
Ai-je besoin d'une source map ?
Pour le rapport de plantage, oui, et elle doit rester privée. Comme une map servie est une annulation parfaite, gardez-la sur votre propre traqueur d'erreurs et nulle part en public.
Est-ce la même chose que minifier ?
Non. Un minifieur retire les espaces et raccourcit les noms locaux dans un script. Un obfuscator va plus loin et remodèle le code, et cela coûte plus d'octets.
Dans quel ordre dois-je les lancer ?
Minifier d'abord, puis obscurcir, puis valider. Comme le validateur nomme les lignes, vérifiez le fichier lisible avant qu'une transformation ne le touche.
Peut-il obscurcir un dossier entier ?
Pas sur cette page. Un script à la fois est la règle ici, et un outil de build est le bon endroit pour un dossier.
Fonctionne-t-il sur un téléphone ?
Oui. Les volets s'empilent et les réglages se répartissent en lignes. Ainsi un lancement rapide est possible loin d'un bureau, même si un long fichier est plus facile au clavier.
Puis-je télécharger le résultat ?
Oui. Le téléchargement enregistre la sortie en fichier JavaScript, donc vous la posez dans une étape de build sans copier-coller.
Faut-il un compte ou une extension ?
Non. Il n'y a ni inscription, ni greffon, ni extension à ajouter. Ainsi vous fermez l'onglet quand le build est fini.
Des outils qui vont avec celui-ci
Quatre pages auxquelles le même travail mène souvent.
Lancez celui-ci d'abord. Comme un minifieur retire des octets et laisse les noms tranquilles, c'est la moitié la moins chère de la même étape de build.
Ouvrir l’outil →Puis vérifiez que l'entrée et la sortie s'analysent. Comme une erreur de syntaxe arrête tout le script, ce contrôle va avant que rien ne parte.
Ouvrir l’outil →Quand un fichier compacté ou renommé d'ailleurs vous arrive, cette page le remet en forme. Comme une seule ligne dense est dure à suivre à l'œil, réindenter est le premier pas.
Ouvrir l’outil →La moitié feuille de style du même build. Comme un navigateur télécharge chaque commentaire et saut de ligne, la feuille mérite le même traitement.
Ouvrir l’outil →
Augmentez l'effort de lecture de votre script
Cochez les transformations et collez le script. Rien ne s'exécute ni ne s'envoie, et le JavaScript obfuscator vérifie chaque passe avant de rendre le résultat. Ainsi, traitez-le comme un ralentisseur, pas comme un verrou, car il fait bien son travail.