jf4@bonnie.UUCP (John Fourney) (02/13/85)
*** REPLACE THIS LINE WITH YOUR MESSAGE *** When I boot a protected disk into internal RAM, what's to prevent me from copying the program to another disk? Someone told me that my drive heads will get messed up. Is this true? Can we discuss how one can copy protect their own disk? Thanks, John
joels@tektools.UUCP (Joel Swank) (02/18/85)
> When I boot a protected disk into internal RAM, what's to prevent me > from copying the program to another disk? Someone told me that my > drive heads will get messed up. Is this true? Can we discuss how > one can copy protect their own disk? Copy protection does not prevent you from actually copying anything. It just prevents the copied program from running. When the program initializes, it looks for something weird on the disk: certain error patterns, tracks written off center, codes written in unused portion of the BAM, etc. if these are not present, it assumes that it is a copy and wipes itself out. What copier programs do is find these weirdnesses, and copy them too. Copying a copy protected program can in no way damage your disk drive. It is theoreticly possible that running a copied program might damage your disk. The program could, when it discovered that it was a copy by one of the above means, download a program into the drive that could try to damage the drive by beating the head against the stop. I know of no companys that have resorted to this yet. If you want to protect your diskettes, you will have think up a scheme that no one has come up with yet. Then don't tell anyone. We've already had several rounds of new protection schemes, followed by new copier programs. I expect this this competition to continue. Joel Swank Software Center Tools Support 50-487 Tektronix Beaverton OR 97077 (503) 627-4403
lenoil@mit-eddie.UUCP (Robert Scott Lenoil) (02/19/85)
This month's COMPUTE! (or was it COMPUTE GAZETTE?) had a neat article on
write protecting disks. It involved changing the flag byte on track 18,
sector 0 of the disk that flags the DOS version. Changing that value
allowed the 1541 to read the disk, but refuse to write to it on the
grounds that it was a different DOS type. To unprotect the disk, you
issue a memory write command to the 1541, to trick it into thinking that
its DOS version corresponds to the one on the disk. Unfortunately, I
only had a peek at this article. Could someone with access to it please
post the specifics?
Robert Lenoil
USENET: {ihnp4, decvax!genrad}!mit-eddie!lenoil
ARPA: lenoil@mit-xx.arpadpa@snow.UUCP (David Angier) (02/21/85)
> When I boot a protected disk into internal RAM, what's to prevent me > from copying the program to another disk? Someone told me that my > drive heads will get messed up. Is this true? Can we discuss how > one can copy protect their own disk? About the heads, rubbish. The usual method of disk protection is to have a boot up program ("loader") that brings in the bulk of the code and does many nasty things, such as :- 1) Checking for certain errors on the disk, these are put on the disk during production and are very hard to create otherwise. If the error is not on the disk the program will not work. 2) Setting up lots of horrible vectors so that there is no way of reseting the machine while loading of after it is loaded. (without turning off that is :-) ). This stops you putting on another disk since there is no way of getting to a save routine. 3) Writing the loader with a lot of illegal opcodes, these are not documented but do the same things on all 6510's. These make it hard to crack the loader, so that the above is no longer done. 4) Using bugs in the 6510 to confuse people cracking the loader. 5) Using tracks 36-40 of the disk drive!! 6) Auto-running loader that means nothing if loaded in the wrong place. 7) Encoding the main program chunk so that it means nothing without the loader. The list goes on and on, to put in your own protection I suggest getting 'Disk Di-Sector' that allows error creation, this will stop all but the must rabid pirates. There is some protection that I don't understand, I could back up every bit on a disk to another disk, find no errors and still not have it run! Dave.
dpa@snow.UUCP (David Angier) (02/28/85)
I've just discovered a NEW form of protection (I was looking at a game called Fighter Pilot). I am intrigued at how it protects itself, there are no Disk Errors and yet it still won't get past the loader when copied (I've got the original, it's just a hobby trying to find out how things work). A lot of hard work (and looking at the dis-assembly of the DOS) has lead to the re-discovery of a DOS command '&', when sent to the disk controller it crashes, except on the original of Fighter Pilot where the default drive number becomes 8!!! (Not the device no. the DRIVE no. :-) Much later I found that this causes a file called '&,USR' to be loaded into the DOS RAM directly and then executes (seems like B-E to me), but has a strange file format:- Low address (load and execute) Hi address Byte count data . . Checksum. This was deduced from the DOS dis-assembly, but the file on the Fighter Pilot disk (&,USR) points to track 18 sector 1, the directory track and the check-sum would be wrong etc.. Looking around I found the directory header block (Trk 18 sct 0) was set up in this format!! The original loads the header block into the DOS RAM, all copies load the directory, is there any one out there who knows what the '&' command really does, has it a bug? Dave.
dillon@ucbvax.ARPA (The Sherif "Matt D.") (03/06/85)
> the directory, is there any one out there who knows what the '&' > command really does, has it a bug? > Dave. The & command is called the "Utility loader". It was placed in by Commodore but strangely never documented (gee... I know of 10-20 other things like that) Anyhow it loads and executes a disk file in DOS ram. On early 1541 disk drives you could also use the "boot clip" to auto load and execute the first file on the disk on powerup. (this feature was removed in ROM revision 5) The command does not have bugs (!), just a weird format for more than 253 bytes of data. -Bryce Nesbitt of the society to port BSD 4.2 to the Timex/Sinclair 1000