Addendum to “Using OpenSSL for software licenses, revisited”

[Please note: This article originally appeared on sentientfood.com 2-Feb-2005.]

After the initial publication of the article, feedback came my way indicating there were some problems with the scheme that made it fairly easy to crack. “Fairly easy” is a relative term, of course, and it depends on the skill and the desire of the person doing the cracking and any counter-measures that the developer adds on top of the vanilla code available on this site. That being said, some of the points brought up were definitely valid.

Here are some tips, tricks, and approaches to improve the overall security of the licensing scheme.

Tip: Assume someone will crack the license

First, it’s most important to assume that _someone_ will crack the license. Few products can’t get cracked. There should be two goals: make breaking the scheme inconvenient for most casual crackers and make it as difficult and/or annoying to distribute the crack.

Tip: Add something into the hash

Someone determined to crack licenses based on this scheme can set up a debugger to trap the result coming back from re-hashing the “application values” that should be used as a comparison to the decrypted information.

By adding some data into the resulting hash (or taking something away) after the hash but before encryption, you’re making the cracker decipher what modifications you do as well as getting the hash itself. This modification can’t be random (based on the target machine, anyway) but it can be different from application to application, meaning that a crack for one will not necessarily carry over to the next.

Approach: Make the public key private

Yes, this seems odd, but one crack approach (combined with sniffing the hash value mentioned above) involves substituting the existing public key with one of the cracker’s creation. For example, if you’re creating a Mac OS X application, don’t put the public key (or any sensitive information) in any file that will be plain-text in the application package (such as Localizable.strings). This probably seems like a silly, unnecessary warning to old-hat Cocoa programmers, but it’s certainly not obvious to those new to the platform.

In addition, extra steps might be warranted, like breaking the key up into several pieces or otherwise obscuring it in the binary so that a simple search of the executable won’t easily reveal the location for substitution.

Tip: If you use formatting in the license string, strictly check to ensure the format is correct

Getting the correct formatting is not tremendously difficult (especially if the cracker has a valid license to look at). However, if all you as a developer do is check to see if the license is formatted or not and handle it either way, you’ve done part of the cracker’s job for him. If you know your application is going to use formatting, make sure the formatting is there and correct. If the application does not use formatting, reject any license that is formatted.

If you find this useful, entertaining, or otherwise of value to you, consider donating to support the creation of more content like this.

One comment on “Addendum to “Using OpenSSL for software licenses, revisited”

Comments are closed.