0

我想避免我的程序简单地删除许可证验证器部分。

我不想使用商业混淆器，因为：

  1. 的成本。虽然他们可以比我做得更好——他们也不会让它变得不可能破解，只是更难。
  2. 似乎有时混淆器会在生成的代码中导致错误。

显然，我将保留一份未混淆的副本以进行维护。

4

3 回答 3

2

我曾经不得不在客户可以修改的代码中隐藏一个许可证验证器。可以想象，如果他们知道去哪里看，他们本可以将其移除。以下是我当时使用的一些技巧。

  1. 为您的验证器类、程序集名称和变量名称提供看起来像是它们实际上在做其他事情的名称。
  2. 从代码的多个部分调用验证器。
  3. 向验证调用添加随机化器，以便有时运行，有时不运行。这将使我们更难知道验证码的实际来源。

我应该补充一点，所有这些都是可以解决的，并且可能会导致严重的维护问题，但在我的特定场景中它确实有效。

于 2012-04-18T15:51:52.380 回答
1

如果您的意图是让它变得更难，但并非不可能，一种方法是让多个代码点检查您的许可证文件是否有效。

假设您有一个带有一些密钥的许可证文件，如下所示

abc-def-fhi-asdf

所以，关键的四个部分。然后，我们将创建四种不同的方法来检查密钥的各个部分。

通过这样做，并通过代码改变使用的方法（理想情况下，在运行时随机选择验证方法），您使删除验证变得更加困难。

最重要的是，一种方法是有一个发布过程来内联您的验证方法，每次调用它时都会巧妙地改变它。

例如这样的：

*user clicks a common function
// [VALIDATION STUB]
*perform user action

新的发布过程贯穿代码，拉出 // [VALIDATION STUB] 并将其替换为您的验证代码（在代码编译之前），正如我所说的，每次都应该尽可能地变化。

从我的回答中得出的主要结论是，混淆很难，但并非不可能。尤其是如果您接受恶意用户最终总会破坏它的现实

于 2012-04-18T15:52:08.667 回答
0

我有一些你可能会觉得有用的建议。

首先，您当然可以使用免费的混淆器，例如 VisualStudio 附带的混淆器。总比没有好。

其次，您可以编写您的许可证验证代码，一旦它工作正常，尽可能重构它，将类名、成员变量、局部变量和方法更改为 c1、v1、l1、m1 等。这基本上就是混淆器所做的。

第三，做到以上所有。

第四，用非托管代码（C++、Delphi）编写您的许可证验证，并将其命名为重要的 DLL，例如 core.dll、net.dll 等。您还可以在其中放置一些无用的诱饵方法。从代码的多个位置对该 DLL 进行多次调用，并假装您对这些调用的结果做了一些事情。

于 2012-04-18T21:44:38.757 回答