问题
If I NGen an assembly, is it normal that ildasm still disassembles it?
Ok. I wrote a HelloWorld class library and the ensuing dll is named NGenILDasmTest.dll. --> Targeted for the .Net fw 4.
From Vs 2010 command prompt, I did
gacutil -i NGenILDasmTest.dll
I could see the assembly installed in the GAC. And I ran ildasm so I could view the IL. So far so good.
Then I run
ngen NGenILDasmTest.dll
(I did not specify any options for ngen). And this assembly successfully got compiled. I located it with a name NGenILDasmTest.ni.dll under the folder
C:\Windows\Assembly\NativeImages_v4.0.30319_32\NGenILDasmTest\81d49dd4c7df22fb3df530402b58ffc9
Now, when I run ildasm like below
ildasm "C:\Windows\Assembly\NativeImages_v4.0.30319_32\NGenILDasmTest\81d49dd4c7df22fb3df530402b58ffc9\NGenILDasmTest.ni.dll"
I could see the contents of the Ngen-ed assembly. Is this normal?.
Technically speaking, Ngen generates native CPU instrcutions for the IL (and apparently places it under C:\windows\Assembly\NAtiveImages_V4.#####_32 - in my case). If that is the case, how am I still able to see the NGen-ed assembly as IL using ILDasm?
Please help me understand that 'little something' that I am missing here.
回答1:
An NGEN'ed assembly is the IL plus native code. The IL is not stripped out. There is often confusion that NGen assemblies contain only the native image. The original information is still needed for metadata.
Microsoft doesn't seem to have very specific information on the internals of an NGen assembly. Most information that we know is from reverse engineering.
EDIT:
After installing the .NET Framework 1.1 (yay..) - it appears that .NET 1.1 NGen does strip out the IL. It looks like starting in v2 - the IL is kept. This seems to be why there is contradicting information lying around .The exact reason this change was made doesn't seem to be known.
There is a good article on some of ngen's internals (and how it is an extremely bad idea for obfuscation) here: http://www.woodmann.com/forum/entry.php?68-Rebuilding-native-.NET-exes-into-managed-.NET-exes-by-Exploiting-lefotver-IL...
Now, the interesting thing about Ngen is that it does not eliminate the IL or the metadata, because while the IL code is not needed for execution, the metadata is, because all the strings and other relevant data that the program needs are contained within the metadata. So, Ngen copies all the metadata to the .IL section of the native exe, and copies the IL code as an afterthought
回答2:
If you look into fast/easy obfuscation, write a mixed mode assembly in C++, which will be a boot loader of your own assembly (it will load legacy .NET FW 4.0 through COM in native code, and use a public interfaces declared from managed part, trough .tlb generated for your managed assembly) held as an encrypted resource (using RSA), and encrypt native C++ code, then sign the both assemblies. That will prevent from ILDASM ing your assembly still allowing you to debug and build project (using build events)
来源：https://stackoverflow.com/questions/7373169/can-we-disassemble-using-ildasm-an-ngen-ed-assembly