Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!hplabs!otter.hpl.hp.com!hpopd!simonh
From: simonh@hpopd.pwd.hp.com (Simon Hunt)
Newsgroups: comp.sys.atari.8bit
Subject: Copy Protection Scheme
Message-ID: <40060005@hpopd.pwd.hp.com>
Date: 11 Apr 91 11:59:58 GMT
Organization: Hewlett-Packard CCG-PWD, UK.
Lines: 58

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

Using a monitor/disassembler program, which allows you to read/write selected
disk sectors to a specified buffer, I eventually disassembled enough code to
discover how the program loaded itself in. Apart from the usual "unformatted
sectors" method, the program used a really neat trick which goes something
like this:

       :
       :   (set colours & display list pointers etc.)
       :
       * Read Sector <N> into buffer        [$600-$67F]
       * Read the SAME Sector into buffer   [$680-$7FF]
       * For X = #$00 to #$7F do..
	  * EOR $600,X with $680,X and store in $2800,X
       :
       :   (more stuff)
       :
       * JSR $2800
       :

The point is, on a normal disk (ie. a "copy" of the original) the values
loaded into the destination buffer [$2800-$287F] all equal #$00, since

  <n> EOR <n> = #$00

so the JSR encounters the BRK instruction and stops. However, on closer
inspection of the original disk, I discovered that reading sector <N>
several times in a row produced one of TWO sets of data in the buffer.
When I EOR'd the two sets of data together and disassembled the result, 
there was the "missing" subroutine.

Does anyone know how the disk was manufactured such that reading the same
sector gave TWO different, but CONSISTANT, sets of data?

Observations:
  1. The two sets of data NEED to be consistant to produce the correct code
      when EOR'd together.
  2. It doesn't matter which order the data sets arrive in as EOR is 
      commutative.
  3. Reading the sector several times did not guarantee alternation of the
      two data sets.
  4. There wasn't any provision for checking that the second read of the 
      sector had produced the OTHER data set.

What puzzles me is 3. and 4.  Together they seem to imply that occasionally, 
two consecutive reads of the sector would produce the same result which when
EOR'd together would, of course, produce a zero filled buffer. This in
turn would halt the program with the JSR call. However, in the numerous
times I have loaded and played the game in the past, I have NEVER seen this
happen.. it's always loaded fine.

Any ideas?

Simon Hunt.