I am curious enough to considering not evening writing certain code in Java because of how easy it is to decompile. Is there a way that I can write in Java and not have to worry about decompilers? I understand anything can be reversed engineered given enough time, so what I am asking is: are Java class obfuscators effective enough to deterrent decompliation?
+2
A:
From personal experience decompiling Java, I will say that obfuscation can make someone's attempts to decompile very very irritating and difficult. The most irritating to me is when the final builds class files are all named "a.class, b.class, c.class" and so on, and a large amount of dummies are thrown in. In terms of in code obfuscation, try/catches do a fine job of messing stuff up for the decompiler.
In general, anything you decompile will not be compilable, but will give you hints as to the general workings of the program.
revenantphoenix
2010-02-11 03:32:05
Please note, you shouldn't do any obfuscation in your debug build, just in release builds! It's so hard to work with obfuscated code.
revenantphoenix
2010-02-11 03:33:04
+8
A:
are Java class obfuscators effective enough to deterrent decompliation?
I would say "no". When I decompile source code with the intent of trying to figure out how someone did something, I already know what I'm looking for. So I don't have to understand the entire program -- just the one piece that's of interest to me at the time. With enough puzzling over methods and backtracking a bit up the call chain, it's usually possible to determine what's under the hood without an excessive amount of effort.
John Feminella
2010-02-11 03:34:31
+1
A:
Frankly speaking No. No matter how ridiculously you obfuscate the code, if someone knows he can make a million dollar out of your code, he will decompile your class files and get the code.
There are alternatives though:
Convert your java program to exe beofre distributing. You must know that there are catches here.
Encrypt you class files with a key. Make a custom classloader that can decode the class files using the private key before loading it into memory. There are two problems here, a) load time increases, b) how will you hide the private key.
Suraj Chandran
2010-02-11 03:49:31
Neither of these will *really* prevent decompilation either - 1.) Just means they need to decompile the native executable to assembly - http://stackoverflow.com/questions/2244321/does-compilng-java-code-to-exe-e-g-using-launch4java-ensure-code-cannot-be-rev 2.) If a custom classloader can decrypt the class, they can just get it from the classloader - http://stackoverflow.com/questions/1175008/encrypting-war-files/1178074#1178074
Nate
2010-02-18 00:03:22
@nate...its easier said then done..1) in case of exe if decompiling native to assembly would have really helped then no code on earth would be safe 2) Not if only your classloader knows to the keys
Suraj Chandran
2010-02-18 01:47:21
@Suraj - did you even read the links? 1.) No code (that a user has direct access to) *is* "safe" from reverse engineering - any executable can be decompiled to assembly - and there are people that can program assembly as well as Java. 2.) Class encryption is useless, no matter the encryption scheme, because for a ClassLoader to work in a JVM, it has to provide the *unencrypted* class to the JVM through the defineClass() method - what's to stop someone from just using your ClassLoader to decrypt your classes for them, and them save them off unencrypted?
Nate
2010-02-18 02:58:43
@nate...as i said before..its easier said then done. don't read from here and there...do it, get success and then believe it.
Suraj Chandran
2010-02-18 05:08:06
@Suraj - 1.) I've seen decompilers decompile .exes to assembler - I don't know assembler well enough myself to do much with it, but I know people do. 2.) The article in the link provides a short example, plus just from the *required* ClassLoader and JVM spec, this won't work. I believe it, and it won't get success (well, depending on the definition of "success" - 1.) *does* make it much harder (but really just because more people understand Java than assembler) which may be "good enough" to be "success" - however 2.) is flawed no matter what. )
Nate
2010-02-18 11:55:04
A:
HI suraj,
Good answer. You can explain or tell us some suitable links where we can learn the above two methods.
Sreejesh
2010-02-11 03:53:33
Sreejesh, welcome to StackOverflow. If you have something to say about an answer that is posted you can do so my adding a comment to the answer. If you have something that helps to answer the question asked then post it as an answer.
sateesh
2010-02-11 04:14:39
+1
A:
None of the conventional methods (obfuscation, encrypting the bytecodes, compiling to an "exe") will stop a determined attacker with enough time and incentive.
The only way you can protect against a serious reverse engineering effort is to use a secure execution platform; e.g. using something based on TPM. Even then, if the bad guys can attach a logic analyser to a system running your code, they can (in theory) capture the native code being executed and then start on the reverse engineering path.
EDIT : Someone has reportedly succeeded in breaking a popular TPM chip, using an electron microscope; see this Register article. And interestingly, his original motivation was to hack Xbox 360 consoles!
Stephen C
2010-02-11 04:36:56
+4
A:
If your question is Can I ensure that no one can hack my code , the answer would be NO.. Whether it is in JAVA or Visual C++ . As long as your software which is made up of byes or bits is directly accessible by the hacker.
The REASON is simple.
However you encoded , that can be decoded.
The best strategy could be to make a web service and deploy your secret logic there. Let others use your service without having access to how you wrote.
Sreejesh
2010-02-11 05:32:14
+1
A:
Obfuscation, in Java and other languages, is just a deterrent. It simply raises the bar for the attacker. That doesn't mean obfuscation has no value, it just isn't a guarantee.
What are you trying to protect and what type of market are you targeting ?
Obfuscation to protect a license algorithm in a market that it full of pirating isn't going to mean that much. However, for SMB, it may be a enough to cut out most of the casual pirates.
If you are trying to protect IP from competition, I see two answers. The idea, will be hard to protect. A capable engineer looking at the code will figure out the gems of the logic and be able to reimplement. Obfuscation will make it a lot harder for people to just pick up the code and include it in their own product. The maintenance costs will continue to grow as they attempt to make changes (I'd say that is also true for cleanly decompiled code).
The java products I develop for my company are obfuscated. Have they protected us from theft...I doubt it. But, in the context of our development costs, the obfuscation wasn't that expensive. A small bit of protection for a small price isn't a bad trade-off.
Jim Rush
2010-02-13 14:04:53