Floating License Management - A Review of FlexLM

DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES

FLOATING LICENSE

MANAGEMENT

A REVIEW OF FLEXlm

PREPARED BY:

SALYS SULTAN

June 30th, 2006


Table of Contents

ABSTRACT 3 1.0 INTRODUCTION 4

1.1 LICENSING POLICIES 5 NODE-LOCKING 5 USER-BASED LICENSING 5 SITE LICENSING 5 NETWORK LICENSING 5 1.2 LICENSE MANAGEMENT 6

2.0 FLEXLM, FLEXIBLE LICENSE MANAGER 8 2.1 OVERVIEW 8 2. 2 COMPONENTS 8

License Manager Daemon ( lmgrd ) 9 Vendor Daemon 9 License File 10 Client Application Program 10

2.4 THE LICENSE FILE 11 SERVER lines 12 DAEMON lines 12 FEATURE lines 12

2.5 LICENSE FILE TYPES 13 2.6 THE OPTIONS FILE 14 2.7 FLEXLM STANDARD ENCRYPTION ALGORITHM 15 2.8 HOW IT ALL WORKS? 15 2.9 SEED HIDING SYSTEM 16

3.0 FLEXLM – THE OTHER SIDE 18 3. 1 LIMITATIONS 18 3.2 THE REVERSING 19

Generating the license key that belongs in the license file 19 Disabling Verification 20 Emulating the Vendor Daemon 20 Extraction of seeds FLEXlm protected targets 21 Decryption of FLEXCrypted Files 22

3.3 WHERE ARE THEY NOW? 22 4.0 RELATED TECHNOLOGIES 23

4.1 AUTO-X 23 4.2 HASP HL NET USB KEY 24 4.3 IBM LICENSE USE MANAGEMENT (LUM) 24

5.0 RECOMMENDATIONS 24 6.0 SUMMARY 25 BIBLIOGRAPHY 25


Abstract

This paper presents an overview of license management that is used for the protection of

software products. This mechanism falls into the software-based protection category. The

emphasis is on the Flexible License Manager (FLEXlm) system. It highlights the different

components of the system as well as describes the license request process. The paper also

provides an analytical view of some methods employed to secure the system and how they

can be reversed. Finally, some recommendations of a desirable software protection system

are concluded based on the analyses of different methods.


1.0 Introduction

The first models of software licensing developed in the days of stand-alone computing and

million dollar computers included licenses were fixed to a particular CPU, prices of software

licenses increased as the computer's performance increase and limiting the number of copies

of software made to disk or tape was important as this was seen as an exhaustive and

expensive task.

When PCs became popular in the early 1980s, PC software vendors kept this earlier view of

licensing software with the exception of pricing based on CPU performance. However, with

the rapid evolution and market acceptance of networked computing in the late 1980s, the

industry was forced to rethink what software licensing means in a networked environment of

workstations, servers, and terminals. With this concept of software licenses, system

administrators could keep track of software by limiting the copies of software to hard disks

that were directly attached to licensed CPUs. Networked file systems made this view of

licensing obsolete.

The new workstation customer called for a new wave of software licensing. Software was

now seen as a network resource, therefore licenses "float" on the network. Software costs

were defined in terms of how many users simultaneously run the software, as opposed to

pricing based on number of users or CPU performance. Furthermore, actually value existed

in the use of software and not in the number of copies on disk.


1.1 Licensing Policies

License managers embody the licensing terms of a developer into software and data files.

Licensing terms refer to the specific manner in which the software is to be used. To

understand license managers, it is important to understand the common types of licensing

policies used today by software developers.

Node-locking This was once the most common form of licensing. It parallels the view that software is

licensed to a particular computer. This licensing model is usually found in computationally

intense applications and with software used on workstations dedicated to a particular

application.

User-based licensing This form of licensing assigns a given license to a named user identification. This is useful

for products that are user dependent, such as an e-mail product, or business transaction

applications or any other application in which "lending" user identification conflicts with the

very nature of the application.

Site licensing This involves licensing software to a geographical site. This model can be used for example,

in a company with a large corporate campus where multiple sites are defined. Site licenses

