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"?
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