现在的位置: 首页 > 综合 > 正文

未完成的.net组件破解

2014年03月12日 ⁄ 综合 ⁄ 共 1654字 ⁄ 字号 评论关闭

最近的项目里,需要使用一个第三控件,用来实现对xml数据的编辑功能。几经周折终于从国外网上找到了一个叫RichWinFormSuite的控件包,下载安装之后就开始使用,简单学习了一下开发范例和Demo,发现功能很丰富,界面效果也不错,开发挺简单,这个组件也挺小,只有1M不到的一个dll文件。唯一的不爽是运行起来的时候会弹出许可窗口,需要点击关闭之后才能继续运行。

在国内网站上搜索了一下,基本上没有关于这个软件的介绍,更没有破解版,只好向搞安全方面的同学请教,希望能破解掉。

根据和同学和讨论,以及从网上找的资料,找到了一个破解.net程序的方法:先将.net程序(exe或者dll)通过反射工具Reflector的FildDisassembler插件将dll输出成源代码,然后自己组织和重新编译。

用Reflector打开dll之后,却发现有些不一样,类名和函数名变成了带有很多数字的字符串,和本来的名称变得面目全非。

 [使用reflector反编译dll ]

这肯定是通过混淆器处理之后的dll,既然函数名和类名都变了,那通过Reflector输出的源代码也全是数字和字母,重新编译了也没用,只好找个别的思路和方法。

 

后来想到另一个思路:先将.net程序(exe或者dll)反编译成IL语言,找到它弹出对话框的执行代码,然后修改成其它命令,直接让许可窗口不弹出来,再将修改后的IL代码重新编译成dll文件。

为了验证这思路的正确性,我写先一个小程序,在程序启动时弹出一个普通窗体,编译运行正常。

然后使用.net framework提供的工具包的ILDasm命令,输出该文件的IL代码,命令如下:

ildasm /output=c:/temp/test.il ILTest.exe

执行之后,会在C盘temp目录下生成一个test.il文件和一个test.res文件,以及其它资源图片也会输出在同一文件夹。

使用文本编辑器找到执行的语句,然后替换成nop命令,以使程序执行空操作,保存文件,使用ILAsm重新编译成exe文件,命令如下:

ilasm /exe /resource=c:/temp/test.res c:/temp/test.il /output=c:/mytest.exe

注意:第一个参数/exe是编译后的程序类型。

 

编译之后再运行,果然不再弹出窗口了,顿时喜上心头,感觉到离成功不远了。

立即使用按刚才的步骤来破解这个下载的dll,输出成IL语言代码之后,为了确定弹出窗口的代码位置,直接先搜索许可窗口中提示信息,找到该字符串所在的方法之后,觉得读IL代码太麻烦,函数名又都是数字,就利用Reflector的Analyze分析功能,找到该函数的"Used By",发现是在一个类名为xb08f1495afd18c6f的构造函数中被调用,于是就确定了弹出窗口的代码位置,将该行代码直接替换成nop命令。

[找到要修改的位置]

再重新编译成dll之后加入项目中使用,发现无法把该控件拖到设计器上,使用代码调用能编译通过,却在运行时弹出了异常信息:

“未能加载文件或程序集“RichWinFormSuite, Version=4.0.2.36, Culture=neutral, PublicKeyToken=a730077342cbf1ce”或它的某一个依赖项。强名称验证失败。 (异常来自 HRESULT:0x8013141A)”。

 

于是从网上找了资料,下载了一个snRemove的工具来,按照网上的说明进行操作,先将原始的dll文件去除强名称,然后再复制刚才的IL代码修改过程,完毕,重新加到项目引用中,却总是依旧。网上有人说这个工具去掉的强名称在windows2003上会失效,而我用的正是这个操作系统。

[使用snRemove ]

后来又在网上搜索了一些关于强名称破解方面的资料,但暂时还没有找到方法。我尝试过索性将IL语言中的.publickey代码段直接删除,然后在运行的时候居然报出一个异常:公共语言运行库检测到无效的程序。

 

哈哈,看来强名称还是强呢,虽然.net的反编译省事很多,但是这破解并不像传说中那么简单啊。

 

抱歉!评论已关闭.