Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Is it worth to obfuscate java web application? and why?
No. The code is stored on the server where external users (hopefully) don't have access to it. You may want to obfuscate the JavaScript if you feel it's worth the (minimal) IP protection.
The best thing is so make sure your server security is up to scratch and you don't have open access to your application directories (which shouldn't happen anyway).
IMO, no.
There are two main use-cases for obfuscation:
to protect access control "secrets" (e.g. passwords) embedded in the code, and
to protect against someone stealing your "intellectual property".
The problem is that obfuscation only foils half-hearted attempts at reverse engineering. A serious attempt will always succeed. It is really not that hard to decompile an obfuscated JAR file, and there are lots of tools around for doing it.
For the use-cases above, better alternatives to obfuscation are:
just don't embed secrets in the code, and
one or both of the following:
secure your webservers so that hackers cannot get at the code, and
don't ship the code that you consider to be valuable IP, or if you do, then only ship code to people who have signed a legally binding contract / license agreement that guards your IP rights.
The only scenario where you would obfuscate a java web application is if you gave the code to your customers to run on their servers. Otherwise, it is just a waste of time and an extra complexity.
Obfuscation is for the purpose of making it harder for someone to decompile your byte code and get useful code out of it. To do this, they have to have access to your class files, something that only exists when you deliver them to your customers, not when they access it remotely.
I would add that you should have a good justification, because obfuscation will make debugging harder.
You might find the answers to Do you obfuscate your commercial Java code? relevant.
Is it worth to obfuscate java web application?
It depends
and why?
If you're licensing your web-app to be installed on your customer's site and you don't want your customer to reuse your code by decompiling it*, then it is.
If you're serving your web-app and the installation is available only from you, I would say it is not worth it. Better would be to increase your net security.
* see Stephen C comment
Absolutely yes.
If your development process is correct, only binaries and some support files (markup and stylesheets, for instance) need to be on the server. There's no good reason to not obfuscate binaries in any production environment.
Others here have said that doing so creates problems for staff. The only people that should be aware of or concerned about the contents of your binaries are developers - and they have the source, so they shouldn't be concerned about poking around compiled objects.
The only reason I can see that anyone that doesn't have access to the source would be interested in the contents of binary would be reverse engineering - and no one on your staff should have any interest in reverse engineering your own product, unless they don't have access to the source. That means they either aren't cleared for that code, or you've lost it, which means your source control system either sucks or is missing entirely. That is a completely different conversation.
I've yet to hear any practical examples of server-side obfuscation causing development or administrative difficulties.
Is it a good idea to obfuscate your server side code? I'd give an unqualified YES.
The reality is that the end user is only one group which might have nefarious plans. All too often internal employees, whether they are business users, support staff, etc, might also have their own plans.. or made unwitting accomplices.
If you deal with ANY information which requires a password to access, then you have a duty to leverage every tool at your disposal in order to safeguard that information.
This includes protecting it against both external and internal people. Companies lose both data and intellectual property all of the time due to internal people with too much access. Whether those people purposely stole the information or simply lost control of their computers due to hacker attacks is immaterial.
So, again, yes one step is to obfuscate in the hopes of whoever acquires the binaries has a harder time in figuring out how your application works. Of course, you should go a lot further by securing the servers it lives on; and not just production, but all the way back to source control.
Related
Im thinking about creating spring boot application that i would like to comercialize some day.
I planned to build a Jar that i would allow to download, and once client launched it locally and provided some license key, it becomes useable.
I have some doubts about this distribution strategy especially in the meaning of the safety of the code and licensing.
If i provided a Jar, anybody may try reverse engeenering on it - so its easy to be hacked or cracked.
Turning it into executable is more user friendly, also possibly may hide the code better, but still i think its relatively easy to be reverse engineered.
It made me think about obfuscation. If i completely messed up the app before prod build, it would be a way harder to understand or change the code. It may seem okay in the matter of "copying and modifying" the app, but still i think it would be easy to locate licensing limitations in the source files. For example: limit for 5 users can be easilly located in sources by value "5" or the message the user sees, and even if code looks awfull, this lines can be removed, project compiled again, breaking the limitation and wasting my entire effort.
It will be small application, I want to provide clients the instalator, and let them set it up personally. I dont want to be responsible for settting it up in the cloud for the client (without publishing instalator or Jar), as clients may not be interested in cloud based access.
Could You advise me some wise solution for this situaltion?
Thanks in Advance ! :)
The short answer is that there is no way to prevent reverse engineering if someone can run the software on hardware that they control.
The only way to 100% prevent reverse engineering is to ONLY run the software on a platform that you control ... and that can prevent them from getting a copy of the executables.
There are a couple of ways that can make reverse engineering harder:
Use an obfuscator on your JAR files. It will make it harder for someone to read the decompiled code. There are 3rd-party obfuscator products you could use.
Use jpackage (or a 3rd-party tool) to create a native executable for your application.
But beware that modifying an application to disable a license check is much simpler than full reverse engineering. A determined software engineer (or hacker) will be able to do that, given enough time and incentive.
Look at this problem another way:
There are many people and companies making money out of writing and supporting software without resorting to license keys, obfuscation and so on.
Conversely, there are probably millions of aspiring software entrepreneurs who never even turn their clever idea into a worthwhile (saleable) product.
Conversely, there are millions of apps (e.g. in Android app stores) that are simply not worth the effort protecting from IP theft.
Don't get lost in the problem protecting your IP before you have actually created it. And don't overrate its (hypothetical) value.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I want to sell my Java application using PayPal. When a payment is received, the customer is mailed a one-time download link to my application.
My question is, how do I prevent people from sending the .jar file to their friends/uploading it on the internet?
Obviously I need some kind of check in the application which only allows it to run on one computer. And that's another problem, I don't want a customer to have limitations on one computer, they should be able to run it at home and work etc.
Maybe some kind of cd-key would do the trick? Is there any cd-key resources for Java out there? Or should i build my own algorithm? Here comes yet another problem, reverse engineering..
Please help me solve this :)
The most common way to handle this is: customer gives you money, you generate a unique unlock key and provide that to the customer. The key should be a valid unlock key, and it should encode identification information about the user. Customer uses that key to install on as many of their computers as they like, or is allowed by the license.
Don't worry about reverse-engineering. Your product, if it's at all popular, will be pirated - you'll find unlock keys online if you look hard enough. If you like, you can take that as a compliment - someone liked your software enough to steal it. Cold comfort, I know, but the alternative is to get in an arms race with the pirates, and you won't win that. In the end, a few percent of the population will steal software, and you can't do much about that. You can use the key's identification information, if your scheme is strong enough, to trace who released the key in the first place.
Actually there are a number of license management solutions that can help, but the REAL problem is that all of they can be cracked. I've personally tried the most expensive to the cheapest. Finally I rolled my own, and I check the software's pc details (mac id, etc.) against the recorded details in my server every time the software is run. Because my software is tightly tied to the Internet, it is okay, but I am sure it will be cracked one of these days.
What you probably need is to police the Internet regularly, and find where your software is being pirated, contrary to the popular belief you can actually stop them in most cases. Just serve a DMCA to the downloading website (most of them will comply), and you will be able to get your software removed in about 80% of the cases. I've done and experienced it on my software. Some people do not remove, but I've found that in the 1.5 years I've been doing this, my sales have improved.
I also use a service -- http://spotpiracy.com which helps me find these links apart from my own manual research (i have a guy dedicated to this). :)
Everyone has their own opinion on this subject so expect lots of different advice. Here's my take on it:
1. Obfuscate your code (proguard is recommended)
2. Offer a FREE version with full capabilities for a trial period
3. Use a serial number routine based on the registering users email or other unique info
Overall you will have to accept a certain amount of piracy, but if your application is worthy people will pay for it. Honest people will be honest and copy protection will not make dishonest people honest.
In my opinion, if you don't know exactly how you will protect your source code efficiently, then don't start trying to hash something together yourself based on hardware. It will be too easy to break, and most likely just annoy your customers.
I would sugest you have a look at how Atlassian does this. They happen to sell Java software, and apparently do quite well. http://www.atlassian.com/ Try downloading e.g. JIRA and play with an installation. This will give you a good idea of how their licensing scheme works, and what users can reasonably expect from professional software.
You must implement licensing capabilities.
Here is one interesting resource as a starter: http://members.chello.at/stefan-schneider/JavaLicenseKit.html
In my old c++ days i get in arms to front the piracy using MAC Address code protection, very nice and really no body stole my software uppone the mac address protection because i always force the OS to re-read the real mac avoiding mac overrides. That was on C++ coding having direct access to local resources.
thats not the case today, nither in java applications in which the code is located in .class files that can always being decoded back to the original source code (yes it is possible, and very easy to find tools to do so).
i think, as resume, it is impossible to protect java programs agains piracy. i find no way like the old golden c++ days :)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have written a Desktop based accounting software in Java. I want to put a key or licence or other kind of security to prevent redistribution of the software by the client.
I just want to know how to go about it?
The short answer: DRM doesn't stop piracy. It only hurts your paying customers. It doesn't really matter what you do.
The best you can do is set up a simple product-key system, all that really does is makes your application not able to be copied quickly with no work, it doesn't really harm your paying customers but don't expect it to stop anyone who's determined not to pay for your software.
The best thing you can do is make your software good. This gives people incentive to actually purchase it. Also a fair pricing plan helps (There's a reason Adobe / Microsoft software are highly pirated).
First, lets leave alone the commercial/GPL war out of SO and actually answer the OP's question...
I work for a company selling protected Java software. Our software is good. It actually rocks and completely owns the competition's offerings. If users aren't happy with our protection scheme, they can go use the inferior products our competitors are making.
The thing is: we're moving to a more and more networked world. Our software mandates an Internet connection for some functionalities to work correctly (the software will launch without an Internet connection, but not everything will work correctly).
A correctly designed server/client protection scheme, where sufficiently enough processing happens on the server side, cannot be pirated. At one point, it becomes easier to rewrite the software than to try to reproduce what's happening on the server side.
You can think of it this way: nobody ever succeeded playing on the real "World of Warcraft" servers with a pirated or keygen'ed licence (there have been fake servers but that would be missing the point: people playing on rogue servers are not playing in the real economy, which is a massive fail).
Or this way: nobody has pirated GMail. GMail definitely rocks: it's probably the app I use the most (after my IDE). Sure, it's free... But nobody can clone it: nearly everything is happening on the server side.
It is very common in some software circles to have restrictive copy protection in place: it was hardware dongles back in the days now it's mostly server/client scheme. For example there are a lot of very good and very expensive software thare are using the "Flex license manager", including expensive C++ compiler that beat the crap out of anything free (or cheap), which some companies are very happy to shell out big $$$ for and very happy to have the ability to buy such a software (and they don't mind needing an internet connection for the license verification).
So, to answer your question:
I want to put a key or licence or
other kind of security to prevent
redistribution of software by the
client. I just want to know how to go
about it?
Go about it by puttin a client/server key verification in place. Ideally, make part of the computation your desktop software is doing happen on the server side: that gives headaches to wannabe pirates (they either have to pirate your server or to reproduce what the server does, there's simply no other way around it).
Here's a +7 upvotes answer I made to a similar question which gives more detail:
Making commercial Java software (DRM)
For online software, you can request the email address and first and last name from the buyer. You can apply an algorithm on those values to turn them into a large number. You prompt the user to enter the number, and if the calculated number matches what was entered by the user, you store the number and enable the software.
I use Plimus, which is a service that delivers my software and bills the customers for me. I store the key generator on their server, which generates the serial number based on the information from the customer's online order.
For shrink wrapped (off-the-shelf) software, you could still do this, but you'll need some type of online activation mode that basically forces the user to register when they first run it. This allows you to collect the email address and name and send them their serial number. Users typically don't like this. What if your server is down? However, they'll be willing to do it if your software is good enough and you provide decent support to help them with problems registering.
For off the shelf software, typically, some algorithm is used to generate a series of large numbers, each of which matches some algorithm and enables the software. One serial number is packaged with each copy of the software.
In my opinion, the most difficult issue is providing the user the ability to try the software out. You could offer refunds, but you'll need a way to revoke the software. You could have a trial version, but trial software is even harder because you don't want to let them keep using the trial version. It's simpler to create a free (forever) limited version, and the pay version has additional features.
Use of java is tempting to many as it is rapid and does not demand geeklike skills to code. But i dont think you can DRM your apps successfully made in Java. To recover from this mistake start coding with C/C++ from now on.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
What is the best way to implement license enforcement in a Java application, so that the application cannot be "distributed" and used without the user purchasing the license?
Take a look at truelicense which is an open source framework for doing just that. If you want to make your own there is some documentation that explains the concepts and you can probably get some good ideas by looking at the code as well.
EDIT:
worth mentioning that it is not a copy-protection scheme
I suggest you don't even attempt to add copy protection. You will just annoy people. You are much more likely to get sales if people like your product. Being petty and treating customers like thieves is not going to help. (Unless the product really sucks, and you have to prevent people from being able to try it before they buy.)
You might want to send a license key the sole purpose of which is to satisfy users that want to receive something for their money. Just add a status somewhere to show whether it has been paid for. The status needs to be reasonably obvious so that it is clear that something has happened (a product I worked on along time ago came on floppy two discs - half of the support calls were because the installer didn't ask for the second [win32s] disc).
There isn't a licensing scheme that I am aware of that is not easily breakable. I will not go into specifics, but as an example, in the Java case if it is done in Java then it can be decompiled (as can C++ or any compiled language, but Java is easier than C++ for instance). If it is done natively then you need native methods, and the DLL/so could be replaced with one that allows access.
For the C/C++ example I know someone who decompiled the CL (Microsoft compiler) to figure out how they do name mangling. All they had was the binary, and they were able to do it with a disassembler and a lot of time.
Don't bother with this type of thing, it annoys honest users and moderately slows down those that want to copy it. Take a look at World of Goo (great game!) and their take on DRM (which is a similar idea to what you are talking about).
The developers of World of Goo found that their product was pirated 90% of the time (they explain how that number could be inaccurate), contrast that to another game that shipped with DRM and was pirated 92% of the time.
If you are talking about legitimate businesses then they want to be in license compliance usually, so ensuring that they are not copying is a waste. If you are talking about people who would not buy the product to begin with, or just don't want to pay for it, you are not really going to alter the number of people that get your software illegally, you will only slow down the first person who gets it - after that the cat is out of the bag.
Personally I think IntelliJ gets it right: fully-featured version for 30 days. You shouldn't be any more restrictive than that.
The "fully featured" part is important. If your unregistered version is so crippled as to be useless, how do you expect people to decide to buy it? They have to try features before they decide they like them and want them but the notion some vendors have that people will buy something on the promise of features they haven't been able to try is ludicrous.
Oracle is at the most liberal end of the spectrum. You can basically download a fully-featured version of their software and just use it. They treat licensing as a social problem and there's a lot of merit to that argument.
You should never nag or otherwise annoy your potential customers (beyond possibly expiring the software after a predetermined period). The most notice you should give is "X expires in N days" on say a splash screen or something.
The other thing you can and should do is provide a low barrier to entry for your software.
Provide a cheap (if not free) academic or personal version. Marketing is also a good idea. By this I mean take IntelliJ: it's offered free to approved open source projects.
As for the technical aspects of enforcement: don't be too concerned about the technical aspects. Never choose any scheme that annoys your users or, worse yet, slows down your software (as some schemes do) or (even worse) violates the security of the user's operating system (eg like the Sony rootkit fiasco). Your enforcement is not meant to be hack-proof. If people want to steal your software they will. The enforcement system is there as a gentle reminder (and nothing more) for a social not a technical problem.
After reading oracle's BCL(which affirmed commercial freedom). I then had a conversation with an oracle representative who said JavaSE is free for commercial use!.
I have a standalone Java app that has some licensing code that I want to secure, i.e., prevent users from changing my software to circumvent the licensing. What is the best way to do this?
I've looked at obfuscation, but that entails all sorts of problems: reflection, serialization, messed-up stack traces, etc. Perhaps jar signing could be a solution? But how do I verify the jar at runtime? And how do I ensure that the user doesn't change the jar verification code?
Sorry, if your users are savy enough to tamper with your class files, they will remove the signature checking features first thing.
I agree with obfuscation, but shouldn't a good obfuscator keep some dictionary to convert an obfuscated stack-trace for you?
This discussion is really old, and really really complicated. Just look at the game industry. Maybe you should consider shipping a guitar with your application?
Combine the two, and you should have good synergies.
We currently use an obfuscator, which provides reasonable protection against attack. The one we are using right now provides a stack trace tool which will de-obfuscate them when they come out the other end (based upon the log file generated at obfuscation time).
Even with this, there is no real protection against the determined hacker.
This is a legal problem, not a software problem.
You can make it more difficult for the first user to make a copy, but not impossible. And once the determined attacker has broken your security, he can make an unlimited number of copies for the lazy.
If you think it's profitable, prosecute people who make unlicensed copies of your software.
I believe the portion of users who will knowingly steal your software (or, more generally, intellectual property) varies with the type of media, and for most products, is relatively small. If you are selling T-Pain MP3's, theft might destroy your business. Otherwise, adopt the stance of credit card companies, who expect to tolerate some losses due to fraud but still make a profit.
You can seal the jar. Pls. see the below links for details
-- http://java.sun.com/docs/books/tutorial/deployment/jar/sealman.html
java.sun.com/developer/JDCTechTips/2001/tt0130.html