紫雨日志

DNGuard HVM Release

瑞克 — Fri, 10 Aug 2007 13:43:00 +0000

应使用者的要求，增加了反制静态编译工具查看程序集完整结构的功能。
当然首当其冲的就是Reflector了。
个人认为，加密最主要的就是加密方法代码，结构啥的并不是重点，
如果是做中间件、类库啥的，结构还非得给用户看不可。

试用版开放了常规模式的用户字符串加密功能。

标准版将会提供名称自动混淆功能。
具体详情可参考软件界面中的即时提示信息。

程序中灰色不可用的选项是标准版或者专业版才提供的功能。

标准版将在这个周末正式发布。

注意：RC1和RC2的运行库可以通用， RC3 以及 Release 的运行库结构都有变化，不能和其它版通用。

下载地址：
http://www.redcheek.net/bbs/read.php?tid=5051
重新下载压缩包即可。

介绍：

.Net 内核级的加密保护工具。

采用的是纯虚拟机处理层的内核。

兼容目前所有的32位 .Net 框架版本，Net 1.1, 2.0, 3.0, 3.5 以及其所有子版本（如beta x，CTP，RC，sp x等）。

支持泛型类型以及泛型方法的加密。

加密保护过程不依赖 ildasm 和 ilasm 。加密速度快。

支持 C++/CLI含本地代码的混合程序集的加密保护。
完全兼容其它纯混淆保护工具，不必担心其它混淆工具对ildasm设限导致无法加密。

加密后的程序集完全兼容其它整体加密或者打包、xbundler等保护方式。

试用版的保护方式类似CliProtector，内核抗Jit层脱壳的强度和 CliProtector、Maxtocode 2007 企业版相当。
具体详情可参考：
常见dotNet加密保护工具介绍
http://www.cnblogs.com/rick/archive/2007/07/27/834172.html

DNGuard HVM 标准版和专业版分别对虚拟机处理层防脱壳做了更多增强处理。
虚拟机处理层的脱壳原理可参考：
.Net Jit层脱壳的实现原理
http://www.cnblogs.com/rick/archive/2007/08/04/843297.html

下载地址：
http://www.redcheek.net/bbs/read.php?tid=5051

浅谈DotNet 保护中的字符串加密技术

瑞克 — Fri, 10 Aug 2007 13:42:00 +0000

学习过了名称混淆，最近又看了一些字符串加密方面的东西。
在混淆保护和加密壳中都有字符串加密保护功能。
总体上字符串加密可以分为两类，
第一类是混淆保护中的字符串加密技术。主要特征是修改代码执行路径。
大部分混淆保护工具的字符串加密都是这一类。

第二类就是加密壳中的字符串加密技术。这种不用修改IL代码，直接对元数据中的字符串加密。
这一类以remotesoft,maxtocode为代表。

先看第一类，加密实现大致如下。

加密前：
MessageBox.Show("Hellow World!");

加密后：
MessageBox.Show(Helper.Decode("A34579dfbbeyu346563345/=="));

简单的说就是将原来使用字符串的地方，将直接使用字符串改为间接使用字符串。
在这里保护软件将字符串 "Hellow World!" 进行加密得到结果 "A34579dfbbeyu346563345/==" 。
Helper.Decode 是保护软件提供的一个解密函数，它实现将 "A34579dfbbeyu346563345/==" 还原为 "Hellow World!" 。

因为是混淆保护，所以我们可以分析得到 Decode 的代码。然后直接用这个函数的代码写一个小工具将程序集中所有加密的字符串都还原。生成一个字符串对应表。以方便代码阅读和调试。

如果再深入，可以实现自动将字符串还原到原程序集中。
再来看上面例子的IL代码。
加密前:
ldstr "Hellow World!"
call MessageBox.Show(string)

加密后：
ldstr "A34579dfbbeyu346563345/=="
call string Helper.Decode(string)
call MessageBox.Show(string)