are most appropriate when companies standardize on a specific product.

Network licensing This model also know as “floating licenses” is almost synonymous with license management.

Floating licenses fit very well with the concepts of networked computing due to its efficient

matching of usage to the number of licenses sold. Users can have access to a software

product, but the cost of this access may be the price of a few licenses. As the software

becomes widely used, additional licenses are purchased.


Floating licensing provides benefits for users, administrators and vendors:

• Users have access to the shared resource, versus limiting access to those with a

license on their workstation.

• Administrators can control the node(s) where the licenses will be available across

heterogeneous networks.

• Vendors can control who uses the licensed application.

Other licensing policies include specifying an "expiration date" or a "start date" for licenses.

This type is often used in software evaluations or leasing programs.

There is no "right" licensing policy for all products. Software developers decide policies

based upon the way the software product is designed and used, and commercial competitive

factors. Sometimes the same software may be licensed in many different ways depending on

the users needs.

1.2 License Management

License management differs from software "copy protection" used in the PC marketplace by

controlling execution instead of copying. Research has shown that PC users rebelled against

copy protection because the practice inconveniences honest customers while giving them

nothing in return. In contrast, UNIX customers pressure software developers to provide

them with license management because it makes software a network resource and makes

software pricing more equitable.

The new models of licensing require dynamic tracking of users and software licenses. The

technology that does this is called a license manager. Without license management technology,

it is unfeasible for a system administrator with a network of even ten workstations to

monitor of how many floating licenses are used concurrently.


Workstations today are on large heterogeneous networks, and license managers may be

called upon to serve hundreds or thousands of licenses at one time. These networks may

support workstations from Microsoft, Sun, HP, IBM, etc. In addition, many applications run

on several different workstations. The license manager should allow licenses for Sun

applications to be shared with the HP and IBM workstations; if the software developer so

chooses.

Some of the first license managers were special purpose license managers written by

software developers for their own products. Today, however, software developers rarely

write their own license manager. Instead, they license commercially sold license managers,

such as FLEXlm (a contraction of FLEXible License Manager) to assist in the

administration of license usage.

License management is a growing trend and most system administrators prefer to learn and

use only one license manager for controlling applications at their sites, rather than learning a

different one for each licensed product. Even developers with their own license manager

switch to standardized package like FLEXlm because of requests from their clients for them

to be consistent with the commercial license managers.


2.0 FLEXlm, Flexible License Manager

2.1 Overview

FLEXlm is a network license manager used by many software developers to control the use

of their software products. It allows software licenses to be available (float) anywhere on a

network, instead of being tied to specific machines. It was originally developed by

Globetrotter Inc., FLEXlm is now owned by Macrovision and has now been renamed to

FLEXnet. It is commonly used for the management of licenses of electronic design

automation software, normally on computers running on both UNIX and Windows

operating systems.

2. 2 Components

FLEXlm consists of the following main components:

• License manager daemon

• Vendor daemon

• License file

• Client application

These components are illustrated in Figure 1.0.


Figure 1 - FLEXlm System Components

License Manager Daemon ( lmgrd )

The license manager daemon ( lmgrd ) handles the initial contact with the client application

programs, and passes the connection on to the vendor daemon. It also starts and restarts the

vendor daemons. FLEXlm permits multiple redundant license manager daemons on

different server nodes, allowing you to make your license available only if any two out of

three server nodes is running. The lmgrd eliminates the necessity of splitting your licenses

among multiple servers or of relying on any one machine.

Vendor Daemon

In FLEXlm, licenses are handled by running processes. There is one process for each

vendor who has a FLEXlm-licensed product on the network. This process is called the

vendor daemon. The vendor daemon keeps track of how many licenses are checked out, and

Vendor Daemon

License(s)

Debug Log File

Options File

Report Log File

License Server Manager

Application Code

FlexLM

Licensing C

lient Library

TCP/IP

FLEXenabled Application

License Server System Components


who has them. If the vendor daemon terminates for any reason, all users lose their licenses.

Users normally regain their license when lmgrd restarts the vendor daemon.

Client programs communicate with the vendor daemon through TCP/IP or UDP/IP

