I' looking for a java obfuscator that will at a minimum rename all private method names, inner method variables such that reading the source code and decompiling a jar will make it unfriendly to do so.
I realize it isn't that hard to get algorithm knowledge etc., I just want it to be a pain to decompile and thus maintain the decompiled code.
The goal is to prevent someone from decompiling the source and simply using it w/o having to do any work. I don't care if they can figure out my algorithms etc., I just don't want it to be super easy where they can just decompile the .jar and add the 100% visible and readable source code into their project.
Suggestions?
ProGuard is what I use.
http://proguard.sourceforge.net/
has a nice easy to use GUI or can be implemented into ant scripts. Also offers optimization and some other nice features.
Obfuscation is not your only option. See my article "Protect Your Java Code - Through Obfuscators and Beyond". If nothing else, you will find there links to actively maintained obfuscators.
Related
How do I create a .jar file that does not allow others to decompile it and get my source code? Is this even possible without having to encrypt it then decrypt it when it loads in the JVM? To the point, I don't want others to steal my program.
You could obfuscate your code with ProGuard (http://proguard.sourceforge.net) or similar tools. It won't give you great protection tho, but makes it harder to understand the code if someone decompiles it.
Obfuscation is what you're looking for.
For free obfuscators, there's ProGuard.
http://proguard.sourceforge.net/
It gets the job done, but it's still pretty easy to read the source unless you mess with the settings a bit. For example, you could have it obfuscate the classes and methods to be incredibly long names, but that can always just be obfuscated over with ProGuard again with default settings to make the class names short again.
If you're willing to spend some money, Allatori and ZKM are great (but very expensive!).
http://www.allatori.com/price.html
http://www.zelix.com/klassmaster/order.html
Allatori is probably my favorite, but I think ProGuard would work fine if you spend some time to mess with the settings.
Better than obfuscation is the encryption of the classfiles, so the classfiles are no more readable for a decompiler.
JarProtector: http://bfa-it.com/?lang=en&id=products/jarprotector
ClassGuard: https://www.zenofx.com/classguard
Java Antidecompiler: https://marketplace.eclipse.org/content/java-antidecompiler
Now, I know that...
Anything can be reverse engineered, given enough time and resources.
However, would compiling your Java code to native code with a tool like GCJ make it more difficult to decompile? I mean, given a few minutes, I can decompile a .jar using JD-GUI, and it is relatively accurate. Most of the "Java to EXE" converters are just .exe launchers for the JVM, and while there are many benefits to the JVM, I have been led to believe that security of the source code is not one of them.
Bottom line: Can you use something like GCJ to compile your Java source (or .class) files to native machine code, and if so, will that protect it from decompiling?
EDIT: Ideally, it would be something more than just obfuscation. The specific project is a commercial game, so what we are looking for is a way to make it more difficult to get to the source code to begin with, not just understand it. Also, I'm not sure that Steam accepts .jars, and we are planning on submitting it to the new Green Light project.
I wouldn't choose that approach just for source-security.
Check out some Obfuscator tools out there like ProGuard
If you want to see what those tools do to your source code, just try read the decompiled Minecraft jar if you have one on hand.
A downside to using this is, that if your code depends on using reflection, you'll have to configure the tools to ignore those functions/classes/whatever, as those will not be found at runtime otherwise.
Technically, yes. Using something like GCJ will make it harder to decompile, however keep in mind that you are losing some major benefits of using Java if you do this. Namely, you lose the ability to write cross-platform applications.
You could use an obfuscator to make the code harder to decompile AND still keep the benefits of using Java.
a Source code obfuscator like
this , this and this
makes your variables, functions, etc... unreadable by other(has no logical meaning). You should read here too!
I don't want my class to be decompiled.
I have gone through some of the articles and found a patent site
Zelix KlassMaster
Is there any free tools available in the market which works in the similar way..
As far as I know there are no free tools with the same set of functions.
In my opinion the mix between ProGuard and Stringer Java Obfuscator is the best and also most cheap way to protect Java and Android applications.
N.B. I'm CEO at Licel LLC. Developer of Stringer Java Obfuscator.
Proguard is the best available free and open source obfuscator. Obfuscators jumble your class, field and method names so that it becomes difficult to make sense out of the decompiled code.
Zelix Klassmaster is a commercial obfuscator and is one of the best in the commercial space. Also, it has some additional feature to encrypt the string constants to that the strings arent visible when decompiled. There are also some other commercial tools like yguard, DashO-pro, Allatori and Smokescreen etc.
You can obfuscate your code, so that when it de compiles it isn't easy to read (for programmer)
You can't specifically stop it being decompiled. After all, a decompiler only has to be able to read the byte code to turn it into source code, and reading the byte code is also what the JVM has to do. So if you were to come up with some way to prevent programs from reading the byte code, the JVM wouldn't be able to run your class.
As others have pointed out, obfuscation is the way to go if you REALLY need to do this, but I would question whether you really do need to. It's also worth pointing out that if you do use obfuscation, finding bugs will be much harder because stack traces will also be obfuscated.
Obfuscation is certainly a way to protect your code. Also, there are other tools which encrypt your classes and provide a custom classloader which can decrypt and load your class at runtime. This is not a very foolproof way but yes there are tools doing that.
You can't prevent a java class from beeing decompiled. However, you can make the life of someone who will try to understand your code very very hard. This is the task of a so called obfuscator, like KlassMaster.
Please see this list for Open Source obfuscators.
Please see also one of my questions: https://stackoverflow.com/questions/1872170/how-to-protect-intellectual-property-in-java-app
Unfortunately in Java like in JavaScript getting to the source code is easy.
Understanding it is another thing.
If you try hard enough and send date through dozens of functions each doing a small part and passing it along then obfuscating it and maybe add some fake functions you might just give enough head eke to those with ill intentions enough of a head eke that they will quit before succeeding.
I'm using Zelix Klassmaster for my app Visual Watermark for about two years now. No new program "cracks" were released since then. So, it seems a good option for protecting Java apps.
Ok I'm kinda in a predicament right now.
I have a java program that I have split into a core/outside sections.
I collated my core into a java library that the outside code (which will be publicly released) can reference.
However, I do not want the contents of this java library to be decompilable.
So I went to find a good java obfuscator.
What complicates my situation is the fact that my java library isn't exactly modular - it references/changes state of outside code (yes it's terrible but whatever)
I've tried demos of all premium obfuscators (ZKM, allatori, etc) and free ones, but they either
have very weak control flow obfuscation which is what I need
halt because of references to java library's/dependencies that are not in the jar itself but are still referenced.
Any advice?
Obfuscation does not prevent decompilation. It can always be decompiled. It just make help making your code less readable afterwards. Obfuscate only your logic, keep interfaces untouched.
If there are no obfuscators that have control flow obfuscation which meet your standards, then you will have to write your own obfuscator or submit a request to an existing vendor to improve their product.
Run both the external and internal parts of the program through the obfuscator, together at the same time. But write exclude rules for all of the external code. You should also write exclude rules for the public API of your internal code. If you don't have a public API layer on your internal code, then you are going to have a hard time, because your external code will have to refer to your internal code by obfuscated names, which will make for very unmaintainable and hard to read external source code.
I second ahanin's comment.
But, if you're looking for an obfuscator, a good one that has a pretty robust rule set is Proguard. Its used heavily in the Android space where code needs to be made as minimal (small) as posible.
Link: Proguard
I am looking for a java obfuscator with maven-plugin support? We tried using ProGuard but we ran into some runtime issues which doesn't happen if you don't obfuscate. Are there any alternate obfuscators.
Since ProGuard operates in a manner similar to most other Java obfuscators (at least the ones that I'm familiar with), it's pretty likely that you'll run into similar problems. (In fact, ProGuard goes out of its way to emit compliant bytecode, while some other obfuscators are rumored to be less vigilant about this.)
What sort of problems were you having? Typically the issues with using obfuscation are with name mangling - running into problems with other libraries being unable to locate public classes / methods / fields, or problems using reflection. This is often solveable by being very careful about which class names and method names you allow to be mangled.
The last time I used obfuscation on a Java project, we were fairly conservative about what was obfuscated. We placed the classes we wanted obfuscated into a subpackage of their original package called 'internal', and we obfuscated only .internal.. We found this much more usable than trying to determine what not to obfuscate.
Another issue with obfuscators is their optimization. Although I've not seen bugs from optimization in ProGuard, it's certainly not impossible. Regardless, I turn this off for a few reasons: first, when you get an (obfuscated) stack trace for a customer, it's hard enough to unmangle the names to determine what went wrong. If your obfuscator has optimized anything, that stack trace is likely meaningless. Second, it's unnecessary: the JVM is very, very good at optimizing byte code and this is interfering with that (thus potentially making it worse.)
Stringer Java Obfuscation Toolkit has a great set of options for integration with the IDE and build system, including Maven.
Several years ago, I had similar problem than you.
If I remember correctly ProGuard did optimize short private method wrongly:
It did dissmiss effects of "synchronized" keyworld of method during inlining.
We fix this problem by using -dontoptimize option of ProGuard.