.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程序了


native compile 方式就是将dotNet程序编译成native的本地代码，有代表性的相关工具有xenocode, themida 和 remotesoft。