This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Hello , I have builed one swing application as per client specification. I giving this package as jar file and some directiries containing images. Now how do I put some securities in application, so that client can not sell or distribute that aplication to further any other person. Please Help .
I've actually wondered the same thing every now and then. The biggest problem is that, by default, .class files can be decompiled into the same nice source code that they were compiled from (without the comments, of course). Thus, any attempt to use an encryption algorithm of some sort or to require connecting to a licence server over the network can be bypassed by decompiling, bypassing the particular operation, and compiling back into .class/.jar file. The least you should do is obfuscate your .class files. That will make it more difficult to extend/modify your application because the class and variable names are something like s1, s2, s3, s4, and so forth. Another trick could be to write such a mess that it would take a significant number of days to find out where one needs to tweak in order to disable the security stuff. I would also be very interested to hear about any better ways towards this goal?
Originally posted by raj varma: Hello , I have builed one swing application as per client specification. I giving this package as jar file and some directiries containing images. Now how do I put some securities in application, so that client can not sell or distribute that aplication to further any other person. Please Help .
This is actually an easy question: you can't. Deep breath. Ah... That feels good, doesn't it? Remember, when you run an app on my machine, I own the JVM. Java provides a ton of security features and not a single one of them was designed to protect your code from me. (By the way, this is a good thing, not a bad thing)
If we can all accept that there is absolutely no technical solution to the problem, then you are in a position to consider technical solutions. Just remember that any technical solution is a deterent only. Ultimately, the security of whatever you are trying to protect is a matter of law, and that is the only real power you have. So, what can you do? The real question is what are you trying to protect against? Do you think the customer wants to redistribute your application or are you just trying to be safe "just in case"? Are you afraid of them just sending the whole package over as is, "hey, here's a free copy of XYZ Pro 1.0", or are you afraid of them repackaging it as "ZYX Pro 2.0, for only half the price of XYZ 1.0"? What you want to protect against (specifically) and how much it is worth to you will dictate the ultimate solution. Assumming you are willing to invest $$$ to "protect" your code, the biggest bang for your buck from a third party licensing system which clearly identifies the "owner" in the license. (You could attempt to write this yourself, but I strongly recommend against it. Even the "experts" have a hard time getting it right) The user can still redistribute the code, but only by incriminating himself or removing the licensing code. The latter is almost always trivial, but it requires an adversary who is actively trying to attack you. Your investment to stop a dedicated attacker will be MUCH greater, so you need to make sure that the value of what you are protecting is worth it. It's hard to recommend anything more than that without knowing exactly what you are guarding against. If you post more specific concerns, it would definitely help everyone here to give more specific advice.
Joined: Jan 05, 2003
Hello Norman richards, I want to protect against redistribution of my application. How and what kind of securities I can put in my application so that technically it become hard to redistribute the application by customer. [ January 01, 2004: Message edited by: raj varma ]
Joined: Jul 21, 2003
I'm not sure what you are implying by redistribution, but I'll assume you mean you don't want your customer at company A to let someone at company B use your code. (code that the person at company B knows is not licensed to them - both A and B are out to get you) The key point here is protecting them from actually running the code, not from seeing the code. The distinctions here are VERY important because they require very different solutions. A simple license is insufficient because the license file can be transferred to another machine. To really stop the code from being run, the license needs to be tied to a particular machine. (cpu id, mac address, host name, etc...) Your customer can hack around this (very easily) but they have to really be motivated to actively cheat you to do that. Of course, if you impose a very draconian licensing system like this on them, they may very well be motivated to do this to you just to spite you. Another option here is reporting. If your software periodically pings your server, you can detect if it is being run somewhere other than where it should. Firewall and connectivity issues aside, this is somewhat shady. When your customers figure out what you are doing (and they will) they will not be happy with you if you didn't disclose what you are doing. You could disguise this as a "check for update" or a "bug reporting" system, but that's somewhat dishonest. You could also have a centralized license server on your site that the code needs to contact, but you have to be careful that you never disable the clients system by your system failures or event their connectivity problems. If they can't run the system, they will hate you. I should point out that what you want is more than most commercial products (ones that are probably worth many times what your product is) do. Most commercial systems don't try to prevent redistribution, they try to make sure that the code can't be redistributed without fingering the original source. A simple license file accomplishes this and your customer won't hate you.