3 votes

Édition de IL d'une assembly C# sans source ne reflétant pas les modifications lors de l'exécution

D'accord, j'ai une application à éditer pour laquelle le code source n'est pas disponible et en raison de la confidentialité, je ne peux pas partager l'application/le code - Je sais que cela rend ce genre de questions difficiles, mais comme je l'ai déjà fait par le passé, je pense que c'est quelque chose de simple que je ne vois pas.

J'ai déjà fait ça par le passé et la seule différence est que c'est une nouvelle version utilisant .NET Framework 4.5 et le dernier compilateur C#, etc.

Voici le scénario :

Je peux ouvrir l'application, la lire correctement et éditer le code IL. En fait, je peux l'éditer sans problème en utilisant Reflexil à la fois dans l'outil Reflection (dernière version), Telerik (ma référence habituelle) également avec Reflexil mis à jour, puis j'ai également essayé dnSpy dernière version nightly 3.0.1.

Je pensais perdre la tête, j'ai même essayé d'ouvrir l'application avec une ancienne version de GreyDragon, j'ai édité un peu de code IL, sauvegardé l'assembly exe, et même en modifiant directement le code IL au niveau du point d'entrée principal, il ne s'exécute toujours pas comme modifié mais reste identique à l'original non modifié, pourtant, dans TOUS ces outils, si je réouvre l'assembly exe édité et sauvegardé précédemment, les changements s'affichent correctement dans tous les cas, à la fois en C# décompilé et dans les instructions IL correspondantes.

La seule chose que je peux remarquer qui pourrait être différente est à nouveau la version de .NET ciblée et le fait qu'elle soit compilée avec une version plus récente du compilateur C#.

Alors, est-il possible que la dernière version de C# Rosylyn, etc. empêche les méthodes d'édition IL (et pratiquement tous les outils qui peuvent éditer le IL) qui fonctionnaient auparavant de fonctionner maintenant, presque comme si une table de sauvegarde des instructions secondaires, etc. contenait une copie de l'original non modifié qui s'exécute ?

Ou est-ce qu'un "paramètre" particulier de régénération de l'assembly est à l'origine de ce comportement ?

Commençons par le grand tableau de ce blocage fondamental que je pourrais manquer avant de chercher à décrire des détails plus fins.

Encore une fois désolé de ne pas avoir de code réel à partager, mais j'espère qu'un véritable expert saura ce qui se passe et aura des idées. Merci !

2voto

Collin Chaffin Points 369

Poster ma propre réponse ne peut pas croire que j'ai manqué cela.

La réponse est que même si ce n'est pas installé comme une assembly dans le GAC, le comportement de cette application a changé et j'ai raté le fait qu'une sorte de processus a exécuté NGEN.EXE contre elle pour compiler l'image native NI en une IMAGE NATIVE et l'installer - qui contient ensuite une version mise en cache du code machine foutu en question - exactement ce que mon instinct disait se passer, je devais juste trouver cette "copie de sauvegarde".

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X