Il n'y a pas de fonctionnalité similaire pour le code d'octet Java.
Lorsque vous compilez un programme C, et le liez statiquement à une bibliothèque standard, le code de la bibliothèque sera présent, plus ou moins non modifié, dans le binaire (sauf pour les adresses qui changeront), mais il n'y aura aucun indice qu'une fonction particulière avait un nom particulier avant d'être compilée (sauf si le débogage est activé lors de la compilation / liaison). Mais, toute fonction donnée a un modèle d'octets plus ou moins fixe, et en reconnaissant ces octets, IDA peut attribuer le nom d'origine à la fonction.
Dans le bytecode Java, il n'est pas nécessaire de le faire. Les noms de fonctions, les noms de variables et des informations similaires sont de toute façon présents dans le bytecode compilé. La "bibliothèque standard", rt.jar , n'est pas non plus intégrée dans le bytecode, donc si une classe utilise une ArrayList , la classe aura une référence à java.util.ArrayList même après le processus d'obfuscation. Donc, rien à faire ici pour un analyseur de signature.
Si l'application choisit de masquer également la bibliothèque standard, elle doit inclure cette bibliothèque obscurcie dans ses propres fichiers jar. Cela soulèvera probablement des problèmes de licence, mais à part cela, comme l'obfuscateur renommera les méthodes et les champs, le code d'octet de cette bibliothèque obscurcie sera trop différent du code d'octet d'origine pour être reconnaissable par une fonctionnalité comme FLIRT d'IDA. De plus, vous ne pouvez pas simplement renommer la méthode dans IDA, car vous devrez également modifier toutes les références.
Cependant, il y a au moins un projet open source qui a un problème similaire au vôtre, et ils semblent l'avoir assez bien résolu. Minecraft est un jeu populaire qui comprend un serveur écrit en Java (et obscurci); le projet Spigot décompile ce serveur, change certaines choses, ajoute une API et distribue le résultat. Plus précisément, pour éviter les problèmes de licence, ils distribuent un système de construction qui télécharge, décompile, corrige et recompile le serveur Minecraft sur la machine de l'utilisateur.
Ils utilisent le décompilateur fernflower, qui a une option pour renommer les symboles lors de la décompilation, et inclure une carte complète de noms de symboles obscurcis à lisibles. Exemple:
AttributeInstance a () LIAttribute; getAttributeAttributeInstance a (D) V setValueAttributeInstance e () D getValueAttributeMapServer b () Ljava / util / Set; getAttributesAxisAlignedBB b (DDD) LAxisAlignedBB; grow
Le code source, qui est généré à l'aide de ces cartes, est évidemment bien plus lisible que l'original. Et, au moins pour le projet spigot, recompiler cette source (après avoir ajouté quelques correctifs pour créer une API) donne un serveur Minecraft fonctionnel.
Donc, peut-être, cela pourrait être un moyen pour vous de continuer - utilisez fernflower pour décompiler vos classes, les charger dans un éditeur pour trouver du code utile et attribuer des noms de classe lisibles, écrire un fichier de mappage et répéter ceci plusieurs fois. Ensuite, lorsque vous souhaitez effectuer une analyse dynamique, recompilez le code Java décompilé et chargez-le dans IDA.
Bien sûr, cette approche pose encore quelques problèmes:
- vous devra toujours identifier chaque fonction manuellement - mais comme je l'ai dit, vous ne trouverez probablement aucune fonction de bibliothèque standard dans votre code de toute façon. Et, il n'y a pas de bibliothèques de signatures existantes pour la méthode que vous utilisez, donc il n'y a probablement aucun moyen de contourner cela.
- le code décompilé / recompilé peut ne pas fonctionner, en raison de bogues / lacunes dans le décompilateur Java lui-même
- le code décompilé / recompilé peut ne pas fonctionner à cause de l'obfuscateur; par exemple, l'obfuscator peut remplacer toutes les constantes de chaîne par quelque chose comme
Obfuscator :: decode ("some_crypted_stuff") , où la fonction decode utilise le nom de la classe appelante comme son clé de déchiffrement, ce qui signifie que le déchiffrement échoue lorsque la classe est renommée - l'obfuscateur peut apporter son propre chargeur de classe, qui modifie le nom de la classe avant de la charger; par exemple, il peut savoir qu'il faut transformer une classe
com.obfuscate.SOME_BASE_64_STRING en chaîne base64 décodée, donc com.obfuscate.amF2YS51dGlsLkFycmF5TGlzdAo.something () appellerait java.util.ArrayList.something () . Cela rompt la connexion visible entre l'appelant et l'appelé (mais le mappage de nom pourrait très bien résoudre ce problème et vous pourriez en automatiser beaucoup)
Même si vous ne pouvez pas obtenir un fichier décompilé, recompilable, version de votre binaire, vous pouvez probablement écrire du code qui fonctionne sur la source décompilée pour identifier les fonctions par leur comportement, en utilisant des heuristiques, Ensuite, demandez à votre code d'écrire une table de mappage et d'écrire un plugin python pour importer cette table de mappage dans votre code sous forme de commentaires.
Il est douteux que ces approches battent l'ingénierie inverse manuelle dans IDA, mais comme IDA n'a pas cette fonctionnalité, et comme il n'y a pas de bibliothèques de signatures génériques (et elles ne fonctionneraient pas de toute façon, voir ci-dessus), c'est le meilleur que j'ai à offrir.
Modifier le 17/04/2016
Il s'avère que j'ai un petit projet où je pourrais utiliser moi-même une cartographie de désobfuscation, et j'ai vérifié dans le processus de désobfuscation de l'étape de décompilation de Minecraft un peu plus.
Il s'avère qu'ils n'utilisent même pas de fleurs de fougère r fonction d'émappage. Au lieu de cela, ils ont leur propre ensemble d'outils. Celles-ci sont lamentablement sous-documentées, mais il semble y avoir un dépôt GitHub.
Le premier, SpecialSource.jar, compare un fichier jar masqué avec une version non masquée et génère une table de mappage. Cela semble permettre de construire rapidement de nouvelles tables lorsqu'une nouvelle version de l'original masqué sort. Il n'y a cependant aucune documentation sur ce qui est exactement comparé.
Le second, SpecialSource-2.jar, remappe les références et noms de classes et de méthodes directement jar , sans étape de décompilation / compilation, ce qui évite tous les problèmes qui viennent avec. Donc, une fois que vous avez un fichier de mappage, vous pouvez l'appliquer au fichier jar pour obtenir un fichier jar de sortie, que vous pouvez ensuite alimenter dans IDA, ou un décompilateur de votre choix.L'utilisation est
java - jar /chemin/vers/SpecialSource-2.jar map -m mapping.csrg \ -i obfuscated.jar -o readable.jar
avec le fichier de mappage ressemblant à ceci
# Ceci renomme une classe, étant donné le nom obscurci et le onecom lisible / exemple / ab / a MyNiceClassName # Cela renomme une méthode, étant donné la classe, la méthode, la signature et le nom lisible.MyNiceClassName a (D) Je doubleToInt