WO2004086200A1

WO2004086200A1 - Multilevel software protection system

Info

Publication number: WO2004086200A1
Application number: PCT/GB2004/001382
Authority: WO
Inventors: Behrooz Toloui; Nigel John Paul Fenner-Fownes
Original assignee: Natmed Holdings Limited
Priority date: 2003-03-27
Filing date: 2004-03-29
Publication date: 2004-10-07
Also published as: GB0307098D0

Abstract

A multilevel software protection system is disclosed. The system compiles an unprotected application (2) leaving areas of dummy code. Preferably, the location of the dummy areas is randomised so that it is unique for each compiled application. On registration of the software application, one or more security or licensing programs are written to the dummy areas to form a protected program (20). The security or licensing program preferably operates by verifying both hardware and software parameters on the machine on which the software application is running to ensure that the application is not a copy. Information about the hardware and software parameters, may be stored on a central server for reference by the security or licensing programs on start up of the application.

Description

Multilevel Software Protection System

This invention relates to methods and systems for protecting software from unauthorised copying, and to software protected by such methods and systems .

Software is one of the most valuable technologies of the Information Age, running everything from PCs to the Internet. Unfortunately, because software is so valuable, and because computers make it easy to create an exact copy of a program in seconds, software piracy is widespread. From individual computer users to professionals who deal wholesale in stolen software, piracy exists in homes, schools, businesses and government. Software pirates not only steal from the companies that make the software, but with less money for research and development of new software, all users are hurt. As a result, all software piracy is illegal, even if it involves one copy made for a friend.

As the number of PCs increases and Internet use grows, so too does the incidence of software piracy. It has therefore been recognised that new technologies should be developed to enhance ways of accessing and distributing copyrighted works legally, not illegally.

The fifth annual benchmark survey on global software piracy highlights the serious impact of copyright infringement to the software industry. Piracy losses exceeded $12 billion worldwide in 1999 and topped $59 billion during the past five years. The survey, conducted by an independent research firm, was commissioned by the Software & Information Industry Association (SIIA) and the Business Software Alliance (BSA) . The 1999 software piracy estimates indicate that more than one in every three business software applications in use during 1999 was pirated. Piracy losses for the U.S. and Canada lead every other region of the world at $3.6 billion, or 26% of the total. The continuing problem means lost jobs, wages, tax revenues, and a potential barrier to success for software start-ups around the globe.

A program's greatest weakness is that it can be easily de-compiled to a source code listing using commercial-end freeware products. This means that the intellectual property of the program can be accessed and modified allowing a software pirate to bypass security routines built into the program.

Currently there are two main methods of protecting software to make counterfeiting and or unauthorised copying and or cloning by end-users more difficult. One is the use of a physical security device, such as Dongles, which restrict the software from being run on unlicensed equipment. The other is the use of software security polices coded into the application program. These may rely on unique serial numbers embedded in the software or burnt on to the master disk on installation. Both methods have start-up checks and all system security presets must be present before the application software can be rendered operational.

A Dongle is a hardware device that is used to prevent illegal installation of software. The software is designed so that it will only operate when the hardware device is permanently attached. Therefore, only users who have the proper hardware device attached can operate the software. If the software is installed on another machine it will not work because the hardware device is not attached. Hardware keys are distributed to end users corresponding to the number of seat licenses purchased. Apart from the cost, an additional drawback is that if the Dongle is lost or stolen the software is unusable.

Embedding program serial numbers into programs, may include the use of dummy sub-routines or redundant code. These alternatives typically add the information about the security registration to the end of the program, at the same time causing an increase in the size of the operational application. An advanced user may also decipher and rebuild the original structure of the program avoiding the inbuilt security checks. This means that program clones can be created very cheaply and in volume in a very short space of time.

Both of these protection methods have drawbacks and we have appreciated that there is a need for an improved software protection system.

Summary Of Invention

The invention is defined in the independent claims to which reference should now be made. Advantageous features are set forth in the dependent claims.

A multilevel software protection system is provided. The system compiles an unprotected application leaving areas of dummy code. Preferably, the location of the dummy areas is randomised so that it is unique for each compiled application. On registration of the software application, one or more security or licensing programs are written to the dummy areas to form a protected program. The security or licensing program preferably operates by verifying both hardware and software parameters on the machine on which the software application is running to ensure that the application is not a copy. Information about the hardware and software parameters, may be stored on a central server for reference by the security or licensing programs on start up of the application.

Brief Description of the Drawings

A preferred embodiment of the invention will now be described in more detail, by way of example, and with reference to the drawings in which: Figure 1 is a schematic illustration of compilation process according to the preferred embodiment of the invention; and

