I have a java program which I consider valuable intellectual property.
 The .class files sit and run on Linux machines (Red Hat, SuSE) which
are used by other people, so an unscrupulous individual could
theoretically take my class files and decompile them.

How can I prevent this?  There must be some way to encrypt the
classes, decrypt them at runtime w/ a password, without ever leaving
the bytecode classes subject to viewing.  Or make the .jar like an
.exe, that is, non-decompilable.

This process must not hinder performance, and hopefully won't take a
Linux SA to administer.  It is not an option to rewrite the thing in
C++.

Looking forward to hearing from you, -t

Hello timbo70-ga,

Your question is actually a very practical one, and there are actually
multiple approaches which will prevent make it extremely difficult for
someone to decompile your bytecode.

When you compile source Java code, known (and publicly available)
methods are used to create bytecode. This is where decompilers came
from - the fact that there is a method for compilation in general
means that it is possible to develop an algorithm for decompilation.
In fact, there are several utilities out there that do exactly that.

The process of obfuscation will convert bytecode into a  logical
equivalent version that is extremely difficult for decompilers to pick
apart. Keep in mind that the decompilation process is extremely
complicated and cannot be easily 'tweaked' to bypassed obfuscated
code. Essentially the process is as follows:

1. Compile Java source code using a regular compiler (ie. JDK)
2. Run the obfuscator, passing in the compiled class file as a
parameter. The result will be a different output file (perhaps with a
different extension).

This file, when renamed as a .class file, will be functionally
equivalent to the original bytecode. It will not affect performance
because a virtual machine will still be able to interpret it.

Here is an article describing this process in more detail and
introducing an early obfuscator, Crema:

http://www.javaworld.com/javaworld/javatips/jw-javatip22.html

(note that since the passing of the creator of Crema, this utility is
not being officially distributed)

Another discussion of decompilation and obfuscation is available at
the IBM developerWorks site:

http://www-106.ibm.com/developerworks/java/library/j-obfus/

Obfuscation tools:

Jmangle - The Java Class Mangler

"The Jmangle program helps discourage reverse engineering of Java
programs and software piracy by allowing the developer to mangle the
symbols used in the class file. Long descriptive names for classes,
methods and fields can be replaced by meaningless symbols making it
much more difficult to reverse engineer. Jmangle allows the developer
to selectively mangle just the classes internal to the application
while leaving desired public class, method and field names unmangled."

Feature list:

Mangle package, class, method and field names 
Control mangling by access control (e.g., public, protected, private, friendly) 
Control mangling options on a class by class basis 
Strip debugging information 
Insert string tags to secretly mark class files as yours 
Output map of symbols to mangled symbols 
Easy to use graphical user interface, see screenshot. 
Command line interface, useful in Makefiles and build scripts 
Reduces size of strings in class files for better performance 

http://www.elegant-software.com/software/jmangle/

Download Jmangle:
http://www.elegant-software.com/software/jmangle/download.html

Zelix KlassMaster

"Zelix KlassMaster is a utility written in Java that reads and
modifies Java class files. KlassMaster views, edits, obfuscates, and
unobfuscates. It will run on any platform that supports version 1.1.6
of the Java Virtual Machine. Zelix KlassMaster 2.0 builds on 1.0 by
providing a sophisticated name-exclude facility and an advanced script
interface called ZKMScript, complete with its own interactive wizard."

Download Zelix KlassMaster:
http://www.zdnetindia.com/downloads/info/898255.html

Cinnabar Canner:

"Canner protects your code from reverse engineering by creating a
native Windows executable (EXE file) that contains an encrypted
version of all of your application's classes and resources. The
contents are decrypted in memory as they are requested by the JVM."

http://www.cinnabarsystems.com/canner.html

Download Cinnabar Canner:
http://www.cinnabarsystems.com/download.html

