🚀 go-pugleaf

In article <1992Aug9.164459.22118@news.columbia.edu>, lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
> I just finished using Teledisk in the attempt to copy the copy-protected
> disks.  The analysis section of Teledisk told me some interesting stuff:
> 
> Apparently the scheme is to put "funny business" in track 39 past all of the
> files.  The two descendents are indeed different from each other, and also
> from the original.  I still don't know why COPYIIPC can't just make a
> direct copy, but in any case I at least have a slight handle on what's being
> attempted:
> 
> The Broderbund disk apparently has sectors 1-9 everywhere but on track 39.
> On 39 you get something like most of 1-7 and then something like sector 222
> and 242.  On side 2 of track 39 you get 1-8 and then 45.  Additionally,
> 45 is a 256 byte sector, not 512.  Further, all of the "funny" sectors have
> a non-standard CRC in them so disk copiers will complain the data is
> corrupted.  Since Teledisk can't copy bad sectors, it creates "good" ones
> there and the copy-protection can't be thwarted.

I was once involved in an attempt to build an AT-compatible hard-disk 
controller that used an SMC 9224 for both the floppy and the hard disk, so
I've been bit by some interesting copy-protection schemes.

The one that killed my project (a 1:1-capable controller on a two-sided
PC board a couple of years before WD did it) involved storing a bad cylinder
number in the header of some small sectors. The sectors involved _claimed_
to be 256-byte sectors, but in fact did not have any data; an attempt to
read them would return a CRC error because it would get the headers of the
remaining sectors as data. There were a number of these bogus sectors on the
track, but I never figured out the algorithm they used to determine which
sector/cyl combinations to check on which track.

The software turned out to be really easy to unprotect, though. To make sure
that I understood what the software was doing, I wrote a TSR that intercepted
the floppy BIOS entry point and simply returned CRC error status for any
sector number greater than 9; worked fine! :-)

The reason it killed the project is that the 9224 has implied seek; when you
tell it to read a sector, it will find a header and examine the cylinder
number to see if it has to seek the drive. The bogus information in the
cylinder fields of the headers on that disk drove the thing nuts; it kept
banging the floppy head against the stops in a futile attempt to step from
track 255 to track 3 (or something like that).

Roger Ivie
ivie@cc.usu.edu