NET代码保护解决方案

正如你们许多人可能已经知道，NET应用程序不分发的二进制代码，但使用一个专门的格式，称为MSIL’，这是微软中间语言的缩写。MSIL格式背后的想法是提供一个独立于机器的分发格式，促进运行的能力。NET应用程序的跨平台。这是通过CLR（。NET运行时引擎），具体由“只是在时间编译器（又名抖动）。CLR双手抖动，这反过来又原生格式的代码编译MSIL代码。然后，在其原生格式的代码交给CPU执行。不幸的是，这个重要的美德。NET应用程序容易受到恶意逆向工程攻击。事实上，它是如此容易篡改，人们可能会考虑是否使用该框架的优势，是值得的，考虑到涉及的风险暴露潜在的黑客的代码。为了证明它是多么容易篡改的代码，我们会看一个例子。

比方说，你是一个发展中的一个WinForms应用程序称为’MyPreciousApp’。在花费数月时间开发它，你现在准备将它部署。知道，软件盗版等待你，你已经决定使用您最喜爱的许可管理组件，以保护您的应用程序。您的代码可能看起来像这样：

读者可能会觉得奇怪，为了解除这种保护机制，黑客并不需要费心比自己更与您的应用程序搞乱几分钟。事实上，你并不需要成为黑客做到这一点。您只需要两个简单的工具，微软做的工作。首先，你将不得不使用ILDASM工具，这是微软的IL反汇编。该工具暴露了你的程序所使用的IL代码指令。

现在，撤防代码保护，你会通过简单地删除调用“ IsRegisteredUser方法的IL代码编辑。这是通过去除一个圆角矩形标记的代码。

要完成的过程中，你将不得不使用ILASM工具，又是一个由微软提供的工具，可让您组装的。NET应用程序从MSIL代码。

 

最后，您的应用程序已被篡改！

打破误解围绕强名称组件

鉴于所示的例子中，我想讨论三种方式，我已经遇到的努力来克服这个问题，一个问题，我想叫’ 篡改的不能承受之轻。NET应用程序 “。

首先，我想讨论强名称组件“。它似乎有很大的混乱，围绕这个问题，我想扫清。该工具允许你给它一个强名称，唯一标识一个程序集。名称实际上是由用于识别的信息，包括集的文本名称，版本号由四部分组成，文化信息（如果提供），公共密钥和数字签名存储在程序集清单。数字签名编译期间所创建内容的装配，并运行它通过某种散列算法，其结果是使用分销商的私有密钥编码，并存储在程序集清单。

一旦组件已经准备好被加载到内存中，验证过程是由CLR启动。CLR获得集，并运行它通过在编译时使用相同的哈希算法。然后将结果相比原始签名的店，同样写在编译阶段。要破译签名，CLR使用的装配的公钥。

“强名称组件的引进确保相同的程序集编译你的程序将被加载到内存中运行。这解决了一个被称为“DLL地狱”，这种情况时产生一个组件被更新的问题，有可能打破依赖于它的其他应用程序。此外，强名称组件构成，可以利用出版商的身份发布的代码访问权限由用户定义。这意味着，例如，用户可能不允许目标发布者，其硬盘上，根据其身份访问文件。

一些开发商都倾向于认为，因为强名称组件的唯一标识程序集，它们可以被用来作为一个代码保护工具。他们简单地相信，如果组件被篡改，它将无法加载CLR的运行时引擎。这一切都是真实的，但，他们没有意识到，强名称组件没有被设计作为一个防篡改设备。因此，并不奇怪，张女士删除一些MSIL指令，可以改变一个强命名程序集，以同样的方式，在上一节所示。

回过头来的’MyPreciousApp例如，我们可以看到，它已被赋予一个强名称。这是显而易见的。公钥属性如下图所示。从MSIL代码删除这个属性和重建使用ILASM工具装配打破集的强名称，实际上它指定为私有程序集。打破所有组件属于上述结果相同的方式描绘在一个程序中的应用程序，是完全处于弱势逆向工程攻击。

混淆和它的缺点

，今天在同行业中是一种流行的代码保护技术，代码混淆。代码混淆器变换成一个应用程序，它的功能是相同的，但更难理解。这是通过有意义的符号名称命名，如变量，字段和方法名非有意义的。代码块重新排列，从而使其更难推断程序逻辑。

