Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Technology Project and PMC » Java Software Protection & Licensing Methods..
Java Software Protection & Licensing Methods.. [message #585578] Thu, 07 November 2002 00:20
David Ryan is currently offline David RyanFriend
Messages: 4
Registered: July 2009
Junior Member
I know this is not exactly on topic, but I've been researching java
software protection and licensing methods. I would be interested in
anyone elses experiences with the problems associated with licensing
java software. I really wasn't sure where to post this to and get some
feedback. If you can suggest better places to post, let me know.

To keep it slightly on topic. I'm curious to know what people think the
effects of CPL on the resulting software when attempting to protect
software that uses SWT.

My initial report is below. Comments, additions, corrections, and
everything in between are most welcome. If you feel this is all way too
off topic or wish to flame that I should be open-sourced and not
protecting a years worth of time and money.. please do it via email. :)

Thanks,
David.

-------------------------------------------------------

Java Software Protection & Licensing.

In order to protect a product we need to add both protection mechanisms
and licensing mechanisms. Protection Mechanisms aim to stop people from
gaining access and reverse engineering the source code, while licensing
mechanisms aim to stop people using the software when obtained illegally.

Protection Mechanisms

Java by design is open and able to be executed on multiple platforms.
Because of this Java is much easier to disassemble than other binary
code. A .jar file which is the normal distribution method for Java
programs is simply a zip file of the classes that make up the program.
Gaining access to the source code is a matter of unzipping the file and
running the classes through a decompiler(freely available on the web)
and much of the source code will be revealed.

There is no way of fully protecting the binary code from decompiling, as
eventually the code must be loaded and executed by the Java virtual
machine. There are however a number of methods designed to slow people
down (hopefully enough to have them give up) from reverse engineering a
Java program.

Obfuscation

There are a number of programs on the web (both commercial and free)
that are designed to Obfuscate the Java classes. They do this by
renaming classes, variables and functions to hide their true meaning.
They also remove unused functions from classes and unused classes to
ensure only code that is used in the product is released. They are also
able to rearrange Java packages into a single package to hide further
the functionality.

Encryption

Using obfuscation hides the functionality of the Java code, however the
obfuscated code is still able to be decompiled. The resulting source
code is much harder to understand, however is still easily decompiled.
Encryption techniques place another layer to make it harder to access
the class files so that they can be decompiled. This is done by
installing a special Java class loader in the program which is able to
load encrypted class files. Decryption is done using a public key or
set of public keys. To ensure these public keys are protected they are
also encrypted. The license key is used to decrypt these keys.

A person wishing to gain access to the source code would need to first
have a license key. Then using this key unlock the public keys, and
then unlock the encrypted Java class files. The other method is to find
the class loader and decompile it and modify it to save the loaded files
after decrypting.

Compiling to Executable

Another method that can be used is to compile the Java byte code into an
executable program. This locks the program to a single environment. It
does however makes it more difficult to decompile to source code, as
much of the information that was contained in the byte code is now
unavailable.

Compiling to Executable may cause some licensing problems as some
licenses like CPL, LGPL, may define the linking of the code into the
executable as a derivative work. Any derivative works of these licenses
must have the source code released.



Licensing

Licensing aims to protect the software from unauthorized use. This is
done using a license key which uniquely identifies the client owning the
software. Different levels of protection can be applied to the license
key to stop use on unauthorized computers. Time based keys for trial
periods should also be available to allow temporary use of the software.

Public Keys Ciphers

Using a public/private key scenario provides a secure way of delivering
credentials of a license. The credentials of the license, such as the
serial number, version and expiry of the product are encrypted using a
private key. The program includes a public key inbuilt which decrypts
the license key. After the data is decrypted, the serial number is
matched against the serial number entered by the user, version of the
product and expiry date. If any matches fail the product does not start.

The credentials that are encrypted can also include the public key
required to decrypt class files used as a method to protect the source
code of the software.

It is important that these credentials are encoded reasonably small so
that the resulting license key is not too large to provide to the user.

License Challenge

Scattered through important locations of the software a challenge checks
to see if the license information is still valid. For server programs
that are long running this is important if the credentials have an
expiry date.
Previous Topic:Java Software Protection & Licensing Methods..
Next Topic:activex
Goto Forum:
  


Current Time: Thu Apr 25 02:35:10 GMT 2024

Powered by FUDForum. Page generated in 0.02693 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top