Best Java Obfuscator

Best Java obfuscator?

First, you really need to keep in mind that it's never impossible to reverse-engineer something. Everything is hackable. A smart developer using a smart IDE can already get far enough.

Well, you can find here a list. ProGuard is pretty good. I've used it myself, but only to "minify" Java code.

Do you obfuscate your commercial Java code?

If you do obfuscate, stay away from obfuscators that modify the code by changing code flow and/or adding exception blocks and such to make it hard to disassemble it. To make the code unreadable it is usually enough to just change all names of methods, fields and classes.

The reason to stay away from changing code flow is that some of those changes makes it impossible for the JVM to efficiently optimize the code. In effect it will actually degrade the performance of your application.

Is it safe obfuscating with opensource tools?

Obfuscation is security by obscurety; a way of securing that is frowned upon by security experts. Indeed as the commenters say, not shipping the code and keeping it behind a webservice is a better way of keeping the code private. I disagree that switching to an other language would help: a CPU will have to be able to execute your code, therefore with human effort your code canbe reverse engineered.

Obfuscated source or intermediated code can deter attackers that try to steal your code.

A code obfuscator can perform a varity of operations to obfuscate your target code. For most of these the obscurity of these does not have to come from obscurity of the obfuscator's code. Randomisation is a better way to make target code obscure.

An advantage of an opensource code obfuscator is that you can check that the obfuscator does what it is supposed to do.

Suppose you use a closed source (and ofcourse obfuscated) obfuscator from a source that you don't know or do not trust (or from a supposedly trustworthy source). How do you know that:

it doesn't install a backdoor into your software and turns it into Trojans?
it is written correctly and doesn't introduce subtle bugs or unintentionally expose your source?
it doesn't steal your unobfuscated code itself?

I know that the many eyes principle isn't as great in practise as some opensource advocates believe. But still its preferable to a proprietary obfuscator from an dubius supplier.

Java & Android Obfuscator Tool Suggestion

Proguard's (java and android, open source) sibling DexGuard (android, closed source) does string encryption.

See: https://www.guardsquare.com/en/dexguard

Let me also add that the proguard page also list a lot of other(!) obfuscators: https://www.guardsquare.com/en/proguard#alternatives.html

Best Java Obfuscation Application For Size Reduction

When it comes to J2ME and obfuscation it pays to be a bit cautious. Proguard is the best choice because of the many years it has been in development, and the many bugfixes that it has received. I remember the version transition between 2.X and 3.X and how it broke many of my (then) employer builds. This happened because some of the changes that enabled more size savings also broke the class files in subtle ways in some handsets, while being perfectly fine in others and on desktop JVMs.

Nowadays Proguard 3.11 is the safest choice in obfuscators. 4.XX is probably fine if you don't have to support very old handsets.

What is the best way to go about obfuscating Java code?

There are many obfuscators around, ProGuard is one well known example. Try searching for "java obfuscator", google finds enough hits on that.

Obfuscate a game in Java

First of all, sorry for the amount of text I wrote.

Secondly, I totally agree with the answer to the question you linked to:

Stay away from code-flow-altering "obfuscators".

