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.
Related
I make a program in Netbeans but I want my program files locked because I not want that any one can read or copy the source. How can I lock the files?
thank!
This is a very very broad question, but i'll try to help a little bit.
The best thing you could probably do for something written in java is called 'obfuscation', which means that your code is still readable, just very jumbled and very difficult to understand to a human
"Locking" files on a JVM language is an uphill battle that you probably won't ever win, if someone really really wants to see your source code and edit it, they can, it will just take some time, this actually applies to any language really, to be honest. No matter what you do, if someone is smart enough and really wants to edit your program, they can and will find a way, the best you can do is try to make it as hard as possible for them.
That being said, a decent obfuscator is enough to make most people look at your project and decide it probably isn't worth their time to manually deobfuscate it.
Is there any open-sourced compilers for Java that able to produce bytecode-less output? I'm selling a Java application and I it to stop people from reverse engineering my program and giving it away for free.
There are ways to make java code hard to reverse engineer such as code obfuscators like ProGuard but that won't stop someone from giving it away for free.
To stop people from giving it away you need to use some kind of serial key that is assigned to each customer. At least that way if they give it away you know who did it.
If it runs on a computer, it can be reverse engineered. What you need is to use obfuscation. This way, your code will be harder to reproduce, because the logic in the obfuscated code is much more complex, than the code you originally wrote.
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 have an issue here..and its making me really nervous.
I was working on this game, and it was going great, so I took a copy of it on my laptop to work do some work while away from my computer.
long story short, hard-drive failure + poor back ups led to me losing a very important class.
Is there a way to decompile the apk to retrieve the bit of code that was lost? It isn't overly complicated or sophisticated, its just that its impossible to re-write it without reading every. single. line. of. code. in the entire application since it initializes a LOT of classes and loads a bunch of stuff in a specific way.
With a quick google search I was able to find apktool, which decompiles it into a bunch of .smali files, which I don't think were designed for human reading.
All I need to recover is one very big method in the class. I found the smali file that contains it and I think I found the line where it starts. something like
.method public declared-synchronized load(Lcom/X/X/game/X;)I
Anyone help would be appreciated since I would have to scrap the entire game without this method.
A quick google resulted in a way to decompile apks (decompile apk to java source). However, even though it results in java code, you probably won't have any variable names (just default ones like param1) as those are unrecoverably removed when you compile the source code to byte code, also, depending on the decompiler, for/foreach loops will be while loops instead, if/else blocks might not represent your original control flow due to compiler optimization.
As a general advise: Use some sort of source control. On your own server, paid account with github doesn't matter what, but use source control. Even if you are just one person developing on a project. It helps with this situation, it helps with reverting to a previous version, it helps finding a bug you introduced. When the tools are available, use them.
I know about class/jar executable format. But jar/class can not ensure source security, because java source code(.java) can retrieve from it. I am looking for such a format where source are secure/un-retrievable.
You can't make code secure from reverse engineering. If one has permission to execute it, then it can be examined where it can be disassembled, reverse compiled, or matched against known assemblies.
If your computer can run it, then you can reverse-engineer it. There is no way to avoid this. The best you can hope for is to stop casual cracking by (for example) passing your source through an obfuscater before compiling.
IBM did this with their type-4 JDBC drivers and it makes it hellishly difficult to understand what's going on (right up until the point you write a program that can de-obfuscate it although you still need to add information back in like function and variable names, no easy task).
Security through obscurity never works against a determined foe. This is the same as with physical security. You can put as much security in your house as you like, and that will prevent casual break-ins, but it will not stop a determined burglar.
I would rather concentrate on doing what I do best, providing top-notch quality software. Most attempts to secure code (beyond simple obfuscation) almost always disadvantages your real customers more than your attackers. Is your code really so precious that you want to risk that?