Apple-2-SW/beneath-apple-dos
1
0
Fork 0
mirror of https://github.com/iKarith/beneath-apple-dos.git synced 2024-06-07 09:29:34 +00:00
Code Issues Projects Releases Wiki Activity

Clean up appendix B

Browse Source
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 # APPENDIX B - DISK PROTECTION SCHEMES
.np
.ce
APPENDIX B - DISK PROTECTION SCHEMES
.sp1
As the quantity and quality As the quantity and quality of Apple II software has increased, so has the
of Apple II software incidence of illegal duplication of copyrighted software. To combat this,
has increased, so has the incidence software vendors have introduced methods for protecting their software. Since
of illegal duplication of copyrighted most protection schemes involve a modified or custom Disk Operating System, it
software. To combat this, software seems appropriate to discuss disk protection in general.
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 Typically, a protection scheme's purpose is to stop unauthorized duplication of
purpose is to stop unauthorized the contents of the diskette, although it may also include, or be limited to,
duplication of the contents of the preventing the listing of the software (if it is in BASIC). This has been
diskette, although it may also attempted in a variety of ways, all of which necessitate reading and writing
include, or be limited to, preventing non-standard formats on the disk. If the reader is unclear about how a normal
the listing of the software (if it is diskette is formatted, he should refer to Chapter 3 for more information.
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 Early protection methods were primitive in comparison to what is being done now.
primitive in comparison to what is Just as the methods of protection have improved, so have the techniques people
being done now. Just as the methods have used to break them. The cycle seems endless. As new and more
of protection have improved, so have sophisticated schemes are developed, they are soon broken, prompting the
the techniques people have used to software vendor to try to create even more sophisticated systems.
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 It seems reasonable at this time to say that it is impossible to protect a disk
say that it is impossible to protect in such a way that it can't be broken. This is, in large part, due to the fact
a disk in such a way that it can't be that the diskette must be "bootable"; i.e. that it must contain at least one
broken. This is, in large part, due sector (Track 0, Sector 0) which can be read by the program in the PROM on the
to the fact that the diskette must be disk controller card. This means that it is possible to trace the boot process
"bootable"; i.e. that it must contain by disassembling the normal sector or sectors that must be on the disk. It
at least one sector (Track 0, Sector turns out that it is even possible to protect these sectors. Because of a lack
0) which can be read by the program of space on the PROM (256 bytes), the software doesn't fully check either the
in the PROM Address Field or the Data Field. But potential protection schemes which take
on the disk controller card. This advantage of this are limited and must involve only certain changes which will
means that it is possible to trace be discussed below.
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 Most protected disks use a modified version of Apple's DOS. This is a much
version of Apple's DOS. This is a easier task than writing one's own Disk Operating System and will be the primary
much easier task than writing one's area covered by this discussion.
own Disk Operating System and will be
the primary area covered by this
discussion.
Although there are a vast array of Although there are a vast array of different protection schemes, they all
different protection schemes, they consist of having some portion of the disk unreadable by a normal Disk Operating
all consist of having some portion of System. The two logical areas to alter are the Address Field and the Data
the disk unreadable by a normal Disk Field. Each include a number of bytes which, if changed, will cause a sector to
Operating System. The two logical be unreadable. We will examine how that is done in some detail.
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 The Address Field normally starts with the bytes $D5/$AA/$96. If any one of
with the bytes $D5/$AA/$96. If any these bytes were changed, DOS would not be able to locate that particular
one of these bytes were changed, DOS Address Field, causing an error. While all three bytes can and have been
would not be able to locate that changed by various schemes, it is important to remember that they must be chosen
particular Address Field, causing an in such a way as to guarantee their uniqueness. Apple's DOS does this by
error. While all three bytes can and reserving the bytes $D5 and $AA; i.e. these bytes are not used in the storage of
have been changed by various schemes, data. The sequence chosen by the would-be disk protector can not occur anywhere
it is important to remember that they else on the track, other than in another Address Field. Next comes the address
must be chosen in such a way as to information itself (volume, track, sector, and checksum). Some common
guarantee their uniqueness. Apple's techniques include changing the order of the information, doubling the sector
DOS does this by reserving the bytes numbers, or altering the checksum with some constant. Any of the above would
$D5 and $AA; i.e. these bytes are not cause an I/O error in a normal DOS. Finally, we have the two closing bytes
used in the storage of data. The ($DE/$AA), which are similar to the starting bytes, but with a difference.
sequence chosen by the would-be disk Their uniqueness is not critical, since DOS will read whatever two bytes follow
protector can not occur anywhere else the information field, using them for verification, but not to locate the field
on the track, other than in another itself.
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 Data Field is quite similar to the Address Field in that its three parts
the Address Field in that its three correspond almost identically, as far as protection schemes are concerned. The
parts correspond almost identically, Data Field starts with $D5/$AA/$AD, only the third byte being different, and all
as far as protection schemes are that applies to the Address Field applies here also. Switching the third bytes
concerned. The Data Field starts between the two fields is an example of a protective measure. The data portion
with $D5/$AA/$AD, only the third byte consists of 342 bytes of data, followed by a checksum byte. Quite often the
being different, and all that applies data is written so that the checksum computation will be non-zero, causing an
to the Address Field applies here error. The closing bytes are identical to those of the Address Field ($DE/$AA).
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 As mentioned earlier, the PROM on the disk controller skips certain parts of
disk controller skips certain parts both types of fields. In particular, neither trailing byte ($DE/$AA) is read or
of both types of fields. In verified nor is the checksum tested, allowing these bytes to be modified even in
particular, neither trailing byte track 0 sector 0. However, this protection is easily defeated by making slight
($DE/$AA) is read or verified modifications to DOS's RWTS routines, rendering it unreliable as a protective
nor is the checksum tested, measure.
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, In the early days of disk protection, a single alteration was all that was
a single alteration was all that was needed to stop all but a few from copying the disk. Now, with more educated
needed to stop all but a few from users and powerful utilities available, multiple schemes are quite commonly
copying the disk. Now, with more used. The first means of protection was probably that of hidden control
educated users and powerful characters imbedded in a file name. Now it is common to find a disk using
utilities available, multiple schemes multiple non-standard formats written even between tracks.
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 A state of the art protection scheme consists of two elements. First, the data
consists of two elements. First, the is stored on the diskette in some non-standard way in order to make copying very
data is stored on the diskette in difficult. Secondly, some portion of memory is utilized that will be altered
some non-standard way in order to upon a RESET. (For example, the primary text page or certain zero page
make copying very difficult. locations) This is to prevent the software from being removed from memory
Secondly, some portion of memory is intact.
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 Recently, several "nibble" or byte copy programs have become available. Unlike
copy programs have become available. traditional copy programs which require the data to be in a predefined format,
Unlike traditional copy programs these utilities make as few assumptions as possible about the data structure.
which require the data to be in a Ever since protected disks were first introduced, it has been asked, "why can't
predefined format, these utilities a track be read into memory and then written back out to another diskette in
make as few assumptions as possible exactly the same way?". The problem lies with the self-sync or auto-sync bytes.
about the data structure. Ever since (For a full discussion see Chapter 3) These bytes contain extra zero bits that
protected disks were first are lost when read into memory. In memory it is impossible to determine the
introduced, it has been asked, "why difference between a hexadecimal $FF that was data and a hex $FF that was a
can't a track be read into memory and self-sync byte. Two solutions are currently being implemented in nibble copy
then written back out to another programs. One is to analyze the data on a track with the hope that the sync
diskette in exactly the same way?". gaps can be located by deduction. This has a high probability of success if 13
The problem lies with the self-sync or 16 sectors are present, even if they have been modified, but may not be
or auto-sync bytes. (For a full effective in dealing with non-standard sectoring where sectors are larger than
discussion see Chapter 3) These 256 bytes. In short, this method is effective but by no means foolproof. The
bytes contain extra zero bits that second method is simple but likewise has a difficulty. It simply writes every
are lost when read into memory. In hex $FF found on the track as if it were a sync byte. This, however, will
memory it is impossible to determine expand the physical space needed to write the track back out, since sync bytes
the difference between a hexadecimal require 25% more room. If enough hex $FF's occur in the data, the track will
$FF that was data and a hex $FF that overwrite itself. This can happen in general if the drive used to write the
was a self-sync byte. Two solutions data is significantly slower than normal. Thus, we are back to having to
are currently being implemented in analyze the data and, in effect, make some assumptions. It appears that, apart
nibble copy programs. One is to from using some hardware device to help find the sync bytes, a software program
analyze the data on a track with the must make some assumptions about how the data is structured on the diskette.
hope that the sync gaps can be
located by deduction. This has a The result of the introduction of nibble copy programs has been to "force the
high probability of success if 13 or hand" of the software vendors. The initial response was to develop new
16 sectors are present, even if they protection schemes that defeated the nibble copy programs. More recent
have been modified, but may not be protection schemes, however, involve hardware and timing dependencies which
effective in dealing with require current nibble copy programs to rely heavily upon the user for
non-standard sectoring where sectors direction. If the present trend continues, it is very likely that protection
are larger than 256 bytes. In short, schemes will evolve to a point where automated techniques cannot be used to
this method is effective but by no defeat them.
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 .nx appendix c.1