虽然代码混淆器理解程序的逻辑，提高了吧，他们有一些重大缺点。首先，他们不重命名的公共方法名称，因为这种方法可以调用其他组件引用混淆组件。这意味着可以很容易地追踪组件间调用时，看着MSIL代码混淆组件，因为原来的方法的名字都在使用。下面的例子说明，正是：

混淆代码清楚地表明，System.Windows.Forms的组件是由外部调用的主要方法。由于许多程序依赖于外部库组件来管理授权和认证，此故障是主要的。通过简单的MSIL代码，这些调用可以截获和删除。

第二个缺点是混淆工具引入时使用反射的问题。通过使用反射进行方法调用可能失败，一旦应用程序已经看不到。这种情况发生混淆，但由于该方法已被重新命名呼叫的站点仍然是指方法，其原来的名称。

当然，许多混淆器允许用户来定义，应该不被更名为它的方法，但是这引发的开销研发团队以及QA团队，现在有应付由于混淆代码引入的错误。

第三个缺点是跟踪错误的能力，一旦他们从外地报道。堆栈转储信息的能力恢复通过的System.Exception.StackTrace方法的使用是必不可少的跟踪源的错误，一旦应用程序已部署。试想一下，一个用户向您发送一个bug报告，说他有问题，使用您的应用程序。堆栈转储信息如下：

System.NullReferenceException：对象引用未设置AA object.at（）（AB）在AC（）广告（AA）的一个实例（对象A_0，EventArgs的A_1）System.Windows.Forms.Control.OnClick （EventArgs五）

 

这告诉知之甚少问题的根源，并且可以使研发在这种情况下，低迷的响应。

基于代码加密解决方案

MSIL的知名度，以限制的窥视，从逆向工程的代码，代码的加密技术是用来防止潜在的黑客。代码加密使用的标准加密算法，密MSIL代码，从而使它完全不可读的人类或反汇编。在这方面，混淆技术功亏一篑相比，代码的加密技术。

ILDASM或其他反汇编的组装不能转储的内容，仅仅是因为它不再包含MSIL指令。你可能会奇怪，现在怎么来的CLR读取装配的内容，并将其编译到本地汇编指令，因为该组件不包含任何MSIL指令？“。

答案很简单，因为CLR引擎无法应付编码版本的代码，它有被破译它之前，它被解释。这就提出了一个重要的问题，许多加密代码保护工具，我一直在努力未能实现。一旦代码被破译，它完全暴露在内存中的一个潜在的黑客窥探，其MSIL形式，因为整个程序集加载到内存中。这构成了安全威胁，因为一旦程序集加载在内存中，它可以被转储到一个文件中，使用标准内存转储工具。

实际上，你可以建立你自己的内存转储工具，使用一些Win32 API函数。首先，你必须获取进程句柄，这是可以做到使用OpenProcess API函数：

HANDLE ph = OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, processId);

“OpenProcess”过程访问权限和进程ID，返回值作为进程句柄。现在，你有你想的内容转储到一个文件来访问特定的组装。由于过程可能加载多个程序集，我们使用“ EnumProcessModules 'API函数来获取由进程加载的所有图像处理模块。

HMODULE modules[1000];DWORD nModules;
EnumProcessModules(procHndl, (HMODULE*)&modules, 1000*sizeof(HMODULE), &nModules);

然后，你必须确定具体的汇编文件，您感兴趣的' GetModuleFileNameEx '与' GetModuleInformation '可以用来识别该文件，并检索其内存位置。

GetModuleFileNameEx(ph, modules[0], (LPTSTR)&fileName, MAXFILENAME);

所有剩下来完成此过程的是阅读组装内容。要做到这一点，我们使用' ReadProcessMemory '：

ReadProcessMemory(ph, lpAssemblyBaseAddress, destBuffer, dwBytesToRead, &dwBytesRead);

，ReadProcessMemory需要组装基地地址检索使用’ GetModuleInformation和一个缓冲的内存写入。

所描述的过程表明，在任何时候都保持MSIL代码的编码形式是维持一个可靠的防篡改解决方案的关键。从倾销程序集的内容，使用这项技术，我在上面已经说明，这限制了潜在的黑客。在任何时候都保持MSIL代码保护是什么在SecureTeam的家伙已经工作了相当长的一段时间。