¢<=<=<=<=<=<=<=<=<=<=<=<=<=<=<=<=<=¢¢This article deals with various disk¢protection techniques. Note: this is¢not a beginners article. Taken from¢the Unix newsnet. Transferred by Mike¢Blenkiron. Tidied by Dean Garraghty¢(ENGLAND??),(in the early hours of the¢morning!)¢-----------------------------------¢¢simonh@hpopd.pwd.hp.com (Simon Hunt)¢writes:¢>"Over the last few evenings, I have¢been trying to discover how the copy¢>protection works on one of the¢disk-based games I have. The game¢loads itself¢>in several stages, to display a title¢screen whilst the rest of the program¢>loads..."¢>¢>HE CONTINUES:¢>"Does anyone know how the disk was¢manufactured such that reading the¢same¢>sector gave TWO different, but¢CONSISTANT, sets of data?¢>¢>Any ideas?"¢¢¢The various protection schemes used on¢the disk based Atari 800 series¢computers are fascinating, and some¢are very clever. Quite a number of¢them used custom disk formats, which¢an unmodifed 810/1050 would be unable¢to produce. The custom disk format¢allowed: bad sectors; sectors with CRC¢errors; unformatted tracks; tracks¢with extra sectors; sectors too long;¢sectors too short; and tracks with¢duplicate sectors (amongst other¢techniques).¢¢Gosh I am remembering more and more of¢these techniques all the time. Some¢custom formats had 20+ sectors per¢track.¢¢This is actually not too difficult, so¢long as you have low level access to¢the floppy disk controller IC,¢something which was impossible with¢the "intellegent" Atari drives. You¢can in effect program the floppy disk¢controller (FDC) to put any data¢format on any track that you wish,¢with the right computer system.¢¢Now each sector on a particular track¢is preceded by a short header, which¢contains (if my memory is correct),¢the track number, and sector number,¢plus a couple of other things (?) and¢a CRC. The floppy disk controller may¢be able to check the track number¢against the track which it believes it¢is on (a flag will be set in the¢status register if this is not the¢case). If a certain sector number has¢been requested, then as soon as this¢sector number is seen in the sector¢header, the FDC will start to read the¢data portion. Now it is not too¢difficult to lay down a track in which¢*all* sectors are numbered 1 (for¢example) and each have different data.¢In this case the data read will be in¢effect random, and depends on the¢rotational position of the disk when¢the read request was issued. The FDC¢will read the first sector with a¢matching header.¢¢On your disk, I suspect that there are¢two sectors with the same sector¢number, and the rest may well be¢normal. They will probably be arranged¢to be directly opposite each other on¢the disk (180 degrees apart). Now the¢trick is all to do with timing. Send a¢read command to the 810/1050. One of¢the 2 sectors will be read, which one¢is random. With either no delay, or a¢*calculated* delay do another read.¢The disk will have rotated by some¢part of a revolution past the 1st¢duplicate sector, so that the next¢read will catch the 2nd duplicate. The¢trick to recreate this yourself is too¢code up two reads in assembler back to¢back, and check the result. Run the¢assembly code using your debugger,¢rather than using the debugger to read¢the sector twice. In the assembly¢code, there is a fixed delay between¢both reads. If you are using a¢debugger, there is a random delay¢between subsequent reads, hence the¢sector read is random.¢¢This is very clever. Using the XOR¢means that it doesn't matter which of¢the two sectors gets read first. If¢you copy the disk using a straight¢forward sector copier when it come to¢the track in question, you will read¢one of the two duplicate sectors, and¢it will be written onto the single¢sector on the destination disk. As you¢say this new disk will read the same¢twice, and the program would crash¢when executing the unmangled code.¢Some years ago when I has an 8 bit¢Atari, I bought a booklet which¢described these techniques, from an¢advertiser in Antic (or Analog), and¢it came with a specially formatted¢disk to play with, using some of their¢supplied programs (this sounds like¢Atari Protection techniques, available¢from Gralin International, Ed.). It¢really is a very interesting subject!¢¢A UK software house (Red Rat¢Software), used an interesting¢technique. They burnt a hole in the¢disk using a laser (apparently). The¢sector never read the same twice. A¢copy would always read the same twice.¢A friend of mine (who had bought an¢original incidently), experimented¢with adding a hole using a pin. I am¢not sure of its success.¢¢The well known "Happy Mod" allowed the¢Atari computer, low level access to¢the FDC, and so could read, analyse¢then format these custom formats. I¢first saw a similar mod called "the¢chip" for an 810. Using the supplied¢software, it was fascinating to see¢the 810 analyse the disk format and¢display it on the screen. Duplicate¢sectors were very easy to spot.¢I believe that one of the commands the¢810 supported was to return the status¢from the FDC after a read or write.¢The value passed back came in part¢(or all?) from the FDC (an 1771 chip)¢status register. The register knew¢about CRC errors, data overflow, etc ,¢which is why some of the techniques¢mentioned above were popular, as the¢810 could detect these specially¢created disk faults. A disk¢formatted/copied on the 810 would be¢fault free. When the 1050 drive first¢came out, a number of software titles¢wouldn't load, as the software¢believed itself to be copied, although¢they were originals. This was because¢the 1050 used a different and newer¢FDC (a Western Digital 2797 or¢similar), one which could support¢double density. The 1050 status¢command returned similar information¢to the 810 including a copy of the FDC¢status register. As the status¢registers of the 1771 and 2797 are¢different with different meanings to¢each bit, of course software which¢relied on the 1771 status register¢bits been set according to these disk¢faults, got confused, as the new FDC¢returned slightly different status¢results.¢¢On a different note, Atari used both¢the 2797 and 2793(?) FDC's which are¢virtually identical in the 1050. I¢bought a very early Happy mod (from¢B&C Computervisions? in Santa Clara),¢which didn't work in my 1050 drive,¢which I had brough over from the UK.¢This was due to the switch in FDC¢(97->93 or vica versa) used by Atari¢in the 1050. The original Happy ROM¢code, which replaced the Atari 1050¢ROM, was written with a particular FDC¢in mind. I discovered this by¢disassembling the Happy ROM code. It¢was quite a lot of hassle to get them¢to fix it.¢¢Ah, those were the days.....¢¢Article by: Gary Morton. (REPRINTED¢WITH THANKS!!)¢¢ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=¢
