Software-based protection system for software products distributed on copyable media, or downloaded over a communications link

[0002] (1) Field of the Invention

[0003] Innovations disclosed by the present invention relate to the protection of a computer software product from unfair use on more than one customer system. This invention is based on the use of a protection file that contains internalized attributes that characterize a specific customer system environment. The protection file is encrypted and contains a digest, so that attempts to convert a protection file for use on another system are futile. Programs within the product distributor's software product interrogate the protection file to determine if the internalized attributes correspond with the attributes of the prevailing system environment. The protection file is either prepared on the product distributor's system, or is prepared by special programs that operate on the customer's system. These special programs are contained within an encrypted composite file. At any moment, no more than one of the special programs that participate in protection file preparation is decrypted. Thus, attempts to reverse engineer the process that prepares the protection file are futile.

[0004] (2) Description of the Related Art

[0005] Various-strategies are used to prevent unfair use of software products today.

[0006] The most common technique uses a key, which is a series of characters, that is typed during product installation. Often this key does not contain information regarding the customer's system environment, and the product can be installed on other systems by typing the key during installation there as well.

[0007] Another method prepares a special key file (license) that is stored on customer systems, so that the product is only operable if the license is present. However, this method fails if the software is copied to another system, and the license is copied to that system as well; i.e. the license file does not contain information regarding the attributes of a specific system.

[0008] Another method uses an electronic device, called a ‘dongle’, that is attached to a customer's printer port to enforce use of the product on systems that have this device. This requires product distributors to acquire and ship an electronic device with every product shipment. This approach is particularly inappropriate for software that is distributed by communication media downloads.

[0009] U.S. Pat. No. 5,917,908 describes a method which encodes a key that is unique to a customer's system environment, along with positional information regarding where the key is stored within the customer's storage media, but this solution always requires an interaction between the customer and the product distributor after the product is received. Furthermore, this patent lacks a method for backing up the protection file, in case the original protection file is lost or damaged.

[0010] Problems associated with software protection strategies are described on page 179 of the book “A Gift of Fire”, by Sara Baase (1997 by Prentice-Hall, Inc. Upper Saddle River, N.J. 07458; ISBN 0-13-458779-0).

[0011] The present invention is a fail-safe technique for ensuring a software product operates on secured customer systems, without opportunities for reverse engineering the technology that secures these products. A protection file is created that is stored in the storage media associated with a customer's software utilization-system. The protection file contains internalized attributes that characterize a specific customer system environment. The system identifier of IBM mainframe computers, is an example of an attribute that characterizes that system. The protection file is encrypted and contains a digest, so that attempts to convert a protection file for use on another system are futile. Programs within the product distributor's software product interrogate the protection file to determine if the internalized attributes correspond with the attributes of the prevailing system environment.

[0012] When the computer software product is distributed on copyable media, the protection file must be created on the product distributor's system environment. The unique attributes of the customer's system environment are encoded within a binary file, that is sent to the product distributor by electronic mail. The binary file that is encoded during this process is not the same as the protection file that.is required for software product usage. Upon receiving the binary file, the product distributor decodes the attributes and prepares the required protection file. The product distributor sends the protection file to the customer by electronic mail, along with instructions describing where the protection file should be placed within the customer's storage medium.

[0013] When the computer software product is distributed via a communications media download, the protection file can be created directly on the customer's system environment. However, this requires encryption of the programs that prepare the protection file. These programs create the protection file by a cascade of successive steps. A parameter that is passed to the product distributor's installation program contains the required keys for decoding the programs in all steps. Each program that participates in this process:

[0014] eliminates the previous program

[0015] extracts the key that is required for decrypting the next program

[0016] decrypts the next program

[0017] invokes the next program with the remaining parameters after key extraction

[0018] At the conclusion of the last program, only the last program remains. If a system outage occurs during the protection file preparation process, no more than two programs associated with this process will remain on the customer's system. Every other program, including the first and last program, do not participate in protection file preparation. The logic that is encoded within a single program that participates in protection file preparation should be minimal, to thwart reverse engineering attempts. The parameter that contains the keys for decoding remaining programs, is lost as a consequence of the system outage. The customer must use the technique associated with acquiring a protection file for ‘copyable media’ that was described above.

[0019] Subsequently, the customer can use the technique associated with acquiring a protection file for ‘copyable media’, in case the protection file is lost or damaged. The customer can also store copies of the protection file on various storage media, and use these as subsequent replacements for a protection file that is lost or damaged.

