Obfuscation can help prevent the hacking of your Java code, but how does it work? Alex Kalinovsky explains the most common methods and how they can help protect your intellectual property.
Also, Tim Stevens shows how combining the open source database HSQLDB with Sun’s Java Data Objects extension may save you a lot of excess coding, without losing too much in terms of performance.
Covert Java: Obfuscating Classes
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
…from my experience, seems to work quite effectively.
It works well for small programs. I had to write a plugin for a very poorly documented Java API and the only way I was finally able to get anything to work (despite correct logic code) was to decompile sample plugins provided by the company and see how they used their own API. While decompilation may not work for say intellij, it should work fine for very small programs.
It’s funny not protecting your classes in any way and then trying to implement some serial number validation…
I remember a certain commercial Java application, which I won’t mention. There was a trial or reduced version, and out of curiosity I tried it. I knew I wasn’t going to use it because they wouldn’t buy me a licence where I work (cheap bastards).
So anyway, I don’t really know why but I decided to look for a ‘crack’. I guess I wanted to see how simple it was, patching a Java app.
What I found was a serial number ‘generator’. It wasn’t a generator at all. The app used a process of generating an ID which you mailed to buy a serial number which in turn the app validated again against the ID. So this ‘generator’ simply loaded the jars and used the same classes from the application to generate a serial number for that ID.
(Not completely on-topic, I know, but…)
Howdy
This has not only a uses for protecting your code but can in some cases be used to make your code smaller, reducing method names and so forth.
Have a look at developing for mobile or MIDP type of devices
Secondly sometimes you can still understand a decompiled/obfuscated class if the code still has all the Java library names in full, it kinda defeats the purpose sometimes and i often wonder why they don`t fix this situation.
A friend of mine was hired a few years to reverse engineer some code a firm had made a few years before that.
You see, while the company had the original code (their own employees developed it), they decided to take small steps to obfuscate it to protect their trade secrets. The orignal employees moved on, so the trade secret ended up a bigger secret to the company which developed them than to the company which employeed their ex-employees.
They shot themselves in the foot.
Knowledge is property. Knowledge must be held in secret and guarded jealously. Give me a break.
If you live by the sword, you deserve to die by the sword. If you try to hold knowledge in secret rather than spreading it, you risk losing what you tried to defend. If you guard knowledge jealously, you risk being losing your freedom to those who want to guard their own knowledge jealously.
Knowledge is not a loaf of bread. If I share it, I do not lose it. If I lock it up, I only gain from it through extortion (copyright/patent lawsuits).
should be obfu enough
but beside this joke is anonymous above completly right
Hmmm you do know that you don`t obfuscate source code? the only thing that should ever be touched by this is the resultant binary or byte code!
So I really can`t understand how that company even survive with such an obvious brain hemorage of a development process.
First, there is no way you can make Java impossible to decompile – but you can make it very difficult. Someone determined to break in will find a way – ultimately all code will depend on the core Java library and there is no way to hide that – from there it is just a matter of spending hours of decoding the byte code. But it is not that hard, really, I mean Java checks all byte code to be sure it is safe before it runs the code. The fact that Java can detect safe code (unlike say Win32 binary code) come from the fact that Java has very controlled access to resources like memory and IO and such. Because of this controlled and safe code, about the only options available are to rename classes and methods or to introduce misleading code that is essentially ‘no ops’ but that may confuse the decompiler. Misleading code and bad class names do not make the code better – and, as I said, cannot stop a determined hacker.
Second, the only Java code that should be on the client machine should be presentation logic. All business logic and data access should be on the server and the server should be secure from prying eyes. If the server is not sercure you have much bigger problems than someone decompiling the Java byte code.
Third, since the only Java code runnning on the client is presentation logic the code should not be very valuable in terms of IP. I mean sure, it does take time and effort to do it, but we are basically talking about presenting input fields and buttons to the user. This is not high stakes IP.
Forth, what is high stakes IP is how data is transmitted between the client to the server. In this case the communications method must be secure (encrypted and authenticated) and as close to impossible to spoof as possible. Packet sniffing is one of the first tools of a good hacker. If your communications are secure and cannot be spoofed then it doesn’t really matter if the hacker sees the source code. They cannot run it unless they are a valid and authentic user or unless they steal someone’s account (or if you put a back door in your code – which you should not). In no case does having the source code help the hacker if the communications are well done, and if they are not most hackers won’t even bother looking at the source code.
Finally, my point is that obfuscation is generally useless in Java and in safe .NET code. If using a mutli-tier model, then the client byte code is basically throw away code – much like HTML is, though admittedly not as easy – whether we like it or not. I am assuming, of course, that no one would write a complex stand alone desktop application in Java – but some people do weird things…
I bring all this up because my public library made just this mistake. They released a horrid little Java applet a while ago that interfaced with the library search engine and the patrons personal accounts. The code was thoroughly obfuscated. But I have to ask why. I mean it is a public library, why not share the code that interfaces it? They had the wrong attitude that obfuscation = security, it does not.
APW: Second, the only Java code that should be on the client machine should be presentation logic.
What about apps that are entirely on the client machine. Like a word processor or an off-line game?