Message-ID: <414@bonnie.UUCP>
Date: Wed, 13-Feb-85 14:11:22 EST
Article-I.D.: bonnie.414
Posted: Wed Feb 13 14:11:22 1985
Date-Received: Thu, 14-Feb-85 01:25:15 EST
Organization: AT&T Bell Laboratories, Whippany NJ
Lines: 7

*** 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

Message-ID: <3651@mit-eddie.UUCP>
Date: Mon, 18-Feb-85 17:23:29 EST
Article-I.D.: mit-eddi.3651
Posted: Mon Feb 18 17:23:29 1985
Date-Received: Wed, 20-Feb-85 20:17:20 EST
References: <414@bonnie.UUCP>
Reply-To: lenoil@mit-eddie.UUCP (Robert Scott Lenoil)
Organization: MIT, Cambridge, MA
Lines: 13

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.arpa

Message-ID: <136@tektools.UUCP>
Date: Mon, 18-Feb-85 11:37:56 EST
Article-I.D.: tektools.136
Posted: Mon Feb 18 11:37:56 1985
Date-Received: Fri, 22-Feb-85 01:07:24 EST
References: <414@bonnie.UUCP>
Organization: Tektronix, Beaverton OR
Lines: 28

> 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

Message-ID: <403@snow.UUCP>
Date: Thu, 21-Feb-85 13:42:50 EST
Article-I.D.: snow.403
Posted: Thu Feb 21 13:42:50 1985
Date-Received: Wed, 27-Feb-85 04:01:37 EST
References: <414@bonnie.UUCP>
Organization: Computer Science Department, Warwick University, UK
Lines: 46

> 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.

Message-ID: <420@snow.UUCP>
Date: Wed, 27-Feb-85 19:34:43 EST
Article-I.D.: snow.420
Posted: Wed Feb 27 19:34:43 1985
Date-Received: Mon, 4-Mar-85 04:50:18 EST
References: <414@bonnie.UUCP> <136@tektools.UUCP>
Organization: Computer Science Department, Warwick University, UK
Lines: 34

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.

Message-ID: <5274@ucbvax.ARPA>
Date: Wed, 6-Mar-85 02:51:40 EST
Article-I.D.: ucbvax.5274
Posted: Wed Mar  6 02:51:40 1985
Date-Received: Thu, 7-Mar-85 04:05:53 EST
References: <414@bonnie.UUCP> <136@tektools.UUCP> <420@snow.UUCP>
Organization: University of California at Berkeley
Lines: 15

> 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