[0020] The invention associated with this patent is characterized by the following significant innovations.

[0021] Innovation #1:

[0022] attributes that uniquely characterize a customer system can be encoded in a key file.

[0023] Innovation #2:

[0024] the key file, prepared by Innovation #1 can be sent to the product distributor, who responds with a protection file.

[0025] Innovation #3:

[0026] a protection file can be directly created when software is downloaded using a communication media.

[0027] Innovation #4:

[0028] the programs that create the protection file are encrypted. The keys to decrypt these programs are passed as a parameter to a program that is invoked on the customer's system during the conclusion of the download process. The parameter is passed in a volatile memory area, and is lost if a system outage occurs during the download process. The parameter is sufficiently intricate, so that a protection file cannot be prepared with prevailing files after the system outage has occurred.

[0029] Innovation #5:

[0030] accidental loss or damage of a protection file, can be overcome by using backup copies, or using Innovation #1 and #2 again.

[0031] FIG. 1 is a diagram illustrating a software product distribution overview.

[0032] FIG. 2 is a diagram illustrating how a computer system attributes are encoded in a ‘key’ file.

[0033] FIG. 3 is a diagram illustrating how the key is encoded as a protection file.

[0034] FIG. 4 is a diagram illustrating how the key file is sent to the product distributor.

[0035] FIG. 5 is a diagram illustrating how the product distributor prepares the corresponding protection file.

[0036] FIG. 6 is a flowchart illustrating a procedure that encrypts key information to produce the protection file.

[0037] FIG. 7 is a diagram illustrating how the protection file is sent to the client.

[0038] FIG. 8 is a flowchart illustrating how other programs validate the protection file for the current system.

[0039] FIG. 9 is a diagram illustrating how the system attributes could be encoded directly as a protection file, during a network download, without distributor involvement.

[0040] FIG. 10 is a diagram illustrating how the program that creates the protection file is activated with a special parameter string, which provides the keys to successively decrypt the programs in the encrypted program bundle.

[0041] FIG. 11 is a diagram illustrating the organization of the protection file prior to encryption, or after decryption.

[0042] FIG. 12 is a diagram illustration the organization of the composite file of encrypted protection file preparation programs.

[0043] A description will be given of an embodiment of the present invention.

[0044] A customer system (a computer system) to which the protection system of the present inventions is applied is formed as shown in FIG. 1. Referring to FIG. 1, the customer system has a computer processing unit (CPU), display device (video display tube (VDT)), keyboard, persistent storage file system (hard disk), and either a device that can read copyable media (floppy drive, CD-ROM drive, magneto-optical (MO) disk) or a device that can participate in communication media interactions (modem, network interface card).

[0045] Two software product distribution techniques are displayed in FIG. 1. FIG. 1A illustrates a technique that distributes the software on copyable media, and acquires a protection file from the product distributor's site. FIG. 1B illustrates a technique that prepares the protection file directly on the customer system, without requiring further distributor involvement.

[0046] The product distributor prepares the contents of one or more units of copyable media. This media contains the installation program, product programs (applications) and associated files. This media also contains the key discovery program. The customer acquires the media from the product distributor by completing a terms of sale agreement. The product distributor delivers the copyable media to the customer using conventional package shipping agents. The copyable media is accompanied with a product serial number.

[0047] Software products that are distributed on copyable media are loaded into the customer's copyable-media device. An installation program that was provided by the product distributor is activated on the CPU. The installation program converts product programs and other files to a directory (folder) in the customer's storage system. The installation program then displays a fill-in-the blank registration form on the customer's display device. This form has a field where the product serial number is entered. The form has various other fields; i.e., name, mailing address, phone numbers, etc. When the customer has completed the registration form, the installation program activates the key discovery program, which prepares a binary ‘key’ file containing attributes that are unique to the current system environment. The binary ‘key’ file includes a digest that ensures the integrity of the file's contents. FIG. 2 shows the key discovery process. After the binary ‘key’ file has been prepared, the installation program transmits information entered in the form's fields as an electronic mail message to the product distributor. The binary ‘key’ file is sent as an attachment of the message. FIG. 4 shows how the message and ‘key’ are sent. After the message has been sent, the binary ‘key’ file is erased from the customer's storage system.

