.Net 保护中的 native compile 方式

 

据宣传，这个功能就是将dotNet程序编译成native的本地代码，有代表性的相关工具有xenocode, themida 和 remotesoft。
他们实际上属于两类：
一、伪编译
就是把磁盘上的 dotNet程序转换成 win32 的程序，但运行后在内存中实际上还是dotNet程序，只是使用了一个win32 loader，把dotNet程序整体打包嵌入到了这个 win32 的loader中。

二、ngen编译
ngen 是 dotNet提供的将IL编译成native的工具。
这种可以算是真实的编译吧。

但是它们有一个共同的特点，依然不能脱离dotNet框架单独运行，当然可以使用虚拟框架运行。

xenocode, themida属于第一类，他们只是打包后生成的磁盘文件是 win32的，这个其实只是一个loader，他们在运行时会是否出dotNet程序集（内存中），然后调用框架运行原始dotNet程序。在加密保护方法可以看着是整体加密保护类的加密壳。
算不上 native compile保护，但是 xenocode的宣传说的是native保护，x还有一个功能就是可以直接把虚拟框架也一起打包进去，这样运行起来确实很像是传统的win32程序。

remote的就是利用 ngen 编译成 本地代码。但是ngen编译的本地代码也不能脱离framework单独运行。而且ngen编译的本地代码平台依赖性很强，不仅不能脱离framework运行，而且一般都只能在其编译时使用的framework中运行。
这样发布 ngen编译的本地程序时必须同时打包编译时使用的framework。

前面我介绍了一个利用飞信框架脱离framework运行 dotNet程序的方法。
其中飞信框架有两个主要文件 FetionVM.exe 和 FetionVM.srm 这个两个是框架的loader程序，用来加载待运行的dotNet程序。

FetionVM.exe是native的win32程序，它实际上只是调用了rsdeploy.dll 里面的三个函数来启动 fetionvm.srm。srm这个文件其实是一个最简单的。net程序，在这个srm文件里面它会用反射启动 参数传递进来的那个 。net程序。

FetionVM.exe很简单，反汇编看看就清楚了。

fetionvm.srm是DotNet程序，如果你用reflector等工具查看会发现它只是一个“空壳”，里面啥都没有。
真正的实体在
\C\WINDOWS\assembly\NativeImages_v2.0.50727_32\FetionVM\6e39d95b1cb7d342a0ad2b892350dc65\FetionVM.ni.exe 中。
FetionVM.ni.exe 就是 ngen生成的native文件。
fetionvm.srm实际上使用了 native compile方式的保护。

fetionvm.srm这个文件的存在只是用来欺骗framework，框架在加载 fetionvm.srm 后，根据其程序集名称在 nativeimages中查找是否存在 native code，如果有就会加载 native code版本的。

对于微软 ni 的这种文件格式资料不是很多，目前还不太清楚全部的文件格式。
不过确定了一点， ni 的文件中会包含原始的 元数据。
据推测 ni 文件中应该也会包含原始的IL代码，目前还没有确定它们的关系，
如果能确定，那ngen生成的ni文件就可以直接还原成 dotNet程序了。