Revulytics Blog

Piracy Scene Using New Ways to Bypass Tamper Resistant Licensing (TRL)

September 8, 2010


Many of the ISVs we work with use TRL to help defeat simple license key generators for their applications. TRL, previously known as Counterfeit Resistance Option (CRO), leverages Elliptic Curve Cryptography (ECC) and public and private key pairs to make producing a counterfeit license key generator next to impossible. The idea here is that as long as the ISV’s private key is kept secure, only the vendor itself could generate a signature that the client application could authenticate and work with. Now over the years since TRL’s introduction, we seen some clever methods used to bypass TRL to enable piracy of the application.

  1. Exploit license format backward compatibility in client – In this method the cracker tampers with the application to remove the TRL check and then leverages the existing logic within the application that allows the use of an older non-TRL format license.
  2. Exploit license format backward compatibility in server - Same process as above except that the cracker focuses on the license server. Normally this tactic is used in response to the ISV closing the backward compatibility vulnerability on the client. This is either performed by leveraging an older version of the server that is still compatible with the client or tampering with the vendor’s license daemon itself.
  3. Complete binary tamper – This is a more difficult crack, but essentially the cracker bypasses the entire license checks within the application. This normally requires that every application component linked to license routines be tampered. The cracker may bundle this within a “patcher” utility or distribute new application files.

Each of above methods has been used across a number of high value software titles. However, we have seen a new approach that appears to have emerged within the last year, Public Key Replacement. With this approach the cracker searches the target ISV application components for all references of the ISV’s public key and replaces it with their own generated public key. Then the cracker creates a new key generator (using the license vendor APIs) with a matching private key. At the end of process the Cracker has the ability to generate a license file that appears legitimate to the application. Although this still requires the application files to be tampered, it does not require the same level of reverse engineering as discussed in method 3 above.

- Vic

Activate Your Data-Driven Compliance Program

Add new license revenue by detecting, identifying and converting unpaid users into paying customers.

Victor DeMarines

Post written by Victor DeMarines

Vice President, Products & Strategy at Revulytics

Victor DeMarines brings extensive security product management and marketing experience to Revulytics, where he is responsible for product strategy and direction. He is a frequent speaker and author on topics including piracy, reverse engineering and the protection of intellectual property.