Stronger Protection with licmax™

License Key verification can be done online via http request to licmax™ or offline using hash algorithms. While one suffices, the two together make a formidable buffer between your application and the pirates. License keys licmax™ generates are a function of the IMEI (PIN) of the device and other parameters that are specific to your product. A copy of your application licensed for a device, can't run on another since the IMEI (PIN) will not match. For maximum protection, we recommend you take the following approach:

• Choose Hashed License Key for your Product Instance configuration. licmax™ provides various industry-standard one-way hashing algorithms and multiple ways to use them to build the key. Choose an algorithm that the intended platform of your application provides.
• Apply the verification process using a combination of Online and Offline methods. The outcome of each applied individually should match. If they don't match, this is a good indication your application has been tampered. This technique foils piracy attempts at server spoofing .
• Randomize the location and time of your verification code. Don't centralize it in one location. Verification of the license key and the decision to halt or continue to run can occur at any point and time of execution of your program. See further suggestions below.
• Use Fetch License Key™ often instead of storing the key on the device. (Be aware Fetch License Key requires an internet connection). Be unpredictable in how often and where and when you fetch the key.
• If your license key is not bundled with the installation (as done by BlackBerry™ App World), be sure it is stored in a manner and location not obvious to someone intent on pirating. Consider using encoded form when passing the license key about in your code so it isn't obvious in a binary debugger.

Obfuscate Your Java Code

Don't let your method names be visible to a decompiler or debugger. Having a method named LicValidVerify.verifyValidity() sticking out like a bright flashing light in the debugger would have your app pirated in no time, unless you use other techniques to detect tampering (see below). While Java API method names themselves still won't be obfuscated, at least your code structure won't be obvious. If you use code obfuscation in combination with name obfuscation, then also your logic will be convoluted for the intent hacker trying to follow at the byte level.

Be sure you understand the disadvantages of obfuscation before you use it. For example, if you plan to issue updates to your obfuscated application, you have to ensure that the names of classes in the new version of your application are consistent with the version originally shipped to end users. When choosing an obfuscator make sure it can reproduce the renames made during the previous obfuscation session.

Inline and Statically Link Your C++ Code

If using C++, you can make your license verification function difficult to identify in the disassembler if you have it occur inline and in a couple of places. Again, depending on the platform, calls to the system APIs may be identifiable, but at least you won't have one centralized function where verification shall always pass. Avoid using a dynamic linked library to house your verification class or functions. DLLs make it easier to hijack your functions replacing them with stubs which simply return imposter's values (eg. "Authorized Permanent").

Don't Be Predictable About When You Verify

A good policy is to avoid verifying in predictable intervals. Verifying your license once every time your application starts up is going to be easier to crack than if you verify a random number of times at random intervals. Use a random number generator so that on any given startup, it verifies zero, one, two or three times for example. Trying to crack the verification when it isn't known when it occurs serves as yet another deterrent.

Don't Be Predictable About Where You Verify

Similar to the previous (When), scattering your license verification requests or checks throughout various sections of your code can effectively frustrate piracy attempts. Making your code inline or have a multiplicity of routines all which perform verification, and call any of them at odd intervals. This way when an attempt to crack your copy protection appears to have succeeded, there will be yet another location and function and time where license verification is still undetected.

Don't Be Predictable About How You Verify

If possible, don't let the intent cracker identify a repeatable sequence of verification instructions. Mix online and offline verification, use different sequences of commands, and perhaps mix other functionality and variables in with the sequence of commands which are making the verification. We appreciate this can be painstaking and fraught with maintenance difficulty. So the extent is your decision. Alternatively, a good code obfuscator could serve a similar purpose here.

Hide Your License Key

Don't allow your licmax™ license key to be identifiable on the file system. Store it in a private location if the platform provisions such, or at least put it in a file the name of which can't be identified as the file where your license key is stored. If someone trying to crack your copy protection can identify in the debugger the location in your code where the license key is read, they can get closer to identifying where the verification occurs and stub that out, or they can try to replace the key with a valid license key from another application.

Disguise Your License Key

Another way to make things difficult for piracy attempts is to handle your license key in some encoded form at runtime. Don't pass it around in its full form in plain ASCII. Wait until the last moment to decode it and perform verification. If using a licmax™ Hashed License Key, consider also encoding your secret passphrase. Do this to make it difficult for someone to identify locations in your code where you are verifying the license key.

Use checksums To Detect Tampering

Assume then, someone does get to the point in your disassembled code where they can insert opcodes to jump around your license verification checks. You can employ checksums on your binary at runtime to detect any tampering. Again, you'll want to disguise this operation and the hard-coded checksum to make it difficult to identify as well.

Summary

The extent of defense against piracy which you implement is up to your own strategy as an application owner. Most likely, you won't elect to implement all these measures, but we hope to provide an arsenal of techniques for you to evaluate for various trade-offs during your product development.

Don't underestimate the abundance of idle minds out there bent on proving they can crack your copy-protection scheme. At least you can make it difficult for all and impossible for most.