< meta http-equiv="description" content="一看,里面没有一个汉字,用许多“\u7237\u7016”之类的字串,这就是汉字的Unicode了。把模块代码复制出来,找个Unicode转换工具转一下,现在一目了然了,直接找到弹出“*****未注册*****”的条件判断,该判断调用了some.dll中的一个过程Check.Textxyz,点击过程名字跟踪过去"/>

验证.NET强命称的思路和实例

[来源] 达内    [编辑] 达内   [时间]2012-09-12

一看,里面没有一个汉字,用许多“\u7237\u7016”之类的字串,这就是汉字的Unicode了。把模块代码复制出来,找个Unicode转换工具转一下,现在一目了然了,直接找到弹出“*****未注册*****”的条件判断,该判断调用了some.dll中的一个过程Check.Textxyz,点击过程名字跟踪过去

  手头有一个行业软件,是需要插上加密狗才能正常运行的,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作用有限。

资源下载