Question

Y at-il un utilitaire similaire à OllyDbg / SoftICE pour java? C'est à dire. exécuter la classe (de pot / avec chemin de classe) et, sans le code source, afficher le démontage du code intermédiaire avec la possibilité de parcourir / enjamber / pour les références / modifier le code intermédiaire spécifique dans la mémoire / apply modifier fichier ...

Dans le cas contraire, est-il même possible d'écrire quelque chose comme ça (en supposant que nous sommes prêts à vivre sans point d'accès pour la durée de débogage)?

Edit: Je ne parle pas de JAD JD ou Cavaj. Ce sont décompilateurs bien, mais je ne veux pas un décompilateur pour plusieurs raisons, la plus notable est que leur sortie est incorrect (au mieux, parfois tout simplement faux). Je ne cherche pas un « magique octets compilé à code java » - Je veux voir les octets réels qui sont sur le point d'être exécuté. En outre, je voudrais la possibilité de changer ces octets (comme dans un débogueur de montage) et, espérons-le, écrivez la partie a changé dans le fichier de classe.

Edit2: Je sais existe javap - mais il ne fait qu'une seule façon (et sans aucune sorte d'analyse). Exemple (code tiré de la documentation vmspec): À partir du code Java, nous utilisons "javac" pour compiler ceci:

void setIt(int value) {
    i = value;
}
int getIt() {
    return i;
}

dans un fichier .class java. En utilisant javap -c je peux obtenir cette sortie:

    Method void setIt(int)
   0    aload_0
   1    iload_1
   2    putfield #4
   5    return
    Method int getIt()
   0    aload_0
   1    getfield #4
   4    ireturn

Ceci est OK pour la partie de démontage (pas vraiment bon sans analyse - « champ # 4 est Example.i »), mais je ne peux pas trouver les deux autres « outils »:

  1. Un débogueur qui passe au-dessus les instructions elles-mêmes (avec la pile, la mémoire des décharges, etc.), me permettant d'examiner le code réel et l'environnement.
  2. Une façon d'inverser le processus - modifier le code désassemblé et de recréer le fichier .class (avec le code modifié)
  3. .
Était-ce utile?

La solution

Je ne pense pas que ce soit vraiment une réponse complète, mais quelques conseils qui peuvent fournir quelque chose de réalisable:

(1) En termes de visualisation et de travailler directement avec l'ancien bytecode BCEL Classe Construction Kit peut être utile (il est le seul éditeur de GUI pour bytecode je suis au courant).

(2) En ce qui concerne le débogage et pas à pas par l'intermédiaire du bytecode, ce plugin Eclipse , qui intègre avec le débogueur Eclipse peut répondre à vos besoins.

Je ne suis pas au courant des services publics qui combinerait ces fonctionnalités et vous permettent de manipuler bytecode alors que le code est en cours d'exécution (au moins de la même manière que vous pouvez dans OllyDbg, etc.). Cependant, Java API de débogage devrait être capable de supporter la manipulation du code à l'exécution (bien que, compte tenu de la nature de HotSpot et JIT en général, je ne sais pas s'il serait possible de réécrire une instruction juste avant qu'il ne soit invoqué --- l'opcode bytecode en cours d'exécution est vraiment une abstraction de la façon dont l'interprète choisit de mettre en œuvre l'op, à la différence du code natif où le désassemblé opcode est, en fait, l'instruction envoyée à la CPU). Sinon, vous pouvez regarder dans le Java API Instrumentation qui fournit un moyen de redéfinir le code d'octets lors de l'exécution. Et, bien sûr, l'une des différentes bibliothèques de manipulation de bytecode open source peut être en mesure d'aider ou inspirer.

Et, bien sûr, il y a toujours la possibilité de contourner l'ensemble de l'infrastructure de machine virtuelle Java et fixer simplement un débogueur au processus JVM. Il y a une discussion de ce à cette question et cette page liée de cette question.

Cependant, la ligne de fond, est que ce que vous semblez essayer d'accomplir, tout lieu commun dans le monde du code natif, est pas tous une pratique courante dans le monde Java (partie de la raison de l'utilisation Java est l'abstraction de tous les détails sordides). Ceci, ainsi que la nature relativement triviale de code octet décompilation (contre, par exemple C ++) a conduit à une situation où ce type d'exigence est rare et est donc ce type d'outillage.

Autres conseils

Jetez un oeil à la décompilation du code Java pour JAD Decomplier . Vous pouvez ensuite exécuter le débogueur intégré d'un IDE en utilisant des sources produites. IDE peut être IntelliJ, Eclipse ou NetBeans. Cette approche est pas complètement automatique, mais il doit faire le travail.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top