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

你可能感兴趣的:(compile)