Figure 2 is a flow chart showing the security verification procedure according to the preferred embodiment.

Detailed Description of the Preferred Embodiment

The preferred embodiment of the invention takes the form of a Multilevel Software Protection System (MSP) , which combines the effect of the two methods above to solve the cloning issues.

The MSP system also comprises a new method of compiling the software, which reduces the likelihood of counterfeiting/ cloning. This is explained with reference to Figure 1.

Figure 1 shows an uncompiled standard program 2, comprising a number of instruction blocks. Instruction blocks are provided for registration of the program 4, operation of the program 6, as well as for link routines 8 and libraries 10, on which the program will rely during its operation.

Compilation of the standard program 2 into machine code, using the preferred method, is illustrated by process box 12.

Firstly, as illustrated by box ^dispersion' 14, the program size is expanded by insertion of a series of dummy instructions at the time of compilation using a dynamically defined template. The resultant space created by these dummy codes is then used later to write in a randomised working procedure for security checks at the time of registration, thus creating a unique program for the specific serial number within the application program. The generation of the randomised procedure takes place in step 16, labelled DNA engine' . This increases the possibilities of security codes as well as the difficulty of identifying the end location of the security codes for deciphering. It is important to understand that each individual application program has its own allocated randomised security code.

The writing of the randomised security procedure to the resultant spaces is shown in the ^recompile' step 18, following which the resulting security protected program is completed. This is shown as Protected Program 20, which in addition to having instruction blocks 22, 24, 26 and 28 corresponding to registration instructions 4, operation instructions 6, link routine instructions 8 and library instructions 10, now contains a security program written into the program. This is represented in Figure 1 by the blocks of a lighter colour interspersed throughout the program code.

Additionally, the location of licensing or the security code is randomly produced at the time of the registration and as it is created in real time the possibility of decoding of it is not mathematically possible.

Therefore the preferred multilevel protection system provides a unique registration process which runs- a randomised parallel security check program which is embedded within the main application routines.

The generation of the security program according to the preferred embodiment, will now be described in more detail.

The protection applied to a protected program 20 relies on data held in a Software Bank or server accessible across a network to which the machine running the protected program is connected.

During the process shown in Figure 1, in which the protection is applied, a number of factors are variable leading to different permutations of protection, or different DNAs' for each of the protection programs applied. Some of the variables are stored in the software bank during the protection process, and are then checked every time the application is launched.

Firstly, an application program is compiled using a preselected security template. The security template creates several dummy areas within the compiled code which hold no information but which are available for use to code at the time of the registration.

The security template, and the location of the dummy areas within the compiled code are preferably randomised, so that the dummy areas themselves form a unique identifier for each registered program. The security templates are stored in the central server or software bank as an additional verification check for a registered protected program.

The dummy areas location structure is then loaded into the header of the program. The route to each location is however protected by encryption. The templates responsible for the generation of the dummy memory locations encrypt the code for registration options into to the program header.

These locations will later together form a path for a registration/licensing program to be incorporated within the original program.

The registration/licensing information is written to these dummy locations, in the recompiling step, as programming instructions when the software program is registered on a machine. As space for these extra instructions is burned into the program at the time of compiling and there will be no increase to the size of the application program after registration during the recompiling stage.

The header routine of the original program is used at the time of the installation/registration to generate further code which will be stored in the dummy positions to facilitate further security and authenticity checks. The preferred method of generating the registration/licensing information which is written to the dummy locations will now be described in more detail.

There are many different checks that can be made to validate the authenticity of a software program. The preferred method involved using a combination of these randomly distributed through the dummy locations, which are themselves random, in the protected program. On launching the protected program, the identification checks are performed comparing data drawn from the machine on which the program is running as well as from the program itself. This data is compared with corresponding data held in the software bank or central server to validate the program each time it is launched. As will be understood in the art, copying the program and running it on a machine other than that on which it was registered may cause the copied program to fail one or more of the security checks. Furthermore, as the location of the security program routine in the original program is random for each protected program, by passing of the security program is difficult.

The preferred system combines the effect of both hardware and software solutions to protect a software application.

At the time the application is registered, for example, the "Anchoring" position of the software in the memory of the machine on which it is running is stored in the software bank as a verification parameter. It will be appreciated that a copy of the software when installed on a different machine will have a different anchoring position. By installing a security program to check the anchoring position against that stored in the software bank for the registered program, operation of unauthorised versions of the software can be prevented. The effect of this is similar to the Dongle effect described earlier. Additionally, the preferred system makes use of hard disk serial numbers (HDSN) which are pre-burned into most modem IDE hard disk drives. Not to be confused with the easily changed "Volume" serial number, the HDSN is a permanent read-only attribute of a personal computer hard drive. Normally the HDSN is very difficult to access, but the preferred system reads this data and logs the HDSN, model number, and end firmware identifier in the software bank. This information can then be used as verification parameters in the licensing program.

