Pour .net, il y a SOS.dll et WinDbg. Vous pouvez trouver des versions, pour chaque version des frameworks .NET installés, dans les sous-dossiers de %SYSTEMROOT%\Microsoft.NET\Framework\ . Vous pouvez le charger dans WinDbg en tapant .load et le chemin complet de la dll SOS.

Utilisez ! name2ee pour obtenir la table des méthodes de la classe, ! dumpmt pour vider la table des méthodes, ! dumpmd dans vider le descripteur de méthode pour la méthode que vous souhaitez examiner, CodeAddr est l'adresse du code JITed, et enfin ! U pour désassembler l'adresse de code.

Voici un lien vers un blog décrivant le processus.

En fait, je ne suis pas sûr de ce que vous gagneriez à attaquer le code compilé JIT car il est presque toujours le cas que la VM source est plus simple et fortement annoté. Il est presque toujours plus facile d'attaquer le langage intermédiaire. La seule raison à laquelle je peux penser est si vous souhaitez utiliser les optimisations du JIT pour éliminer l'obfuscation. Même dans ce cas, il est probablement plus facile d'appliquer les passes d'optimisation au langage intermédiaire. Je suppose qu'il y a aussi le cas où vous voulez masser le code JIT de sorte qu'il puisse être réutilisé dans une sorte d'exploit.

Est-ce que je comprends mal la question?

Oui, la réponse dépend de ce que vous essayez exactement de réaliser.

En termes d'analyse de l'application .NET elle-même, vous pouvez obtenir un code source complet en utilisant, par exemple, DotPeek écrit par JetBrains. Vous pouvez même l'exporter dans un projet Visual Studio entièrement fonctionnel, le créer et le déboguer. Cependant, certaines applications peuvent être obscurcies.

Un autre scénario se produit lorsqu'une application .NET fait partie d'une autre application écrite dans un autre langage (par exemple C ++). Dans ce cas, le code .NET le plus probable est compilé en DLL qui peut également être désassemblé à l'aide d'applications comme DotPeek.

Il peut exister des scénarios beaucoup plus complexes comme un compilateur JIT personnalisé, intégré dans un malware. Dans de tels cas, le moyen le plus raisonnable peut être d'écrire un plugin personnalisé (par exemple en utilisant IDAPython pour IDA Pro). Ce plugin doit être conscient des structures de données ou du comportement et peut vous aider à chaque étape d'un processus de rétro-ingénierie. Mais l'écriture d'un plugin personnalisé peut nécessiter une grande connaissance du langage sous-jacent et peut être un défi en soi.