I am doing some Java work for a company that has some code that they want protected in an application that they are giving to their customers.

For example what if you have information such as FTP or DB login information in the client side application source code? The login would be visible to anyone who viewed the code, so access to your server is right out there in the open, which means your code on the server would also be vulnerable. Should the login information be protected by sending information using HTTPConnection/HTTPClient to the server to be processed while using Encryption in transit and sending login credentials to verify request is from a legitimate source.

However wouldn't that also prove to be risky in case the server is hacked/breached, and the Java source would be wide open? (Apparently Execelsior can do server protection with Tomcat applications so there is also that).

I was also looking into various Java-to-Exe programs such as Excelsior Jet, but I also ran into programs that simulate Exe's and apparently have protection such as JWrapper.

I had read in this question https://stackoverflow.com/questions/2244321/does-compilng-java-code-to-exe-e-g-using-launch4java-ensure-code-cannot-be-re

That the emulated exe's are not protected, and still contain Jar files, so I'm assuming the best bet are programs similar to Execelsior Jet, and a program such as JWrapper would not be good then?

Would it take more time for someone to decompile Native code than to try and hack a server (if they even knew what to look for, or that we are even trying to hide anything). My best bet would be doing server + Excelsior, but the price also goes up if I want to get their Enterprise version instead of Professional.

I am curious what approach people would recommend for safe protection methods. Thank you.

EDIT: This question is not a duplicate, because the other question asks about protecting Web Application code from "Web Hosts."

I am asking what the best method of protecting my source code would be. Whether Desktop, or server based. The other question could make sense if I was looking at a server solution, but doesn't provide a solution to my need.

Thank you.

EDIT2: It seems the consensus is that "if someone wants to break, they will..." but isn't there a point to protecting it to stop anyone from just looking at the code? There are coders who aren't knowledgeable in reverse-engineering, but still can understand code if it's readable.

marked as duplicate by Xander, techraf, symcbean, Stephane, Steffen Ullrich Oct 7 '16 at 12:48

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • I wouldn't say this is even close to what I'm asking, but there are points that are similar. Thanks for the link. – XaolingBao Oct 5 '16 at 21:47
  • 2
    It is, you're just farther down the same rabbit hole. Your customer has simply already decided to throw time and money away chasing a non-issue. So, since providing bad answers to a non-security-issue isn't really in the realm of information security, bringing it back up to a risk assessment level at least keeps it on topic, even if a duplicate. – Xander Oct 5 '16 at 21:54
  • 2
    Replace "web hosts" with "customers" and the questions are effectively identical. So are the answers. For the general case, anything you do to "protect" your source code is both wasted effort and ultimately futile. File it away under low-risk threats and focus on things that are more important. For more details, see the answers in the duplicate. – Xander Oct 5 '16 at 22:47
  • 1
    "login information in the client side application source code" You should <b>never</b> hard-code any kind of credentials into source code. Have user input it, hash it, then store it as salted hashes. Always. – Kirill Sinitski Oct 6 '16 at 12:50
  • 2
    Now that you've modifed the question to be specifically about credentials in source code, the question is a duplicate of this one: How should an application store its credentials. – Xander Oct 6 '16 at 14:29

There are 2 obvious problems with credentials being stored in the source code are:

  1. The source code can be easily reverse engineered and the credentials extracted.
  2. If the credentials are leaked, you would have to change the password on the server, change the password in the code, rebuild and re-deploy

So one option to get round both of these issues is not to have the credentials in the source code at all. A suitably protected configuration file may be all you need, read in the credentials when needed, use them and then clear out the memory after use.

  • So technically instead of doing everything on the server, I could grab the login information from the server, and then login on the client and use that login for what's currently being done? That makes sense as it wont be stored in the application itself, and I don't have to waste sever resources either :). – XaolingBao Oct 6 '16 at 16:54

This also brings up the point that what if you have information such as FTP or DB login information in the client side application?

