在 net 2.0 中 ngen 能生成 native code 的 image,但是它同时会保留原始程序集的 MetaData 和ILCode 。
这就是还原的关键。同样的,知道了还原方法后加强保护也很容易实现。
ni 文件中的元数据和普通元数据相比多包含了一个 NativeHeader。
在 NativeHeader 中第12个入口是 OrgMetaData的 RVA和Size,第13个入口是 OrgILcode的 RVA 和Size。
我是一个偶然机会发现ni包含原始metadata,然后强制方法重新进入Jit,截获IL代码。
根据查找到的OrgMetaData的 RVA 和 Size 我在 NativeHeader 中找到了一个匹配的,再根据截获的IL的RVA,
推测出它下面的那个RVA和Size可能是OrgILCode的,经测试果然是这样。
OrgMetaData中的每个方法对应一个RVA值,这个值 加上 OrgILCode的RVA就是实际RVA了。
这样提取出MetaData和ILCode就可以还原了。
要加强保护也容易,擦除 ILCode 就行了,因为net 2.0 ngen生成的 ni 文件真正包含了 native code,可以不需要 ILCode 运行。
ngen保护方式有一个遗憾,就是发布时需要附带一个虚拟框架环境。
我写了一个小工具来实现这种 ngen 的保护,不过我还没有自己实现虚拟框架环境,直接使用了 fetion程序里面的那个虚拟框架环境来运行ngen保护的文件。
这样处理后的ni文件能100%防止 IL代码泄露,不过美中不足的是抗破解能力比较差,ngen后native代码的位置就都固定了,不会变化,相当于win32程序裸奔。
目前还没有第三方工具能实现对这种 native 程序的保护,不知道今后是否会出现。
这就是还原的关键。同样的,知道了还原方法后加强保护也很容易实现。
ni 文件中的元数据和普通元数据相比多包含了一个 NativeHeader。
在 NativeHeader 中第12个入口是 OrgMetaData的 RVA和Size,第13个入口是 OrgILcode的 RVA 和Size。
我是一个偶然机会发现ni包含原始metadata,然后强制方法重新进入Jit,截获IL代码。
根据查找到的OrgMetaData的 RVA 和 Size 我在 NativeHeader 中找到了一个匹配的,再根据截获的IL的RVA,
推测出它下面的那个RVA和Size可能是OrgILCode的,经测试果然是这样。
OrgMetaData中的每个方法对应一个RVA值,这个值 加上 OrgILCode的RVA就是实际RVA了。
这样提取出MetaData和ILCode就可以还原了。
要加强保护也容易,擦除 ILCode 就行了,因为net 2.0 ngen生成的 ni 文件真正包含了 native code,可以不需要 ILCode 运行。
ngen保护方式有一个遗憾,就是发布时需要附带一个虚拟框架环境。
我写了一个小工具来实现这种 ngen 的保护,不过我还没有自己实现虚拟框架环境,直接使用了 fetion程序里面的那个虚拟框架环境来运行ngen保护的文件。
这样处理后的ni文件能100%防止 IL代码泄露,不过美中不足的是抗破解能力比较差,ngen后native代码的位置就都固定了,不会变化,相当于win32程序裸奔。
目前还没有第三方工具能实现对这种 native 程序的保护,不知道今后是否会出现。