Patent Publication Number: US-2003233564-A1

Title: Software program protection mechanism

Description:
FIELD OF THE INVENTION  
       [0001] The present invention relates to a protection mechanism to prevent unauthorized modification and/or redistribution of computer software programs.  
       BACKGROUND OF THE INVENTION  
       [0002] In the field of commercial software, especially software for consumer personal computers or “PCs”, it is common to distribute free or low-cost demonstration versions of software programs for marketing purposes. Software publishers distribute large numbers of such demonstration versions in order to expose many potential buyers to their software. The rationale is that the low cost of distribution is more than offset by the additional purchase revenue likely to be generated by users who try the software, like it, and decide to buy it. Such demonstration versions are sometimes distributed over the Internet, but physical media such as diskette, CD-ROM or DVD (Digital Versatile Disc) are more commonly used. Such physical media are inexpensive, they can be easily targeted to a specific audience, and, unlike downloads supportable via most consumer Internet connections, they have enough capacity to distribute a large demonstration version which is sufficiently full-functioned to trigger a sale.  
       [0003] Such demonstration software programs have the following characteristics: i. the distribution form of the demonstration software program includes a full-function version of the software program; ii. all distributed copies of the demonstration software program are identical; iii. upon normal installation, the software program provides a demonstration mode which includes one or more restrictions (functionality, time, number of users, etc.); iv. a means is provided by which the user can acquire a fully-licensed version of the software, and convert the demonstration version to a full version without the need for delivery of additional media; v. The demonstration software programs do not rely on any special hardware support, but will run (and convert to full-function versions) on a normal consumer PC.  
       [0004] Typically, most such demonstration distributions of software actually contain all the functionality of the full-price version, with software protection mechanisms embedded therein which are designed to prevent access to the full version until sale. This is done for two reasons. First, software publishers want to avoid the expense of different software development streams, one for demonstration and one for “full” versions of the software. Second, software publishers want users to be provided with the means to convert a demonstration version into a full version, without the need for further delivery of software to the user.  
       [0005] While the system described thus far can be an effective marketing tool, it has a serious disadvantage. Such demonstration media are a major source of working material for software pirates. It is usually possible for a software pirate to modify the demonstration version so as to circumvent whatever protection mechanism has been embedded by the software publisher. When demonstration versions of software have been so modified, full program functionality latent in the distributed form of the program is unlocked, without the publisher receiving any consideration. Furthermore, once a software pirate successfully circumvents the protection mechanism employed by the software publisher, a piracy-assisting package called a “crack” can be created to assist others to similarly convert a demonstration software program to a full version without payment to the publisher. The practice of freely distributing “cracks” is sufficiently widespread that software publishers recognize it as a significant source of revenue loss.  
       [0006] There are several well-known protectionist countermeasures known in the art designed to make a demonstration form of a software program resistant to piracy attacks. Typically, such protectionist techniques consist of adding extra internal functions to the binary executable form of the software program, which enforce demonstration restrictions. The desired result is that any unauthorized modifications designed to sidestep the demonstration restrictions, would be detected and result in, for example, specific screens being displayed, or automatic program failure. However, the binary executable program (for example, the file with an extension of “.EXE” in the Windows™ operating system) is usually only a very small component of the overall software program. In most consumer software applications, an executable file is about one megabyte in size, while the data files and other files necessary for program execution can exceed several hundred megabytes overall. Thus, by protecting only the core binary executable file of a software program, only a very small proportion of the demonstration version of the software is actually protected from piracy.  
       [0007] If a software program protected according to the current art is freely distributed, then the simplest form of “crack” is simply to replace the protected core binary executable file with an unprotected equivalent unprotected version, which can be obtained via a single legitimate purchase. This form of crack is easily produced without the need for great technical skill. This constitutes a significant weakness for the current art in software protection schemes.  
       [0008] Alternative software protection mechanisms employ cryptographic techniques. While cryptography is an adequate solution for the one-time transmission of computer messages, it is not generally adequate as a software protection mechanism. This is because the cryptographic keys required by cryptographic systems are inherently liable to discovery, since they must be applied every time a protected software program is run.  
       [0009] Thus, a need exists for an improved software protection mechanism.  
       SUMMARY OF THE INVENTION  
       [0010] The present invention provides an improved software protection mechanism for computer software programs. What is disclosed is a system for transforming the “asset files” of a software program (i.e. the data files) and modifying the core executable program itself, in such a way that any redistribution of the modified executable program would also require redistribution of the corresponding transformed asset files. A redistribution composed of the modified executable file along with non-transformed (i.e. original form) asset files (and vice versa) would not operate.  
       [0011] To create a distribution form of a protected software application, the application is first broken up into its main constituent elements, namely the core executable program and the asset files (read-only data files and/or read/write data files). Using a transformation key, a transformation function is applied to the asset files to create transformed data files. The transformation key is then stored for later use. A modified executable program is then formed by embedding into the core executable program a call to the execution of a protection module program. The protection module program may only be invoked upon the execution of said modified executable program, and will not operate under any other conditions. A file transformation module program is then generated and added to the bundle of software elements. The transformation keys and list of transformed data files may optionally be added to the protection module program. The bundle of software elements (comprising the transformed data files, transformation keys, modified executable program, protection module program and file transformation module program) are then transferred to a medium for distribution to a user.  
       [0012] In operation on a computer system, the modified executable program is loaded, which automatically causes the protection module program to be run. The protection module invokes the operation of the file transformation module, which is designed to intercept requests for file operations (such as, for example, file-READ, file-WRITE, file-OPEN and file-CLOSE) made by the modified executable program to the computer system&#39;s operating system. Using the transformation key, the file transformation module will perform the required reverse transformation only if the file operation request is identified as being for transformed data.  
       [0013] Through the use of the protection module program, the present invention connects the modified executable program to the transformed data files. As such, under no circumstances will the file transformation module perform the required reverse transformation except in the presence of, and under the control of the modified executable program.  
       [0014] Other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures.  
     
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
     [0015] Preferred embodiments of the invention will now be described with reference to the attached drawings in which:  
     [0016]FIG. 1 is a block diagram of a typical installation and run-time structure of a software program without a protection mechanism;  
     [0017]FIG. 2 is a block diagram of an installation and run-time structure of a software program with the addition of a typical software protection mechanism;  
     [0018]FIG. 3 is a block diagram of an installation and run-time structure of a software program with the addition of a software protection mechanism for asset files;  
     [0019]FIG. 4 is a block diagram of one embodiment of the software protection mechanism of the present invention;  
     [0020]FIG. 5A is a flow chart of the initialization steps of the present invention;  
     [0021]FIG. 5B is a flow chart of the operational steps taken by the transformation module of the present invention;  
     [0022]FIG. 5C is a flow chart of the termination steps of the present invention;  
     [0023]FIG. 6 is a block diagram showing the process by which a software program has its assets transformed according to the method of this invention; and  
     [0024]FIG. 7 is a flow chart of the file transformation process shown in FIG. 6. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
     [0025]FIG. 1 is a block diagram of a typical installation and run-time structure of a software program without a protection mechanism. Such software programs are usually distributed on CD-ROM  10 , or other physical media. It is immaterial to the present invention whether the distribution source is other than CD-ROM (e.g. DVD, Internet download, etc.), but a CD-ROM is used for ease of description.  
     [0026] An installation program  20  is run from CD-ROM  10 , which reads  11  the CD-ROM  10 , and copies ( 21 ,  22 ,  23 ,  24 , and  25 ) to the internal disk of the user&#39;s PC, core executable program  30  and a number of file sets  40 ,  41 ,  50  and  51 . The core executable program  30  will typically rely on executable operating system code in support of the core executable program  41 , which may have been updated or initially installed by the installation program  20 , or may already have been in place on the user&#39;s PC. An example would be the DirectX™ graphics facility of Microsoft Windows™. The core executable program  30  will also typically rely on core executable support files  40 , also installed by the installation program  20 . An example would be one or more Dynamic Linked Libraries (DLLs) for use of the specific application in the Windows&#39; operating system.  
     [0027] To run properly, the core executable program  30  will typically interact with and manipulate data files. For example, a read/write file set  51  is shown being accessed via file system interface  61 , and a read-only file set  50  is shown being accessed via file system interface  60 . File sets  50  and  51  are known as “asset files”. No software protection mechanism is shown in FIG. 1, which means that the software application can be easily copied and distributed without difficulty.  
     [0028]FIG. 2 is a block diagram of an installation and run-time structure of a software program with the addition of a typical software protection mechanism known in the art. With the exception of modified executable file  30 A and protection module program  31  (hereinafter referred to as “protection module  31 ”), all the elements of FIG. 2 are the same as those described in FIG. 1. The dashed line outline of components  30 A and  31  is a visual aid to convey the fact that these components are protected.  
     [0029] In FIG. 2, modified executable program  30 A is modified relative to the original core executable file  30  in FIG. 1 in some fashion to protect the file&#39;s integrity. Commonly, an additional protection support module executable component (“protection module”)  31  is installed  26  and used at run-time  62  under the control of the modified executable program  30 A. The protection module  31  is not always in use during program execution, but in a typical implementation would monitor and/or set-up the functioning of modified executable program  30 A to ensure compliance with pre-set restrictions while the program was in demonstration mode.  
     [0030] The weakness of the system illustrated in FIG. 2 is that, if the protected executable program  30 A is replaced by a copy of the original core executable program  30 , then all protection is lost and the resulting application will have unlicensed full functionality. The protection functions provided by protection module  31  will be lost, even if that component is still present. This is because such protection functions are only invoked by modified executable program  30 A and will remain dormant if unprotected original core executable program  30  is used in the place of modified executable program  30 A.  
     [0031]FIG. 3 is a block diagram of an installation and run-time structure of a software program with the addition of a software protection mechanism for asset files. Only elements  20 ,  40  and  41  of FIG. 3 are the same as those described in FIGS. 1 and 2. Except for CD-ROM  10 A, the remaining elements are shown in dashed line outline, which is meant to indicate that they are protected in accordance with the software protection mechanism of the present invention. CD-ROM  10 A is the distribution medium for the protected software. As in FIG. 2, the modified executable program  30 A is modified relative to original core executable program  30  in FIG. 1 in some fashion to protect the file&#39;s integrity. Commonly, an additional protection support module executable component (“protection module”)  31  is installed  26  and used at run-time  62  under the control of the modified executable program  30 A.  
     [0032] In FIG. 3 file sets  50  and  51  of FIG. 2 (the “asset files”) are replaced by transformed file sets  50 A and  51 A. There may be one or more transformed data files in transformed file sets  50 A and  51 A. Transformed file sets  50 A and  51 A, which may include any format of file, including even executable files,  
     [0033] are accessed by the modified executable program  30 A via interface read/write function  60 A and interface read-only function  61 A (through transformation module  70  shown in FIG. 4) which provide appropriate run-time transformations and inverse transformations. It will be appreciated by one skilled in the art that the exact nature of the transformations and inverse transformations is not fundamental to the invention. For example, the transformations could involve encryption and decryption using standard algorithms such as Data Encryption Standard (DES) or Rivest Shamir Adelman (RSA), or other less complex encryption and decryption algorithms. A mix of different transformations could also be used for the same application. The only real requirements are that the transformations be reversible and that they provide an appropriate balance between performance and security for the software program. For example, a simple transform might consist of applying byte-by-byte logical operations such as bit shifts or EXCLUSIVE OR operations with secret byte values to the transformed buffered data to produce cleartext data. Interface functions  60 A and  61 A, which provide the required run-time transformations, may be implemented in various ways. For example, the required transformations may be built-in at the source code or library level to the modified executable program  30 A. They could also be inherently provided by the operating environment, or in conjunction with special media.  
     [0034]FIG. 4 is a block diagram of one embodiment of the software protection mechanism of the present invention. Shown in FIG. 4 are transformed file sets  50 A and  51 A, modified executable program  30 A, and protection module  31  which are all similar to that of FIG. 3. Some of the elements of FIG. 3 are omitted from FIG. 4 for visual clarity but are logically present and unchanged in the scenario of FIG. 4. Interface read-only functions  60 B,  60 C,  60 D and interface read/write functions  61 B,  61 C,  61 D are those which provide appropriate run-time transformations and inverse transformations in accordance with the present invention.  
     [0035] In this embodiment, interface functions  60 B,  60 C,  60 D and  61 B,  61 C,  61 D are provided in a fashion that is transparent to the modified executable program  30 A. That is, the code within the modified executable program  30 A that uses the transformed file sets  50 A and  51 A, can be left in its original form, because file input/output as seen by that code according to the present invention is identical to that which would be seen with no protection in place This is done by means of operating system  71  and file transformation module program  70  (hereinafter referred to as “file transformation module  70 ”) which intervene in the reading and writing of file operations via interfaces  60 B,  60 C and  61 B,  60 C. Operating system  71  (for example, Microsoft Windows 95™ or 98) and file transformation module  70  are the means by which file transformation is attached transparently to file operations.  
     [0036] There are various ways in which file transformation module  70  could be implemented. However, in accordance with this embodiment of the present invention, the objectives of this module are: i. To make file transformation completely transparent to the modified executable program  30 A that is, no modifications have been made to the program as a result of the file transformations; and, ii. to provide file transformation services only under appropriate circumstances, which, in this case, only to a legitimate modified executable program  30 A. Transformations will not be performed on behalf of other executable programs, such as the original core executable program  30 , or to non-affected assets such as files belonging to unrelated programs. The means by which these objectives are met is through the initialization and execution logic of file transformation module  70  as described below.  
     [0037] The operational logic of file transformation module  70  is shown in the flow charts of FIGS. 5A, 5B and  5 C. There are three distinct phases of operation: initialization (FIG. 5A), file hook handling (FIG. 5B) and termination (FIG. 5C).  
     [0038] File transformation module  70  must be initialized before it can intercept any file activity from the operating system  71 . It is important to note that the protection module  31  is only active in the presence of, and as a result of running, the modified executable program  30 A. For example, for the Windows™ operating system, the protection module  31  could be a Dynamically Linked Library (DLL) file, which could be added to the “import table” of the original executable program  30 , as part of the conversion process by which the modified executable program  30 A is produced. This would have the effect, via inherent behaviour of the “loader” in the Windows™ operating system, of running specific code in protection module  31  automatically when the modified executable program  30 A was first invoked, before any of the actual run-time binary instructions of modified executable program  30 A were executed. No other program will cause protection module  31  to run, and since protection module  31  sets up file transformation module  70  via the calls under discussion here, file transformation module  70  will not be set-up to provide service to any other programs. Notably, original core executable program  30  will not invoke protection module  31  or the transformation services that it triggers.  
     [0039] As shown in the flow chart in FIG. 5A, at steps  501  and  502  protection module  31  first initializes file transformation module  70 . At this stage, information would be passed by protection module  31  to file transformation module  70 . Such information would include asset lists (i.e. members of transformed file sets  50 A and  51 A), calling process identification information, transformation keys, and optionally other information such as transformation algorithms. The calling process information would be obtained from the operating system  71 , and the asset-related information could be embedded in protection module  31 , or obtained by protection module  31  by reading other files. Note that the asset-related information could also be obtained by file transformation module  70  by other means, for example, it could be read from files directly by file transformation module  70 , or embedded into file transformation module  70  itself. In this embodiment, at step  503  protection module  31  uses available operating system services to “hook” the file transformation module  70  into the file system. For example in Windows 95™ or Windows 98™, file transformation module  70  could be a Virtual Device Driver (VxD), and protection module  31  could use Windows™ “Virtual File System” calls to arrange that the operating system invokes file transformation module  70  as part of the low-level sequence of operations performed on subsequent file system calls. As another example, a software interrupt handler in a “Terminate and Stay Resident” (TSR) program for Interrupt  13  hexadecimal could be used for the Microsoft Disk Operating System (MS-DOS™) With respect to FIG. 4, this hook mechanism is the means whereby interface read/write function  61 B and interface read-only function  60 B to the operating system  71  are intercepted at interface functions  60 C and  61 C by the file transformation module  70 . In this embodiment, such “hooks” (or interceptions) are reached whenever a file-READ, file-WRITE, file-OPEN or file-CLOSE operation is performed. The initialization process is then completed at step  553 . The hook having been established, and file transformation module  70  initialized, file transformation module  70  is automatically invoked on any subsequent file request.  
     [0040] Once initialized, file transformation module  70  will receive file operation requests that are directed at operating system  71 . File transformation module  70  will perform the required reverse transformation (i.e. “transformation services”) only if the invoking request to operating system  71  was identified as being for transformed data bound to or from the modified executable program  30 A. If file transformation module  70  determines that the request is not for transformed data bound to or from the modified executable program  30 A, the intercepted request would be returned to the operating system  71  for normal processing. In all cases, file transformation module  70  is invoked in such a way that the file data (if any) associated with the operation has already been placed by operating system  71  in a memory buffer known to file transformation module  70 . File transformation module  70  then has the option of applying transforms to this buffered data, or simply returning to the operating system and leaving the data in the as-found state.  
     [0041] The exact set of file operations of interest to file transformation module  70  would vary with different implementations of this invention. At a minimum, the file-OPEN, file-READ, and file-CLOSE operations are relevant. Other operations, including the file-WRITE operation, can also be used as triggers via the same operating system hooks that invoke file transformation module  70 .  
     [0042] Further information concerning these file operations follows: (i) file-OPEN: Operating system environments such as Microsoft DOS™, Microsoft Windows™, and Unix™ use the concept of integer file identifiers to keep track of opened files. File-OPEN requests that originate from the secured process (i.e. modified executable program  30 A), for files that are listed in the process&#39;s asset list (i.e. transformed file sets  50 A and  51 A), will cause file transformation module  70  to record the unique file identifier designated by operating system  71  for the opened file to be recorded along with the associated transformation keys and to add this file to an active files list; (ii) file-READ: The data returned by operating system  71  is decrypted by file transformation module  70  when a file-READ operation with a unique file identifier as established in the file-OPEN phase above, occurs for a unique identifier of a protected asset file. This is accomplished by allowing operating system  71  to complete the read operation to the destination buffer specified by the calling process and subsequently transforming the data in-place (that is, in the same destination buffer) with the asset file&#39;s associated keys; (iii) file-WRITE: Although the handling of the file-WRITE operation is not shown in FIG. 5B, it is similar to the file-OPEN operation. The transformation module  70  reverse-transforms the data in-place in the calling processes&#39; data buffer prior to calling the operating system environment to perform the actual file-WRITE operation; and (iv) file-CLOSE: The resources used to store the file identifier and keys for an opened protected asset file are discarded when the transformation module  70  receives a request to close that file.  
     [0043]FIG. 5B is a flow chart of the operational steps taken by file transformation module  70  of the present invention. At step  510 , a “hook” to file transformation module  70  is activated by the operating system  71 . If file transformation module  70  determines that the request is not for transformed data bound to or from the modified executable program  30 A, the intercepted request would be returned to the operating system  71  for normal processing at steps  523  and  525  If, however, the calling process is protected (i.e. the request is for transformed data bound to or from the modified executable program  30 A), then an analysis of the file operation is performed at step  512 . Note that in FIG. 5B, the only operations shown to be effected are file-OPEN, file-CLOSE and file-READ. Other operations, including the “file-WRITE” operation, can also be similarly intercepted.  
     [0044] If the operation is file-READ, a determination is made at step  516  whether the file identifier is in the active files list. If not, the intercepted request would be returned to the operating system  71  for normal processing at steps  517  and  525 . If the file identifier is in the active files list, file transformation module  70  returns to the operating system  71  at step  521  to allow it to complete the low-level read in the normal manner, but in such a way that it returns to the control of file transformation module  70  (via logic of file transformation module  70  not shown) at step  522 . The correct transformation key for this asset is determined at step  522 , and the data in the read buffer is transformed at step  523 . Said data will have been placed there by operating system  71  in the normal course of the read operation which was “hooked” to invoke file transformation module  70 . The process is then completed at step  525 .  
     [0045] If the operation is file-CLOSE, a determination is made at step  518  whether the file identifier is in the active files list. If not, the intercepted request would be returned to the operating system  71  for normal processing at steps  517  and  525 . If the file identifier is in the active files list, then at step  519  the file identifier and transformation keys are removed from the active files list. At step  520 , the file-CLOSE operation is performed. The process is then completed at step  525 .  
     [0046]FIG. 5C is a flow chart of the termination steps of the present invention. To terminate, at step  551  all resources allocated for the calling process are freed, and at step  552  the operating system environment hook mechanism is removed. The termination process is then completed at step  553 .  
     [0047]FIG. 6 is a block diagram showing the process by which a software program has its assets transformed according to the method of this invention. This is the pre-distribution transformation process which transforms a software program into its distribution state (see FIG. 4). First, the original distribution form  10  of the software program is taken apart by process  100  into its key components, namely installation program  20 , read-only file set  50 , read/write file set  51 , core executable support files  40 , generic executable system resources  41 , and original core executable program  30 .  
     [0048] A software conversion program  101  is then run, (the logic of which is illustrated in the flow chart of FIG. 7). This software program, typically with user input, selects specific asset files from the run-time non-executable components read-only file set  50 , read/write file set  51 . Software conversion program  101  will select transforming algorithms and keys for each chosen asset file. Then, the selected encryption algorithm for each file is applied, using the key for that particular file.  
     [0049] Modifications to the original core executable program  30  are also required. Specifically, the original core executable program  30  is transformed into modified executable program  30 A which invokes protection module  31 . For example, in the Windows™ environment, this could be accomplished by adding a reference to a DLL in an expanded version of the import table of original core executable program  30 . Protection module  31  and file transformation module  70  must be added to the file-set. The transformation keys and asset list must also be added to the file-set. They could be stored as a separate file or, for security reasons, embedded in other files such as files  30 A,  31  and/or  70 .  
     [0050] Finally, modifications to the non-run-time components are also required. Specifically, the software program&#39;s installation program  20  must be enhanced to include the new and changed components described above, resulting in a modified installation program  20 A.  
     [0051] When this process is complete there is a new set of run-time components, namely modified executable program  30 A, protection module  31 , file transformation module  70 , and transformed file sets  50 A and  51 A. The components are then transferred to a CD-ROM  10 A or other media using process  102  for distribution to the software user. These components will thereafter be invoked as necessary at application run-time.  
     [0052] It is immaterial to the present invention whether all the foregoing modifications are performed by software conversion program  101 , or whether some conversions, such as those performed on the original core executable program  30  and/or installation program  20  are implemented by independent but related processes. It is also immaterial exactly what the nature of any other transforms are applied to produce the modified executable program  30 A, as long as it invokes (usually via the protection module  31 ) file transformation module  70 .  
     [0053] There are other ways in which the conversion of core executable program  30  into modified executable program  30 A could be performed, and still effectively control the transformation behaviour of file transformation module  70 . For example, the conversion process by which modified executable program  30 A is created could add non-executable data to core executable program  30 , such that this data could be found and inspected at run-time by file transformation module  70 . This data could serve as a form of “license”, the presence and contents of which would be used by file transformation module  70  in deciding whether to apply transformations to this particular program. In another alternative conversion mechanism, the conversion process could add to core executable program  30  an extra executable “callback” function. This function would not require any relationship to the pre-existing executable code of program  30 , but would be called by file transformation module  70  when said module was determining whether to supply transformation services or not. In either of the variant embodiments described above, the first initialization of file transformation module  70  will not be invoked by core executable program  30  (or by protection module  31 , if present). However, file transformation module  70  could be initialized by some alternative means, such as by the application installation program  20 .  
     [0054]FIG. 7 is a flow chart of the file transformation process shown in FIG. 6. At step  601 , the file transformation process is started. At step  602 , the user selects the destination directory for the new set of run-time and non-run-time components, namely modified executable program  30 A, protection module  31 , file transformation module  70 , transformed file sets  50 A and  51 A, and modified installation program  20 A. At step  603 , the user selects the core executable file (executable) to be transformed in accordance with the present invention. At step  604 , the user also selects a data file to be transformed (also known as an “asset file”)). At step  605 , the software conversion program generates a transformation key. At step  606 , the selected asset file is transformed using the transformation key, and is placed in the destination directory. Using decision step  607 , steps  604 - 606  are repeated until there are no more asset files to transform. At this point the asset list and associated transformation key set is available and may be stored separately, or incorporated into other files.  
     [0055] At step  608 , protection module  31  is retrieved and added, including optionally the aforementioned asset file and transformation key information. At step  609 , a modified executable program  30 A is created with dependence on the protection module  31 . As previously discussed, such dependence would typically consist, in the Windows™ environment, of adding an import table reference to modified executable program  30 A which refers to a protection DLL. Note that in one embodiment of this invention, the linking of original core executable program  30  to protection module  31  may be the only modification done to original core executable program  30  to produce modified executable program  30 A. The file transformation process is completed at step  610 .  
     [0056] The following is an example of the operation of the present invention according to an implementation of one embodiment.  
     [0057] 1. A software publisher creates a software program for the Windows 95™ environment. An example would be a role-playing entertainment program with multiple levels. In this example, each level is represented by a 50-megabyte read-only data file (the assets). The core executable file is a .EXE file of 2 megabytes.  
     [0058] 2. Using the steps shown in FIG. 6, the software program is converted in accordance with the present invention, such that each data file  50  is transformed into a transformed data file, and a modified executable program  30 A dependent on these transformed data files is also created.  
     [0059] 3. This converted form of the software program is packaged and distributed to users on CD-ROM or other media.  
     [0060] 4. A user installs and runs the software program.  
     [0061] 5. Upon installation, the modified executable program  30 A, modified read-only file-set  50 A, protection module  31  and file transformation module  70  are all copied or made available to the user&#39;s computer. This is in addition to all of the components which would normally be in place for the software program in question. Protection module  31  could take the form of an Object Linking and Embedding (OLE) object, a separate executable file, or a Dynamically Linked Library (DLL) file. In the case of a file executable in conjunction with Windows 95™ or Windows 98™, the file transformation module  70  would optimally be a Windows Virtual Device Driver or VxD. In the present example, the read/write files, if any, of the software program would not be affected.  
     [0062] 6. When the program is run, it presents the user with the first level of the software program. Of necessity, this means that the first level data file must be accessed and read by the modified executable program  30 A. In accordance with the flow chart shown in FIG. 5B, the initial file-OPEN operation triggers file transformation module  70  which determines that this particular combination of file and file-READing program is to have a transformation applied.  
     [0063] 7. All subsequent file-READS to the level  1  data file invoke file transformation module  70 , which, according to FIG. 5B, allows the file system do the actual reading, and transforms the buffered file data in-place prior to it being make available, by the operating system  71 , to the modified executable program  30 A. While it is not common for such files to be read/write, writes could be similarly intercepted and transformed if required.  
     [0064] 8. When the program exits, or the user moves to another level within the software program, the level  1  file is closed, at which time the transformation module  70  resets all information associated with that data file. Any subsequent manipulation of that file would have to be started with a file-OPEN operation, as required both by the local file system and by transformation module  70  according to this invention.  
     [0065] The above description of a preferred embodiment should not be interpreted in any limiting manner since variations and refinements can be made without departing from the spirit of the invention. The scope of the invention is defined by the appended claims and their equivalents.