File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes locking binary against decompiler Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "locking binary against decompiler" Watch "locking binary against decompiler" New topic
Author

locking binary against decompiler

Amirtharaj Chinnaraj
Ranch Hand

Joined: Sep 28, 2006
Posts: 230
hi guys

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

regards
amir
Srikanth Ramu
Ranch Hand

Joined: Feb 20, 2007
Posts: 76
you could obfuscate the code, search for java obfuscation. however you can decompile the obfuscated code too
[ April 16, 2007: Message edited by: Srikanth Ramu ]
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

Obfuscation is one way of protecting your code. One such freeware is yguard.
However, this discussion is interesting for measuring the pros and cons of obfuscation.


apigee, a better way to API!
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 39547
    
  27
I agree with the other thread in that ProGuard is a very good tool, and it makes the issue of obfuscated stacktraces moot. I disagree with the notion that obfuscation should not be used, even if some source code can generally be recovered.

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).


Ping & DNS - updated with new look and Ping home screen widget
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

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
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
A bit off topic ...

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.
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

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>
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

Or modify your own bytecode in the classloader to correct a few subtle bugs in the actual source code.

Wishful thinking indeed
Again it goes back to the same point of "whom are you protecting your code from?" Smartness doesn't have a limit
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 39547
    
  27
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.
Roseanne Zhang
Ranch Hand

Joined: Nov 14, 2000
Posts: 1953
Obfuscater is the way to go. Proguard is a good choice.

The key concept is not nobody can break the obfuscation, but how much effort/cost needed to break it. If your software worth 5k, but the effort needs 50k, nobody will do that.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: locking binary against decompiler
 
Similar Threads
Read Byte Code
wierd problems..
.class file problem
Java Decompiler
JDBC Interfaces