Of course, there are several other similar utilities that you can use
as well. These utilities use many different techniques to obtain (more
or less) the same result. Collectively, they allow conversion to .exe
files (a different process), as well as obfuscation of .class and .jar
files. A comprehensive list is available in the Google Directory:

http://directory.google.com/Top/Computers/Programming/Languages/Java/Development_Tools/Obfuscators/

I hope that the information above gives you sufficient options to
protect your intellectual property. Please let me know if any of the
above information is unclear.

Cheers!

answerguru-ga

---

Request for Answer Clarification by timbo70-ga on 20 Nov 2004 17:14 PST

Thank you, but I need more info.  I have looked at obfuscators, but
they aren't good enough because they dont hide the syntax, and more
importantly, they dont hide my constant values (<-- that is the most
valuable part of my program).  A snooper could still get the jist of
my program.

The Canner app would be perfect... except my program has to run on Linux.

One of your links led to an app called JLock which says it actually
encrypts the code:

http://www.jbitsoftware.com/JBitSoftware/jlockinfo.html

This sounds great, but they don't go into too much detail on their
site.  Do you have any experience w/ JLock, or any similar products? 
Thank you in advance, -t

---

Clarification of Answer by answerguru-ga on 20 Nov 2004 17:35 PST

Hello again,

I have not had first-hand experience with JLock - it does seem to be
conceptually the same as what you're after though. The
cryptography-based methods for protecting bytecode are still *very*
new and have not been widely accepted yet. This is still an emerging
field of research and I don't think I would vouch for any solution
that claims the use of these sort of techniques (simply because there
isn't one that can be certified by any authoritative body).

If your concern is with constant values, I would strongly suggest
parameterizing these values and reading them from a protected resource
on runtime. In other words, obfuscate your bytecode, and use an
encrpytion algorithm of your choice to protect those constants only.
It is generally not a sound practice to hardcode constant values into
your code anyways.

Thanks for your question :)

answerguru-ga

I've thought it over, and the whole thing really needs to be encrypted
- constants, code and all.  So sounds like it's either "try JLock and
pray", or I'm out of luck.  If anyone has any further suggestions,
followup comments greatly appreciated.

very dood answer, really helpful

Obfuscator can not help protect your Java code from decompilers.
Obfuscator can hide valuable names but not hide your logic or
algorithms.

There are a number of Java de-compiler products on the market that do
this task such as Mocha, DJ Java Decompiler, Jad, WingDis, DejaVu,
open source decompiler Jreverse Pro, Cavaj Java Decompiler, JCavaj
Java Decompiler, Decafe Pro, SourceAgain ... etc. They produce
readable source code even though your classes have been obfuscated.

<A HREF="http://www.excelsior-usa.com/jetprotection.html">http://www.excelsior-usa.com/jetprotection.html</A>
Excelsior JET JVM offers a solution but actually it recompile your
java source code and that is not Java program anymore.

The only solution is to create a java secure class loader which does
encrypting/ decrypting classes in the memory.  We got the solution and
is preparing patent it. The secure class loader already apply to <A
HREF="http://www.setecs.com">SETECS</A> products written in JAVA. It
is proven as secure and efficient solution so far.

Even a 'secure java class loader' is not an end-all solution. Anyone
with a little bit of time on their hands and a mediocre amount of java
experience can still crack it.

THE ONLY SOLUTION. Let me repeat this, THE ONLY SOLUTION, to keeping
your code safe from decompilation, dissassembly, theft, etc, is to
implement a service-based business model.

Do not let the sensitive code reside on the client, and the client
can't hack it. If all the client has is a 'stupid' UI that connects in
some way-shape-or-form to a service and retrieves data that way,
there's nothing to crack. Your code remains secure.

Don't let anyone ever tell you they can make your code secure. Quite
simply, they cant. Any code can be cracked. The one stipulation is,
you gotta have the code to crack it. If you give them nothing, they
have nothing: they have no choice but to pay you for the 'service'.