如何用实例探讨.NET强命称的思路
如何用实例探讨.NET强命称的思路,相信很多没有经验的人对此束手无策,为此本文总结了问题出现的原因和解决方法,通过这篇文章希望你能解决这个问题。
专业从事成都做网站、成都网站建设,高端网站制作设计,小程序设计,网站推广的成都做网站的公司。优秀技术团队竭力真诚服务,采用H5网站设计+CSS3前端渲染技术,响应式网站建设,让网站在手机、平板、PC、微信下都能呈现。建站过程建立专项小组,与您实时在线互动,随时提供解决方案,畅聊想法和感受。
手头有一个行业软件,是需要插上加密狗才能正常运行的,C# / .Net Framework 1.1环境开发的。这是我们公司购买的正版软件,所以是能正常使用的,但是由于电脑多,加密狗难免要拔来拔去的。闲来无事,就研究研究吧,也好多学些调试知识。
PEiD可以“鉴定”出该软件是Microsoft Visual C# / Basic .NET,新手不要以为脱壳查壳才用到PEiD啊。
那就用Reflector分析吧,注意到不插加密狗会弹出个对话框提示“*****未注册*****”的字样,部分功能受限。按F3显示搜索窗口,输入“未注册”,点其右侧“String Seach”图标进行字符串搜索。找到一项,是程序启动的一个模块,双击来到左侧树状列表,再双击打开代码,我选的C#格式。一般我是IL和C#两种结合对照使用。鉴于诸多原因,代码已经精简并修改,特此说明。下同。
GlobalVariant.zhuce = Check.Textxyz; if (!GlobalVariant.zhuce) { MessageBox.Show(this, "*****未注册*****"); }
一看,里面没有一个汉字,用许多“\u7237\u7016”之类的字串,这就是汉字的Unicode了。把模块代码复制出来,找个Unicode转换工具转一下,现在一目了然了,直接找到弹出“*****未注册*****”的条件判断,该判断调用了some.dll中的一个过程Check.Textxyz,点击过程名字跟踪过去,点开如下:
public static bool Textxyz { get { return ((Check() != 0) ? 1 : 0); } }
再点击追查Check()函数,除了定义什么都没有,已经是传说中的Native Code了(本机代码)。[后来反编译才发现的。
[PreserveSig, MethodImpl(MethodImplOptions.Unmanaged, MethodCodeType=MethodCodeType.Native), SuppressUnmanagedCodeSecurity] public static int modopt(CallConvCdecl) Check();
但是无所谓了,分析一下,只需修改上面那个Textxyz中的return ((Check() != 0) ? 1 : 0); 根据判断返回1(true)或0(false),应该是检测软件狗的Native Code为:return ((Check() != 0) ? 1 : 1); 不管怎么样都返回1(true)
嗯,方案确定,那就干吧。。。。
程序有5个DLL和2个.EXE,其中一个.EXE不是C# .Net程序(Assembly),只需解决这5个DLL和1个EXE就完了。简单!
全部ildasm出来,将some.il的代码根据上面改法做了修改,很简单,就是把那段里的ldc.i4.0改为ldc.i4.1
L_0009: ldc.i4.0 /这里改成ldc.i4.1
L_000a: br.s L_000d
L_000c: ldc.i4.1
L_000d: ret
全部去掉强名称,用ilasm编译回去。。。。。。。
到some.il卡壳了,我郁闷,还以为胜利在望了呢。这才注意到some.dll使用了本机代码(Native Code)。some.dll中还有许多.NET代码的软件功能。大家一致认为,混合了本机代码的Assembly是无法重新编译的,因为无法反编译(不信你试试)
唉,怎么办,查资料,眼都看晕了,结果还是NO WAY。PS 看来使用本机代码混编译.Net是保护.Net Assembly程序很强的方法。
只能16进制编辑了,弄了一份some.dll,对照some.il找到特征字串,在编辑器中搜索到以后16(false)就改成了17(true)。这里some.il在用ildasm导出(即转储)时一定要把那几个方框打上勾,这样反编译出来的代码就有IL指令对应的some.dll中的16进制代码。很方便去编辑器中搜索定位。
保存后打开软件,看看能不能运行---弹出公共语言运行库错误提示!运行.Net Framework SDK 1.1 的DbgCLR进行调试,查到是强名称认证出了问题!对有强名称的Assembly.Net程序,只要用16进制编辑器修改了任何字节,都会导致强名称验证失败而使程序无法运行。(不知道修改header会不会也这样,没试)
解决强名称认证问题的常规方法就是重新编译程序,可是刚才就试过了,不行!
反编译带本机代码的Assembly?搜索和研究了好久没找到解决方案。那么,能不能将全部DLL/EXE强行去掉强名称,试了一下不能运行,而且也不可能加载到GAC中运行。那么,怎么根据算法给some.dll“更新”成修改后的正确强名称?没有答案。这一点我很感兴趣,以后还会留意。
没辙了,***一招:怎么欺骗Microsoft.Net让它不去检查强名称,或者让它怎么看都是对的?网上找到写注册表的方法,但我试了几次都不行,怀疑是不是需要重新启动一下电脑??没再试。干脆,把.Net Framework 1.1的这个强名称机制破解了算了,我是没看到它到底有什么用。
破解系统的强名称验证机制:
结合网上找到的资料,StrongName强名称相关的操作在.Net Framework运行库的文件mscorsn.dll里,具体位置,一般在系统目录C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\下,自己找。涉及到的函数是StrongNameSignatureVerification和StrongNameSignatureVerificationFromImage。
于是复制了一份mscorsn.dll,用OD打开,先点运行让它运行一遍(管它运行不运行呢),然后点菜单中 调试 --> 调用DLL输出,找到相关的函数并参照着找到函数入口点,修改一下让它们直接返回一个True。修改保存,覆盖掉系统原来的那个文件,注意先备份一下以防修改失败或事后系统恢复。覆盖时,要先覆盖Windows/System32/dllcache/目录下的那个,然后再覆盖Windows/Microsoft.NET/下的目录下的那个。现在点击已经修改好的程序看看怎么样了?
运行成功!无异常。
同事说我把这个软件和.Net一块给Crack了。只可惜要替换.Net Framework的系统文件mscorsn.dll才行,安全性是否下降尚不知道。这个系统文件的替换做法,在.Net Framework 2.0中应该是一样可以对付强名称的。
总结: (很重要)
1. 如果你都看到了这里,证明你很有耐心,也很谦虚,麻烦不要挖苦我:-),请多多指点
2. .Net程序(Assembly)的逆向研究难点就在Native Code混编,这个应该是研究方向
3. 不可逆强名称程序的强名称验证能否从正面解决能否“更新”强命名是不是不可完成的任务?
4. 这一点很重要:本文提出了一个强名称验证+编译本机代码保护程序的一个Crack思路,只要找到需要修改的关键点,只要能用16进制编辑器让它突破限制,那么程序也是可以照常使用的。只不过再给系统打个免强名验证补丁而已。虽然是有所得有所失,但反过来想想,对软件到了要Crack的地步的“强烈需求”,会在乎给系统打个并不是很令人讨厌的补丁吗?这个补丁怎么样,还需要大家大面积的试验,实践出真知。
可能有人会说,你想的也太天真了,如果软件的核心功能和验证都是NativeCode那你怎么办?其实不用担心,因为你说的程序已经算不上.Net程序了。只是披上.Net外衣欺骗用户而已。为什么要使用.Net开发程序?答案很多,开发快捷,功能强大易用(都是针对开发人员)等等等等,所以呢。。。如果用.Net进行开发,肯定软件的核心功能是靠.Net NonNative Code实现的,至于验证非法用户的核心功能,就写道Native Code中,然后混编一下。然后,这样的程序应该还是很容易Crack的。没有强名称验证,Native Code作用有限。
看完上述内容,你们掌握如何用实例探讨.NET强命称的思路的方法了吗?如果还想学到更多技能或想了解更多相关内容,欢迎关注创新互联行业资讯频道,感谢各位的阅读!
文章标题:如何用实例探讨.NET强命称的思路
网站链接:http://scyanting.com/article/ihpscd.html