FlexNet Publisher Licensing Security
Upcoming SlideShare
Loading in...5
×
 

FlexNet Publisher Licensing Security

on

  • 451 views

Fnp wp lic_toolkitsec_apr12

Fnp wp lic_toolkitsec_apr12

Statistics

Views

Total Views
451
Views on SlideShare
451
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

FlexNet Publisher Licensing Security FlexNet Publisher Licensing Security Document Transcript

  • WHITEPAPER FlexNet Publisher Licensing Security
  • FlexNet Publisher Licensing Security Overview As software vendors and intelligent device manufacturers increase their customer base, product overuse may become more of an issue that costs organizations significant revenue loss. Overuse comes from many different areas, ranging from accidental overuse of purchased products, purposeful overuse of purchased products, to blatant piracy to avoid payment. Often the type of overuse depends on the type of application. Many consumer oriented products are hacked and shared over file sharing networks with the express purpose of avoiding payments, but enterprise applications often get overused simply because the application has no compliance metering built within the application to tell the customer when to stop using the product. The Business Software Alliance Organization (BSA; www.bsa.org) found that in 2010, worldwide software piracy was at 42 percent which translates to over $59 billion in lost revenues. For software vendors and intelligent device manufacturers, this means taking a serious look at ways to protect products from piracy and/or overuse. FlexNet Publisher Licensing (hereafter called FlexNet Publisher) provides several approaches that a vendor can use to protect their products. This paper will group these approaches into three categories: • Flexera Software technology developed to protect against overuse • Development practices to deter, detect and protect against overuse • Policies and procedures around license management This paper will detail each approach so you can determine the best way to protect your hardware and software products. FlexNet Publisher Licensing Security Features Developed to Protect Against Overuse Before drilling down into the different technologies that Flexera Software provides to help the vendor protect against overuse, let’s first start with an executive summary of the technologies that will be explained in more detail later. 1. Tamper Resistant Binding prevents piracy of licensed software through obfuscated machine binding technology. A common practice for vendors is to lock to machine identities like the MAC address, IP address, host name, etc. All of these items can easily be spoofed. Flexera Software’s Composite Host ID allows the vendor to create an obfuscated 12 character ID out of 1-x machine identifiers that make it more difficult for hackers to know what to spoof. 2. Tamper Resistant Licenses leverages an elliptical curve cryptography (ECC) public key algorithm-based signature that makes changing or creating counterfeit licenses almost impossible. 3. Tamper Resistant Application makes use of Secure Data Types (SDTs) to prevent normal operation in the event of modification of the application. SDTs work by encrypting customer defined values within the FlexEnabled application that are crucial to its correct operation. Operations on these encrypted values produce incorrect results in the event of application modification. 4. Debugger Detection Technology allows a program to detect running debuggers before launching. If a debugger is detected, the application will not start up and allow the debugger to examine the executed program. 5. Hardware Dongles (add-on feature) allow software to run only when a “dongle” is attached to an authorized machine. Dongles can be used on a node locked machine and/or on a license server. 6. Terminal Server Lock will allow the software vendors to enable/disable remote use (terminal server) of licensed applications. 2 Flexera Software: FlexNet Publisher White Paper Series
  • FlexNet Publisher Licensing Security 3Flexera Software: FlexNet Publisher White Paper Series 7. Trusted Storage Technology allows the vendor to place a customer’s usage rights into an encrypted file that is locked to a specific machine. It is like having a safe on the customer’s disk that you have control of the contents; not the customer. When the application runs, license rights are verified by checking the contents inside this encrypted file. Essential Activation uses Binding which is a capability used with trusted storage where one or more properties of a system, combined together into a unique identifier, are used to ensure that license rights held in trusted storage are not copied to another system. Each feature brings unique capability to help enhance the security of a FlexEnabled application. Just as most software applications have some bugs, no software can be made completely secure against every threat. With FlexNet Publisher, Flexera Software has developed significant measures to secure the integrity of FlexEnabled products. It must be emphasized that a combination of software, processes and policies is usually the best way to attack product overuse. Tamper Resistant Binding Whether an application is node locked or floating, the license that describes what the customer is entitled to should be locked to ‘something’ so it cannot be replicated onto multiple machines. There are many different items an application can be locked to depending on the hardware and the OS. Common locking mechanisms are Ethernet (MAC) address, IP address, Disk Serial Number, Host Name, Host ID and Dongle ID (Refer to the FlexNet Publisher documentation for a complete list). Many software vendors also lock to other unique ID’s such as a graphic card serial number. These locking capabilities are supplied out-of-the-box with the standard FlexNet Publisher Licensing binaries. Tamper Resistant Binding using the Composite Host ID allows the software producer to combine ‘x’ number of locking items into one obfuscated ID. Consequently, if a hacker tries to spoof the machine, he would have to spoof several items making it almost impossible to succeed. A trick that some software vendors take is to use this capability on a single item like disk serial number. Since the ID is still obfuscated, they get the same level of security without having to lock to more items which could change in the machine’s lifetime. Tamper Resistant Licenses FlexNet Publisher offers a private/public-key algorithm that is recognized by the security community and recommended for US government work (with US government export approval). The algorithm comes from Certicom (www.certicom.com) and uses Elliptical Curve Cryptography Digital Signature Algorithm (ECDSA). Without Tamper resistant licenses, FlexNet Publisher utilizes the standard FlexNet license key, which uses a proprietary, symmetric digital signature method. What is the difference between the Certicom signature and the standard FlexNet Publisher 48-bit license key? The Certicom signature is much more difficult to crack, making it less likely that a license key might be counterfeited. To put this in perspective, Certicom offered a $100,000 reward to crack their cryptography. A team of researchers solved one 97-bit key with 195 volunteers, 40 days of calculation and 16,000 MIPS-years over 740 computers. To date, even the lowest strength level of TRL has not been compromised. Tamper resistant licenses uses a private key known only to the publisher for encryption and offers 3 strength levels: 1. LM_STRENGTH_113BIT--58 character keys 2. LM_STRENGTH_163BIT--84 character keys 3. LM_STRENGTH_239BIT--120 character keys The public key that is used for authenticating the license does not violate any US export law because encryption, no matter how strong, is exportable if only used for purposes of authentication. Tamper Resistant Application Tamper Resistant Application uses Secure Data Types which is a method of adding code obfuscation to a FlexEnabled application by detecting when a hacker tries to change the application binary or change the instruction flow at runtime. This detection is provided by encrypting values within the FlexEnabled application that are crucial to its correct operation. These values are decrypted at runtime by the activation library component when there is a valid license. The parameters whose values are encrypted are defined within the code using Secure Data Types (SDTs). You define product-specific SDTs that are linked to licensed features within the FlexEnabled application. Then the SDTs are used within the FlexEnabled application for crucial parameters including constants. A product-specific version of the activation library is created so that it is bound to the FlexEnabled application that contains the SDTs. The method used for binding provides a code obfuscation defense against static and dynamic analysis of the application code. Static analysis is examination of the executable code when it is not executing, that is, on disc, and dynamic analysis is examination of the executable code while it is running. Thus, it provides a defense against reverse engineering of a product. View slide
  • FlexNet Publisher Licensing Security 4 Flexera Software: FlexNet Publisher White Paper Series Debugger Detection Technology The activation library can also provide some additional security by using Anti-Debugger Technology (ADT). This code attempts to prevent the use of debuggers and system tracing facilities while the executable is running and therefore make dynamic analysis more difficult. ADT operates at the operating system level. It can be turned off if it is not required, for example, for products that require the use of debuggers. This type of protection is platform- specific and the level of security it can provide varies widely between platforms. Hardware Dongles Another way to license where your application will run is with a hardware dongle. If a license is to be moved between different machines, it can be node-locked to a FlexNet ID (a dongle that connects to a parallel or USB port). This license can be moved among machines by installing a copy of the license file on each of those machines and moving the FlexNet ID from one machine to another. The Dongle is one of the most secure ways to lock an application to a specific location. Hardware dongles are encoded with a secure ID that is extremely hard to break. This allows the license to use that ID as its locking ID. For added protection, FlexNet Publisher requires a handshake with each USB FlexNet ID device. This handshake assures FlexNet Publisher that the ID being returned comes from authentic hardware and not a spoofed USB driver. While some companies have been trying to move away from hardware licensing solutions, the Dongle is still one of the best ways to create a secure ID that can’t be changed. Terminal Server Lock FlexNet Publisher detects when a node-locked, uncounted license is running under Windows Terminal Server. To allow your FlexEnabled application to run via a Terminal Server Client window (e.g., a Thin Client), the license is node- locked to the Terminal Server machine and the TS_OK keyword is added to the license. For example: FEATURE loadrunner <vendor id> 1.00 1-jan-2008 uncounted HOSTID=ts_hostid TS_OK SIGN=sign There are two ways to access a Windows Terminal Server (host server): 1. through the thin client “host session” (where you see the actual desktop of the host) or 2. through the thin client “guest session” (where each session gets its own unique desktop). The TS_OK keyword is not required for an application to check out a license when using the host session. An application can checkout a license with the TS_OK keyword from a terminal services client associated with the host session or with any guest session running on the terminal server. Consider the scenarios where a FlexEnabled application is installed on a Terminal Server machine with its license locked to Terminal Server machine’s hostid. • The application successfully executes directly on the Terminal Server machine, whether or not the feature line contains the TS_OK keyword. The license is checked out as though it was a regular node-locked license. • If the feature line does not contain the TS_OK keyword and a user tries to run the application from a Terminal Server Client window, an error is generated (License fails to checkout). • If the feature line contains the TS_OK keyword and one or more users try to run the application from a Terminal Server Client window, the license is checked out and the application can run. FlexNet Publisher does not limit the number of Terminal Server Clients that can use this node-locked license. A keyword (i.e., One_TS_OK) is available on FlexNet Publisher that allows only one remote session to check out a feature at a time. Counted licenses behave on a Terminal Server Client as they do on any other machines on a network. Trusted Storage FlexNet Publisher uses trusted storage as a secure storage area used to store license rights (Entitlements) and other licensing information. Trusted storage is an encrypted file that is controlled by the vendor and is bound to a given machine so the rights cannot be used anywhere but the location the vendor placed those rights. Several protection mechanisms are used to protect trusted storage from being tampered with: 1. The trusted storage file is encrypted 2. Items within trusted storage are digitally signed 3. Fingerprinting technology is used to identify the machine where trusted storage is suppose to be located 4. Binding is used to lock license rights to a machine and preventing those rights from being transferred illegally to another machine. This is implemented by storing identities obtained from the machine in trusted storage. Each time trusted storage is accessed, these binding identities are checked and compared with the values held in trusted storage. Then a decision is made, based on the relative security of the binding identities used, whether trusted storage security has been compromised and needs repair. Multiple binding identities are available depending on the specific operating system. Flexera Software has done extensive research to determine the binding identities that are used and their relative weights. View slide
  • FlexNet Publisher Licensing Security 5Flexera Software: FlexNet Publisher White Paper Series 5. Anchoring is a link between the system and the trusted storage that is used to detect whether trusted storage has been tampered with, deleted, or restored. Anchors are also used to ensure that information in trusted storage about trial licenses persists beyond the expiration date. Development Practices to Deter, Detect and Protect Against Overuse In this section we will discuss different development approaches that can be taken to secure an application. As stated above, Flexera Software does not claim that this will make an application hack proof, but it can make your application hard enough to hack that it won’t be worth the effort to do so. 1. Protecting against a hack to the Flexible API At times, hackers will try to circumvent the lc_checkout call because that is where the software application would call to check the validity of the license (whether it is allowed to run or not). Typically, calling a routine that does this check will often times return a Boolean value (TRUE or FALSE) or an integer where zero usually means “OK”, and a non-zero means there is an error. Hackers could find the routine and simply change it to immediately return “OK”; and the program will always run and won’t even bother to check for a license. A good protection against these kind of hacks must ensure that such simple patching does not work by doing an indirect verification of the result. One mechanism to safeguard licensing binary decision points is to use Secure Data Types. By placing an anchor around the licensing feature(s) in the software application, one can continue doing the licensing checkout call and validate the result as normal; but at some point in the software application lifecycle, the application must ensure that the anchor or the secure data types that are associated with the licensing feature(s) did not return a random result. 2. Malloc feature names Make sure your feature names are not “clear text” strings, as a hacker can easily add a more expensive feature in place of a less expensive feature name. The feature names should be malloc’d, and then sprintf’d. For example, assume the feature name is “feature1”: char *feat; feat = (char *)malloc(20); sprintf(feat, “%s%c%c%s%d”, “fea”, ‘t’, ‘u’, “re”, 1); CHECKOUT(..., feat, ...); 3. Disable or modify features with expiring demo licenses The most common mode of shipping demo licenses is a FEATURE line that enables each feature with an expiration date in the near future. This line typically has a hostid of “DEMO”, and a count of 0: FEATURE ... 1-jan-2005 0 ... HOSTID=DEMO While FlexNet Publisher’s built-in security is robust, we recommend that the application use the FLEXible API. After determining the checkout was enabled with a DEMO FEATURE line, it should limit or modify behavior in such as way that the product is not really useful. A famous real- world example is the word-processing program that prints “EVALUATION” in gray diagonally across every output page; the evaluator can fully evaluate the program, but it has no real utility. 3A. Prominently display expiration date After a successful checkout, call: conf = lc_auth_data(job, feature) to get an authenticated copy of the CONFIG struct that authorized the checkout. Put the expiration date (CONFIG->date) in a prominent place in the GUI so the date-setback detection is more public. 3B. Provide an insistent reminder If it is an expiring evaluation version, periodically do something annoying—perhaps a popup that appears every few minutes which encourages the user to purchase the product. 4. Use heartbeats Heartbeat messages are strongly recommended for client software to prevent checkout of licenses from a restarted server, thereby reducing over usage. If FlexNet Publisher heartbeats are used, the client will automatically reconnect and re-checkout its license from a server that has restarted. It also informs the application of a number of states that may indicate attempted tampering with the license server such as system date changes.
  • FlexNet Publisher Licensing Security 6 Flexera Software: FlexNet Publisher White Paper Series 4A. When HEARTBEAT function fails, exit or freeze the application Stopping and restarting the server is a way of getting extra licenses. A way to prevent this is via the HEARTBEAT function. Make sure it’s called regularly (at least once every 5 minutes), and exit when it fails for, say, 10-20 minutes, depending on your application. Be sure to warn the users to what is happening, and to save their work before exiting. 4B. Use “ret_num_reconnects, minutes” arguments to lc_heartbeat() Use the lc_heartbeat() FLEXible API call, and utilitize these 2 arguments. When used properly, they prevent the hacker from stopping and restarting the server many times in a few minutes, which is another way or getting extra licenses. 5. Call lc_auth_data and make sure it looks correct. After a successful checkout, call lc_auth_data() on the feature checked out. Since lc_auth_data() only works for features which have really been checked out, if the function returns NULL, you’re being spoofed. This prevents some simple hacks in the server that would always return ok on a checkout. Another approach hackers take is to spoof the license. They will typically try to set the host id to ‘ANY’ or ‘DEMO’ which allows the license to be used on any machine. They will also set the expiration date to ‘permanent’ as well, so your application should check against licenses that take the form of: FEATURE <feature name> <vendor> <version> PERMANENT HOSTID=DEMO or FEATURE <feature name> <vendor> <version> PERMANENT HOSTID=ANY If the license has these traits you know that you have been hacked and should shut down the application. Additionally, check for ANY or DEMO HostID whose days to expire is beyond any normal amount you might offer. For example, a license that expires more than 30- days after the current date when, at most, you ever issue a 30-day evaluation. 6. Put customer name in the license and present in splash screen. If someone steals a license and runs it on a machine with a changed hostid, the customer name appearing indicates that it’s a stolen license. 7. Check to make sure the checkout calls haven’t been hacked. To protect the application from hackers trying to hijack the checkout calls, make an extra checkout call against a feature that does not, nor ever will, exist. If the checkout is successful, then you know something is wrong. 8. Use a “splash-screen” to identify the user. This makes the user of a stolen license more aware of this. And will prevent a single “free” license from being used at “respectable” sites. • Require NOTICE=”” (lc_notice) in CONFIG struct • Display contents of NOTICE=”” prominently, using lc_auth_data(). 9. The following ensures that the license-key is being checked. After successful checkout, use the following outline: CONFIG *c, ctemp; int i; VENDORCODE code; lc_new_job(...&code...); lc_checkout(...”myfeature”... &code...); if (!c = lc_auth_data(job, “myfeature”)) { this should succeed and return a valid CONFIG struct ... it’s a security problem if it doesn’t } status = lc_checkout(...,LM_CO_QUEUE,...) switch (status) { case 0: break; /* got the license */ case LM_MAXUSERS: case LM_USERSQUEUED: case LM_FEATQUEUE: printf(“Waiting for license...”); while (lc_status(job, feature)) { /* processing */ } break; /* got the license */ default: lc_perror(job, “Checkout for license failed”); }
  • FlexNet Publisher Licensing Security 7Flexera Software: FlexNet Publisher White Paper Series 10. Adding security to application binaries When the UNIX strip command processes a dynamically linked binary, it leaves external symbol names intact in case they are referenced from a shared library. Using lmstrip on a dynamically linked binary increases security because it obfuscates all Licensing symbol names that UNIX strip leaves intact. If any external Licensing symbol is referenced from a shared library (which is very rare), use lmstrip -e. This command leaves the Licensing external symbol names intact but still obfuscates the internal Licensing symbol names. Because symbol names do not appear in fully linked Windows binaries, this procedure is not needed on Windows platforms. You can now safely ship libraries to your customers. When your customer links their objects to licensing libraries, calls are resolved correctly and the temptation to alter the libraries and/or functions is reduced because the function names are not meaningful nor deducible. 11. Add private security information to the VENDOR_ STRING=”” (or another secure text field in the license file) This could be a proprietary encryption of the FEATURE line, possibly using RSA encryption. This feature line could be checked at run-time and appropriate action taken when the key doesn’t match. It could also only be used during an “audit” to find counterfeit licenses. The latter approach is more secure, since no one would ever see the key verifier code used, except the license auditors. The most secured approach is to add two keys, one which is checked and one which is not checked. 12. Provide additional security when implementing trial licenses in trusted storage Trial licensing allows potential customers to try out your product for a limited time before purchasing a full license. If your application is configured for trusted- storage-based licensing, you provide the customer with an Activation Specification Record that defines license rights for the trial. The Activation Specification Record requires the following elements in its data dictionary to configure these rights for trial usage: • PUBLISHER_DEFINED_CRITERION set to LOCAL_ ONCE to ensure that the license rights for the trial are installed only once. • PUBLISHER_DEFINED_DURATION set to a positive value that defines the time limit for the trial license. Additionally, to prevent your application from executing if trusted storage is deleted or overwritten, you should configure a trial anchor in the Activation Specification Record. A trial anchor stores information about the trial on the customer’s machine. This information is retained on the machine even after trusted storage is deleted, thus preventing an unauthorized attempt to reload the trial. To define a trial anchor in the Activation Specification Record, use the PUBLISHER_TRIAL_ID data dictionary element, and increment the Trial ID for each new trial. Along with configuring a trial anchor, you should implement these best practices: • Never generally release an Activation Specification Record that includes the PUBLISHER_TRIAL_RESET data dictionary element. This element is meant for use in your testing environment only; serious security breaches can occur when this element is present and enabled in the Activation Specification Record you provide the customer. • Embed (and obfuscate) the Activation Specification Record in your application deliverable. • In the activation utility delivered along with your application (and used to activate the customer’s trial license), specify the flxActCommonLicSpcAddASRFromBuffer function to load the licenses. 13. Java There are special security considerations for companies using FlexNet Publisher for Java, because there aren’t many possibilities for node-locked hostid types in the Java environment and Java applications can be relatively easily decompiled. Flexera Software recommends that enterprise customers use a license server rather than using node-locked, uncounted licenses. When using the Java binaries, it is mandatory to use the Tamper Resistant Licenses (TRL), to reduce the possibility of counterfeit licenses. TRL utilizes Certicom’s public-key system based upon elliptical curve cryptography (ECC), which is considered secure, fast, and efficient (see www.certicom.com). Also, some of the application protection practices below can help protect a Java application: • Check out a feature that should not exist. If you get a response indicating the user should have access to that feature you know the license component of the application has been compromised. • Never decouple licensing from the whole application. In fact, it is good practice to put licensing with some of the major functions of the application. This way if someone tries to remove the license call, they may also remove other important parts of the application. Another protection scheme for Java is to use a third party obfuscation product. There are several on the
  • FlexNet Publisher Licensing Security 8 Flexera Software: FlexNet Publisher White Paper Series market like Preemtive and Zelix. Code obfuscation will help protect an application from being changed reviewed or changed. 14. Use Tamper Resistant Application technology or SDT SDT technology is available through Tamper Resistant Application and provides more comprehensive security against many types of attacks particularly binary image patching. Since static patching of publisher licensing binaries is a very common method of attack, it is strongly recommended the software vendor include SDTs as part of an overall security strategy. While no technology is hack-proof, SDTs provide and extra measure of security. 15. Development practices to deter, detect, and protect against overuse Don’t use shared libraries or Dynamic Link Libraries: We discourage the use of wrapping the licensing functionality in a single DLL that can be easily replaced by a hack. If DLL use is necessary, embed some of your application’s core functionality, along with the licensing functionality, in the same DLL. That way, if the DLL is replaced by a spoofed version, loss of core functionality will result. Policies and Procedures Around License Management Many companies trying to protect their software have found that simply throwing technology at the problem then forgetting about it has been a failing approach. Customer demands for purchasing products changes over the years which have dramatic influences on packaging and license models. To keep up with these changes, the policies and procedures around licensing also need to change. In this section, we will discuss several processes that can be adopted by vendors to protect their intellectual properties while supporting the dynamic changes of their customers. Expire licenses The hardware environments of enterprise customers are dynamic with machines frequently added, upgraded and retired. The supporting licenses for the software on those machines also have a life of their own. Often hardware needs to be replaced, forcing software to be moved from one machine to another. Depending on the license technology, this can cause issues with the vendor because it is difficult to remove the licenses from the old machine before granting new licenses on the new machine. To protect against this, the vendor should consider expiring their licenses once every year or two and deliver new licenses for the machine(s) they have on record. This process protects the vendor by only being open for abuse between the time of the rehost and the license expiration date. For software vendors that charge for maintenance, this is an ideal time to send the new license. Once the maintenance is purchased, the appropriate license(s) are sent to the customer. A good practice is for the license to expire a few months after the intended maintenance purchase cycle closure date in case the purchase cycle takes longer than expected to finish. Strictly speaking, this process is only necessary if the customer asks to rehost their licenses. But, since this won’t be known ahead of time, consider providing expiring licenses as a standard policy to protect your company. In mission critical applications, the vendor must decide if this process is appropriate and the specific procedure to bring down an application if the license has expired. Lock licenses to maintenance dates Software maintenance is a major cost to any software vendor and is often funded by maintenance revenues. To protect those revenues, the license should lock to a specific version of the product, or even better, expire when a customer’s maintenance agreement ends. If a customer gets software updates while on maintenance, then the license should allow all software that was built before that date. The license should have a way to embed the customer’s maintenance agreement date and check the software for compliance to that date. If maintenance is repurchased on a given interval, the appropriate license(s) should be sent to the customer to reflect the new date. Set limits on the number of rehosts and emergency licenses Over time, software may be permanently or temporarily moved from one machine to another. Some of the reasons for temporary licenses may be: 1. Machine where license or software is located needs maintenance 2. Short term machine failure 3. Customer is in the middle of a purchase cycle but the evaluation licenses are expiring 4. Evaluations Reasons for long-term licenses that need to be created for new machines may be: 1. Upgrade of hardware 2. Moving licenses from one department to another 3. Load balancing license servers There are usually identified patterns for each of these scenarios that allow policies to be set on how often to permit any of these license changes to occur. Often, if the customer is within the policy limit, they can self-service these license changes, but later talk to someone in a license fulfillment role. It is essential for vendors to track these patterns and use trends to refine policies to minimize abuse. If a customer is rehosting their licenses too often, they are a good candidate for an audit or at least a conversation with their sales rep.
  • FlexNet Publisher Licensing Security 9Flexera Software: FlexNet Publisher White Paper Series Software updates as an overuse tracking mechanism Some companies have found that when they implemented software updates, the number of machines being updated outnumbered the quantity of applications sold. This identified the number of overused copies of their application. To formalize this process to discover overuse, the updating service should send back the serial numbers for your product so you can find out if this is a widespread issue or simply one or two serial numbers on the share networks. Final note and warning! The information contained in this document, while not exposing anything new, could be used by a determined hacker to more easily crack your licensing scheme. Release of this document into the public domain reduces the effectiveness of the techniques described for all vendors. About Flexera Software Flexera Software is the leading provider of strategic solutions for Application Usage Management; solutions delivering continuous compliance, optimized usage and maximized value to application producers and their customers. Flexera Software is trusted by more than 80,000 customers that depend on our comprehensive solutions- from installation and licensing, entitlement and compliance management to application readiness and enterprise license optimization - to strategically manage application usage and achieve breakthrough results realized only through the systems-level approach we provide. For more information, please go to: www.flexerasoftware.com
  • Flexera Software LLC 1000 East Woodfield Road, Suite 400 Schaumburg, IL 60173 USA Schaumburg (Global Headquarters): +1 800-809-5659 United Kingdom (Europe, Middle East Headquarters): +44 870-871-1111 +44 870-873-6300 Australia (Asia, Pacific Headquarters): +61 3-9895-2000 For more office locations visit: www.flexerasoftware.com Copyright © 2012 Flexera Software LLC. All other brand and product names mentioned herein may be the trademarks and registered trademarks of their respective owners. FNP_WP_LicToolkitSec_Apr12