如果我NGen一个程序集，ildasm仍然反汇编它正常吗？
好的。我编写了一个 HelloWorld 类库，随后的 dll 名为 NGenILDasmTest.dll。
-->针对 .Net fw 4。
从 Vs 2010 命令提示符中，我
gacutil -i NGenILDasmTest.dll
可以看到安装在 GAC 中的程序集。我运行 ildasm 这样我就可以查看 IL。
到目前为止，一切都很好。
然后我运行
ngen NGenILDasmTest.dll
（我没有为 ngen 指定任何选项）。并且该程序集已成功编译。我在文件夹下找到了它，名称为 NGenILDasmTest.ni.dll
C:\Windows\Assembly\NativeImages_v4.0.30319_32\NGenILDasmTest\81d49dd4c7df22fb3df530402b58ffc9
现在，当我像下面一样运行 ildasm 时，
ildasm "C:\Windows\Assembly\NativeImages_v4.0.30319_32\NGenILDasmTest\81d49dd4c7df22fb3df530402b58ffc9\NGenILDasmTest.ni.dll"
我可以看到 Ngen 编辑的程序集的内容。这是正常的吗？
从技术上讲，Ngen 为 IL 生成本机 CPU 指令（显然将其放置在 C:\windows\Assembly\NativeImages_V4.#####_32 - 在我的例子中）。如果是这种情况，我如何仍然能够使用 ILDasm 将 NGen 编辑的程序集视为 IL？
请帮助我理解我在这里缺少的“小东西”。
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.
发布评论
评论（2）
NGEN 编译的程序集是 IL 加上本机代码。 IL 没有被剥离。人们经常混淆 NGen 程序集仅包含本机映像。元数据仍然需要原始信息。
微软似乎没有关于 NGen 程序集内部结构的非常具体的信息。我们知道的大多数信息都来自逆向工程。
编辑：
安装 .NET Framework 1.1 后（是的..） - .NET 1.1 NGen 似乎确实删除了 IL。看起来像是从 v2 开始 - IL 被保留。这似乎就是为什么存在相互矛盾的信息的原因。进行此更改的确切原因似乎尚不清楚。
这里有一篇关于 ngen 内部结构的好文章（以及它对于混淆来说是一个非常糟糕的主意）：http://www.woodmann.com/forum/entry.php?68-Rebuilding-native-.NET-exes-into-management-.NET-exes-by-Exploiting-lefotver-IL< /a>...
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...
如果您研究快速/简单的混淆，请用 C++ 编写一个混合模式程序集，这将是您自己的程序集的引导加载程序（它将通过本机代码中的 COM 加载旧版 .NET FW 4.0，并使用从托管声明的公共接口）部分（通过为托管程序集生成的 .tlb）作为加密资源（使用 RSA）保存，并加密本机 C++ 代码，然后对两个程序集进行签名。这将阻止 ILDASM 编译您的程序集，但仍然允许您调试和构建项目（使用构建事件）
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)