iam having a doubt that how can i secure my java code
if i sell the binary to my client.if my client uses decompiler
to get the code
[ April 16, 2007: Message edited by: Srikanth Ramu ]
There's some further discussion here in the Applet FAQ (it is relevant for desktop applications just as much as for applets, since in both cases the code ends up on the client).
Originally posted by Stan James:
The analogy on the other thread about locking your house is worth exploring. With your house you have to know who you are trying to keep out. Neighborhood kids looking for a few easy bucks to buy beer, a skilled break-in artist who would avoid anything that makes noise and takes time and go to the next house, or a professional who really wants some precise thing that he knows is in your house and will spend any amount of time and effort? With either your house or your code, there are probably people out there that you cannot keep out, no matter how hard you try. You can weed out the unskilled and eat up some of their time but that's about it.
Well said james. What i felt important was the summarization of the discussion at the end of the thread and the words of wisdom via industry experience specified in the discussion.
Definetly, obfuscation can avoid a casual peep in your house
I'm not able to find it now, but I read a great article on trying to enforce licensing: the old "disable after 30 days" or "run only if license file is valid" stuff. People try encryption, tricky algorithms, JNI to C modules, TCP to license servers, all kinds of things. In Java it always gets down to where you finally check to see if the licensing passed or failed and crackers only have to change that one instruction to always take the true branch. There are a number of hacker tools beyond decompilers to analyze and patch bytecode and it's child's play to experts.
Maybe it would help to extract the license check from one class an duplicate it in hundreds of places in your app. At least you'd give the hackers something really ugly to talk about.
Maybe it would help to extract the license check from one class and duplicate it in hundreds of places in your app. At least you'd give the hackers something really ugly to talk about.
That would also leave the code too cluttered to understand. isnt it
However, an aspect oriented model to insert licence check into byte code may do the trick !!!
<discalimer>I am just throwing my thoughts, nothing concrete.</discalimer>
That would also leave the code too cluttered to understand.
But isn't that the goal? Oh, no, wait, we want to confuse hackers, not ourselves. The AOP approach to that might be cool. Insert so much nonsense bytecode that reading decompiled code is not worth the effort.
I wonder if you can modify bytecode to the point it won't decompile but would still run. Or modify your own bytecode in the classloader to correct a few subtle bugs in the actual source code. A straight decompile of your critical algorithms would not work.
Time to go back to work.
Originally posted by Stan James:
I wonder if you can modify bytecode to the point it won't decompile but would still run.
I seem to remember that there used to be such obfuscators. I think the trick was to rename fields or methods to reserved keywords once the bytecode was generated. The JVM would not care how fields/methods are named, even though bytecode altered this way could not have been generated by a regular Java compiler. Eventually decompilers got wise to this, and it's no longer an obstacle.