Possiamo smontare (usando l'iodasmo) un assemblaggio NGENED?

Question

Se non ho un gruppo, è normale che l'iodasmo lo smonta ancora?

Ok. Ho scritto una biblioteca di classe Helloworld e la DLL che ne consegue si chiama ngenildasmtest.dll. -> mirato per .NET FW 4.

Dal prompt dei comandi VS 2010, l'ho fatto

gacutil -i NGenILDasmTest.dll

Ho potuto vedere il gruppo installato nel GAC. E ho eseguito l'ilildasmo in modo da poter vedere l'IL. Fin qui tutto bene.

Poi corro

ngen NGenILDasmTest.dll

(Non ho specificato alcuna opzione per NGEN). E questa assemblea è stata compilata con successo. L'ho localizzato con un nome ngenildasmtest.ni.dll nella cartella

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

Ora, quando gestisco l'Ildasm come sotto

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

Ho potuto vedere il contenuto dell'assemblaggio Ngen-ed. È normale?.

Tecnicamente parlando, NGEN genera insiemi di CPU nativi per IL (e apparentemente lo colloca in C: Windows Assembly NativeMages_v4. ##### _ 32 - Nel mio caso). In tal caso, come riesco ancora a vedere l'assemblaggio Ngen-Ed come IL usando l'ililda?

Per favore aiutami a capire quel "piccolo qualcosa" che mi manca qui.

Answer 1

Un assembly Ngen'ed è il codice nativo IL Plus. L'IL non è rimosso. C'è spesso confusione che gli assiemi NGEN contengono solo l'immagine nativa. Le informazioni originali sono ancora necessarie per i metadati.

Microsoft non sembra avere informazioni molto specifiche sugli interni di un gruppo NGEN. La maggior parte delle informazioni che sappiamo provengono dalla reverse ingegneria.

MODIFICARE:

Dopo aver installato .NET Framework 1.1 (Yay ..) - Sembra che .NET 1.1 NGEN fa spogliare l'IL. Sembra che inizi in V2: l'IL è mantenuto. Questo sembra essere il motivo per cui ci sono informazioni contraddittorie in giro. L'esatta ragione per cui questo cambiamento è stato apportato non sembra essere noto.

C'è un buon articolo su alcuni interni di NGEN (e su come è un'idea estremamente cattiva per l'offuscamento): http://www.woodmann.com/forum/entry.php?68-rebuilding-native-.net-exes-in-managed-.net-exes-by-exploiting-lefotver-il...

Ora, la cosa interessante di NGEN è che non elimina l'IL o i metadati, perché mentre il codice IL non è necessario per l'esecuzione, i metadati sono, perché tutte le stringhe e altri dati pertinenti di cui il programma ha bisogno sono contenuti all'interno del metadati. Quindi, Ngen copia tutti i metadati alla sezione .il dell'EXE nativo e copia il codice IL come ripensamento

Answer 2

Se si esaminano l'offuscamento rapido/facile, scrivi un gruppo in modalità mista in C ++, che sarà un caricatore di avvio del proprio gruppo (caricherà legacy .NET FW 4.0 tramite COM nel codice nativo e userà un'interfacce pubbliche dichiarate gestite Parte, tratto. Ciò impedirà di il lildasma che ti consente ancora di permetterti di debug e costruzione del progetto (utilizzando eventi di costruzione)