Fnp wp lic_toolkitsec_apr12

1. WHITEPAPER
FlexNet Publisher
Licensing Security

2. 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

3. 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.

4. 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.

5. 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.

6. 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”);
}

7. 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

8. 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.

9. 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

10. 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