views:

512

answers:

7

I'm working on an application that I will soon be publicly distributing. I would like to do anything in my power to make sure those who download my program do not reverse engineer it. I understand that distributing a .jar file is highly insecure.

Can anyone recommend a platform independent way to distribute my Java application? Also, I would like to install it as a service on any platform (Windows, Linux, Mac OSX).

Thanks!

+2  A: 

Have you considered using a native code compiler such as GCJ? It's not platform independent (you would have to compile one for each target platform), but I don't see how you can distribute platform-independent bytecode and yet hide that bytecode from your end users.

Greg Hewgill
+1  A: 

you can obfuscate it. It will make reverse engineering your program more difficult. Also, I think you can make your class files executable (i.e. .exe for windows) too

EDIT: to be honest, if security to your application is so important, best avoid java altogether. You can use gcc compiler for c++ for instance (which is more or less platform independent as long as you don't make system calls). You just need to compile it on the different host machines (which is something that your original question indicates as your need but on java).

There is also qt, but I haven't tried that one myself.

waqasahmed
You can make executables - but all you are doing is ebedding a virtual machine.
Shane C. Mason
Difficult, but not impossible.
matt b
+2  A: 

You can encrypt the jar, but then you will need to write a custom class loader to load the contents of the jar. That still isn't 100% fool-proof though - the simple fact is that nothing you can do will make your code 100% secure if it is targeted. See this discussion here.

http://stackoverflow.com/questions/537596/how-to-create-encrypted-jar-file

Shane C. Mason
The problem with encrypted JAR files is that you have to provide some code to decrypt the files for execution. That code can be reverse engineered to determine the decryption key/algorithm.
Stephen C
@Stephen - agree 100%. There is no doubt that this method is only like a padlock - made to keep an honest man honest. Anyone who wants to put any level of effort into obtaining the source from a jar can do so. After all, once it has been decoded it can be read plain from memory.
Shane C. Mason
+4  A: 

You can scramble / obfuscate your bytecode with yGuard or other java-bytecode-obfuscators.

Operating System independent distribution can be difficult. IMHO the best solution is a normal archive containing several scripts (.bat/.cmd for windows, .sh for linux / OSX)for the program-start under the Operating Systems the program supports.

Running a java-program as service can be even more difficult: It's easy under Linux, where you just have to write a proper startup-script to run it in the background. I know that FireDaemon has problems running java-programs as service, so it might be difficult (or impossible) to run it as service on Windows. Sorry, but I've no idea about MacOS X. Could be as easy as Linux, could be as impossible as Windows.

HTH, flokra

flokra
Obfuscation is the way to go.
Carnell
+2  A: 

Running your application through an obfuscator makes reverse engineering more difficult and costly.

Take a look at the Java Service Wrapper for a relatively easy way to install and run your java app as a service on multiple platforms.

Jeremy Ross
+2  A: 

As others have said, you can obfuscate your code. That will make reverse engineering non-trivial. You could also compile your Java to native code using (for example) GCJ. That will make reverse engineering harder, but it will also mean that you have to create different distribution bundles for each supported hardware/OS platform.

But ultimately you have to recognize that if you distribute software to run on a stock platform, there is nothing technical that you can do to prevent reverse engineering. Nothing.

Ultimately, you have to trade off the benefits of distributing your software versus the risks of someone reverse engineering it. One approach people take is to figure out if the benefits outweigh the risks * costs, and use legal safeguards (e.g. appropriate software licenses) to deter reverse engineering. The other approach is to say "good luck to you" to potential reverse engineers and make your money by offering services rather than software licenses.

Stephen C
+1  A: 

or you can do what I did. java front end with certain backend functions written in c++ compiled into a dll called via JNI. Front end GUI is completely portable with with backend grunt done native.

damhard