sockets. The client (where the application runs) and the daemon processes (the license

server) can run on separate nodes on your network. Also, the traffic between the client and

the license manager daemon is machine-independent, allowing for heterogeneous networks.

This simply means the license server and the workstation running an application can be

either different hardware platforms or different operating systems.

License File

Licensing data is stored in a text file called the license file. The license file is created by the

system administrator. It contains information about the server nodes and vendor daemons,

and at least one line of data (called a FEATURE line) for each licensed feature. Each

FEATURE line contains an encryption code based on the data in that line, the hostids

specified in the SERVER lines, and other vendor-specific data.

Client Application Program

The application program using FLEXlm is linked with the program module (called the

FLEXlm client library) that provides the communication with the license manager daemon.

During execution, the application program communicates with the vendor daemon to

request a license.


2.3 License Request Process

The following describes the sequences of events that occurs when you run a FLEXlm -

licensed application:

1. The license module in the client application finds the license file, which includes the

host name of the license server and port number of the license manager daemon,

lmgrd.

2. The client establishes a connection with the license manager daemon ( lmgrd ) and

tells it what vendor daemon it needs to talk to.

3. If the license server is a redundant server configuration, the lmgrd determines which

machine and port correspond to the master vendor daemon and sends that

information back to the client.

4. The client establishes a connection with the specified vendor daemon and sends its

request for a license.

5. The vendor daemon checks in its memory to see if any licenses are available and

sends a grant or denial back to the client.

6. The license module in the application grants or denies use of the feature, as

appropriate.

Once the license is valid, the user can access the program and or feature.

2.4 The License File

The license file must be accessible to every machine that runs a FLEXlm-licensed

application, and each machine designated as a license server. The format of the license file is

a SERVER line (or lines), followed by one or more DAEMON lines, followed by one or

more FEATURE lines.

The following item can be modified in the license file:


Node names on the SERVER line(s)

Port numbers on SERVER line(s)

Pathnames on the DAEMON line(s)

Options file pathnames on DAEMON line(s)

All the other items in the file are used to compute the encryption code, therefore are left

exactly as supplied by your software vendor. A brief description of each item in the license

file is provided below.

SERVER lines The SERVER line specifies the node name and hostid of the license server, and the port

number of the license manager daemon ( lmgrd ).

DAEMON lines The DAEMON line specifies the daemon name and path.

FEATURE lines The FEATURE lines are not editable. The FEATURE line specifies the name of the feature

to be licensed. A feature can be the name of a program, a program module, or option. The

format of the FEATURE line is as follows:

FEATURE name daemon version expdate nlic code \ "vendor_string" [hostid]

name Name given to the feature by the vendor.

daemon Name of the vendor daemon

version Version of this feature that is supported by this license.

expdate Expiration date, for example, 7-may-2006

(if the year is 0, then the license does not expire).

nlic Number of concurrent licenses for this feature.

(if the number of users is set to 0, the licenses for this feature are uncounted

and no lmgrd is required).

code Encrypted password for this FEATURE line.

(the start date is encoded into the code; thus identical codes created with

different start dates will be different).


"vendor_string" Vendor-defined string, enclosed in double quotes.

(This string can contain any 64 characters except a quote)

hostid Used only if the feature is to be bound to a particular host, whether its use is

counted or not.

Each feature line in the license file has a 12- or 20-character hexadecimal license key. If

anything significant is changed, the key becomes invalid, and the license would not work.

The FEATURESET line is used to prevent FEATURE lines from being added to or

removed from the license file.

The following example is a license file for single vendor with two features.

SERVER excellent_server 17007ea8 1700

DAEMON xyzd /somepath/xyzd

FEATURE xyz_app1 xyzd 1.000 01-jan-2007 10 1EF890030EABF324 ""

FEATURE xyz_app2 xyzd 1.000 01-jan-2007 10 0784561FE98BA073 ""

Here the programs xyz_app1 and xyz_app2 can each be used by a maximum of ten users

simultaneously and the license expires on 1st January, 2007.

2.5 License File Types

The license files are created by the software vendor can specify any of the following types of

software access:

Concurrent (floating) usage

Concurrent usage means anyone on the network can use the licensed software, up to the