怎么还原，其实很简单，我们已经知道了decode的代码，而且已经能实现字符串的解密了。得到了字符串的对应表。

直接将

ldstr "A34579dfbbeyu346563345/=="
call string Helper.Decode(string)

替换为

ldstr "Hellow World"

即可。写一个小工具使用正则表达式搜索替换就可以了。

第二类字符串加密保护：
实现就是直接对元数据中的String流进行加密。

这类保护有一个缺陷，程序运行后元数据中的String流会解密后在内存中完整还原。在我前面的文章里面有介绍元数据的dump。这里就不重复罗嗦了。

对于第一类字符串加密保护，还有其它的形式，如 Helper.Decode这个函数可以是一个native的函数。
或者是和流程混淆结合。

SourceOffSite 4.2中文增强版服务器端(含加密&无加密版)

瑞克 — Tue, 22 May 2007 05:06:00 +0000

1.重写了管理器程序。配置文件采用Xml格式，解决配置中含有特许字符时的bug。
管理程序是中英双语的，根据系统自动选择。

2.相比前一个中文修正版。
本次修正的服务器程序集成了加密版和无加密版。
*可以在项目中提交中文名的文件，中文的注释评论，中文的项目路径名。

新版修正增强：
1.sourcesafe数据库文件可以放在中文目录中。
2.数据库别名可以使用中文。
3.用户名中文
4.Web项目名称可含中文，部署目录可含中文。
5.非压缩模式下中文支持。（前一版本非压缩模式下会有问题）

服务程序增加命令行功能，命令行参考如下：
Usage: SosService.exe [/u | /i | 1]
    /u     Uninstall this Service        卸载此服务
    /i     Install this Service        安装此服务
    1     普通应用程序模式运行（非Windows服务模式）

服务安装后启动、停止服务可在控制面版中操作，也可以在命令行操作
启动：
net start soscnsvc
停止
net stop soscnsvc

下载中文增强版

升级安装说明：
如果你已经安装过SourceOffSite 4.x Server 了。
首先备份 sossvr.prp ， (sossvr.kys)
然后卸载 SourceOffSite Server。
再安装本中文增强版。
安装好后，先将备份的 sossvr.prp，(sossvr.kys) 放到中文增强版的安装目录中。
然后再运行 ServerMgr.exe 中文增强版的管理程序。

请注意一定要先放好 sossvr.prp 文件然后才能运行 ServerMgr.exe。
这样做的目的是保留你以前的配置信息。

中文增强版的配置是存储在xml文件(sossvrprp.config)中的，
管理程序第一次运行时会从sossvr.prp中自动导入旧配置信息。

※※※这个汉化修改版，完美解决了 SOS 不支持中文项目名、文件名、注释的问题

深入Jit，实现dotNet代码的加解密

瑞克 — Sun, 10 Dec 2006 01:03:00 +0000

这段时间在测试.Net Jit的容错性，为了方便，就直接将代码插入到Jit中进行测试了。
这个种方式就是我前面介绍DNGuard时提到的第一种增加内核强度防反射脱壳的方法。
这种技术即可用在dotnet代码的保护上，也可以用在dotnet加密壳的解密上。

目前的加密壳都是将内核插入到ee中提供解密服务。而dotNet的反射功能也是在ee层实现的，
所以才暴露了加密壳之前的反射漏洞。

如果加密壳将内核插入到jit，和jit融合提供解密服务，那么反射就基本上失效了。在 ee 层就无法获取到解密的代码了。
在这种情况下修复反射基本上是不现实的了，jit只是为ee提供编译服务。当然如果实现了jit层的脱壳，然后反过来再从jit增加一个服务提供ee层调用也是可以修复反射的，但如果实现了jit层的脱壳，再修复反射就有点多此一举了。

