java商用_混淆-您是否混淆了商业Java代码？

混淆-您是否混淆了商业Java代码？

我想知道是否有人在自己的商业产品上使用了商业/免费的Java混淆器。 我只知道一个项目在发布的ant构建步骤中实际上具有混淆步骤。

你会混淆吗？ 如果是这样，为什么还要混淆？

这真的是保护代码的一种方法，还是对开发人员/管理人员来说是一种更好的感觉？

编辑：好的，我的意思是确切的：您是否为保护IP(您的算法，产品中投入的工作)而感到困惑？ 我不会因为安全原因而感到困惑，这感觉不对。 因此，我只是在谈论保护您的应用程序代码不受竞争对手的攻击。

@staffan有一个好处：

避免链接代码流的原因是，其中一些更改使JVM无法有效地优化代码。 实际上，它实际上会降低应用程序的性能。

cringe asked 2020-02-01T21:20:11Z

7个解决方案

60 votes

如果进行混淆处理，请远离混淆器，这些混淆器会通过更改代码流和/或添加异常块来修改代码，从而使它们难以反汇编。 为了使代码不可读，通常只需更改方法，字段和类的所有名称即可。

避免更改代码流的原因是，其中一些更改使JVM无法有效地优化代码。 实际上，它实际上会降低应用程序的性能。

staffan answered 2020-02-01T21:24:47Z

25 votes

我认为这种古老的(经典的)混淆方式正在逐渐失去其意义。 因为在大多数情况下，经典的混淆器破坏了堆栈跟踪(不利于支持客户)

如今，重点不是保护某些算法，而是保护敏感数据：API登录名/密码/密钥，负责许可的代码(盗版仍在这里，尤其是西欧，俄罗斯，亚洲，恕我直言)，广告帐户ID等 。

有趣的事实：我们在Strings中拥有所有这些敏感数据。 实际上，字符串大约占我们应用程序逻辑的50-80％。在我看来，混淆的未来是“字符串加密工具”。

但是现在，“字符串加密”功能仅在商业混淆器中可用，例如：Allatori，Zelix KlassMaster，Smokescreen，Stringer Java混淆工具包，DashO。

N.B.我是Licel LLC的首席执行官。 Stringer Java Obfuscator的开发人员。

Ivan Kinash answered 2020-02-01T21:25:27Z

17 votes

我将proguard用于JavaME开发。 它不仅非常擅长使jar文件更小(对于移动设备必不可少)，而且还可以作为一种更好的方式来执行特定于设备的代码，而无需求助于IDE等不友好的预处理工具，例如天线。

例如。

public void doSomething()

{

/* Generated config class containing static finals: */

if (Configuration.ISMOTOROLA)

{

System.out.println("This is a motorola phone");

}

else

{

System.out.println("This is not a motorola phone");

}

}

这将被编译，混淆，并且类文件最终就像您编写的那样结束：

public void doSomething()

{

System.out.println("This is a motorola phone");

}

因此，您可以使用多种代码来解决JVM /库实现中的制造商错误，而无需扩展最终的可执行类文件。

我相信有些商业混淆器在某些情况下也可以将类文件合并在一起。 这很有用，因为您拥有的类越多，zip(jar)文件中的开销就越大。

izb answered 2020-02-01T21:26:05Z

13 votes

我今年花了一些时间尝试各种Java混淆器，而我发现其中的一个比其他混淆器要先进得多：JBCO。 遗憾的是，它设置起来有点麻烦，并且没有GUI，但是就其产生的混淆程度而言，它是无与伦比的。 您尝试将其馈入一个简单的循环，并且如果您的反编译器在尝试加载它时不会崩溃，则会看到以下内容：

if(i < ll1) goto _L6; else goto _L5

_L5:

char ac[] = run(stop(lI1l));

l7 = (long)ac.length << 32 & 0xffffffff00000000L ^ l7 & 0xffffffffL;

if((int)((l7 & 0xffffffff00000000L) >> 32) != $5$)

{

l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL;

} else

{

for(l3 = (long)III & 0xffffffffL ^ l3 & 0xffffffff00000000L; (int)(l3 & 0xffffffffL) < ll1; l3 = (long)(S$$ + (int)(l3 & 0xffffffffL)) ^ l3 & 0xffffffff00000000L)

{

for(int j = III; j < ll1; j++)

{

l2 = (long)actionevent[j][(int)(l3 & 0xffffffffL)] & 65535L ^ l2 & 0xffffffffffff0000L;

l6 = (long)(j << -351) & 0xffffffffL ^ l6 & 0xffffffff00000000L;

l1 = (long)((int)(l6 & 0xffffffffL) + j) & 0xffffffffL ^ l1 & 0xffffffff00000000L;

l = (long)((int)(l1 & 0xffffffffL) + (int)(l3 & 0xffffffffL)) << 16 & 0xffffffff0000L ^ l & 0xffff00000000ffffL;

l = (long)ac[(int)((l & 0xffffffff0000L) >> 16)] & 65535L ^ l & 0xffffffffffff0000L;

if((char)(int)(l2 & 65535L) != (char)(int)(l & 65535L))

{

l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL;

}

}

}

}

您不知道Java拥有goto吗？ 好吧，JVM支持它们=)

adum answered 2020-02-01T21:26:30Z

13 votes

我使用ProGuard并强烈推荐它。 尽管混淆确实可以保护您的代码免受偶然攻击者的侵害，但其主要好处是可以最大程度地减少删除未使用的类和方法并将所有标识符缩短为1个或2个字符的影响。

Lawrence Dol answered 2020-02-01T21:26:50Z

12 votes

我认为在大多数情况下，混淆是没有意义的：即使使用完整的源代码，通常也很难弄清楚到底是什么意思(假设没有注释，并且没有局部变量的有意义的名称，当重新编译时就是这种情况) -从字节码生成源)。 混淆只是装饰蛋糕。

我认为开发人员，尤其是他们的经理往往会过度夸大有人看到源代码的风险。 虽然好的反编译器可以生成漂亮的源代码，但使用它并不是一件容易的事，并且相关的成本(更不用说法律风险)足够高，以致使这种方法很少有用。 我只是反编译用于调试闭源供应商产品的问题(数据库抽象层中的死锁，呃)。我认为字节码实际上是令人困惑的，但尽管如此，我们还是发现了潜在的问题-这是一个实际的设计问题。

StaxMan answered 2020-02-01T21:27:17Z

7 votes

我猜这真的取决于您的Java代码是什么，它如何分布以及您的客户是谁。 我们不会混淆任何事情，因为我们从来没有发现过特别出色的东西，而且它往往比它的价值还要麻烦。 如果某人可以访问我们的JAR文件，并且具有能够在其中进行嗅探的知识，那么与窃取我们的源代码相比，他们可以做的事情要多得多。

ninesided answered 2020-02-01T21:32:35Z