[0048] FIG. 5 shows how the distributor converts the key file to a protection file. When a product distributor's sales support representative receives the registration electronic mail message from the customer, the digest within the binary ‘key’ file is authenticated. If the digest does not match the contents of the binary ‘key’ file, then the file is invalid, and the sales support representative must communicate with the customer regarding the situation. The customer must initiate the product registration activity again.

[0049] If the digest matched the contents of the binary ‘key’ file, the information in the message and the binary ‘key’ file is added as an entry in the customer information database, using the product serial number as a database key (there is no relationship between a database key, and the ‘key’ file). If an entry with the same product serial number is discovered in the customer information database, a comparison is made between the information in the binary ‘key’ file that was sent with the electronic mail message, and the binary ‘key’ file that was previously stored in the customer information database. If these do not match, the sales support representative must communicate with the customer regarding the previous product registration. The sales support representative may establish a new sales agreement with the customer that sent the electronic mail message, in which case a new product serial number is established. The information in the message and the binary ‘key’ file is added as an entry in the customer information database, using the new product serial number as a database key. If the customer declines to establish a new sales agreement, then preparation of a protection file is avoided, and the product registration request is no longer processed.

[0050] If a previous entry was not present in the customer information database, or the previous entry's binary ‘key’ matched the message's binary ‘key’, or a new product serial number was established, preparation of the protection file can ensue. FIG. 3 is an overview of the conversion of the ‘key’ to a protection file. FIG. 6 is a flowchart of the conversion process. The generated protection file contains:

[0051] 1. Key information—attributes that are unique to the customer's system

[0052] 2. Gibberish—to conceal the location of the key information

[0053] 3. Digest—a 16 byte binary value that ensures the integrity of the protection file

[0054] The sales support representative uses a support application to activate the first protection file preparation program with the name of the binary ‘key’ file as a parameter. The support application passes an additional string parameter to the first protection file preparation program. Other protection file preparation programs are encrypted within a composite file, as shown in FIG. 10.

[0055] The product distributor must ensure that the sales support application, the first protection file preparation program, and other protection file preparation programs that are encrypted within a composite file are stored where only authorized employees can access them. If these are accessed by unauthorized parties, opportunities exist for illegal preparation of protection files, or reverse engineering the protection file preparation process.

[0056] The first protection file preparation program extracts information from the additional string parameter to determine how to decrypt the second protection file preparation program from the encrypted composite file. FIG. 10 illustrates the protection file preparation process. The second program is invoked with the name of the binary ‘key’ file as a parameter, and the remainder of the additional string parameter as a second parameter. There are four stages of protection file preparation. Each stage is performed by a different program within the encrypted composite file. Each stage except the first erases the program before it. When the last stage completes, the first protection file preparation program erases the last stage's program. FIG. 11 shows the organization of the protection file prior to encryption, or after decryption.

[0057] Stage 1: random gibberish is added to the body of the protection file.

[0058] The following is a sketch of the algorithm that is used to add gibberish to the file. Here it is assumed that the extent of the body of the protection file is 4096. Other extents could be used instead.

[0059] setRandomRoot(currentTime)

[0060] extent=4096

[0061] loop(i:1 . . . extent)

[0062] body[i]=random( )

[0063] Stage 2: system attribute information is added to the body of the protection file.

[0064] The following is a sketch of the algorithm that is used to add system attribute information to the file. Assume the system attribute information has 16 bytes. These bytes are stored at arbitrary locations within the body of the protection file. Here the factors of 4851 are used to identify where individual bytes are stored. Note: 4851 is the sum of the first 98 integers; i.e. 1+2+. . . +98. It is recommended that the offsets are dynamically computed, instead of providing these as constants in the program.

[0065] systemAttributeInformation [ ]=AcquiresystemAttributeInformation( )

[0066] offset [ ]={3, 7, 9, 11, 21, 33, 49, 63, 77, 99, 147, 231, 441, 539, 693, 1617}

[0067] attributeLength=length(systemAttributeInformation)

[0068] loop(i:1 . . . attributeLength)

