[文章标题] .Net强名称带本机代码程序调试一例
 [Subject ] Crack a .Net Assembly with Strong Name Signature and Native Code
 [Author  ] FucKiNi (It's lccracker)
 [withTool] OD + Ms.Net SDK + Reflector and so on
 [System  ] Win2003 + .Net Framework 1.1 and SDK
 [SoftName] a Commercial Program in Specified Field
 [Download] N/A 
 [Protect ] Native Code Mixed + Soft Dog Hardware
 [Descrip.] This software is not protected with S/N or Lience but Soft Dog Hardware.
            It's a really bad thing that we can't enter any Lience by any way to make
            it run corectly. This article will show you how to make it working.
 [Disclaim] Only tell what I had done, no any warranties of any kind for responsibility.
------------------------------------------------------------------------

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

5. 饿死了,去吃饭,回来再修改吧。


---------------------------------------
 FucKiNi 2006.08.08.00:30