.bp
.np
.ce
APPENDIX B - DISK PROTECTION SCHEMES
.sp1

As the quantity and quality
of Apple II software
has increased, so has the incidence
of illegal duplication of copyrighted
software.  To combat this, software
vendors have introduced methods for
protecting their software.
Since most protection
schemes involve a modified or custom
Disk Operating System, it seems
appropriate to discuss disk
protection in general.

Typically, a protection scheme's
purpose is to stop unauthorized
duplication of the contents of the
diskette, although it may also
include, or be limited to, preventing
the listing of the software (if it is
in BASIC).  This has been attempted
in a variety of ways, all of which
necessitate reading and writing
non-standard formats on the disk.  If
the reader is unclear about how a
normal diskette is formatted, he
should refer to Chapter 3 for more
information.

Early protection methods were
primitive in comparison to what is
being done now.  Just as the methods
of protection have improved, so have
the techniques people have used to
break them.  The cycle seems endless.
As new and more sophisticated schemes
are developed, they are soon broken,
prompting the software vendor to try
to create even more sophisticated
systems.

It seems reasonable at this time to
say that it is impossible to protect
a disk in such a way that it can't be
broken.  This is, in large part, due
to the fact that the diskette must be
"bootable"; i.e. that it must contain
at least one sector (Track 0, Sector
0) which can be read by the program
in the PROM
on the disk controller card.  This
means that it is possible to trace
the boot process by disassembling the
normal sector or sectors that must be
on the disk.  It turns out that it is
even possible to protect these
sectors.  Because of a lack of space
on the PROM (256 bytes), the software
doesn't fully check either the
Address Field or the Data Field.  But
potential protection schemes
which take advantage of this
are limited and must
involve only certain changes which
will be discussed below.

Most protected disks use a modified
version of Apple's DOS.  This is a
much easier task than writing one's
own Disk Operating System and will be
the primary area covered by this
discussion.

Although there are a vast array of
different protection schemes, they
all consist of having some portion of
the disk unreadable by a normal Disk
Operating System.  The two logical
areas to alter are the Address Field
and the Data Field.  Each include a
number of bytes which, if changed,
will cause a sector to be unreadable.
We will examine how that is done in
some detail.

The Address Field normally starts
with the bytes $D5/$AA/$96.  If any
one of these bytes were changed, DOS
would not be able to locate that
particular Address Field, causing an
error.  While all three bytes can and
have been changed by various schemes,
it is important to remember that they
must be chosen in such a way as to
guarantee their uniqueness.  Apple's
DOS does this by reserving the bytes
$D5 and $AA; i.e. these bytes are not
used in the storage of data.  The
sequence chosen by the would-be disk
protector can not occur anywhere else
on the track, other than in another
Address Field.  Next comes the
address information itself (volume,
track, sector, and checksum).  Some
common techniques include changing
the order of the information,
doubling the sector numbers, or
altering the checksum with some
constant.  Any of the above would
cause an I/O error in a normal DOS.
Finally, we have the two closing
bytes ($DE/$AA), which are similar to
the starting bytes, but with a
difference.  Their uniqueness is not
critical, since DOS will read
whatever two bytes follow the
information field, using them for
verification, but not to locate the
field itself.

The Data Field is quite similar to
the Address Field in that its three
parts correspond almost identically,
as far as protection schemes are
concerned.  The Data Field starts
with $D5/$AA/$AD, only the third byte
being different, and all that applies
to the Address Field applies here
also.  Switching the third bytes
between the two fields is an example
of a protective measure.  The data
portion consists of 342 bytes of
data, followed by a checksum byte.
Quite often the data is written so
that the checksum computation will be
non-zero, causing an error.  The
closing bytes are identical to those
of the Address Field ($DE/$AA).

As mentioned earlier, the PROM on the
disk controller skips certain parts
of both types of fields.  In
particular, neither trailing byte
($DE/$AA) is read or verified
nor is the checksum tested,
allowing these bytes to be modified
even in track 0 sector 0.
However, this protection is easily
defeated by making slight
modifications to DOS's RWTS
routines, rendering it
unreliable as a protective measure.

In the early days of disk protection,
a single alteration was all that was
needed to stop all but a few from
copying the disk.  Now, with more
educated users and powerful
utilities available, multiple schemes
are quite commonly used.  The first
means of protection was probably that
of hidden control characters imbedded
in a file name.  Now it is common to
find a disk using multiple
non-standard formats written even
.ul
between
tracks.

A state of the art protection scheme
consists of two elements.  First, the
data is stored on the diskette in
some non-standard way in order to
make copying very difficult.
Secondly, some portion of memory is
utilized that will be altered upon a
RESET.  (For example, the primary
text page or certain zero page
locations)  This is to prevent the
software from being removed from
memory intact.

Recently, several "nibble" or byte
copy programs have become available.
Unlike traditional copy programs
which require the data to be in a
predefined format, these utilities
make as few assumptions as possible
about the data structure.  Ever since
protected disks were first
introduced, it has been asked, "why
can't a track be read into memory and
then written back out to another
diskette in exactly the same way?".
The problem lies with the self-sync
or auto-sync bytes.  (For a full
discussion see Chapter 3)  These
bytes contain extra zero bits that
are lost when read into memory.  In
memory it is impossible to determine
the difference between a hexadecimal
$FF that was data and a hex $FF that
was a self-sync byte.  Two solutions
are currently being implemented in
nibble copy programs.  One is to
analyze the data on a track with the
hope that the sync gaps can be
located by deduction.  This has a
high probability of success if 13 or
16 sectors are present, even if they
have been modified, but may not be
effective in dealing with
non-standard sectoring where sectors
are larger than 256 bytes.  In short,
this method is effective but by no
means foolproof.  The second method
is simple but likewise has a
difficulty.  It simply writes every
hex $FF found on the track as if it
were a sync byte.  This, however,
will expand the physical space needed
to write the track back out, since
sync bytes require 25% more room.  If
enough hex $FF's occur in the data,
the track will overwrite itself.
This can happen in general if the
drive used to write the data is
significantly slower than normal.
Thus, we are back to having to
analyze the data and, in effect, make
some assumptions.  It appears that,
apart from using some
hardware device to help find the sync
bytes, a software program must make
some assumptions about how the data
is structured on the diskette.

The result of the
introduction of nibble copy programs
has been to "force the hand" of the
software vendors.  The initial
response was to develop new
protection schemes that defeated the
nibble copy programs.  More recent
protection schemes, however,
involve hardware
and timing dependencies which
require current
nibble copy programs to rely heavily
upon the user for direction.  If the
present trend continues, it is very
likely that protection schemes will
evolve to a point where automated
techniques cannot be used to defeat
them.
.br
.nx appendix c.1