The preferred system also makes use of a licensing template to write the security program to the dummy areas. Based on the licensing template, a certain path to the dummy areas is selected. This path is selected in a random way making it very difficult for a third party to trace the end copy. This adds to the difficulty of copying or cloning the end software, and gives a Programming Policy effect.

The Random Licensing path is then encrypted and sent to the software bank for registration.

At the software bank or central server all of the above information identifying the program or machine on which it is being run may be compiled into code for a security program and/or a licensing program. It will be appreciated that all of the information could be used to form a security program, or only a subset of the information, depending on the rigour desired for the protection. The more checks that are employed on start up however the longer the start up of the program may take. There is sometimes therefore a trade off to be made.

Additionally, for the licensing program, a software manufacturer may request that a timer or life-span function be added to the program, to stop the program automatically after a certain predefined period of time. This request may be encoded in the registration instructions for the software, along with other information such as a software serial number.

At the time registration of the application is made, information about the PC or hardware, the serial number of the software, and if needed the time limit for the operation and the information about the modules which is licensed is sent to the software bank.

Once the program is registered, it will be appreciated that any further request for the registration of the same serial number is rejected.

At the software bank, the Licensing template is identified and a unique licensing program carrying information about . the PC, modules and time limit is created.

Once the licensing program is received by the end-user's system, the codes for its operation are then positioned into many of the dummy instruction cells and it merges to form the security check code. This information enhances the security program and produces a unique security routine which is executed on every session prior to the use of application software.

The preferred system described therefore represents a new and commercially valuable method of establishing true and legal ownership by third parties of licensed software applications. The licensing information is no longer just a code it is now a program coded within the application and in addition is loaded in a random path making it even more difficult for anyone to trace and decode. The combination and addition of the IDE Serial number guarantees that application software will only work on the licensed computer and will automatically stop functioning once it is moved to another computer . The combination of hardware tagging (emulating Dongle) and random software code to run the registration makes the system impossible for counterfeiting.

Although, the operation of the security checks has been described as relying on checks with verification parameters stored in the software bank or central server, it will be appreciated that the verification parameters could be hardwired into the licensing program stored in the protected program, along with routines to check them against the local parameters of the machine.

The registration and protection process is illustrated in more detail in Figure 2 to which reference should now be made.

Installation of the compiled, un-protected software, from a CD or via a dedicated installation and registration procedure, is started in step 30. The installer of the application is then requested in step 32 to enter a unique serial number for the application. This will often be included in the literature enclosed with the software bundle, or may be written onto the surface of the installation CD itself.

At the same time, the installation process, determines the anchoring data of the software on the machine in step 34, as well as the other information required for the security programs .

In step 36, a random deactivation timer may also be generated for the licensing program, as well as an additional random code which is generated uniquely for the software program in step 38. This gives users a trial period to test the software application before registration is required.

Lastly, a key to deactivate the program once the licensing timer has expired is generated in step 40 according to the registration instructions in the program. Following entry of the serial number in step 32 the installer is prompted, in step 42, that it will now be necessary to contact that software bank or central server for registration to proceed. A call waiting state, step 44, is now entered in which it is determined whether the call to the server has been initiated. It will be appreciated that this will involve the installer ensuring that the computer is online, and confirming that the call may be made. As long as the call is not made, control cycles in a loop from step 44 to step 42 and back again for the duration of a grace period. At the end of the grace period, if the call has not been made, then control flows to step 46 where the installation and registration process is stopped.

If the call to the software bank is made, then control flows to step 48 where the key data generated in steps 34 to 40 is transmitted to the software bank and logged. This information is used by the server to generate the security or licensing program in step 50. In conjunction with the generation of these programs, in step 52, the serial number provided by the installer is also checked to determine if it is a valid serial number or not. This check will involve determining whether the serial number has already been registered in the software bank. The method of checking the validity of the serial number in cases where the serial number is not yet registered, to determine whether it is an authentic manufacturer' s serial number will be understood to those skilled in the art. If the serial number is not valid, or if it has already been stored in the software bank, then control flows to step 46 where the installation or registration process is stopped.

Following generation of the required security or licensing program by the server in step 50, and identification of a valid serial number, the security and licensing program is written into the software in activation step 54. Any licensing timer is then initiated in step 56, and the software is finally anchored in step 58.

Claims

1. A method of protecting a software application, comprising: compiling the software application, such that one or more areas of dummy code are created throughout the compiled code; writing a security program into one or more areas of the dummy code, the security program being run on operation of the application to validate the application's authenticity.

