Can we disassemble (using ILDasm) an NGen-ed assembly?

Question

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.

Kwarteng

Answer 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

Murdock

@Murdock I agree! That link in your answer explains it all. True reverse engineering. Meanwhile I tried building by NGenILDasmTest.dll in both /release and /debug mode separetely. That does not seem to make any difference either. One more thing observed is the original assembly NGenILDasmTest.dll is 5KB in size as Explorer shows it, and the Ngen-ed assembly assembly NGenILDasmTest.ni.dll is 10KB. Without second thought, that makes me believe the statement "An NGEN'ed assembly is the IL plus native code". – Kwarteng

Answer 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)

Johnsen

Thx. I guess I will have to give it a shot. – Kwarteng

Do you need the sample project to start with? I can give you a sample, if you wish. – Johnsen