如果直接从Jit层脱目前ee层的加密壳是比较轻松的，根本不用考虑修复反射的问题，对.Net 2.0 , 1.1都管用。
这种方法对目前加密壳以及它们的各个版本都有效。只是jit层脱壳有一个问题要解决，因为只有方法被编译时才会进入jit，所以要完全脱壳需要让方法都被编译。
不过这个问题不大，从ee层或者反射着手都可以解决。之前对付某壳老版本时用过，当时该壳没有躲过Profile，可以从profile里面dump到代码，同样只有方法在编译时才能通过profile得到代码。
用反射比较简单，不用了解ee都可以，invoke一个方法时这个方法肯定会被编译的。

Jit层脱壳可以通吃目前的ee层加密壳，加密壳如果还在ee层混就没什么前途了。

Jit层脱Jit层的加密壳，就如同目前用反射脱ee层的壳差不多（甚至可能还稍差一筹），没法做到通吃，只能针对不同的加密壳内核做不同的脱壳核心才行。
Jit加密壳和Jit融合得越复杂，要脱壳难度就越大。不过这样要保证加密壳的稳定性和兼容性，就要做更多的工作了。
就是这个原因，我才做Jit的容错性测试，DNGuard 2.0的内核使用的就是Jit层，容错性测试差不多了。
DNGuard目前的内核基调就不会再调整了。

接下来就要着手DNGuard H-VM的试验和测试了。这个也是纯Jit层的。（H = half）

DNGRuntime在运行时动态还原程序集，进行程序集方法的拆分（即一个方法被拆分为两个或多个），
拆分后的方法差不多是一半走jit，一半走DNG H-VM。

遵循如下约定：
如果方法A走Jit，则被方法A所调用的方法都走 DNG H-VM

.Net加密壳认识的一个误区

瑞克 — Sat, 02 Dec 2006 00:12:00 +0000

自从.Net 2.0的新特性被公开用来获取IL代码后，加密壳就成了鸡肋。
就如tankaiha所说“.net下逆向暂时没啥新东西可搞，某软件的版本升级是一次不如一次强”，由于先天不足，这成了加密壳强度的一个瓶颈。

但是还有相当一部分人认为1.1的程序集加密后是安全的。
其实不然，绝大部分1.1的程序集加密后也能用发射的方式进行脱壳。
（注：这里的脱壳仅指加密保护壳，混淆是无法还原的，如某软件现在同时提供了加密和混淆功能，脱壳仅能脱除加密保护部分）

.Net 1.1没有 2.0中有的新特性，怎么能用反射脱壳呢？原因很简单，因为大部分1.1的程序集能在 2.0的框架中运行。
如加密的 dll，我们可以用2.0写一个程序集来load它。我们就有了2.0的运行环境了。
那加密的 exe 呢，也好对付，微软允许用户通过修改程序配置来强制指定一个程序运行的 .net framework版本。
假设 a.exe 是被加密的1.1程序集。
我们只要建一个文件 a.exe.config 和它放在一起，文件内容如下：

这样你再次运行a.exe时，系统就会自动启用 .Net 2.0 framework 作为运行环境。

如果说只能一个一个函数的获取IL代码，那么加密保护还有一定的利用价值。
然而反射脱壳已经有了成品脱机了，这就使加密保护彻底成了鸡肋。

对于反射，加密壳还是有一定作为空间的，但是作用很有限，治标不治本。
那就是破坏反射，让反射无法正常工作。
即通过破坏反射正常运行的系统地层代码或代码路径达到破坏反射的目的。
只要修复反射，就可以继续使用脱机脱壳。

这就将战场转移到了传统的Win32层面。
然而受限于.Net内核框架，破坏总是有限的，熟悉一点汇编，了解一些.Net底层机制，要修复是很比较容易的事情。

当然要修复总得需要先找一个sample来分析才行，如果没有sample神仙也没有办法。
这就有了某壳新版不再发布试用版本的事情出现。
这对于安全有那么一点点作用，即不至于新版一发布别人就找到的patch修复的办法。
但是只要有一个加密保护的程序发布，那就有了可分析的sample了，结果可想而知了。

