|
|
| Home | Product Evaluation | Resources | Contact Us |
May 22, 2002. Burlington, Ontario, Canada
This paper discusses code protection, a subject that can easily be misunderstood. In order to understand code protection, it is best to review it's related topics separately, as follows.
Let's talk about each of these items.
Software vendors want to prevent illegal distribution of their software. One approach is to split the product into several parts. For example, part of the installation of a product on a given system is customized for that particular computer, therefore using a copy of that installation makes it impossible to use on another system. Customization might mean using local fixed folders or even specific hardware classes or model numbers. It is even possible on proprietary systems to tie a specific hardware serial number or CPU ID number to code to confine that copy of that application to that specific system. Some vendors are using unique hardware tokens with each individual copy of their application.
Therefore, for vendors to ensure their product will run on specific hardware, the vendor only has to validate the application configuration environment. This is hardly failsafe, but still useful. Often coupled with this form of copy protection is license validation, the next logical protection to use
Application vendors always like to ensure that customers only run the level of product they pay for. This includes limiting applications to a specific hardware platform for execution; limiting the specific number of host systems that may run the application; limiting the number of client connections a server may permit; or limiting the length of time a license is valid.
With any of these validation scenarios, application developers have to implement some internal logic that uses an external entity (for example: configuration setting, date/time, total # users) to determine if the application is still licensed, and therefore available to the end user. This external entity therefore becomes the real license as it permits differentiation between clients. All clients effectively get the same code base (on CD or downloaded), but utilization is on a different basis. Some clients order and pay for the full enterprise version and others request a demo version. This scheme allows the vendor to maintain a single code base but yet still enable control over who can use the application. This is a very attractive product management and engineering paradigm.
Unfortunately for some type of external entities, they can easily be changed in order to gain access to the application. For example, if the license is just a configuration file, it is easy to edit and make changes either programmatically or using an editor. For time based licenses the system date can be changed. For system serial numbers a hack using a privileged mode is usually attainable. Therefore, licenses themselves need to be protected, and it is unwise to use anything that cannot be protected outside the application.
The license generator has to make sure that some of the following capabilities are enabled:
These three capabilities will only be safe if the license verification code itself is protected.
The Java world has presented a huge challenge for vendors who like to protect their important application assets. Java bytecode is very well documented and standardized. There are many tools available to reverse engineer Java bytecode into source. This means it is very difficult to hide anything in Java - especially license validation code.
Most license validation is usually done using embedded logic within an application. Unfortunately this logic can be changed. To make this more difficult to change, many developers try to distribute license validation code throughout the application and then try and make their code unreadable.
Of course there is no absolute protection, but there are some things that can be done to make an intruder's life very difficult.
Static bytecode obfuscation makes code difficult to read by changing the names of classes, methods and variables to meaningless objects. Some obfuscators even scramble bytecode to hide the logic but this often causes performance degradation. Unfortunately obfuscators can't really change code syntax, and therefore an "if statement" will still be an "if statement", and it is still possible to de-compile code and change that "if" statement logic as it pertains to licensing.
Dynamic protection is available, based on multi-layer class loading where bytecode never appears as an accessible file, but is loaded on the fly by a chained class loader from secure storage that is only available at runtime.
Saffeine solves the issues described in the previous sections.
Saffeine uses encryption to split a single distribution unit into several independently licensed modules. In this scenario the license does not include a decryption key for the unlicensed module, so there is just nothing to break.
Code is hidden behind the Saffeine runtime environment and doesn't appear in a jar file, so it is more difficult for the intruder to get access, change the code and run without limitations, unlike today's traditional jar archive.
Secure runtime gives a lot of flexibility for implementing additional checking for other license parameters and for license verification itself. Of course that security is not absolute and still could be broken but it will be many degrees more difficult than for simple obfuscated code. Saffeine can also protect obfuscated code, and this only serves to increase security even more.