J'écris une application flash et j'ai peur qu'il soit décompilé. Afin de minimiser cette chance, je souhaite obfusquer le fichier.
J'ai entendu parler de Securewf ( http://www.kindisoft.com/ ), et ils font Énumérez certains "commentaires des utilisateurs". Celles-ci sont toutefois si optimistes qu'elles sont difficiles à faire confiance. Il n'y a pas un seul commentaire pessimiste (pas même par exemple l'interface utilisateur ou le support), alors quelque chose me dit qu'ils ne les posteraient peut-être pas tous. De mon expérience, même les meilleures entreprises ont une sorte de critique de temps en temps.
Alors, tout ingénieur inversé ici, pourrait me dire à quel point vous êtes expérimenté dans le travail - et si vous avez réussi à inverser l'ingénieur un fichier obstructionné SecuresWF? Si oui, combien de temps cela vous a-t-il pris environ? Recommanderiez-vous ce logiciel?
Merci beaucoup à l'avance.
4 Réponses :
Règle 1:
Quelqu'un avec intelligence et détermination obtiendra toujours votre code / clés / source / fichiers / données
Tout ce que vous faites augmente simplement le temps / effort potentiel requis pour compromettre
avec ou sans Securewf, les gens vont-ils au problème? Un rapide Google suggère que peu de tentatives ont été apportées à des fichiers SWF décompilés créés avec Securewf ... mais ils doivent toujours respecter la spécification du bytecode compilé ... donc cela équivaut à l'obfuscation. Le manque de test suggère:
- Personne ne l'a vraiment testé de manière indépendante, et donc aucune valeur dans sa sécurité ne peut être faite
- Les gens l'ont testé, il est très efficace et les gens n'ont pas posté les résultats
Je pense que le premier est plus probable. Si vous avez dit ce que l'application Flash fait, ces points peuvent être plus spécifiques.
Je rechercherais des sources de données relatives à la durée de la date à laquelle ces choses ont été inversées plutôt que la sécurité du système lui-même (qui n'est pas pertinente).
Assurez-vous également que la sécurité de votre source-ish (plutôt que de coopérer avec la communauté) est la meilleure stratégie qui compte que, à un moment donné, un esprit déterminé sera en mesure d'accéder à votre logique.
Du point de vue de l'entreprise, votre position stratégique ne doit pas conserver votre logique brouillée ... Comme c'est inutile. Vous pouvez être aussi exclusif que vous voulez ... mais les gens vont se déplacer (juste demander à l'industrie des jeux). Et la sécurité des mains lourdes provoque une réaction (voir DRM).
Si vous êtes convaincu, votre application est
si incroyable que les gens iront à l'effort de l'inverser, recherchez une autre proposition de valeur. Flash est l'une de ces choses, comme JavaScript, où il y a seulement que vous pouvez faire et cela compte vraiment? Quelle est la logique des applications sans les autres liens dans la chaîne?
Quoi qu'il en soit, recherchez les efforts
requis pour inverser le codage plutôt que la force perçue des clients du logiciel. Quoi qu'il en soit, bonne chance!
Merci. Je comprends que le code peut toujours être obtenu. Cependant, il est possible de faire l'effort d'effort plus élevé - à un point où l'effort ne vaut plus le "profit". L'application est un jeu multijoueur. J'ai remarqué qu'il n'y a pas beaucoup d'expérience avec Secureswf, pensez-vous (ou quelqu'un d'autre) que d'autres logiciels pourraient être meilleurs? Existe-t-il une expérience avec ce logiciel (d'un point de vue de l'ingénieur inversé)?
Telle est la question. Le logiciel peut élever la barre au point où 99,9% des personnes ne peuvent pas être arsed ... mais cela prend simplement 0,1% pour faire le bloc de 99,9% sans valeur.
Ce n'est que si que 0,1% va faire la source publique, cependant.
Vérifiez les compilateurs open source, comme Swfmill et Haxe http://haxe.org/ ils ont généré Différents octets-code dans leur dernier SWF, un collision de plusieurs décompileurs populaires. Est évident que le code peut être obtenu comme le SWF ordinaire compilé Adobe, mais de nombreux décompileurs ne travailleront tout simplement pas avec elle, donc si vous souhaitez augmenter le «montant d'effort nécessaire», je vous suggérerais de jeter un coup d'œil à cette solution. et peut-être créer quelque chose de mélanger tout cela.
Disclaimer: je travaille pour Kindisoft. em> Securewf est le meilleur obfuscator ActionScript là-bas. Je crois qu'il n'y a pas de doute absolument à ce sujet:
https://www.mochiadads.com/ Communauté / Forum / Sujet / Quel-OBFuscator-devrait-I-Use-Use-AS3 P> http://asgamer.com/2009/why-how-a-crypt-Your-Flash-Swf p> Obfuscators de code devrait rendre impossible pour les ingénieurs inverseurs d'utiliser un outil automatisé capable de récupérer un code source lisible (c'est-à-dire un décompiler). Et à ce jour, SecuresWF a beaucoup de succès. Étant donné que l'automatisation du processus n'est plus possible, le temps et l'effort de l'ingénieur inverseur, l'application obscurcie dépend de sa taille. Plus l'application est grande, plus l'ingénierie inverse complexe et gagnant du temps devient. Réécrire le code à partir de zéro est généralement plus simple. P> Obfuscation n'est pas cryptage. Cela devrait être un processus à sens unique. Lorsque vous renommez des identificateurs, les noms d'origine n'existent plus. Le seul moyen de les récupérer est de deviner. La même chose s'applique à l'obscurcissement du flux de contrôle. Mangling l'instruction et modifier la manière dont le code s'exécute à Bytecode ne suit pas les mêmes règles de ActionScript. Considérez les éléments suivants: P>
// swapping the values of a and b
var t = a;
a = b;
b = t;
// will be compiled to something similar to:
get a
set t;
get b;
set a;
get t;
set b;
// and will be obfuscated to something similar to:
get a
get b
set a
set b
// then it can become:
goto l1:
l2:
set a
set b
goto l3
l1:
get b
get a
swap
goto l2
l3:...
// after that it becomes:
goto l1:
l2:
set a
set b
goto l3
get b
dup
add
l1:
get b
get a
swap
goto l2
l3:...
// and finally (? denotes an unprinted char)
goto l1:
l2:
set ?
set ?
goto l3
get ?
dup
add
l1:
get ?
get ?
swap
goto l2
l3:...
+1, post informatif, avec fond de produit, quel que soit le biais d'emploi :)
// et sera obscurcié à quelque chose de similaire à: : Voulez-vous dire "optimisé"?
Ce n'est pas si bon. J'ai essayé de décompiler SWF protégé par SecuresWF. Le verrouillage du domaine défini par SecureWF est ridiculement facile à supprimer.
Je n'ai pas de vastes expériences avec des obspustes, mais il y a quelques mois, on m'a demandé d'essayer quelques-uns d'entre eux pour un projet spécifique (c'était en réalité un jeu multijoueur Simple-- Multiplayer). J'ai essayé Secureswf et Amayeta Swfencript (les deux versions d'essai, qui étaient entièrement fonctionnelles, si je me rappelle à droite).
Les deux ont eu des problèmes avec les fonctionnalités plus "avancées". Si je choisirais juste pour renommer des identifiants, les choses fonctionnent bien. Mais même avec les paramètres par défaut (un minimum d'obfuscation de flux de contrôle), l'un des Obfuscators a produit un bypode illégal, c'est-à-dire qu'il serait rejeté par le vérificateur du joueur. Cela produit une exception et c'est à ce sujet. Je ne me souviens vraiment pas de lequel, mais cela a échoué dès que vous exécutez le SWF.
Je n'ai pas beaucoup testé beaucoup plus loin, mais cela m'a fait voir ceci est quelque chose que vous devez prendre en compte également. Il y a un coût supplémentaire dans l'utilisation de ces outils . Cela pourrait être acceptable ou non à vos besoins, mais vous devriez en tenir compte. Une fois que vous avez changé et vous tordez SWF, ce n'est pas le même SWF que vous avez débogué et testé plus . Ainsi, vous aurez maintenant deux fois plus de test de travail, car il y a une chance que l'Obfuscator ait introduit des bugs. Celui que j'ai vu était assez évident et soufflé le joueur tout de suite, mais il pourrait y avoir subtiller, les plus difficiles. Et si vous avez un bogue qui ne montre que dans votre "version sécurisée" (ou pire, on dirait que cela ne se produit que dans votre version sécurisée, mais que vous n'êtes pas positif), le débogage qu'il ne sera pas amusant.
Bien sûr, ce n'est pas un examen approprié, juste mon expérience limitée. La plupart des obfusques ont des essais gratuits afin que vous puissiez les essayer vous-même. Et je devrais également dire que le code décompilé et démonté était bien, vraiment obscurcissé et que vous stimiez que ce serait une tâche ardue.
Pourtant, je pensais ajouter une perspective différente, ce qui n'est pas souvent mentionné.
Vous aurez seulement besoin de parcourir votre application pour le tester après l'obfuscation. Toute erreur introduite par l'obfousiste sera prise à l'avance par le vérificateur. Si cela se produit, vous revenez à l'obfousciateur et configurez-le (c'est-à-dire dire de ne pas renommer des identificateurs référencés dynamiquement). C'est un processus droit et chaque erreur a une solution de contournement. Et cela ne vous oblige certainement pas à déboguer et à tester votre application à nouveau.
Oui, vous pouvez trouver des solutions de contournement pour presque toutes les erreurs. Mon point était que vous devez le faire et il faut du temps supplémentaire; quelque chose pas toujours mentionné. Je ne te connais pas, mais j'appelle ce genre de chose testant. Et si vous trouvez un problème, j'appelle le processus de résolution de son débogage. Donc, je dirais que vous devez tester et éventuellement déboguer le SWF obscurcier.
@AMMAR: Pas nécessairement. Le vérificateur est probablement moins strict que la spécification SWF, donc même si Bytecode non valide fonctionne aujourd'hui, il n'y a aucune garantie que cela fonctionnera avec la prochaine version de Flash Player.