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
Related
From what I understand, obfuscating a java web application will just make it a little harder to read your application, but reverse engineering is still possible.
My goal is just to make it very difficult to read, and not be able to decompile and run (not sure if that's possible, I guess it will still run just with ugly variable names??)
So variable names like:
String username = "asdfsadf";
will become
String aw34Asdf234jkasdjl_asdf2343 = "asdfsdaf";
Is this correct:
public classes and variables will remain unchanged
ONLY private strings/classes/methods can be renamed
string encrytion can be used for some sensitive string data like encryption keys etc.
Really my goal is so that someone can't just decompile and release the code.
Web applications run server side. Clients will not see the code unless you mess things up.
There are plenty of good Java obfuscators which will do what you say, and much more. Here are some from google:
ProGuard
yGuard
JODE
Although these will make it much more difficult to read the decompiled code (and some decompilers will refuse to even try), keep in mind that it is always possible for someone to reverse-engineer the code if they have the binary, and are knowledgeable and patient enough.
The problem here is that the code needs to be in proper java syntax when you compile it. So no matter what obfustication you applied, if I have access to even just the bytecode I can figure out a way to reconstruct the source.
(http://www.program-transformation.org/Transform/JavaDecompilers#Java_Bytecode_Decompilers)
What you would need to do is keep the proprietary part of the software in such a place that your pirates would not be able to see it. As far as I am aware, that is the ONLY way to avoid hijacking your software.
You cannot prevent java code from being decompiled and run. Even if it is obfuscated, there may be people out there that are still able to figure out what your code is doing, despite the obfuscation. Everything you publish can be reverse engineered.
There exist even much stronger efforts in other languages to prevent decompiling and debugging, disk copy protection solutions for example, and even they get reverse engineered and hacked frequently.
If you don't want people to reverse engineer your code, let it run server side only, don't publish it and try to harden the server as much as possible.
http://www.excelsior-usa.com/protect-java-web-applications.html
Disclaimer: I work for Excelsior.
http://www.arxan.com/products/server/guardit-for-java/
Disclaimer: I don't work for Arxan.
No amount of obfuscation can protect you against "decompile & compile again" (without trying to understand what the code does). Decompilers don't care for unreadable variable names, nor do compilers.
Incidentally, if someone has access to your code, they don't need to decompile it to use it.
So the question is really: What do you want to achieve? When you know that then you can go to the next question: How much does it cost and how much money can I earn?
Usually, that equation is: You can't save/earn any money from obfuscation but doing it costs you time and money (good obfuscators aren't free). So it's a negative ROI.
Instead, try this approach: Create a great product (so people will feel it's justified to pay for it), fix bugs quickly (-> the thieves have to steal your work again and again just to keep up), add new features. That way, honest consumers have reason to buy from you.
If you plan to get money from thieves and criminals, well, forget it. They don't want to pay you, no matter what. You can make their lives a little bit harder but at a cost.
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.
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.
I work for a government contractor that is really picky about what software gets installed on their machines (US government laws). As part of a reverse engineering effort, I need to figure out what a certain set of .class files do. A decompiler would be really helpful, but I can't seem to find one that meets the standards set here. Basically, I need to find a decompiler that was developed in the United States. Anyone know of any? Free is preferred, but commercial will do.
FYI, JAD and JD are out as they are not developed in the US.
I'd inform your employer that putting preconditions on where the software comes from isn't going to protect them, and it's not going to get them what they want. The U.S. competes in a global economy and in the global internet. It sounds a little childish of them to think that they gain any advantage or security from not installing software that works. Part of being a good employee, designer, or programmer is helping your client realize their limitations and overcome them. You should help them to greater success.
What about installing "unapproved" software on a VM?
It scares me when I hear this type of nonsense eminating from my own government.
Run jad -p, recompile the source and compare the compiled class with the origional class file.
You can run jad on a throwaway computer/VM instance. If there is reasonable agreement on the compiled class you know the software functioned properly.
I figured that I should answer this since nothing provided worked. I ended up solving the requirements by using javap, guessing a lot, and banging my head against the desk until it worked. javap didn't give me much of what I needed, since it called a lot of native code. Eventually, I got what I needed using the tried and true guess and check method.
There really needs to be a decompiler. Maybe Sun (Oracle) can make one...
I'm assuming that you can't move the .class files off of the machine and on to a lab machine where you can install JAD?
I work with the government as well and if a particular piece of software is critical to the success of your project, you need to communicate that to your PM, who will then communicate that to his or her government counterpart. After that, there should be a checklist for your IA assessors to follow to approve that piece of software.
Procyon is all-American, it is developed by Mike Strobel. According to Mike's profile page, he is in Manhattan.
I assume that it's legal for you to be decompiling them in the first place, right? Most user-agreements I've read state that you aren't allowed to reverse engineer anything... Assuming it's legal, how come JAD and JD are out?
I've had success with DJ Java Decompiler, though it's not nearly as pretty as JD. There's also SoThink Java Decompiler, but I've never used it personally.
There are several others, but most of them seem to be built upon JAD, so I guess they're out too.
I once used cavaj (freeware), but I don't know whether it is made in the US.
mmmh pretty ironic, you cant use a decompiler because the decompiler isent made in the US but you can decompile code nevertheless ?
If you need to know what a class does then ask the people that created it for the source
If they refuse to give the source then i dont think its legal to decompile it anyway
Here's an idea, can you send the files to someone else to decompile and then just send you the decompiled source?