.NET体系中的源程序安全问题(3)

原创 2004年09月25日 19:56:00
三、反向工程
 当程序集以MSIL而不是机器代码的形式发布时,最令人关心的问题应该就是安全。正如前面所介绍的,程序集包含了关于包里面所有模块的manifest以及详细描述各个模块的元数据。.NET SDK 提供了一个名为ILDASM的工具,它是一个IL反汇编程序,能够从模块反汇编出IL代码以及应用程序中各个模块的元数据说明。从Listing 1可以看出,利用ILDASM对代码实施反向工程是极为方便的。


【Listing 1】下面是IL反汇编程序ILDASM输出的部分结果。
它显示的是应用中一个名为LeavingMessage的私有方法,后
面部分是调用LeavingMessage方法的代码。CLR把参数压入
栈,执行调用,然后恢复栈为下一个操作做好准备。

.method private instance void LeavingMessage(class System.String& strText) il managed
{
// Code size 10 (0xa)
.maxstack 8
//000059: Private Sub LeavingMessage(ByRef strText As String)
IL_0000: nop
.line 60
//000060: debug.Write(strText)
IL_0001: ldarg.1
IL_0002: ldind.ref
IL_0003: call void [System]System.Diagnostics.Debug::
Write(class System.String)
.line 61
//000061: End Sub
IL_0008: nop
IL_0009: ret
} // end of method Form1::LeavingMessage

Code to call LeavingMessage Sub

finally
{
IL_002d: nop
.line 73
//000073: LeavingMessage("Goodbye Dear Friend")
IL_002e: ldarg.0
IL_002f: ldstr "Goodbye Dear Friend"
IL_0034: stloc.3
IL_0035: ldloca.s _Vb_t_string_0
IL_0037: callvirt instance void
GoodbyeVB6.Form1::LeavingMessage(class System.String&)
IL_003c: endfinally
.line 74
//000074: End Try
} // end handler


人们已经认识到了这个问题,一个常见的反驳意见是:在现实中,应用的规模很大,IL反汇编输出结果的规模将超过可以忍受的限度。但是,它可能使一个业余爱好者望而却步,却不能阻止一个真正对代码感兴趣的人。实际情况是:与机器代码的反汇编结果相比,ILDASM的反汇编结果要容易阅读得多,任何对此感兴趣的组织都能够从IL反汇编结果了解到大量有关应用的信息。

按照Microsoft的意见,要保证企业机密安全,我们应该把所有包含企业机密的模块放到受保护的服务器上。对于ASP.NET客户机/服务器应用来说这没问题,但对于标准的桌面应用来说它行不通。那么,如何才能对知识产权进行保护呢?MSIL汇编程序文档提到了一个命令行参数/owner:


ilasm ... /owner
ilasm ... /owner=fergus


这个选项用密码加密代码,防止代码被反汇编。问题在于Microsoft准备取消这个选项,因为它看起来不是一种好方法。这样,对于用受管理的C++、C#或VB为.NET Beta 1编写的桌面应用来说,要保护知识产权将非常困难。

但希望仍旧存在。在.NET最终发布之前,Microsoft可能提供一个模糊器(Obfuscator)程序,它能够修改MSIL的私有方法,使得除CLR JIT编译器之外没有人能够阅读这些私有方法。但是,它不会隐藏应用的公用(全局)方法以及对外部库的调用,这是因为:如果修改全局调用的名字或者隐藏这些调用,CLR将不能再链接到外部函数。因此,黑客们仍旧能够通过查看IL代码,找出应用调用系统DLL的各种信息。这样,现在我们只能用一种方法对桌面应用的知识产权进行保护,即用非受管理的C++编写关键性代码,然后从VB.NET通过为访问非受管理代码提供的交互机制访问它。当然,对于VB开发者来说,这可能比较困难。