(I'd call them "scramblers", but that would be a case for English.)

Thirdly, very strictly speaking, pure obfuscation (as in class & member renaming) usually generates much shorter names (see Minecraft with it's a, b, ...) than you chose, so because the class files are shorter, loading classes might be just a tiny bit faster, and because it takes less time to compare shorter strings, member lookups will be a tiny bit faster as well, maybe resulting in a tiny performance improvement on non-static method calls.

However, the improvement is most likely going to be negligible, and if the JVM does any form of lookup caching, I wouldn't expect any performance improvement at all.

However, with only class and member renaming, I wouldn't expect the performance to drop either.

As for whether it's gonna stop people from doing evil... maybe a little.

Very lazy programmers and newbies will certainly be scared away.

And then it depends on how much someone can gain by cracking your code.

If a hacker can personally gain something from cracking your game (i.e. speedhack), I'd say there's a much bigger chance of it happening than if it's a paid game that he can make run without a license or something.

And it also depends on how much code there is and how much you need to change.

If you have around 25 classes or less, I think for a somewhat advanced developer, it wouldn't really be hard.

But an application of the size of Minecraft is a different story.

But taking Minecraft as an example, I eventually learned to find my way through the obfuscated code, as the deobfuscation lists would take longer and longer to be generated after every release and I just wanted to keep my mods up-to-date.

Making a bold claim, I'd say for me it wouldn't be much harder to crack an obfuscated java application than to crack it non-obfuscated, and I'm certainly not the only one.

Also, some obfuscators choose names completely randomly, thus releasing an update might have totally different names.

One might think that would set hackers back, but once you have a rough idea of which class stands for what in one release, you can easily find that class again in the next one by searching for strings and imported classes or members of such, and from there you can make the connection to other obfuscated classes.

(For example, in Minecraft I always started with the crafting manager, because it had the unique "###" Strings, and since it heavily used blocks and items, I could find many class right away from there.)

But you actually have one thing truly on your side: name collision.

Again with Minecraft, I realised that some files couldn't just be compiled again - not due to invalid code generated by the decompiler, but simply because a was used as a class name and a field name, the field took precedence (otherwise I could've used a and this.a - note that this only works if your obfuscator removes the package and places all classes at the top level!), and so there was no way of referencing the class other than by reflection, which was what I ended up doing in some cases. In other cases (where performance was an issue), I created sort of a "fake" class with a different name that I could compile against, and then tampered with the generated bytecode to change the name back.

So while it is still possible, it certainly is a lot of effort to go through.

If I had to work around hundreds of collisions, I would most likely have given up pretty soon.

Also, I learned that, at least with Oracle's Java implementation, versions 6 to 8, "invalid" names in the bytecode don't seem to be a problem, at least not to some extent.

In one of my projects I needed to create bytecode at runtime and I needed the generated class to contain a method with a name that would not collide with any other method that class might contain, so my first try was to use an invalid character (*) as its name, it so far (it has been out for 2 years) I haven't received any error report about a JVM rejecting it.

I don't know if there's an obfuscator out there that supports invalid names, but with a such, you could certainly generate code that would not only look horrible when decompiled, but which would be not even anywhere near compilable.
I imagine something like

Some thing = field.method().whatever.array[index];

turning into:

! ? = &.%().+.*[/];

Looks neat, doesn't it? And I'm sure the compiler will love it. *evil grin*

(But even if it works, I can't recommend it, because it's just not really good practise.)

At that level, your code will still be crackable, but probably not a great deal more than machine code, so you should be sort of safe.

TL;DR

Stay away from code-flow-altering cruft.
Lots of classes = additional layer of obscurity.
Lots of classes = higher chance for name collision.
If the reward is high enough, someone will always crack it.

Obfuscate Strings in Java

Taking a look back at this question after almost 2 years, This question has gotten quite a lot of attention, I have found some obfuscators that I ended up using for String obfuscation but every Obfuscation can be broken. This is my List of obfuscators that encrypts Strings I will start of by listing paid obfuscators.

1. Zelix Klass Master

Their official website is https://zelix.com

This is one of the best java obfuscators for either jar or android in my opinion.
How ever It's not cheap as expected because of how good the obfuscator is.

A single license can cost you $239 If you are a small developer or $479 if you are a team of developer (Comapany).

You can see the list of features here

2. DexGuard

Their official website is https://www.guardsquare.com/en

DexGuard is an Obfuscator made by the people who are behind Proguard

This is the second best obfuscator in my opinion. The name obfuscation is way better then the name obfuscation on Zelix.

I am not sure about their pricing since I have never used it but I have seen it being used on applications. How ever you can request a pricing here

Free Obfuscators.

You can find free alternative's such as StringCare and Paranoid

They aren't as good as the one's I listed above, It would take at most 5 seconds for someone with basic knowledge of java to crack your program with these two tools.

Best Java Obfuscator