Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!samsung!interlan.InterLan.COM!interlan.interlan.com!dave From: dave@interlan.Interlan.COM (Dave Goldblatt) Newsgroups: comp.sys.atari.8bit Subject: Re: Copy protection (was Re: M.U.L.E. Sorrow!) Message-ID: Date: 25 Feb 91 15:22:32 GMT References: <1991Feb21.000558.15650@dhw68k.cts.com> <39563@cup.portal.com> <1991Feb25.022602.10895@uokmax.ecn.uoknor.edu> <1991Feb25.054200.4817@uokma Sender: news@interlan.Interlan.COM (No News is BAD News) Reply-To: dave@interlan.interlan.com Organization: Racal InterLan, Inc., Boxborough, MA (1-800-LAN-TALK) Lines: 96 In-Reply-To: norlin@uokmax.ecn.uoknor.edu's message of 25 Feb 91 05:42:00 GMT Nntp-Posting-Host: slam.interlan.com In article <1991Feb25.054200.4817@uokmax.ecn.uoknor.edu> norlin@uokmax.ecn.uoknor.edu (Norman Lin) writes: > Indeed so; I used to create bad sectors by using a simple USR call to the > resident disk handler to write a sector, and while it was writing the sector > I wedged a piece of folded paper in between the diskette jacket and the top > of the drive slot, so that the increased pressure on the diskette would bring > it almost to a stop. I'm sure it did wonders for my diskette, to mention > nothing of the disk drive motor... but it did create bad sectors by altering > the RPM in a very crude manner. What I am still not quite sure about is -- > why does altering the speed create bad sectors? That was the oldest (and just about the easiest) way to create a hard bad sector on the Atari. One of the oldest programs I saw to do it (I think it was for sale in ANALOG for $30) said to put a piece of masking tape on the disk, close the drive door with the tape hanging out, and when prompted, to pull on it (as it kept writing out that particular sector). High tech. The easiest (and safest) was to do it was to pop off the cover of the drive, find the speed adjustment screw, and to crank down the speed of the drive (to around 270RPM), write the sector, then bring the drive back up to speed. Essentially (if I can remember my 810 schematics and operation), what happens is this: During normal operation, the write head is only activated for a very precise amount of time -- just long enough to write a particular sector. If it is turned on for any greater length of time, it will continue writing on the next sector(s). The trick to writing a bad sector was that when you slowed down (or sped up) the speed of the drive, the write operation occurred outside the olerances on the disk (either the sector wasn't long enough, or too long). For the most part, Atari drives couldn't handle illegal sectors, which is why you'd hear the head banging around as to tried to read the sector again. > Very interesting... "plain ol' unreadable sectors" had occurred to me, as > they were the most obvious to detect, but short sectors and duplicate sector > headers... What would duplicate sector headers do? Short sectoring seems > quite ingenious too, though how could you tell how much "valid" data was > read? Let's say you're using SIO to read a disk sector into memory, and > only 100 bytes are "valid"; what would the rest of the target buffer in RAM > contain? Garbage? Unchanged? Zeroes? The original form of copy protection on the Atari was the standard hard-error bad sector. That was one MAJOR difference between the Atari and the Apple II. The Apple disk controller was in the machine itself, and subject to complete software control. The Atari controller, on the other hand, was inside the drive. Because of this, only specified operations could be performed on the Atari, and thus modified disk formats were very difficult. That is, until the advent of modified disk controllers, of which the Happy Drive was the first. Another one, called "The Chip" was a drop-in replacement for the Atari disk controller. The Happy drive was actually an additional logic board which provided even more capabilities than The Chip. It buffered reads by track, for example. Duplicate sectors were fairly neat. What happened was two identical sector numbers would be written onto the disk, but with different data within the sector.. When the program called for a disk read on that sector number, one of those sectors would be read in -- but which one depended on where the disk head was currently located! So the test was (a simplified example) to read in sector 7, then sector 8 (the duplicate sector), then sector 10, then sector 8. Then compare the two reads from sector "8". If it was the original disk, you'd see different data. Short sectors were fairly simple to check for as well. You'd initialize a 128-byte block of memory to a value (arbitrarily assume 0x55), then read in the known short sector. If all 128 bytes were altered, you'd know the short sector didn't exist. SIO would only copy the data it could read into RAM. If you just did a straight disk copy on a short-sectored disk, those sectors would (usually, depended on your copy program) read back zeros in the copy of the unused area on the original (i.e. if the sector on the original had only 50 bytes of data before the end-of-sector marker, and you make a sector-by-sector copy with SIO, the duplicate sector would have 128 bytes on it, and thus when that sector was read back in, the buffer you had allocated would change). > As you said, how this brings back memories. :-) I recall one time > disassembling the code to some game (forgot what it was) to see how the copy > protection worked. It was incredible how almost incomprehensible the code > was; 25 or so pages of self-modifying, self-decrypting, partially-resident- > and-partially-loaded-from-disk security checking. Pretty clever, these > copy-protectors... One of the more interesting programs I saw had a one-sector boot loader, which then loaded another loader sector by sector, XORing all of the data in each sector with an incrementing count and the sector number. Normally, just XORing the data with an incrementing count was standard, and this particular one was a tough one to figure out (it was self-modifying as well). But since every program HAD to have just one normal, executable sector (the boot sector), everything else could be derived. :-) -dg- -- "Hey, Copperfield! * Dave Goldblatt [dave@interlan.com] Suck on this!" * - Penn Jillette, of * (No longer working for, or Penn & Teller * representing Racal InterLan, Inc.)