limit specified in the license file. Concurrent usage licenses do not have hostids on the

individual FEATURE lines. This configuration requires an lmgrd daemon because it is going

to count the concurrent usage of the licenses.


Node-Locking

Node-locking means the licensed software can only be used on one node. A node-locked

license has a hostid on any FEATURE line that is node-locked to a particular host. There are

two types of Node-locked licenses; uncounted and counted. If the number of users is set to

0, then the licenses are uncounted and unlimited use is permitted on the specified node. This

configuration does not require an lmgrd daemon because it is not going to count the

concurrent usage of the features.

Concurrent usage with limited availability

Another solution is a combination of the node-locked solution in node-locking and the

concurrent option described above. This provides a fixed number of floating licenses for use

on a set of servers. In this configuration, the license file has one node-locked FEATURE

line for each node that is to be able to run the software. This configuration requires an lmgrd

daemon because it counts the concurrent usage.

Node-locked and concurrent usage

Lastly, it is possible to mix uncounted node-locked and concurrent usage licenses in the

same license file.

2.6 The Options File

The options file allows the system administrator to control various operating parameters.

For example, it can allow, deny or reserve the use of features based on user or hostname. It

also controls the amount of information logged about license usage.

Example RESERVE 1 prog1 USER robert

RESERVE 3 prog1 HOST mainline

EXCLUDE prog1 USER lori

NOLOG QUEUED


This options file would reserve one copy of the feature prog1 for the user "robert”, reserve

three copies for anyone on a computer with the hostname "mainline", prevent the user "lori"

from using the prog1 on any node on the network and all QUEUED messages would be

omitted from the log file.

2.7 FLEXlm Standard Encryption Algorithm

To recap, the FLEXlm license keys consist of a set of information such as the

feature name to be licensed, license expiration date, number of users, hostid of the machine

where the program is allowed to run, issuer name, plus some other deatils. For floating

licenses, there may also be a license server name, hostid, and port number where the server

will be listening.

Each license key also includes an 'encrypted string' which consists of a series of 20 hex digits.

This string is generated by taking all of the relevant licensing information, running it through

a hash function, and then encrypting it using a series of encryption keys which only the

vendor knows. This process is performed by a license generator program supplied with the

FLEXlm package. The algorithm used is a proprietary one-way block chaining

encypherment of all the input data.

2.8 How it all works?

When a software developer wants to license a program, he links the FLEXlm library

in with his program. The vendor encryption keys are also compiled into the program, in a

manner that makes it difficult for malicious user to get them out again.

To verify that a supplied license key is valid, the licensed program reads the entry from the

license file, extracts all of the relevant information, and runs it through the same


hashing function and the encryption function using the vendor encryption keys. The result is

an 'encrypted string' which ideally should match the one supplied in the license file. If both

the strings match, then the license is valid and the licensing library returns success, otherwise

it returns an error.

To summarize, each license key must be accompanied by a checksum (the 'encrypted string')

and the application must validate the checksum before it will run. The only way to produce a

valid checksum is if the proper encryption keys are known.

2.9 Seed Hiding System

FLEXlm has undergone a steady development. As a result of the pressure from crackers, the

programmers who have written this code are constantly improving the quality of the

protection it provides. This section describes how FLEXlm hides the seeds so that casual

cracking techniques cannot find the seeds. An explanation of how the information can be

extracted is also included as discussed in Section 3.2.

Early versions of FLEXlm simply included the seeds with no encryption. Later versions used

distributed binaries to hide the seeds and more recent versions use Crypt Filters. The latest

technique involves Tamper Resistant Counterfeiting which has had no successful attacks

thus far. The last scheme is not covered in detail in this paper.

Crypt filters are an added protection mechanism that can be implemented in FLEXlm

protected applications. They add an additional encryption to the key so that simply knowing

the encryption seeds is no longer sufficient to generate valid keys. The implementation of

user crypt filters requires making the relevant filter programs, then modifying the key

generation daemon, and runtime executables so that they utilize this additional code. There

are two additional modules; one for the generator program, and one that is linked against the