[0069] body[offset[i]=systemAttributeInformation[i]

[0070] Stage 3: a digital digest is appended to the end of the protection file.

[0071] The digest is computed by analyzing the body of the protection file using the MD5 algorithm. The resulting digest is 16 bytes in length. It is stored immediately after the last byte of the body of the protection file. The MD5algorithm is distributed by RSA Security, Inc. A description of this algorithm and its source code are available in Internet RFC 1321.

[0072] Stage 4: the protection file is encrypted.

[0073] Finally, the entire protection file is encrypted using a key-less algorithm. An example of a suitable encryption algorithm follows. More sophisticated algorithms can also be used. In this algorithm contents are processed a word at a time. The size of a word is dependent on the system environment. In the algorithm below the word size is assumed to be 4 bytes. Proceeding from the left toward the middle, words are swapped with those from the right toward the middle. Before swapping, words are exclusive ORed with a mask, and then rotated leftward 20 bits. Then the mask is rotated rightward 2 bits. The value word[n] is a reference to the Nth word within the entire range of the protection file's contents. The mask value shown below is examplary. Other similar mask values could be used instead.

[0074] bodysize=4096

[0075] digestsize=16

[0076] wordsize=4

[0077] left=1

[0078] right=(bodysize+digestsize)/wordsize

[0079] middle=right/2

[0080] mask=2146426330[hexadecimal 7FEFDDDA]

[0081] loop(i:1 . . . middle)

[0082] leftword=word[i]

[0083] rightword=word[(right+1)−i]

[0084] xor(leftword, mask)

[0085] xor(rightword, mask)

[0086] rotateLeft(leftword, 20)

[0087] rotateLeft(rightword, 20)

[0088] word[(right+1)−i]=leftword

[0089] word[i]=rightword

[0090] rotateRight(mask, 2)

[0091] After the above encryption has completed, it is difficult to determine where various bytes of the original protection file reside. In addition, the bytes of the digest have become scrambled as well. Attempts to alter the byte values of the system attribute information is considerably problematic. Altering the digest so that it matches the altered system attribute information is virtually impossible. The digest contains 128 bits (8*16). Thus, 2 to the 128th trial and error attempts are necessary to compute the correct digest that matches the body of the protection file.

[0092] Further integrity can be attained by using multiple digests. The computation of each digest augments the body of the protection file with a computable gibberish segment of arbitrary length. A gibberish segment can be computed by setting the seed of the random number generator to a known value. A sequence of random numbers is then computed. The remainder of the first random number-with respect to a known value (e.g. 250), is added to a minimal size (e.g. 250) to compute the segment's length. Byte values within the segment are determined by subsequent random numbers. If 32 digests are computed, then there are 4096 bits (8*32*16) in all. Under these circumstances, 2 to the 4096th trial and error attempts would be necessary to compute the correct digest that matches the body of the protection file.

[0093] At this point, the protection file is ready to be sent to the customer, for insertion into the appropriate directory (folder) of the customer's storage system. FIG. 7 is an overview that shows how the protection file is sent to the customer. This is done by sending an electronic mail reply to the customer's electronic mail registration request. The text of the message acknowledges that the customer has registered the product serial number. The protection file is provided as a binary file attachment. Instructions within the electronic mail message identify how and where the protection file should be stored. For example, the file should be named PROTFILE.DAT, and stored in the same directory (folder) as the product program (application) executable files. The file could be stored in other well known directories as well.

[0094] FIG. 9 shows the steps that proceed when products are delivered by communication media downloads.

[0095] The product distributor prepares a communications site (internet web page). The customer uses the communication media device (modem, network interface card) to acquire software products from this communications site. The customer completes a terms of sale agreement, and a financial transaction is performed to purchase a product. Afterwards downloading of the product ensues.

[0096] The product download operation is managed by the ‘Download Supervision Program’, which is activated on the CPU. This program receives files from the distributor's site, and converts these to the first protection file preparation program, product programs (applications) and associated files. One of the files is the composite file that contains encrypted protection file preparation programs. Another file contains the customer's product serial number. The key discovery program is one of the programs that is prepared, in case an outage occurs which would require preparing the protection file by using the copyable media technique. All downloaded files are stored in one or more directories (folders) within the customer's storage system.

[0097] At this point the protection file preparation process is performed. The file has a name that is known by product programs (applications); such as, PROTFILE.DAT. The file is prepared in the same directory (folder) as product programs (applications). The file could be stored in other well known directories as well.

[0098] The Download Supervision Program activates the first protection file preparation program, with a string parameter. The first protection file preparation program extracts information from the additional string parameter to determine how to decrypt the second protection file preparation program from the encrypted composite file. FIG. 10 illustrates the protection file preparation process. The second program is invoked with a parameter which is the remainder of the original string parameter that followed the information that was used to extract the second program. There are four stages of protection file preparation. Each stage is performed by a different program within the encrypted composite file. Each stage erases the program before it.

[0099] More than four programs are contained within the encrypted composite file. Every other program erases the prior program, and invokes the next program, without participating in the preparation of the protection file. When the last program completes, it is the only program remaining on the customer's system. The first and last programs also do not participate in protection file preparation. If a system outage occurs during the preparation of the protection file, no more than two preparation programs will be present on the customer's system in decrypted form. Only one of these programs participates in protection file preparation. This reduces exposure of the logic contained in these programs to reverse engineering attempts.

[0100] The information required to extract and decrypt the protection file preparation programs is passed as a volatile parameter. The value of this parameter is lost when a system outage occurs. Thus, the customer does not have sufficient information to continue the protection file preparation process after the system outage has occurred. In this case, the protection file must be prepared by using the copyable media technique described earlier.

[0101] An implementation of the algorithms described here should periodically try to detect if the customer is executing the program in a debugging environment and cease to operate if so.

[0102] FIG. 11 shows the organization of the protection file prior to encryption, or after decryption.

[0103] Stage 1: Random Gibberish is Added to the Body of the Protection File.

[0104] See the algorithm that added gibberish to the protection file in the copyable media technique above.

[0105] Stage 2: System Attribute Information is Added to the Body of the Protection File.

[0106] See the algorithm that added system attribute information to the protection file in the copyable media technique above.

[0107] Stage 3: a Digital Digest is Appended to the End of the Protection File.

[0108] The MD5 algorithm is used, as described in the copyable media technique above.

[0109] Stage 4: the Protection File is Encrypted.

[0110] See the encryption algorithm that was described in the copyable media technique above.

[0111] At this point, the protection file is ready for use by product programs (applications) on the customer's system. The customer should be advised to prepare one or more backup copies of the protection file.

[0112] How Product Programs (Applications) Determine they are Executing on a Secured System

[0113] FIG. 8 shows how product programs (applications) ensure that the protection file is appropriate for the current customer system.

[0114] Each product program (application) contains embedded logic that compares attributes within the protection file versus prevailing attributes of the customer's system. The protection file (e.g. PROTFILE.DAT) is located in the same directory (folder) as the product program (application), or another well known directory. Information within the protection file is processed in three stages. An implementation of these algorithms should periodically try to detect if the customer is executing the program in a debugging environment and cease to operate if so.

[0115] Stage 1: the Protection File is Decrypted.

[0116] The entire protection file is decrypted using a key-less algorithm. An example of a suitable encryption algorithm follows. If a more sophisticated algorithm was used when the file was encrypted, the counterpart decryption algorithm must be used instead.

[0117] In this algorithm file contents are processed a word at a time. The size of a word is dependent on the system environment. In the algorithm below the word size is assumed to be 4 bytes. Proceeding from the left toward the middle, words are swapped with those from the right toward the middle. Before swapping, words are rotated rightward 20 bits, add then exclusive ORed with a mask. Then the mask is rotated rightward 2 bits. The value word[n] is a reference to the Nth word within the entire range of the protection file's contents.

[0118] bodysize=4096

[0119] digestsize=16

[0120] wordsize=4

[0121] left=1

[0122] right=(bodysize+digestsize)/wordsize

[0123] middle=right/2

[0124] mask=2146426330[hexadecimal 7FEFDDDA]

[0125] loop(i:1 . . . middle)

[0126] leftword=word[i]

[0127] rightword=word[(right+1)−i]

[0128] rotateRight(leftword, 20)

[0129] rotateRight(rightword, 20)

[0130] xor(leftword, mask)

[0131] xor(rightword, mask)

[0132] word[(right+1)−i]=leftword

[0133] word[i]=rightword

[0134] rotateRight(mask, 2)

[0135] Stage 2: a Digital Digest is Computed for the Protection File's Body.

[0136] The MD5 algorithm is used, as described in the copyable media technique above. A digest is computed for the body of the protection file and compared with the digest that resides at the end of the decrypted protection file. If these digests do not match the protection file is invalid for the current system environment, because the protection file has become corrupted intentionally or accidentally.

[0137] Stage 3: System Attribute Information is Compared Versus the Value in the Body of the Protection File.

[0138] Attributes that uniquely identify the customer's system are acquired by calling various programs available within the current system environment. The following is a sketch of the algorithm that is used to compare the acquired system attribute information to the file. Assume the system attribute information has 16 bytes. The factors of 4851 could be used to identify where the individual bytes are stored in the body of the protection file. Note: 4851 is the sum of the first 98 integers; i.e. 1+2+. . .+98.

[0139] systemAttributeInformation[ ]=AcquiresystemAttributeInformation( )

[0140] offset[ ]={3, 7, 9, 11, 21, 33, 49, 63, 77, 99, 147, 231, 441, 539, 693, 1617}

[0141] extent=length(systemAttributeInformation)

[0142] loop(i:1 . . . extent)

[0143] if mismatch(body[offset[i]],

[0144] systemAttributeInformation[i])

[0145] error( )

[0146] If the system attribute information does not match the values in the protection file, then the product program (application) is not permitted to execute on the current customer system. Either the file was copied from another system, or the protection file has become corrupted intentionally or accidentally. The customer can replace a corrupted protection file with a backup copy if one is available. Otherwise, a new protection file must be obtained by using the copyable media technique.

[0147] How a Protection File Preparation Program is Encrypted

[0148] Protection file preparation programs are encrypted with a variation of the encryption routine that was described earlier. The following is an example of a suitable key-less- encryption algorithm. More sophisticated algorithms can also be used. In this algorithm program contents are processed a word at a time. The size of a word is dependent on the system environment. In the algorithm below the word size is assumed to be 4 bytes Proceeding from the left toward the middle, words are swapped with those from the right toward the middle. Before swapping, words are exclusive ORed with a mask, and then rotated leftward 20 bits. Then the mask is rotated rightward 2 bits. The value word[n] is a reference to the Nth word within the entire range of the program contents. The mask and the program's origin and size are parameters to the encryption routine.

[0149] word[ ]=GetProgramorigin( )

[0150] programsize=GetProgramsize( )

[0151] wordsize=4

[0152] left=1

[0153] right=programsize/wordsize

[0154] middle=right/2

[0155] mask=GetMask( )

[0156] loop(i:1 . . . middle)

[0157] leftword=word[i]

[0158] rightword=word[(right+1)−i]

[0159] xor(leftword, mask)

[0160] xor(rightword, mask)

[0161] rotateLeft(leftword, 20)

[0162] rotateLeft(rightword, 20)

[0163] word[(right+1)−i]=leftword

[0164] word[i]=rightword

[0165] rotateRight(mask, 2)

[0166] How the Composite File of Encrypted Protection File Preparation Programs is Prepared

[0167] The composite file of encrypted protection file preparation program is prepared as a collection of segments. Gibberish segments of various sizes are added at the beginning, end, and between all of the encrypted program segments. FIG. 12 shows the organization of the composite file.

[0168] How a Protection File Preparation Program is Decrypted

[0169] Protection file preparation programs are decrypted with a variation of the decryption routine that was described earlier. The following is an example of a suitable key-less decryption algorithm. More sophisticated algorithms can also be used. In this algorithm file contents are processed a word at a time. The size of a word is dependent on the system environment. In the algorithm below the word size is assumed to be 4 bytes. Proceeding from the left toward the middle, words are swapped with those from the right toward the middle. Before swapping, words are rotated rightward 20 bits, and then exclusive ORed with a mask. Then the mask is rotated rightward 2 bits. The value word[n] is a reference to the Nth word within the entire range of the program contents. The mask and the program's origin and size are parameters to the decryption routine. These are the parameters that are passed to the various stages shown in FIG. 10; i.e. param_1, param_2, and param_3. The GetMask( ), GetProgramOrigin( ), and GetProgramSize( ) functions below obtain the values from the decryption routine's parameter string.

[0170] word[ ]=GetProgramorigin(parameterstring)

[0171] programsize=GetProgramsize(parameterString)

[0172] wordsize=4

[0173] left=1

[0174] right=programsize/wordsize

[0175] middle=right/2

[0176] mask=GetMask(parameterString)

[0177] loop(i:1 . . . middle)

[0178] leftword=word[i]

[0179] rightword=word[(right+1)−i]

[0180] rotateRight(leftword, 20)

[0181] rotateRight(rightword, 20)

[0182] xor(leftword, mask)

[0183] xor(rightword, mask)

[0184] word[(right+1)−i]=leftword

[0185] word[i]=rightword

[0186] rotateRight(mask, 2)

[0187] Although the present invention has been described and illustrated with specific reference to certain detailed arrangements, it will be apparent to those skilled in this field that alternative embodiments will achieve the same results without deviating from the basic concept of the invention. All such embodiments and their equivalents are deemed to be within the scope of the invention as set out in the description.