Apple-2-SW
/
beneath-apple-dos
mirror of https://github.com/iKarith/beneath-apple-dos.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Clean up appendix B

This commit is contained in:
T. Joseph Carter 2017-07-21 07:35:03 -07:00
parent e3289ad355
commit 01e4dd9f87
1 changed files with 111 additions and 248 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

359
appendixB.txt
View File

@ -1,262 +1,125 @@
.bp
.np
.ce
APPENDIX B - DISK PROTECTION SCHEMES
.sp1
# APPENDIX B - DISK PROTECTION SCHEMES
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.
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.
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.
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.
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.
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.
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 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).
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.
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.
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 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.
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.
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.
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