shippable executable. The module that is linked against shippable (that is, ones that will go to


the end customer) is special in that it requires the correct result value as input so that it is not

possible to search for memory echoes of the correct key value.


3.0 FLEXlm – The other side

No software is completely secure and FLEXlm is no exception. While Globetrotter Software

has made every effort to ensure the integrity of FLEXlm, all points of attack can never be

anticipated. This section covers the limitations of licensing management systems as well as

highlights some of the known points of vulnerability in FLEXlm; this is discussed in the

section entitled “The Reversing”.

3. 1 Limitations Below are some of the limitations of license management systems:

• It is easier to subvert most license managers than to subvert good quality encryption.

Many license managers can be compromised in a few hours with the use of a

disassembler and debugger. On the other hand, high quality encryption is harder to

subvert.

• Network license managers are famous for being buggy, for example crashing, not

recovering correctly when a client is terminated in an unexpected way or checking

out duplicates. Therefore the system often ends up denying legitimate "paid-for" use

of the software.

• With mission-critical software the license is usually tied to particular hosts. If that

particular computer fails, then the system support staff may have to wait for a new

key to get the application up. This can be unacceptable when the software vendor

only gives out keys during business hours, but the site in question needs to have the

application running all the time.


3.2 The Reversing The section describes some of the attacks that have been performed on older versions of

FLEXlm by illustrating the known points of vulnerability in the system, in particular:

• Generating the license key that belongs in the license file

• Disabling Verification

• Writing a new daemon that emulates your vendor daemon.

• Extraction of seeds FLEXlm protected targets and

• Decryption of FLEXCrypted Files

This information was obtained from the CrackZ's Reverse Engineering Website, see

Bilbliography.

Generating the license key that belongs in the license file

To get a valid license, a malicious user could let the system create one for him. This is how it

is accomplished. The malicious user has to:

• Examine the address space using a debugger.

• Determine the address in memory where the results of the checksum are calculated.

• Modify license file to make it invalid.

• Run program and before existing extract the correct checksum for the bogus

licensing information.

• Add this License file. Valid new license created.

This sort of trick can cause a lot of headaches for a software vendor since all it takes is one

pirate to generate a phony run-anywhere, never-expire, unlimited-user license to circulate to

completely nullify the licensing scheme. If the licensing scheme is sound enough that a pirate

must resort to editing the binary to disable it, you are less likely to see the program pirated


on all platforms since each 'cracking' attempt would require a fair amount of platform-

dependent knowledge. By contrast, if someone compromises one version of the binary to

create a phony license key, then all platforms are compromised at the same time.

A really good licensing scheme should not have vulnerabilities that can be exploited by a

software pirate to produce working authorization codes or registration numbers. One way to

create such a scheme would be with the user of public/secret key pairs. A vendor creates a

public key and secret key. The vendor embeds the public key in his program

and keeps the secret key to himself. To produce a license, the vendor provides a set of

licensing information and then uses his secret key to digitally sign the information. The

application can then verify the digital signature using the vendor's public key. Using this

approach, the licensed program can verify the authenticity of the license without having to

generate any information that might allow a pirate to generate his own licenses. It is also

important to carefully encode the public key into the program in such a way that a pirate

cannot easily change it, otherwise he could replace it with his own public key and created

signed licenses with his own secret key which the program will believe to be genuine.

Disabling Verification

One of the most common methods by which programs are cracked is by doing some object

code modifications to disable the checks, rather than figuring out how to get around the

checks. In this case they disable the calls to the FLEXlm API library and return the proper

values to the library rather than trying to figure out new license keys that work. Crackers

usually go much more on ease of effort rather than cleverness of the crack.

Emulating the Vendor Daemon FLEXlm encourages vendor defined encryption (e.g. Triples Data Encryption Standard and

now Advanced Encryption Standard). In earlier versions, it was possible to emulate a fake


server to authenticate and issue licenses. FLEXlm now encrypts the traffic between client

and vendor daemon to make this point of attack much more difficult.

Extraction of seeds FLEXlm protected targets

FLEXlm keys are dependent on two secret values stored inside the licensing software –

encryption seed1 and seed2. These values are chosen by the vendor who is integrating

