Sorry. In preparing the text of !!corner.unp (Cornerstone unprotection scheme), which I uploaded yesterday, I inadvertently deleted the last paragraph. It is necessary for anyone unfamiliar with the structure of directory entries. I am resending the entire document, and apologize for the inconvenience. CORNERSTONE UNPROTECTION SCHEME ------------------------------- The following describes a method of completely unprotecting the hard disk installation of Infocom's Cornerstone, and a less complete method of unprotecting future versions which may render the first method obsolete. The Cornerstone installation process creates a hidden file named INFOCOM.CNR in the root directory. This file contains two bytes, which rperesent in encrypted form the cluster number where the file is stored. When Cornerstone is invoked, the program first checks for the existence of the hidden file, and then compares the data with the cluster number in the directory. If the checks fail, Cornerstone looks for a legitimate system disk in Drive A. At present (Cornerstone version 5.1, which I believe to be the most current release), this can be completely circumvented by searching the file mme.exe for the two INT 13's it contains, and NOP'ing them out. Specifically, rename a copy of mme.exe to something with a non-exe extension, e.g. mme.zap. Run debug, and load mme.zap. Now, at the debug prompt type "s 0 l ffff cd 13" (without quotes). Debug responds: XXXX:86C9 XXXX:86E1 (If this is not the case, you have a different version, though if it detects two INT 13's, it might be worth trying what follows, substituting the offsets that debug reports to you for those I am using.) Type: e 86C9 Debug responds: CD. Type: 90 Debug responds: 13. Type: 90 Now type: e 86E1 Debug responds: CD. Type: 90 Debug responds: 13. Type: 90 Now type: w, then q, then rename mme.zap to mme.exe. If desired, the hidden file INFOCOM.CNR may now be deleted from the hard disk, and the program will run without reference to it. Now, for the second, and still incomplete method, which is unneeded at present but may become important if Infocom becomes aware of the simple method above and changes it to something more complex. As indicated above, the two bytes in the file INFOCOM.CNR represent a nibble for nibble encryption of the cluster number where INFOCOM.CNR resides. Although I have not yet worked out the exact rules of encryption, taking the hex digits of the cluster number from left to right, one adds plus or minus 4 to the first, plus or minus 2 to the second, plus or minus 4 to the third, and plus or minus 7 to the fourth. Thus, it requires at most 16 tries to create the correct contents of INFOCOM.CNR. The following examples may eliminate some of these: Cluster INFOCOM.CNR ------- ----------- 2401 6648 3218 7051 4601 0448 4801 0A48 4901 0B48 4851 0A18 4A01 0848 4B50 0919 5919 1A50 5A19 1850 6317 215E 8619 C450 8B19 C950 8D19 CF50 9B5E D917 BA03 F84A BF5E FD17 D05D 9214 The cluster number can be obtained with any utility capable of displaying the directory contents, e.g. the Norton Utilities, Disk Toolkit, or even debug. It is given by the 27th and 28th bytes (i.e. bytes 26-27) of the directory entry for INFOCOM.CNR, which will appear early in the directory, either between or just following other entries for the root directory. The above encryption algorithm is applied, and the utility program then used to replace the contents. Note that for the purposes of this exercise, the bytes are taken as as, i.e. least significant byte first, not reversed to give the actual cluster number.