Pouvons-nous démonter (en utilisant l'ildasme) un assemblage NGEN-ED?

Question

Si j'engage un assemblage, est-il normal que l'ildasme le démonte toujours?

D'accord. J'ai écrit une bibliothèque de classe Helloworld et la DLL qui a suivi s'appelle ngenildasmtest.dll. -> ciblé pour le .NET FW 4.

De l'invite de commande VS 2010, j'ai fait

gacutil -i NGenILDasmTest.dll

Je pouvais voir l'ensemble installé dans le GAC. Et j'ai couru l'ildasme pour que je puisse voir l'IL. Jusqu'ici tout va bien.

Puis je cours

ngen NGenILDasmTest.dll

(Je n'ai spécifié aucune option pour NGEN). Et cet assemblage a été compilé avec succès. Je l'ai localisé avec un nom ngenildasmtest.ni.dll sous le dossier

C:\Windows\Assembly\NativeImages_v4.0.30319_32\NGenILDasmTest\81d49dd4c7df22fb3df530402b58ffc9

Maintenant, quand je cours de l'ildasme comme ci-dessous

ildasm "C:\Windows\Assembly\NativeImages_v4.0.30319_32\NGenILDasmTest\81d49dd4c7df22fb3df530402b58ffc9\NGenILDasmTest.ni.dll"

Je pouvais voir le contenu de l'assemblage NGEN-ED. Est-ce normal?.

Techniquement parlant, NGEN génère des instructions CPU natives pour l'IL (et la place apparemment sous C: Windows Assembly NativeMages_V4. ##### _ 32 - Dans mon cas). Si tel est le cas, comment suis-je toujours en mesure de voir l'assemblage NGEN-ED comme il en utilisant l'ildasme?

S'il vous plaît, aidez-moi à comprendre ce «petit quelque chose» qui me manque ici.

Answer 1

Un assemblage ngen'ed est le code natif IL plus. L'IL n'est pas dépouillé. Il y a souvent de la confusion que les assemblages NGEN contiennent seulement l'image native. Les informations originales sont toujours nécessaires pour les métadonnées.

Microsoft ne semble pas avoir d'informations très spécifiques sur les internes d'un assemblage NGEN. La plupart des informations que nous connaissons proviennent de l'ingénierie inverse.

ÉDITER:

Après avoir installé le .NET Framework 1.1 (yay ..) - Il apparaît que .NET 1.1 ngen Est-ce que supprimer l'IL. Il semble que commencer dans V2 - l'IL est conservé. Cela semble être la raison pour laquelle il y a des informations contradictoires qui traînent. La raison exacte pour laquelle ce changement a été effectué ne semble pas être connu.

Il y a un bon article sur certains des internes de NGEN (et comment c'est une très mauvaise idée pour l'obscurcissement) ici: http://www.woodmann.com/forum/entry.php?68-rebuilding-native-.net-exes-into-managed-.net-exes-by-exploiting-lefotver-il...

Maintenant, la chose intéressante à propos de NGEN est qu'elle n'élimine pas l'IL ou les métadonnées, car bien que le code IL ne soit pas nécessaire pour l'exécution, les métadonnées sont, car toutes les chaînes et autres données pertinentes dont le programme a besoin est contenue dans le métadonnées. Ainsi, NGEN copie toutes les métadonnées à la section .il de l'Exe native, et copie le code IL comme une réflexion après coup

Answer 2

Si vous regardez un obscurcissement rapide / facile, écrivez un assemblage en mode mixte en C ++, qui sera un chargeur de démarrage de votre propre assemblage (il chargera l'héritage .NET FW 4.0 via COM dans le code natif et utilisera une interface publique déclarée à partir de la gestion Partie, coussin .tlb généré pour votre assemblée gérée) Tenue comme une ressource chiffrée (en utilisant RSA), et crypter le code C ++ natif, puis signer les deux assemblages. Cela empêchera d'ydasme votre assemblée vous permettant toujours de déboguer et de construire un projet (en utilisant des événements de construction)