FLEXlm into their software. If these values are recovered, and no additional security

measures (such as vendor defined checkouts, where additional checks are done against the

license, or user crypt filters, where an additional layer of encryption is applied to the license

key) are implemented, valid licenses can be generated for the application.

One method involves an attack on the vendor daemon, since usually the daemon is supplied,

and there is less additional code to decompile than in the client applications.

Earlier versions of FLEXlm contained an implementation flaw. It was possible to extract the

corrected seeds in the VENDORCODE1 structure by passing in a NULL pointer for the

JOB2 structure into the recovery routine in lm_new3.

The easiest technique was to search for l_sg 4 using a disassembler and the FLEXlm

signatures, search for the call to the lm_new seed recovery routine. Using a debugger, the

program is loaded, and then a breakpoint set at the point where the decoding routine is

called. The pointer to the job structure, the first argument, is then replaced with a null

pointer. The pointer to the VENDORCODE structure, the third argument, is examined,

and the program stepped over the call to the lm_new routine. When the VENDORCODE

structure was examined after the call, and it contains the correct seeds. Later versions of

1 VENDORCODE structure is a data structure used to hold vendor related data. 2 JOB structure is a data structure used to hold job related data. 3 lm_new - function contains the seed decryption source code. 4 l_sg – function where decryption routine is called from.


FLEXlm correct this problem by not filling in the correct seeds when a NULL pointer is

passed in for the job structure. Instead, the subroutine makes no attempt to modify the

seeds.

In later versions, an algorithm used to distribute the data between the VENDORCODE and

the JOB structures. This algorithm was quite simple and based only on the first character of

the vendor name. However, as in the first case, it is possible to totally reverse engineer how

the seeds are extracted, then write a program to recombine the data from the JOB structure

and the VENDORCODE structure, and recover the seeds this way. A detailed description

of this procedure is provided on the CrackZ's Reverse Engineering Website.

Decryption of FLEXCrypted Files

To recap, the implementation of crypt filters requires making the relevant filter programs,

then modifying the key generation daemon, and runtime executables so that they utilize this

additional code. To identify the crypt filter, reverse engineering is used once again.

In this case, there must be a call to lc_set_attr5 telling FLEXlm where this routine resides.

To do this a breakpoint is set in lc_set_attr, and calls to this routine are monitored. For each

call to lc_set_attr the second argument is examined and if the value matches

LM_A_USER_CRYPT_FILTER, the crypt filter routine is located. Once this filter is

located a user can then build his own decryption program.

3.3 Where are they now?

Macrovision is the new owner of the FLEXlm system now renamed FLEXnet. They now

offer a suit of license management software that „suits the needs of their customers“.

5 lc_set_attr function sets a FLEXlm attribute. The key describes which attribute to set, and the value is the value for the attribute.


An employee of the company said, "The business purpose is to allow software vendors to

offer licensing models that match how people use their products. The security is there to

keep honest people honest. In every release we do things to increase the security, but it's like

an arms race — we do stuff, the hackers do stuff."

4.0 Related Technologies This section briefly mentions some of the other license management products that are

currently offered in the market, namely AUTO-X, HASP HL Net USB key and IBM License

Use Management (LUM).

4.1 AUTO-X

AUTO-X is an automated copy protection product from X-Formation that extends the

security of FLEXlm/FLEXnet. By injecting thousands of security checks into users’ source

code it will make it much harder to perform unauthorized usage. Whereas traditional

mechanisms perform license checks only at program startup, AUTO-X continues to run

throughout your program's execution lifecycle; providing continuous runtime protection.

With the additional checks it dramatically increases the level of sophistication required for a

successful crack to occur. Attackers need to spend time picking apart potentially thousands

of different checks, with no guarantee that the last check has been found. And even if a

cracker is able to locate every check, each one is bound together with the operation of the

software therefore a cracker cannot simply bypass the AUTO-X security without affecting

the integrity of the application, leading to unexpected behavior of the software.


4.2 HASP HL Net USB key

HASP HL Net USB key is a single key that when connected to any computer in a network

provides flexible 3-way software protection: software copy protection, limits the number of

users who can access your application concurrently and controls access of up to 112

different software modules and packages.

4.3 IBM License Use Management (LUM)

LUM is the IBM product for technical software license management deployed by most IBM

use-based priced software products. It adds license protection enablement to the software

allowing software vendors to offer flexible pricing policies tailored to their clients needs.

5.0 Recommendations There is no perfect way to protect software applications. It is all a trade off of what the

crackers can do in a given time versus how much time it takes to develop and protect the

code. If the development of the software is costly and has a large market it is worth investing

in the protection of the code against extensive attacks.

Experts in the field have proposed that some of the hardest schemes to get attack, would be

to obscure, hash or encrypt your code on the assembly level; using tricks while running it in

address space. Another suggestion is to make people get critical code segments off your

server on the Net thereby tying them to be always connected to the Net, but this is for the

higher cost environments. Alternatively, make users get new code segments monthly to

activate the right routines in the software.

It is all a trade off. The most determined most profitable payoff to the driven cracker will get

through. If its costs are high ensure that it is hard for malicious users to break it, however, if

protection is needed against normal users, then a commercial package would suffice.


6.0 Summary License Management has come a long way; value exists in the use of software. There is no

"right" licensing policy for all products, developers decide policies based upon the way the

software product is designed and used, and on competitive factors. Floating licenses does a

good job in matching software usage to the number of licenses sold.

The research has shown that no method of software protection is perfect. Any technique

only makes breaking the mechanism harder, but not impossible. When managing intellectual

property, it is important to choose the terms and conditions that maximize the value of the

intellectual property. Furthermore, the system should effectively prevent the unauthorized

access of software programs while ensuring the authorized use of these programs.

Reverse engineering is a common technique used to break software based protection

schemes. FLEXlm is quite an effective product against all but a binary object code cracker,

and will protect software from running on unauthorized machines for a set number of users

and such.

No software is completely secure but it is best to keep the hackers hard at work.

Bibliography

[1] Macrovision Corporation website, http://www.macrovision.com/. Date visited: 01-

06-2006.

[2] MacrovisionTM, FLEXlmTM End User’s Guide Version 9.5, August 2004.

[3] MacrovisionTM, FLEXnetTM Licensing End User’s Guide Version 10.1, July 2004.


[4] MacrovisionTM, FLEXlmTM Programmer’s Guide, website: http://wwweic.eri.u-

tokyo.ac.jp/computer/manual/lx/SGI_Developer/books/FLEXlm_PG/sgi_html/i

ndex.html. Date visited: 05-06-2006.

[5] Nolan Blender, A Detailed Look at CryptFilters, website:

http://www.woodmann.com/crackz/Tutorials/Nbufilt.htm. Date visited: 20-06-

2006.

[6] Nolan, Blender, Cracking ECC FLEXlm, website:

http://www.woodmann.com/crackz/Tutorials/Flexecc.htm. Date visited: 20-06-

2006.

[7] CrackZ website, FLEXlm latest information by CrackZ, website:

http://www.woodmann.com/crackz/Tutorials/Flex2004.htm. Date visited: 20-06-

2006.

[8] CrackZ website, How to crack a PC-based FLEXlm license manager, website:

http://www.woodmann.com/crackz/Tutorials/Flexpilg.htm. Date visited: 20-06-

2006.

[9] Nolan Blender, Information Hiding Methods used by FLEXlm Targets, An

Explanation of the FLEXlm Seed Hiding System, website:

http://www.woodmann.com/crackz/Tutorials/Nolflex2.htm. Date visited: 20-06-

2006.

[10] Aladdin Knowledge Systems website, http://www.aladdin.com. Date visited: 21-06-

2006.

[11] Nolan Blender, Reversing GlobeTrotter FLEXcrypt, website:

http://www.woodmann.com/crackz/Tutorials/Nolflexc.htm. Date visited: 20-06-

2006.

[12] Alandin Knowledge Systems Limited, Software Protection, The Needs, the solutions

and the rewards, 12 August, 2001.

[13] BASIS International Ltd website, http://www.basis.com/advantage/mag-

v3n1/21flexlm.html. Date visited 01-06-2006.

Documents

Floating License Management - A Review of FlexLM