License security in Java, don’t be the easiest target

Java based enterprise products that are not open source have a big issue with Intellectual Property Rights license protection. The relative ease of byte code decompilation makes it easy to copy the product with the license protection disabled. One can measure the magnitude of the problem just by counting the number of products that claim to have the solution. Dongle, code encryption or machine signatures are popular techniques for license security. However, there is always that weak link, that single validation method, returning a Boolean that checks the existence of the license.

A friend of mine once suggested that instead of striving to be perfect, it’s better to invest just enough to avoid being the easiest target. It’s easy to spot this strategy in nature. If you happen to be a wilder beast, you don’t have to be the fastest runner to survive. Just make sure there are a few others slower then you. If you are a zebra, just go stand next to the wilder beast. When I park next to a Lexus, I don’t bother to lock the doors.

The way to implement this strategy over software licensing is by understanding the domain of product hacking and license cracking for enterprise installed software. The goal would be to introduce enough complications in order just to become “not the easiest target”.

Understanding the domain

A business would choose the illegal options of requesting a hacked product if they are far enough or obscure enough from the hands of the IPR owner and only if the cost of the cracked software is considerably lower than the license fee.

The basic interaction with a hacker is; “I give you money and you give me a working version of the product without the license verification part”. Since any single method is prone to be broken eventually, sooner or later the hacker will deliver the “goods” as promised; a cracked version of the product.

The weakness in the hacker’s ‘user story’ is that although the hacker is a master in the technology he employs, he knows nothing about the domain of the product. Thus, obscuring and masking the validation for the license into multiple points in the business logic is an advantage for the IPR owner.

Create an illusion

By all means, use all the conventional protections; obfuscate the code so it won’t be a picnic after JAD (Java De-compiler). Encrypt and put signatures on the classes that handle the license, and so on. Make the hacker sweat a little, in his comfort zone, before he delivers a hacked version that is not really cracked.

Take no immediate action

The easiest way for a hacker to pinpoint the license validation code, is by the actions that are taken by your software when the license is invalidated. The easy points to spot may be log messages, explicitly stating the lack of license or the point where the system freezes up, that’s where the hacker starts his reverse engineering. Instead, do the unexpected. Randomization of decision (heads to freeze, tails to grace), Postponing the enforcement action, and reusing the validation variables for other purposes would make the hacking task so much harder.

Dead code

Implanting license validation code is business logic that is called upon in very specific conditions is probably the best cloaking method. The way to reveal license validations that are hidden in obscured parts of code would be to run every possible scenario. The hacker would have a learning curve to adjust to the unfamiliar domain, in the mean while the business that bought the hacking would suffer more than one production cycle that goes bad on account of licensing.

No Code Reuse please

As code reuse makes code more readable, the way to secure the license validation would be the exact opposite. Repeat the functionality of the validation without referencing or even repeating the code.

In summary

The bottom line is money. The price of an acquisition of a legitimate license compared to the price and risks involved in deploying a hacked version. All you have to do is break the hacker’s promise of his delivery. Instability and unpredictability in a hacked product, and an expensive hacking process can bring you just far enough from being the easiest target.