Est-il possible d'inciter le compilateur .net JIT à exécuter une autre méthode?

Question

Ok, disons que mon application émet des instructions (x86) en mémoire, rend la page exécutable, etc. Existe-t-il un moyen de modifier le talon de méthode d'une méthode non-JITted pour qu'il pointe vers le flux d'instructions que je viens d'émettre?

Exemple:

Supposons que j'ai créé un flux d'instructions x86 en mémoire, ce qui fait quelque chose d'arbitraire. Supposons maintenant que j’ai une méthode 'int Target ()'. Je ne l'ai pas encore appelé, il n'a donc pas été compilé. Y a-t-il un moyen de:

1. Obtenir le pointeur sur le talon de la cible
2. Faites en sorte qu'il pointe vers mon flux d'instructions émises.

Je réalise que pratiquement chaque fonctionnalité de sécurité de .Net est conçue pour prévenir le détournement de ce type. Mais est-ce possible via, par exemple, l’API d’hébergement?

Answer 1

oui vous pouvez le faire!

Méthode Hook getJit de mscorjit. Et il vous sera demandé à tout moment, quelle que soit la méthode, de jitter. vous pouvez passer ce que vous voulez. Certains protecteurs .net fonctionnent comme ceci.

Answer 2

Ceci est possible via l’API de profilage. Je ne l'ai jamais utilisé, mais il est utilisé à des fins similaires dans TypeMock.

Edit: Je pense qu’il y avait une bonne publication sur les blogs de MSDN, elle ira à la chasse.

Éditer 2: Doh, premier coup !

Answer 3

Comme vous le dites, ce n’est pas facile et peut même ne pas être possible. Si je me souviens bien, le code inclura l'adresse du compilateur JIT pour une méthode qui n'a pas été compilée. Ainsi, lorsque vous essayez d'appeler cette méthode, le compilateur JIT fera son travail et insérera l'adresse dans la méthode nouvellement compilée. Si vous pouvez changer cette adresse, vous pourrez peut-être insérer un appel dans votre propre code. Comment vous feriez cela sans être détecté me dépasse. J'espère certainement que le CLR détectera ce type de falsification.

Je ne pense pas que l'API de profilage vous aidera dans ce cas (comme suggéré par Leppie), car vous n'essayez pas de modifier MSIL. Si vous pensez le contraire, cet article peut être utile car il décrit les éléments suivants: vous devez faire pour implémenter ce que TypeMock fait.

Answer 4

En plus de pouvoir utiliser ICorProfiler et de réécrire votre méthode avant son envol, vous pouvez utiliser ICorDebug (le MDBG a géré l'interface). Définissez un point d'arrêt, lorsque le point d'arrêt atteint, définissez l'instruction suivante sur votre code d'interception. Tout ce processus peut être effectué à partir de code, mais il est vraiment intrusif et vous aurez besoin d’un "observateur". processus pour coordonner cela.

Le projet PostSharp , qui présente des méthodes d'entrée et de sortie si vous appliquez des attributs, mérite également d'être examiné. .

Answer 5

Je n'essaierais pas de manipuler directement la mémoire et je ne suis pas sûr qu'il soit même possible d'utiliser l'API de profileur. Il existe quelques exemples mais pas de vraie documentation. Consultez l'article du magazine MSDN - Réécrivez le code MSIL à la volée avec le .NET API de profilage de framework