由于所有受管理代码必须以MSIL形式发布,所以在发布之前代码不能进行JIT编译。但是,在目标机器上安装应用的时候,我们可以把代码编译成汇编形式。从表面上看来这很不错,但代码在安装盘上仍旧是IL形式,我们可以手工从安装盘提取出代码,然而分别对它们进行反汇编。由于应用安装完成后以编译代码而不是IL的形式存在,除了安全之外,它还能够少量地提高应用运行的速度,因为此时我们不再需要JIT编译器编译IL代码。

.NET体系中的源程序安全问题

在.NET平台上,代码以中间语言的形式运行,它是.NET众多优势的基础。但在独立桌面应用中,它给源代码的安全带来了威胁。本文探讨产生这个问题的原因,分析可能的解决办法。   在Visual Studi...
  • tanaya
  • tanaya
  • 2005年02月20日 22:35
  • 1554

.NET体系中的源程序安全问题(1)

在.NET平台上,代码以中间语言的形式运行,它是.NET众多优势的基础。但在独立桌面应用中,它给源代码的安全带来了威胁。本文探讨产生这个问题的原因,分析可能的解决办法。 在Visual Studio....
  • luoboqingcai
  • luoboqingcai
  • 2004年09月25日 19:57
  • 496

.NET体系中的源程序安全问题(2)

二、中间语言  为了了解在用VB.NET构造工程的过程中发生了什么事情,我们需要创建一个生成代码和程序集时使用的示例工程:打开VS.NET,新建一个Visual Basic工程,在窗体中加入一个文本标...
  • luoboqingcai
  • luoboqingcai
  • 2004年09月25日 19:57
  • 549

.NET体系中的源程序安全问题(4)

四、结束语 如果你是一个桌面应用的供应商,你清楚自己应该怎么做。你可以用非受管理的C++编写代码,然后从受管理的VB调用它。用这种方法设计应用,你能够确信代码的安全。然而,如果你是一个第三方供应商,而...
  • luoboqingcai
  • luoboqingcai
  • 2004年09月25日 19:55
  • 478

.NET体系中的源程序安全问题, Delegates

 Delegates1  .NET中的委派(Delegates)      回调函数的确是至今为止最有用的编程机制之一。C运行时的qsort函数利用回调函数对数组元素进行排序。在Windows中,回调...
  • Silicon_Fado
  • Silicon_Fado
  • 2007年02月13日 14:42
  • 849

.NET体系中的源程序安全问题(四、结束语)

   如果你是一个桌面应用的供应商,你清楚自己应该怎么做。你可以用非受管理的C++编写代码,然后从受管理的VB调用它。用这种方法设计应用,你能够确信代码的安全。然而,如果你是一个第三方供应商,而且准备...
  • cbacba
  • cbacba
  • 2001年07月29日 11:51
  • 648

.NET体系中的源程序安全问题(一、概述)

   在Visual Studio.NET(VS.NET)体系中,VB、Visual C++以及C#之类的编译器把源程序编译成MSIL。MSIL即Microsoft Intermediate Lang...
  • cbacba
  • cbacba
  • 2001年07月29日 11:46
  • 661

.NET体系中的源程序安全问题(三、反向工程)

   当程序集以MSIL而不是机器代码的形式发布时,最令人关心的问题应该就是安全。正如前面所介绍的,程序集包含了关于包里面所有模块的manifest以及详细描述各个模块的元数据。.NET SDK 提供...
  • cbacba
  • cbacba
  • 2001年07月29日 11:49
  • 669

.NET体系中的源程序安全问题(二、中间语言)

   为了了解在用VB.NET构造工程的过程中发生了什么事情,我们需要创建一个生成代码和程序集时使用的示例工程:打开VS.NET,新建一个Visual Basic工程,在窗体中加入一个文本标签(Lab...
  • cbacba
  • cbacba
  • 2001年07月29日 11:47
  • 773

net framework体系结构

术语解释 CIL(common intermediate language):公共中间语言。.net框架下各种种类、版本的编程语言在经过编译后生成的中间语言(后缀为.il),与平台无关、与语言无关,...
  • u011872945
  • u011872945
  • 2017年06月07日 11:21
  • 351
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:.NET体系中的源程序安全问题(3)
举报原因:
原因补充:

(最多只允许输入30个字)