Démontage partiel de l'exécutable .net

Je dois écrire un programme relativement petit pour analyser les exécutables .net et générer la liste des appels aux méthodes externes. Par exemple, si System.Console.WriteLine est appelée à l'intérieur du fichier, l'outil doit imprimer que System.Console.WriteLine est appelée quelque part. Je ne peux pas (cerveau et temps limités) et pas besoin (tout ce dont j'ai besoin est une liste d'appels) mettre en œuvre un véritable démontage. Je veux un ~~grep amical~~ ~~perl amical~~ solution relativement courte qui écrit les noms des fonctions appelées et le décalage où l'appel s'est passé.Démontage partiel de l'exécutable .net

choses que j'ai déjà essayé:

Téléchargement spécifications de MSDN. Maintenant, je sais que l'appel statique est traduit à 0x28 en bytecode. :) Il est suivi d'un descripteur de méthode, mais la compréhension de ce que signifie le descripteur de méthode nécessitera probablement la lecture de la spécification entière.
Ouverture simple exe dans le réflecteur. Le réflecteur a reproduit avec précision le code de mon application d'origine mais je ne vois pas le bytecode pour les appels.

Est-il possible de mettre en œuvre la fonctionnalité limitée souhaitée avec un temps et des connaissances limités?

Si oui, que puis-je savoir pour le mettre en œuvre? Y a-t-il un guide "assemblage CIL pour les nuls"?

Source

2009-10-15 Muxecoid

Dans Reflector, vous pouvez faire un "Analyse" sur une méthode et découvrir où elle est utilisée (appelée) à partir d'autres assemblys chargés. Aller dans l'autre sens, je ne suis pas sûr de ... –

Merci, Agent_9191, je l'ai raté. – Muxecoid

L'analyse ne montre pas réellement le code d'octet où il est utilisé. Il affiche la liste des dépendances avec tous les appels utilisés mais la liste des dépendances ne dit rien sur l'emplacement de l'appel par rapport au début du fichier exe ni sur le fragment de bytecode responsable de l'appel réel. – Muxecoid

Si vous voulez quelque chose de convivial pour grep/perl, utilisez ildasm (en mode ligne de commande, c'est-à-dire avec/out ou/text) pour désassembler le code d'octet en IL textuel. Vous pouvez ensuite utiliser grep, perl ou la langue de votre choix pour localiser les instructions d'appel. (grep ne suffirait probablement pas à identifier les méthodes dans lesquelles se trouvaient les instructions d'appel, mais perl devrait pouvoir le faire.)

Source

2009-10-15 20:39:24 itowlson

Merci, ildasm généré CIL aide à localiser et identifier tous les appels intéressants. Y at-il un moyen de détecter facilement les blocs d'essai? – Muxecoid

Essayez les blocs commencent par .try {et se terminent par}. Les blocs catch commencent par catch [mscorlib] System.Exception (ou quelle que soit l'exception), puis un {, et se termine par}. (La meilleure façon de voir ceci est d'écrire un assemblage de test en C# et ildasm it.) Voir aussi le commentaire de Jason sur le formulaire handler/label.) Donc localiser ces blocs ne devrait pas être trop dur. Cependant, il peut être difficile d'utiliser un processeur orienté ligne comme perl pour identifier si une ligne donnée fait ou non partie d'un bloc try-catch: vous pouvez plutôt étudier les projets Cecil et CCI mentionnés par VirtualBlackFox et Jason. – itowlson

Le projet Ceci l est une librairie pour faire exactement ce que vous voulez.

Source

2009-10-15 20:32:40

L'infrastructure de compilation commune peut également vous aider: http://ccimetadata.codeplex.com/. Je voudrais appuyer la suggestion d'itowlson de simplement démonter l'assemblage dans un fichier .il et l'analyser en utilisant grep si c'est ce que vous recherchez. Comme ILDasm affichera des espaces de noms complets pour tous les types, vous devriez pouvoir le trouver assez rapidement s'il s'agit de votre type ou d'un type référencé.

Source

2009-10-16 00:10:17

J'ai oublié de mentionner la ligne de commande pour vous. Quelque chose comme ce qui suit vous donnerait un fichier texte que vous pourriez ensuite grep: ildasm /out:.il –

Je crois avec le ildasm livré avec vs2008, si vous n'utilisez pas le/raweh sur la commande line, votre try/catch/finally sera dans le code (développé) sous .try/catch/finally. Si vous utilisez/raweh, le bloc de gestion d'exécution en formation est à la fin de la méthode (comme s'il était stocké dans le code d'octet). Vous devrez les déchiffrer dans le code en utilisant les étiquettes. –

Démontage partiel de l'exécutable .net

Répondre

Questions connexes