Je recherche un Obfuscator Java Bytecode qui "brouille" l'opcode existante et ajoute un nouveau code (inutile). Je ne suis pas intéressé par des renommages de quelque nature que ce soit, ce qui est quelque chose que la plupart des obvisateurs semblent faire. P>
Un peu de fond: Dans le cadre de ma thèse de doctorat, je développe un outil qui identifie des parties inutiles d'un programme (Java Bytecode). Afin de présenter de bons résultats, j'aimerais avoir des programmes d'entrée avec une quantité importante de code inutile. Outre les exemples que je me concentre actuellement sur (qui ont des bogues subtils qui font du code inutile, pensent que l'appel "est égal à" avec un mauvais argument), je pourrais également avoir besoin d'exemples avec un code "bizarre" - produit par un obfuscator de code. P>
J'ai déjà joué avec proguard code>, mais il semble qu'il optimise (et donc modifie donc) le code légèrement. La partie qui renomme les méthodes, les champs, ... n'est pas pertinente pour moi du tout, c'est pourquoi je l'ai éteint. P>
5 Réponses :
Votre tâche est très intéressante, mais il semble que ce ne soit pas Java octet code Obfuscators sont conçus pour. p>
Si vous souhaitez ajouter du code inutile à un projet, pourquoi pas seulement l'ajouter à un autre projet (ou une partie de celui-ci). Évidemment, le code ajouté sera "utile": personne ne l'appelle vraiment à partir du projet d'origine. Vous pouvez ajouter des parties de la source ou même du code octet du projet absolument différent. De toute évidence, ce code sera écrit dans différentes classes. p>
Si vous souhaitez ajouter le code à vos classes existantes, vous pouvez probablement développer votre propre outil en utilisant, par exemple, cglib qui prend même le code d'octet existant et l'appendez au code d'octet de vos cours. Disons que l'apprécie des méthodes statiques qui ne constitueront pas la cohérence de votre classe existante. p>
Je suis confus, car l'obscurcissement du code en faisant du mal à suivre est une approche assez simple (en plus des renommages). L'ajout de code dans de nouvelles méthodes (ou même des classes) n'est pas utile, détectant que ce code ajouté n'est pas appelé est assez trivial. Et malheureusement, je n'ai pas le temps de développer un outil seul faire le travail dont j'ai besoin.
Autant que j'ai entendu, il y a des choses que vous pouvez exprimer en bytecode que vous ne pouvez pas en Java. Un obfusciateur ajoutant que ce code d'octet empêcherait la décompilation car il n'y a pas de Java valide qui peut exprimer ce qui a été ajouté.
Ce que vous voulez, ce n'est pas réellement obscurci. p>
Ce que vous voulez est un outil comme ASM qui peut ajouter tout le code d'octet souhaité, y compris l'ajout / changement de méthodes . p>
Y a-t-il une définition de l'obfuscation? Et pour autant que je sache l'ASM, je devrais modifier les programmes par moi-même.
L'article Wikipedia définit le code Obfuscation assez bien: en.wikipedia.org/wiki/code_obfuscation et oui ASM exige que vous modifiez vous-même les programmes vous-même. Mais je pensais que vous demandiez qu'un outil crée un code inutile. Le code ASM que vous auriez besoin d'écrire peut être assez générique afin de travailler sur de nombreuses classes d'entrée différentes. Donc, vous n'avez peut-être pas seulement besoin d'écrire 1 programme qui peut transformer de nombreuses classes.
Si vous n'obfusez pas, restez à l'écart des obfuscators qui modifient le code en modifiant le flux de code et / ou en ajoutant des blocs d'exception et afin de rendre difficile la désassemblable. Pour rendre le code illisible, il suffit généralement de changer tous les noms des méthodes, des champs et des classes. P>
C'est contre mon but. Je me fiche des noms. Je me soucie du code inutile seulement.
Pour clarifier: Je ne suis pas dans le cas que vous décrivez comme "habituel".
Cela me semble comme ce que vous recherchez (et je me souligne "pour moi" car il semble que chaque répondeur ait une prise différente) est quelque chose qui vous donne la capacité de générer du code au sein du code existant et utile qui fait Le code résultant a un code inutile ou sous-optimal mélangé à celui-ci. P>
Au début, je pensais que le but de cet outil était d'empêcher l'ingénierie inverse, car le mot clé ici est "Obfuscation" - c'est-à-dire de rendre le code incertain ou inintelligible. Mais vous dites que vous voulez un code "inutile". Le code ne doit pas être incertain pour être inutile. Il n'a rien à faire. P>
Alors, la question est de savoir comment créer un code inutile? p>
Je ne sais pas, mais voici une idée: vous pouvez commencer par le code qui a des éléments inutiles, puis l'optimise. En fait, votre outil vous semble beaucoup comme un optimiseur de code. Vous pouvez prendre un code mal écrit (demander à vos collègues pour les soumissions de code étudiant?) Et comparez-la à ce qui sort d'un optimiseur de code. Cela vous ferait plus que des méthodes et des classes non utilisées. Bien que maintenant j'ai une question (avec tout le respect due): comment votre projet est-il différent d'un optimiseur de code? P>
Je dois dire que je suis d'accord avec la réponse donnée par @dkatzel: cela ressemble à ce que vous avez vraiment besoin n'est pas d'obscurcissement. À ma compréhension, l'obfuscation consiste à faire du code Ainsi, en tenant compte d'un code source correctement fait (je veux dire, sans pièces redondantes ni code inutile, comme vous l'avez mis), l'obscurciez-le (dans le bon sens) ferait simplement le code inintelligible sans changer de chemin d'exécution sans modifier son chemin d'exécution. Cela implique que le code obscurcissant n'a généralement aucun impact (ou très peu) dans la performance du code, et c'est différent de ce que vous souhaitez produire pour vos tests. Par exemple, le type d'obfuscation proposé dans cet article très cool ( http: // www.kahusecurity.com/2011/brilliant-javascript-obfuscation-technique/ ) ne vous aiderait pas du tout, non? (Je veux dire, ignorant qu'il s'agit de JavaScript, pas de Java) P>
Ainsi, je pense que les réponses sont déjà fournies (spécialement celles de la cassette de Seucing à Github et en utilisant ASM) est la voie à suivre. Il existe un célèbre championnat de code obscurposé pour Code C ( http://fr.wikipedia.org/wiki/international_obfuscadu_c_code_contest < / a>) où les gens essaient d'être créatifs et que leurs sources ont peut-être un code inutile (même si ce n'est pas l'intention principale) que vous pouvez utiliser dans vos tests (si vous trouvez des championnats similaires pour le code Java - je n'ai pas honnêtement pas Vérifiez cela). P>
Dans vos chaussures, je envisagerais également de créer un outil de manipulation de code source très simple qui insérerait directement des extraits inutiles dans le fichier .java, à des emplacements valides aléatoires. Vous pouvez définir ces extraits vous-même avec des choses comme: p>
Depuis que nous parlons d'une recherche scientifique (votre projet de doctorat), je suis d'accord avec vous qu'il est important que les résultats du prototype initial soient facilement reproduits. Par conséquent, en ayant un tel outil pour ajouter des extraits connus pour être inutile pour votre code de test simple, vous pouvez avoir une pré-validation. Cependant, probablement à l'avenir, vous voudrez également traiter un code source bien connu (à partir de projets open source importants, par exemple), passez-la via votre outil de code-inutile-inutile, présentez le code supprimé et enfin logique logiquement à propos de la inutile des bits supprimés et validez la sortie de la version modifiée du code par rapport au précédent (sans les trucs supprimés). P>
Bonne chance avec vos recherches, mate. :) p>
acclamations p>
Pour clarifier: J'ai besoin d'un outil qui ajoute du code (méthodes d'appels, certains calculs, peuvent peut-être déplacer des données dans le tas) sans rien faire d'utile. Un obfuscateur très très simple pour moi ajouterais simplement un "nop" partout. Un obvisateur légèrement meilleur inventerait de nouvelles variables locales entier, remplissez-les avec des valeurs et ajoutez un peu / soustraire un peu. Je cherche maintenant un outil qui fait vraiment étrange des choses difficiles à comprendre, mais toujours inutiles pour le calcul d'origine.
Il suffit de prendre un projet d'entreprise Java de 10 ans. Numérisez autour de GitHub, il n'y a pas de meilleur obfousciateur que le temps et la pourriture du bit.
La tristesse: la base de code doit être assez petite. Ceci est un prototype de mise en œuvre, une preuve de type concept - style académia.