单纯的加密壳强度已经得不到保障了，当然多一层保护总是好的。在众多的保护方式里，加密反而成了最脆弱的环节。

DNGuard V1.0 for Win98, WinMe 的运行库发布

瑞克 — Fri, 01 Dec 2006 00:22:00 +0000

昨天晚上花时间测试了一下平台兼容性，发现无法在win98和winme中使用。

今天晚上就搞了搞Win9X平台了的。
唉，本来很简单的一件事竟然搞倒现在才搞好。
Win9X真不是吹的，有兴趣的朋友可以试试写个程序加入 int 1，然后放在Win9X运行，马上就会经典重现。
真是屡试不爽，百试百灵。

使用运行库，能让用DNGuard加密的程序在Win98，WinMe系统中运行。
DNGuard支持的32位操作系统平台算基本完善了。

运行库的版本号没有变，功能也基本上没有变。增加了动态反跟踪。
直接用来替换v1.0版中的运行库即可。
这个新的运行库支持
Win98,WinMe,Win2000系列，WinXP，Win2003。

下载地址：http://www.bbsftp.com/temp/DNGRuntime.rar

DNGuard 平台兼容性测试结果

瑞克 — Wed, 29 Nov 2006 14:58:00 +0000

针对DNGuard 版本V1.0 做了一下平台兼容性测试。
首先 DNGuard 只支持32 位系统平台。
分别在Win98 WinMe , Win2000系列，Win XP, Win2003进行了测试。

1. Win98 WinMe
结果：不支持，无法运行。

2. Win2000系列，Win XP, Win2003
结果：支持，加密后的程序运行正常。

本次测试使用了 WinForm 2.0 程序和 Win Service 2.0程序。
其它类型的程序还未做测试。

DNGuard 使用介绍

瑞克 — Wed, 29 Nov 2006 00:45:00 +0000

DNGuard是一款绿色软件，下载后解压缩即可使用。
软件包包含两个文件
DotNetGuard.exe DNGuard主程序文件
DNGRuntime.dll DNGuard运行库文件

DNGuard的界面很简洁，使用非常简单。
运行后会看到如下界面：

有两个文本框，
第一个用来输入您要加密的程序集，可以点击按钮 3 来选择文件。
第二个用来输入加密后的程序保存的位置，可以点击按钮 4 来选择保存文件。

选择好这个两项后，点击按钮 5 即可。

加密速度会很快，比起其它使用ILDasm反汇编程序为IL文件，然后处理IL文件最后用ILAsm汇编成程序集的工具要快很多。

》支持直接对有强名的程序集加密。DNGuard会自动探测程序集是否有强名，当检测到强名后，
*会弹出一个打开文件的对话框，
*这时是让您选择这个程序集的对应的密钥文件，
*所以您需要选择好密钥文件。

强名程序集加密完成后就可以直接使用，不用再做其它处理。

》支持对本地码与IL代码混编的程序集加密。
*DNGRuntime.dll就是一个例子。

加密后程序集需要 DNGuard 的运行库才能运行。
1。您可以把DNGRuntime.dll和加密的程序放在同一个目录中。
2。您还可以把DNGRuntime.dll 安装到系统的GAC中。

建议使用第二种方式。

DNGuard 免费的DotNet加密保护工具 V1.0

瑞克 — Wed, 29 Nov 2006 00:44:00 +0000

DNGuard 是一款免费的DotNet内核模式的加密保护工具。

这是第一个发布版本，版本号定为 1.0。只支持32位系统。
目前还只在 xp和2003上做过测试，其它版本的系统还未测试，大家有条件的麻烦帮忙试试。

运行本程序需要系统安装 .Net 2.0 框架。

支持加密2.0和1.1的程序集，不过还只测试了winform的。

