Je recherche l'obfuscator JavaScript actuellement plus dur à inverser. Points bonus si cela peut être exécuté sur son propre serveur. Le coup de performance et le code de code sont bien.
3 Réponses :
Écrivez-le en Java, puis exécutez le bytecode en JavaScript avec une obfuscassée orto . Ça nécessitera deux couches de décompilation afin de lui donner un sens.
Woops, j'ai aimé la réponse, mais voici un rapport qui Orto est mort
Cela rendrait probablement encore plus difficile à inverser l'ingénieur. J'appellerais cela une fonctionnalité. La vérité est que même Java Bytecode peut être "décompilée" afin que vous n'ayez jamais une véritable protection de code source. Le mieux que vous puissiez espérer, c'est de le rendre vraiment difficile, plus de problèmes que cela ne vaut. J'ai répondu à A Question sur la façon de réaliser ce genre de chose.
Excellente discussion d'architecture, Tadman! Quand j'obtiens assez d'informations pour une réponse finale, je vois si je peux modifier un résumé de votre réponse.
Je serais curieux de savoir pourquoi vous voulez faire cela. L'obfuscation offre aucune protection réelle. Si vous avez quelque chose à protéger, déplacez-le sur le côté serveur, sinon, pourquoi déranger. Si vous le faites comme vous le devriez et que vous devez minier / combiner votre JS qui devrait être plus que suffisant pour effrayer tout le monde ne se soucie pas de savoir ce que votre code fait et que vos avantages sont des avantages de la performance. S'ils sont sérieux, l'obfuscation ne va pas vous aider.
L'obscurcissement n'est certainement pas une protection réelle. Toute personne qui veut sérieusement savoir ce que le code obscurcissé peut le comprendre. Mais cela ne le rend pas complètement moins de valeur aussi longtemps que celui qui l'utilise sache ce qu'ils obtiennent. L'obfuscation ajoute un niveau de complexité à l'inverse-ingénierie ou à la réutilisation du code. Ce niveau de complexité soulève la barre pour qui irait à la difficulté de comprendre comment ingénierie inverse du code ou voler / emprunter le code. Un voleur vraiment motivé peut toujours l'obtenir (avec plus de travail), mais d'autres ne le verront pas comme ça ne valent pas la peine et le sauteront.
Pour supprimer suffisamment d'informations du code source pour la pousser au-delà du point où il est plus facile de simplement le répéter de zéro.
the JavaScript Code Crypter et Obfuscator semblait agréable, jusqu'à ce que j'essaye de l'attaquer . M'a pris environ deux minutes. La solution triviale: qui a entraîné une bande de gibberish, mais aussi le code d'origine a soigneusement reproché dans une variable. Note à soi-même: jamais, jamais, jamais, jamais , toujours utiliser tout ce que vous ne comprenez pas complètement en matière de sécurité.
Jamais? Ok, j'avoue que j'utilise AES-256 et je n'ai aucune idée de la façon dont ça marche :)
@Camilomartin vous imbécile! Blague...
Exécutez le code à travers plusieurs obfuscators l'un après l'autre. Fun supplémentaire!
Mieux encore - accepter le fait que le code côté client est hors de votre contrôle.
Vous pouvez également avoir des fichiers JavaScript importer d'autres fichiers JavaScript, qui peuvent rendre l'ensemble du processus beaucoup plus difficile à œuvrer ensemble, si la copie est un problème pour vous.
@digitalbath: Ce n'est pas nécessairement bon conseil. Peut-être que CMC essaie de protéger les secrets commerciaux (par exemple, un algorithme) aussi longtemps que possible. L'obfuscation serait très utile pour cela.
@Griffin: Comment un fichier JS importe-t-il un autre fichier JS?
@Gabe, vous pouvez créer un élément de script à la volée:
document.createelement ("script");@Cam: Si quelqu'un est déterminé, ils battront un objet d'obfusteur dans une période relativement courte. S'ils ne glissaient que de curiosité, même en stripping Whitpace pourraient les effacer. Si vous avez des secrets et que vous voulez les protéger, vous ne les mettez pas dans JS ou quoi que ce soit d'autre que le client se met à la main. Si cela fait, c'est comme donner un escroc d'un pistolet chargé, l'ajout d'un obfuscator "pour la protection" est comme pour donner à l'escroc au pistolet, mais veuillez leur demander de ne pas l'utiliser.
@delnan: Je suis en désaccord. Sans aucune obscurcissement, cela pourrait ne prendre que quelques minutes pour déchiffrer. Mais même pour un expert, cela pourrait prendre quelques jours en fonction de l'obfuscation et de la complexité de ce que fait le code JS. Tout ce que je dis, c'est que, dans certains cas, ces quelques jours peuvent être essentiels si vous souhaitez gagner un avantage de temps court avant que les concurrents / adversaires ne puissent prendre votre JS. Je pense qu'une meilleure métaphore est que vous donnez un escroc au pistolet, mais ce n'est pas chargé et que le magasin des armes à feu est de 5 à 6 milles. Ils n'ont pas de voiture.
@Cam: Bien sûr, il faudra Quelques fois , mais y a-t-il une véritable situation où quelques jours comptent vraiment? Surtout si c'est tout aussi possible de mettre les parties vitales sur le serveur, où personne ne l'obtiendra jamais à moins qu'ils ne se cassent pas dans le système (ce qui est considérablement plus difficile que si vous avez une sécurité du tout, et peut avoir une inhibition beaucoup plus élevée)?
@delnan: Bien sûr - il y a des tonnes d'exemples. Supposons que vous exécutez une sorte de service limité de temps et vous souhaitez limiter la quantité de spam / abus. Par exemple, disons qu'il y a un jeu de sport à venir et vous publiez un service sur votre site Web sportif qui concerne le jeu. Une fois que ce sera fini, cela n'a pas d'importance, mais vous souhaitez que vos concurrents ne puissent voler que le même argument de Multijoueur tente de détecter la triche, mais ils le font toujours. Alors peut-être que vous souhaitez obfusquer du code anti-triche pour un jeu HTML5 ou flash.
Je ne comprends tout simplement pas ce que les gens ont contre l'obscurcissement. C'est une très petite quantité de protection supplémentaire, mais c'est là. Pourquoi ne pas profiter? C'est comme si nous enfermons nos portes la nuit - ce n'est pas très utile mais nous le faisons toujours.
@Cam: Je ne suis pas contre l'obfuscation en soi. Mais lorsqu'il est utilisé pour protéger le code côté client et qu'un serveur est impliqué de toute façon, il existe une méthode de protection infiniment plus efficace qui n'a que peu de coûts supplémentaires (mettre les pièces à protéger sur le serveur) disponibles - je ne comprends pas pourquoi il est ignoré. C'est mon point principal, et vos exemples ne semblent pas couvrir - ou sont-ils?
@delnan: D'accord, il s'avère donc que nous sommes d'accord. Ce que je pense, c'est que pour une sécurité maximale, vous devez déplacer tout le code possible sur le SERVERSIDE, puis, ce qui reste vous devriez obscorer. Par exemple, avec l'exemple de jeu Flash / HTML5, vous mettriez autant de détection de triche que possible sur le serveur, bu vous auriez besoin de JS afin que vous puissiez obfosser que
@PIMVDB Tout ce que j'ai dû faire est de mettre un point de rupture sur
eval (s) un regard sur la valeur des . pas si difficile.