FLOATING LICENSE MANAGEMENT

Transcription

1 FLOATING LICENSE MANAGEMENT A REVIEW OF FLEXlm PREPARED BY: SALYS SULTAN June 30 th, 2006

2 Table of Contents ABSTRACT INTRODUCTION LICENSING POLICIES 5 NODE-LOCKING USER-BASED LICENSING 5 5 SITE LICENSING 5 NETWORK LICENSING LICENSE MANAGEMENT FLEXLM, FLEXIBLE LICENSE MANAGER OVERVIEW COMPONENTS License Manager Daemon ( lmgrd ) 8 9 Vendor Daemon License File 9 10 Client Application Program 2.4 THE LICENSE FILE SERVER lines DAEMON lines FEATURE lines 2.5 LICENSE FILE TYPES THE OPTIONS FILE FLEXLM STANDARD ENCRYPTION ALGORITHM HOW IT ALL WORKS? SEED HIDING SYSTEM FLEXLM THE OTHER SIDE LIMITATIONS 3.2 THE REVERSING Generating the license key that belongs in the license file Disabling Verification Emulating the Vendor Daemon 20 Extraction of seeds FLEXlm protected targets 21 Decryption of FLEXCrypted Files WHERE ARE THEY NOW? RELATED TECHNOLOGIES AUTO-X 4.2 HASP HL NET USB KEY IBM LICENSE USE MANAGEMENT (LUM) RECOMMENDATIONS SUMMARY 25 BIBLIOGRAPHY 25

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

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

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

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

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

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

9 FLEXenabled Application Application Code FlexLM Licensing Client Library TCP/I P License Server System Components License Server Manager Vendor Daemon License(s) Debug Log File Options File Report Log File 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

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

11 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:

12 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 daemon version expdate Name given to the feature by the vendor. Name of the vendor daemon Version of this feature that is supported by this license. 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).

13 "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 17007ea DAEMON xyzd /somepath/xyzd FEATURE xyz_app1 xyzd jan EF890030EABF324 "" FEATURE xyz_app2 xyzd jan FE98BA073 "" Here the programs xyz_app1 and xyz_app2 can each be used by a maximum of ten users simultaneously and the license expires on 1 st January, 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.

14 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

15 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

16 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

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

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

19 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

20 on all platforms since each 'cracking' attempt would require a fair amount of platformdependent 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

21 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 VENDORCODE 1 structure by passing in a NULL pointer for the JOB 2 structure into the recovery routine in lm_new 3. 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.

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

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

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

25 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, Date visited: [2] Macrovision TM, FLEXlm TM End User s Guide Version 9.5, August [3] Macrovision TM, FLEXnet TM Licensing End User s Guide Version 10.1, July 2004.

26 [4] Macrovision TM, FLEXlm TM Programmer s Guide, website: ndex.html. Date visited: [5] Nolan Blender, A Detailed Look at CryptFilters, website: Date visited: [6] Nolan, Blender, Cracking ECC FLEXlm, website: Date visited: [7] CrackZ website, FLEXlm latest information by CrackZ, website: Date visited: [8] CrackZ website, How to crack a PC-based FLEXlm license manager, website: Date visited: [9] Nolan Blender, Information Hiding Methods used by FLEXlm Targets, An Explanation of the FLEXlm Seed Hiding System, website: Date visited: [10] Aladdin Knowledge Systems website, Date visited: [11] Nolan Blender, Reversing GlobeTrotter FLEXcrypt, website: Date visited: [12] Alandin Knowledge Systems Limited, Software Protection, The Needs, the solutions and the rewards, 12 August, [13] BASIS International Ltd website, Date visited