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