2. A method according to claim 1, wherein the step of compiling the software application comprises generating the location of the areas of dummy code randomly.

3. A method according to claim 1, or 2, wherein the writing step comprises randomly selecting areas of dummy code for the writing of the security program or parts of the security program.

4. A method according to any of claims 1, 2 or 3, wherein the security program is arranged to verify hardware or software parameters of the machine on which the application is running to validate the application's authenticity.

5. A method according to any of claims 2 to 4, wherein the security program is arranged to verify the anchoring position of the software.

6. A method according to any of claims 2 to 5, wherein the security program is arranged to verify parameters of the hard disk drive of the machine on which the application is to run.

7. A method according to claim 6, wherein the security program is arranged to verify the hard disk drive serial number.

8. A method according to any preceding claim comprising requiring that the software application be registered with a central server before operation.

9. A method according to claim 8, comprising writing the security program to the software application at the time of registration.

10. A method according to claim 8 or 9, wherein on registration of the software application, the serial number of the software is stored on the central server.

11. A method according to claim 10, wherein on registration it is determined whether the serial number is a valid serial number, and if it is not, preventing registration and operation of the software application.

12. A method according to any of claims 8 to 11, wherein on registration of the software application, the anchoring position of the software is stored on the central server.

13. A method according to any of claims 8 to 12, wherein on registration of the software application, information about the hardware or software of the machine on which the software application is running is stored on the central server.

14. A method according to any of claims 8 to 13, wherein on registration of the software application, a random security code is generated and stored on the central server.

15. A method according to any of claims 8 to 14, wherein on operation of the security program information stored on the central server is checked against that of the machine on which the software application is running.

16. A method according to any preceding claim, wherein the location of the dummy areas within the compiled code is checked by the security program to verify the authenticity of the software application.

17. A method according to any preceding claim, comprising writing the location of the dummy areas within the compiled code to the header of the software application in encrypted form.

18. A method according to any preceding claim, comprising writing a licensing program into one or more of the dummy areas .

19. A method according to claim 18, wherein the licensing program comprises a timer function, after expiry of which the software application is temporarily or permanently disabled.

20. A software program product which when executed on a computer causes the computer to perform the method steps of any of claims 1 to 19.

21. A system for protecting a software application, comprising: means for compiling the software application, such that one or more areas of dummy code are created throughout the compiled code; means for writing a security program into one or more areas of the dummy code, the security program being run on operation of the application to validate the application' s authenticity.

22. A system according to claim 21, wherein the means for compiling the software application is arranged to generate the location of the areas of dummy code randomly.

23. A system according to claim 21, or 22, wherein the means for writing the security program is arranged to randomly select areas of dummy code for the writing of the security program or parts of the security program.

24. A system according to any of claims 21, 22 or 23, wherein the security program is arranged to verify hardware or software parameters of the machine on which the application is running to validate the application's authenticity.

25. A system according to any of claims 22 to 24, wherein the security program is arranged to verify the anchoring position of the software.

26. A system according to any of claims 22 to 25, wherein the security program is arranged to verify parameters of the hard disk drive of the machine on which the application is to run.

27. A system according to claim 26, wherein the security program is arranged to verify the hard disk drive serial number.

28. A system according to any preceding claim comprising a central server, and means for requiring that the software application be registered with a central server before operation.

29. A system according to claim 28, wherein the means for writing the security program are operable to write the security program to the software application at the time of registration.

30. A system according to claim 28 or 29, wherein on registration of the software application, the serial number of the software is stored on the central server.

31. A system according to claim 30, comprising means for determining, on registration, whether the serial number is a valid serial number, and if it is not, preventing registration and operation of the software application.

32. A system according to any of claims 28 to 31, wherein on registration of the software application, the anchoring position of the software is stored on the central server.

33. A system according to any of claims 28 to 32, wherein on registration of the software application, information about the hardware or software of the machine on which the software application is running is stored on the central server.

34. A system according to any of claims 28 to 33, comprising means, which on registration of the software application, generate and store a random security code on the central server.

35. A system according to any of claims 28 to 34, wherein on operation of the security program information stored on the central server is checked against that of the machine on which the software application is running.

36. A system according to any preceding claim, wherein the location of the dummy areas within the compiled code is checked by the security program to verify the authenticity of the software application.

37. A system according to any preceding claim, comprising means for writing the location of the dummy areas within the compiled code to the header of the software application in encrypted form.

38. A system according to any preceding claim, comprising means for writing a licensing program into one or more of the dummy areas .

39. A system according to claim.38, wherein the licensing program comprises a timer function, after expiry of which the software application is temporarily or permanently disabled.