This content has been marked as final. Show 15 replies
There are two major way to protect your java application from pirating,
1. (clean way), Obfuscate your code, there are many open source and free obfuscator tools, here is a simple list of them : [Open suorce obfuscators list|http://java-source.net/open-source/obfuscators] . These tools make your code unreadable( though still you can decompile it) by changing names. this is the most common way to protect your code.
2.(Not so clean way) If you have a specific target platform (like windows) or you can have different versions for different platforms, you can write a sophisticated part of your algorithms in a low level language like C (which is very hard to decompile and understand) and use it as a native library in you java application. it is not clean, because many of us use java for it's cross-platform abilities, and this method fades that ability.
There are two major wayActually there are at least six, see below. Not all of them work, see also below.
C (which is very hard to decompile and understand)I dispute that claim. I dispute the entire claim about obfuscation. This is a technical solution to a business problem. There are many threads here on the same topic. They all have the same conclusion: the solution lies in the business domain:
- licence agreement
- time to market
The only viable technical solution is to sell the software as a service on a locked-down server, using e.g. a browser interface.
Fahim wrote:Why don't you perform some research and look for other threads that discuss this (use the search function); perhaps then you'll not jump to such conclusions.
So, your way of protecting software seems a little odd!!! I never heard a PIRATE respect any license agreement !!!!
Believe me: this has been discussed to death. Don't ask that the whole discussion is restarted again just because you can't see it - research it and save everyone else the time.
So, your way of protecting software seems a little odd!!!Which one? I mentioned at least four.
I never heard a PIRATE respect any license agreement !!!!Do you mean 'pirate'? It isn't necessary to shout here, we can all read. I suggest you do further research about this before dismissing the ideas of people who have had perhaps 40 times as long as you've had to think about it.
1. why are you mocking others instead of answering the question ? some one wants to protect his jar file. the solution is simple.
2. you can use google to search, here is result :
3. it is true if you can use basic methods that EJP mentioned, there would be no need for obfuscators, nor native library use.
but there are many situations that you can't do any of those methods.
4. EJP claims that he probably is the one "who have had perhaps 40 times as long as you've had to think about it."
here is the problem that made me use both obfuscation and native library :
My company released a simple java library that scanned a document (directly from scanner or camera device).
the documents were exam papers.
Use some OCR techniques to convert image to text so some other application could calculate the score using it's api.
For marketing purposes, the company needed to publish a 7-day trial version of this library.
So, as you can see I'm eager to hear what you want to suggest.
the solution is simpleThere are simple technical processes that can be applied. None of them is actually a complete solution. There isn't a technical solution. At the point where the code is executed it must be readable in memory by the processor, and it isn't in in principle impossible to read it at that point.
For marketing purposes, the company needed to publish a 7-day trial version of this library.That gives the attackers 7 days to decompile your code. They then have to embed it into a marketable product, unit test it, system test it, beta test it, release it; devise a marketing strategy; devise a licence agremeent; produce marketing collateral; set up distribution channels; ...
Meanwhile you are eating their lunch. That's why I mentioned time-to-market. It is your friend.
And is there really anything magical in your product that can't be reproduced in a clean-room implementation? This is not very likely, unless you have patentable IP, in which case you should patent it.
That gives the attackers 7 days to decompile your code. They then have to embed it into a marketable product, unit test it, system test it, beta test it, release it; devise a marketing strategy; devise a licence agremeent; produce marketing collateral; set up distribution channels; ...The product is a java library for automation software production companies, they won't need setting up distribution channels, they just need to decompile the library to remove the authentication parts of library and use it in their own applications.
And attackers are not limited to 7 days. this is a downloadable library, not an online service.
Yeah I'll just ignore most of what you posted in an effort to keep this civil.
Fahim wrote:Obfuscate the code because that is nearly zero effort. But don't lie to yourself thinking that this is going to be any kind of solution against people that want to break it. Luckily for you nobody will want to do that so it is a non-issue to begin with.
So, as you can see I'm eager to hear what you want to suggest.
And attackers are not limited to 7 days. this is a downloadable library, not an online service.Attackers with the 7-day trial download are limited to 7 days, or you can arrange that it is so. Other attackers must have bought the product, in which case they are subject to your licence agreement, or got it from someone who did, who is also subject to it. This is where price comes into it. You can either make it so cheap that it is cheaper to buy than to reverse-engineer, or so expensive that licensees will (a) have paid enough money so you can afford lawsuits or (b) treat it as so valuable that they won't 'leak' it.
There is nothing above that hasn't been said many times before in the threads here that I alluded to. And they are all business solutions to a business problem. You may not even have a business problem in the first place: the first task is to evaluate the risk against the cost of mitigating it effectively.
Noting that obfuscation isn't actually an effective strategy. More of a deterrent. But so is everything else above.
If you don't want people to have access to your code, don't give it to them.
Period. There's no other way.
If you give your code to someone and they want to pirate it, they're going to. Because if they can run it, they can copy it. And if they can copy it, they can pirate it.
Deal with it. Whether you like that or not is like asking whether or not you like the fact the Earth is round. Reality doesn't care what you like.
Wow, I have read all your post. but i cant seem to get any answer to this question. some say native c library, some say obstrucation. You are saying licensing. Just like Fahim says software crackers are not detered by time or license or patent rites or market time. wen they want ur software they do any thing to get it. Does it mean there is just no secured way of protecting a java jar file to prevent users for been able to reverse engineer the code. I though of converting the jar file to an exe file. Could this work. I think it is really pain breaking to spend dosen of hours writing a software and wanting to sell to make money. now finding out that the software as been cracked and it all over. then y would i stick my time been a java coder. please tell me more. I love to code with java and i want to protect and make money from selling my softwares how can i achieve this, i dont kind of agree with does solutions u gave
928682 wrote:This question does not seem to deter millions of programmers from programming in Java, C#, VB.NET, Android and even interpreted languages. All more or less 'unprotected'.
If so then how can i make money with java then
As for the relative security of native code, are you aware that most popular applications get reverse engineered to crack the licensing mechanism?
But I recommend obfuscators myself. They do a good job, shrink your code significantly (this is even cooler than protection in certain scenarios) and this is the 'protection' chosen by realistic minds at Microsoft (for .NET) and Google (for Android). Oracle does not bother, it just leaves it to third parties that do a good job.
Edit: If you want to turn your jar into an exe and lose portability, you have 2 options that I know (there may be others):
- Exe4j, 70$, hides the jars inside an exe, piece of cake to steal the code
- Excelsior Jet, ~2000$, steep learning curve, produces true native code, last time I tried, years ago, was looking good
Edited by: baftos on May 16, 2012 6:51 PM