This is an article taken from the Unix newsnet system. It is a general article about copy protection. It was transferred by Mike Blenkiron, and tidied up by Dean Garraghty. Note: if you try some of the methods discussed in this article, and kill your hardware, then don't moan at me!¢---------------------------------¢¢¢(Dave Goldblatt) writes:¢¢>You are correct in stating that the fast sectoring could only be produced on¢>specialized hardware, but the flaw is in the timing on the disk read. You¢>couldn't count on any degree of accuracy, because of the possiblity of a¢>missed sector, or just that the drive speed was out of range. You could, of¢>course, create bad sectors on a standard 810 by writing to a sector with the¢>RPMs altered to be out of the allowable tolerance (< or > 20RPM, I think).¢¢¢ 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?¢¢¢>The most common [means of copy protection]¢>(and difficult to reproduce on a normal drive) were modified low-level disk¢>formats -- duplicate sector headers, short sectors (VERY common; you'd check¢>to see how much valid data was read in; if 128 bytes, blam!), and just plain¢>ol' unreadable sectors.¢¢¢ 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?¢¢ 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...¢¢>--¢ Dave Goldblatt¢
