Question

您在混淆人群的设计中使用过哪些常见做法？我发现在不允许重写的项目上很有意思，这将是解决问题的更快，更有效的解决方案。

Answer 1

我的收藏总是围绕变量......在代码中留下不再使用的变量，然后给它们所有无意义的名字。当然，如果你真的想要混淆，你必须小心避免几乎所有的约定。因此，一个完美的变量就是有两个类似的变量，一个名为myVar1，另一个名为myVarOne。这样的东西......

另一个是包含仅在代码中可见的未使用的控件。我盯着一个ASP.NET站点一小段时间试图找出为什么将FormView放入其中..（没有答案）。

Answer 2

我曾经在perl代码上工作，其中作者决定让大多数sub接收单个哈希作为变量，并返回相同的哈希，添加或删除数据。基本上一个全局哈希用于通过不同的代码路径传递数据。

它看起来像这样：

my $hash = ();

$hash->{'CUSTID'} = 1001;
$hash = GetAccounts($hash);

if ($hash->{'AccountTotal'} > 100) {
    $hash = getTotals($hash);
    $hash->{'Acct_Sbkt_Marker'} = 'R1';
    $hash->{'Acct_Invr_Marker'} = 'BT';
    $hash = removeInvalidAccount($hash);
}

到目前为止，我无法弄清楚他试图用这种方式实现的设计模式。

我记得$hash排得很好。

Answer 3

我们有一个人在文件夹调用/ kensington中使用商店文件来“隐藏”它们。它只包含一些他不想看到的xml文件，并且认为人们不会在那里查看。

Answer 4

代码中没有或无用的注释以及没有有用的文档。

Answer 5

我曾经和一个程序员一起工作，这个程序员曾经写过非常复杂的条件，当遇到这些条件时会调用一个简单地执行系统的方法。他在整个应用程序中做了这么多次。仍然不确定为什么......

Answer 6

在那里，我认为精心设计的代码应该独立存在才能被阅读，而不是被破译。

我知道，关心混淆的人会被鼓励使用像dotfuscator这样的工具及其在其他环境中的等价物。混淆意味着使代码更难以反编译，而不仅仅是让它变得很麻烦。

为什么有人故意设计可怕的代码（除了证明陷阱）是超出我的。

混淆实践的常见设计？

6 个答案: