floating license management - a review of flexlm
Post on 29-Dec-2015
160 Views
Preview:
DESCRIPTION
TRANSCRIPT
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
FLOATING LICENSE
MANAGEMENT
A REVIEW OF FLEXlm
PREPARED BY:
SALYS SULTAN
June 30th, 2006
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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.
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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.
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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.
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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.
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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.
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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.
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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.
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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:
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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).
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
"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.
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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.
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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.
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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.
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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.
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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.
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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.
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
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.
DIGITAL RIGHTS MANAGEMENT SEMINAR SOFTWARE PROTECTION TECHNIQUES
[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.
top related