In this case it looks like you want to hide credentials in your Java code which are most likely String constants. If that is the case this question from StackOverflow may be helpful.

What you want (and I said what you want, which is not necessarily what you need as highlighted by other answers and comments) is called code obfuscation.

Code obfuscation is a set of techniques which, given a source code as input, while produce a functionally equivalent but very hard to read / understand source code at the output.

However, be aware of consequences, not only upstream but also down the road since your software will become a lot harder to maintain.

For instance, Java rely a lot on stack traces to diagnose issues, such stack trace usually give clear information about where the error happened. With a correctly obfuscated code, the stack trace will have no meaning anymore:

  • Customers will have no mean to resolve even basic issues, thus increasing calls to your support services.
  • Your support will have less elements to investigate from the customer (as per my experience at least acting as a client to such company, they seem to have no easy mean to de-obfuscate their own stack trace).

In the realm of corporate software, this is rarely used since the cost usually goes over the benefits (but some indeed use it) and a company really willing to reverse engineer your software will most likely do it anyway.

This may be more frequent in some specific domains, like online playing games (MMORPGs for instance) targeting a substantially wider audience and where the risks associated to reverse engineering may be higher. This however does not count as a reliable protection, just a measure amongst others designed to slow-down attackers and deter casual crackers (with the same disadvantages regarding support issues and poor customer relationship).

  • Thanks for the info. I never said "what I want," but thanks for the information on this. So any form of Obfuscation, including Excelsior Jet, would cause problems with stack traces? Can't I use other means to trace errors, such as dialog boxes with the error, or are you saying that it will effect everything in regards to issue tracking?: I definitely don't want to make it harder to track just protect bits of my code. So what would you recommend I "need" then. There are many ideas floating around but nothing concrete. Thanks. – XaolingBao Oct 6 '16 at 16:58

Let's think about what code is for a second. Code is a list of instructions for a device (a processor) to do something. Processors are designed by humans, so it's logical that a human would be able to understand code designed for it and be able to replicate its functionality given enough time and effort.

What you're looking for is essentially impossible - maybe it will be with quantum cryptography where merely looking at information will alter it, but in the meantime it's not.

Maybe the solutions you describe will be enough to protect your code. If you're just looking to prevent kids from using your software this will do the trick, but those same kids will probably never have the money to buy your software anyway, so it's not like you're loosing much. On the other hand, imagine if as a kid you were facing two corporations - one openly giving you the code, and one doing their best to prevent you from using it - once an adult with money, if you had to do business with either of them, which one would you choose? Personally I would choose the former, because they still helped me out while I had no money to pay them. You're basically saving money on the short term without thinking long term.

This is similar to piracy. Some people will pour unlimited amount of money into trying to prevent it, but even then it'll eventually get breached, and all that money goes to waste.

I suggest a different approach, instead of trying to prevent theft/piracy which you'll never be able to achieve completely, try to appeal to your paying customers instead. Make it worth it to be a paying customer. Maybe it's hard to believe, but there are people that are willing to pay money for good software. Focus on them - do they have a feature request, or are looking for technical support? Invest your money there.

If you do still want to try and protect your code, there is a way to do it. Put in on a computer hosted at home, and keep an eye on it 24/24. Or even better, don't even write code (what if your development machine is already compromised?) and do whatever your valuable app does but directly in your head. This should be fairly safe, and you don't have to trust a hosting provider nor employees.

Hopefully this explains well enough why you have to trust someone, like an infrastructure provider. Fortunately enough, not everyone is a crook, and most infrastructure companies out there will happily host your application, making good money from what they already do best without betraying your trust and stealing your application.

  • This doesn't really answer my question, but thanks for your effort. – XaolingBao Oct 6 '16 at 16:59

I would recommend obfuscation, then making the password look like the obfuscated code, then leave a bunch of honeypot passwords.

Not the answer you're looking for? Browse other questions tagged or ask your own question.