因为IL反汇编和IL汇编都是程序实现的，偷了懒，在IL汇编时都汇编成了2.0的格式。
所以，加密后的程序集需要在 .Net 2.0 的框架下运行。

支持直接对有强名的程序集进行加密。加密时DNGuard会自动判断程序集是否有强名，如果检测到强名，会提示用户选择密钥文件。

包含两种加密算法，算法强度一般。

建议用来作为辅助的保护手段，实践证明单纯的加密壳是没有强度可言的。

接下来的计划，增加2-3种加密算法，根据大家的反馈完善稳定性和兼容性。
然后用前面提到的第一种方式增强内核。

接下来着手试验另一种保护技术。

下载地址：http://www.bbsftp.com/temp/DNGuardV1.0.rar

DNGuard 一款DotNet内核级加密保护工具

瑞克 — Wed, 29 Nov 2006 00:44:00 +0000

最近一直学习DotNet相关资料，sscli真是好东西啊:P。

一边学习一边把知识综合了一下，做了这个小工具。
保护原理和国人的remotesoft,maxtocode差不多。加密后的程序发布时也需要附带一个运行库，
不过和那两个不同，附带的运行库不是纯native的dll，而是C++/CLI的混合程序集。

工具已经有了雏形，整体内核框架完成了。用来加密了一个sample，运行正常。
有些方面甚至超过了maxtocode。

1.不依赖微软的ildasm和ilasm程序。
IL反汇编和IL汇编都程序实现。
可以加密包含本地代码的程序集。

2.Anti反编译工具，maxtocode加密的程序集无法用reflector直接查看，但是程序运行后用pedumper，dump后就可以用reflecotr查看结构了，当然还是看不到代码的。
dnguard加密的程序集比我预期的效果还要好，加密后的程序集无法用reflector查看，dump后的也无法用reflector插件。

感觉reflector还是有些弱，同类软件Disa#, Xenocode fox 就可以直接打开查看maxtocode和dnguard加密的程序集。
为此我尝试在dnguard加密的程序集里面增加了结构混淆，有一点效果，就是在Disa＃和 fox里面查看结构是会出现一些张冠李戴的混乱，即类A的函数可能会显示到类B中。效果还不是很好，会出现问题的函数每个类只有很少的几个。

3.Anti .Net 2.0的新特性，不是很强，强度和maxtocode 3.13（内部版）差不多，听说maxtocode出了3.14了，不知道强度是否有增强(看Jason的blog里的回复似乎和3.13是一样的)。max的3.12patch几个字节，反射就可以用了，3.13也差不太多，需要patch的字节数比3.12还要少。

关于这个方面现在有一个比较好的方案，能够在不影响效率的前提下使强度提高很多。但也不能完全防dump。
还有一个比较完美的防dump的方案，需要配合另一项保护技术一起才能实现。
这个方面不打算再深入探讨了，等DNGuard加密壳完成后，会着手另一项保护技术，最后将两项保护合在一起。

4. Anti dump后用ildasm,ilasm恢复程序集。DNGuard除了anti .net 2.0的新特性防dump外，还增加了anti，我早期做的dumper。另外还利用C++/CLI混合程序集的特性实现了，防dump后ildasm。不过这个强度不大，对小程序集能被很容易修复后实现il汇编。

现在需要做的工作还有很多，加密算法还没有弄，运行库自身的保护也还没有做。发现纯native的dll可以找到现成的保护工具，就thmida很不错，maxtocode的运行库就有用这个壳，C++/CLI的dll就一直找不到好的方法。看来只能手动加一层保护了，已经开始着手试验了。现在准备加一个简单的加密壳，等这个做完后就把DNGuard放一个demo上来。

DNGuard加密程序集后用reflector查看：

DNGuard加密程序集dump后用reflector查看：

Maxtocode加密后的程序集用Reflector查看：

Maxtocode加密程序集Dump后用Reflector查看: