¿Podemos desmontar (utilizando ILDasm) un conjunto NGen-ed?

Question

Si conecto NGen, ¿es normal que ildasm aún lo desarme?

Ok. Escribí una biblioteca de clase HelloWorld y el dll resultante se llama NGenILDasmTest.dll. -> selectiva para el FW .Net 4.

el símbolo del sistema Vs 2010, lo hice

gacutil -i NGenILDasmTest.dll 

pude ver el montaje instalado en la GAC. Y ejecuté ildasm para poder ver el IL. Hasta ahora todo bien.

Luego ejecutar

ngen NGenILDasmTest.dll 

(que no especifica ninguna opción para NGEN). Y esta asamblea se compiló con éxito. Localicé con un nombre NGenILDasmTest.ni.dll bajo la carpeta

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

Ahora, cuando corro ildasm, como a continuación

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

pude ver el contenido de la asamblea Ngen-ed. ¿Esto es normal?.

Técnicamente hablando, Ngen genera intrusiones de CPU nativas para el IL (y aparentemente lo ubica en C: \ windows \ Assembly \ NAtiveImages_V4. ##### _ 32 - en mi caso). Si ese es el caso, ¿cómo puedo ver el ensamblaje NGen-ed como IL usando ILDasm?

Por favor, ayúdame a entender ese "pequeño detalle" que me falta aquí.

Answer 1

Un ensamblaje NGEN'ed es el código nativo IL plus. El IL no se elimina. A menudo hay confusión de que los ensamblajes de NGen contengan solo la imagen original. La información original sigue siendo necesaria para los metadatos.

Microsoft no parece tener información muy específica sobre las partes internas de un conjunto NGen. La mayoría de la información que sabemos es de ingeniería inversa.

EDITAR:

Después de instalar el .NET Framework 1.1 (yay ..) - parece que .NET 1.1 NGen hace tira de la IL. Parece que comienza en v2: se mantiene IL. Esta parece ser la razón por la cual hay información contradictoria por ahí. La razón exacta por la cual se realizó este cambio no parece conocerse.

Hay un buen artículo sobre algunos de los componentes internos del NGEN (y cómo es una muy mala idea para la ofuscación) aquí: http://www.woodmann.com/forum/entry.php?68-Rebuilding-native-.NET-exes-into-managed-.NET-exes-by-Exploiting-lefotver-IL ...

Ahora, lo interesante de Ngen es que no lo hace elimine el IL o los metadatos, porque , mientras que el código IL no es necesario para la ejecución, los metadatos son, porque todas las cadenas y otros datos relevantes que el programa necesita están contenidos dentro de los metadatos. Entonces, Ngen copia todos los metadatos al.sección de IL del exe nativo, y copia el código IL en el último momento

Answer 2

Si nos fijamos en fácil de ofuscación/rápido, escribir un montaje de modo mixto en C++, el cual será un cargador de arranque de su propio montaje (se cargará .NET FW 4.0 heredado a través de COM en código nativo y usará una interfaz pública declarada desde la parte administrada, a través de .tlb generado para su ensamblado administrado) como recurso encriptado (usando RSA) y encriptará el código C++ nativo, luego firmará las dos asambleas. Eso evitará que ILDASM forme su ensamblado y le permita depurar y crear proyectos (usando eventos de compilación)