Are you confusing your commercial java code?

Question

Interestingly, does anyone use commercial / free java obfuscators on their own commercial product. I only know about one project that actually had an obfuscation phase at the ant build stage for releases.

Are you confusing? And if so, why are you confusing?

Is this really a way to protect the code or is it just the best feeling for developers / managers?

edit: Okay, I’m definitely talking about my point: are you confusing to protect your IP (your algorithms, the work that you put into your product)? I will not confuse for security reasons, this is not so. Therefore, I am only talking about protecting your application code from competitors.

@staffan has a good point:

The reason to avoid code chaining is that some of these changes prevent the JVM from optimizing the code efficiently. In fact, it will actually degrade the performance of your application.

Answer 1

If you are doing obfuscation, stay away from obfuscators that modify code, changing the flow of code and / or adding exception blocks, etc., to make it difficult to disassemble it. To make the code unreadable, usually just changing all the names of methods, fields, and classes is enough.

The reason to avoid changing the code stream is because some of these changes prevent the JVM from optimizing the code efficiently. In fact, it will actually degrade the performance of your application.

Answer 2

I think that the old (classic) way of obfuscation is gradually losing its relevance. Because in most cases, classic obfuscators break the stack trace (this is not good for supporting your clients)

Currently, the main task is not to protect some algorithms, but to protect confidential data: logins / passwords / API keys, the code that is responsible for licensing (piracy is still here, especially in Western Europe, Russia, Asia, IMHO), advertising account Identifiers, etc.

Interesting fact: we have all this important data in Strings. In fact, Strings represents about 50-80% of the logic of our applications. It seems to me that the future of obfuscation is "string encryption tools."

But now the function "String encryption" is available only in commercial obfuscators, such as: Allatori , Zelix KlassMaster , Smokescreen , Stringer Java Obfuscation Toolkit , DashO .

NB I am the CEO of Licel. Developer Stringer Java Obfuscator.

Answer 3

I am using proguard to develop JavaME. This not only helps reduce the size of jar (Essential for mobile) files very well, but is also useful as the best way to make device-specific code without resorting to unfriendly IDE preprocessing tools such as an antenna.

eg.

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"); } } 

This compiles, obfuscates, and the class file ends as if you wrote:

 public void doSomething() { System.out.println("This is a motorola phone"); } 

Thus, you can have code variants for working with manufacturer errors in JVM / library implementations without adding final executable files.

I believe that some commercial obfuscators can also combine class files in certain cases. This is useful because the more classes you have, the greater the amount of overhead in your zip (jar) file.

Answer 4

I spent some time this year testing various Java obfuscators, and I found that one run ahead of the rest: JBCO . Unfortunately, it is a little cumbersome and does not have a graphical interface, but in terms of the level of obfuscation that it produces, it has no equal. You try to feed it with a simple loop, and if your decompiler does not crash, trying to load it, you will see something like this:

  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; } } } } 

You did not know that Java has goto? Well, the JVM supports them =)

Answer 5

I use ProGuard and highly recommend it. Although obfuscation protects your code from accidental intruders, the main advantage is the minimizing effect of removing unused classes and methods and reducing all identifiers to 1 or 2 characters.

Answer 6

I think that for the most part, obfuscation is pointless: even with the full source code, it is usually complicated enough to find out what the intent is (provided that there are no comments and there are no meaningful names for local variables - this is the case when regenerating sources from byte code). Obfuscation simply decorates the cake.

I think that developers and especially their managers tend to greatly exaggerate the risk that someone will see the source code. While good decompilers can create beautiful looking source code, it isn’t trivial to work with it, and the associated costs (not to mention legal risks) are high enough so that this approach is rarely useful. I just decompiled to debug problems with closed source vendor products (deadlocks in DB abstraction layer, ugh). I think the bytecode was actually confusing, but we still found the main problem - it was the actual design problem.

Answer 7

I think it really comes down to what your Java code is for, how it is distributed, and who your customers are. We do not scare anything, since we never found that which was especially good, and this, as a rule, is more of a problem than worth it. If someone has access to our JAR files and has knowledge that can sniff them inside, then there are much more disturbing things they can do than rip off our source code.