***************************************
*                                     *
*    KRAKOWICZ'S KRACKING KORNER      *
*                                     *
*      THE BASICS OF KRACKING 4       *
*        "WHERE DO I BEGIN?"          *
*                                     *
***************************************

  Several previous episodes of this column have dealt with the
relatively simple techniques which can be used to save a single-load
file to disk as an unprotected binary program, and it is now time to
explore the larger area of multiple-program disks, programs with disk
access, and the approaches used to protect them from being copied. We
will begin with sizing up a disk protection scheme, deciding on a basic
approach, and beginning the unprotection process (the subject of
boot-tracing as another means to the same end will be described in a
future episode, since it is generally used with more sophisticated
protection schemes). The subject is truly mammoth, and will require
several episodes to complete. For now, settle back, open a cold beverage
of your choice, and let's begin a journey into the first level of disk
protection: the modified DOS (as we have often mentioned before, two
stalwart friends in this quest are "beneath Apple DOS" by Worth and
Lechner, and Randy Hyde's "DOSSOURCE". It is possible to krack disks
without them, but with about the same ease as performing an oral
appendectomy).

  Apple's DOS, combined with the division of hardware between the disk
controller card and the disk analog board, is a veritable playground for
those who produce disk protection. There are literally thousands of
different things which can be done to make copying a disk difficult,
challenging, and (maybe someday), impossible. In so doing, they provide
hours of very ingenious puzzles, boundless intellectual stimulation, and
not incidentally, the incentive to learn much more about programming,
the Apple, DOS, assembly language, and treachery than we would otherwise
have the desire to learn.

  By far the most common technique used to protect entire disks is to
make modifications to the operating system, and specifically to the
read/write track and sector (RWTS) routines which defeat ordinary copy
programs (COPYA and SUPER DISK COPY 3.X are examples, but we'll see
later how both of these can be used to our advantage). To find the most
efficient approach to defeating these protection techniques, we need
first to spend a fair amount of time describing DOS and RWTS from a
krackist's viewpoint.

  (On the fundamental principle that giving a man a fish allows him to
eat for a day while teaching him to fish allows him to eat for life, we
will not dwell on the subject of "copying" as such. Many of the
techniques described here are, however, very useful in deciding how to
go about copying a disk. Perhaps an aspiring author out there will build
from the introduction given here to pursue the subject in depth...?)
to spend a fair amount of time describing DOS and RWTS from a

  Before we can get to the core of the matter, we must understand much
more of the processing and encoding systems used by DOS to store
information on the disk. This is fairly heavy stuff, but your kracking
ability depends more than anything else on your knowledge of this
subject. Try your best to work through it now, and the rest of the
process will be much easier.

  We already know that each track consists of 16 sectors which each
represent one page (256 bytes) of data. A sector actually consists of
two separate parts, an address field, which tells DOS which sector it
is, and a data field, where the actual bytes are stored. To begin a trip
around the disk, let's look first at the byte sequence taken from a
normal, unmodified DOS disk at track0, sector 0 (as we mentioned
earlier, the terms 'byte' and 'nibble' are often used interchangeably to
refer to the data read off the disk. The use of 'nibble' is not really
accurate in reference to DOS 3.3, but persists for historical
reasons).


----FF FF FF FF D5 AA 96 FF FE AA AA AA AA FF FE DE AA EB FF FF FF FF
----
              / \      / \   / \   / \   / \   / \   /    \
________(1)__/   \_(2)/   (3)   (4)   (5)   (6)   (7)     
\_____(8)______


  The first few ff's (1) are known as gapbytes, but they're correctly
termed syncbytes, and we'll treat them as simple separators for now.
Next are the three most important bytes on the disk, D5 AA 96 (2). This
sequence may not occur anywhere else on the disk except the address
field, and serves as a unique identification marker. These bytes are
known by all sorts of colloquialisms, including "address marker",
"header bytes", "leader bytes", "prolog", and others. They will always,
repeat always, occur on at least sector 0 of track 0 of every Apple disk
which loads under DOS 3.3 (the first law demands it).

  The next four sequences encode the volume number (3), track number
(4), sector number (5), and checksum (6). Each number is a single byte,
written in an old-style encoding scheme called 4+4 nibblizing. This is a
format for storing data on the disk in which the even bits of a byte are
stored in one 8-bit sequence (representing one-half of the original byte
or one nibble), and the odd bits are stored in the second "byte" (the
requirement for this sort of "byte-splitting" or nibblizing was
established largely by the limitations imposed by disk drive hardware.
You can find much more information in B.A.D., pp. 3-12 to 3-21, but an
oversimplification is that, in the old days, at least every other bit
read from the disk had to be a logical "one", or the circuitry that read
the disk "forgot" where is was and what it was doing). If you are
interested in more detail on the mechanics of the 4+4 scheme, refer to
the very first kracking korner file on Cyclod and the file on Way Out.
The table below lists the values of nibbles of interest to us in this
format:

FIRST  SECOND BYTE   FIRST  SECOND BYTE
NIBBLE NIBBLE VALUE  NIBBLE NIBBLE VAL.
------ ------ -----  ------ ------ ----
 AA      AA     0     AA      BA    10
 AA      AB     1     AA      BB    11
 AB      AA     2     AB      BA    12
 AB      AB     3     AB      BB    13
 AA      AE     4     AA      BE    14
 AA      AF     5     AA      BF    15
 AB      AE     6     AB      BE    16
 AB      AF     7     AB      BF    17
 AE      AA     8     AE      BA    18
 AE      AB     9     AE      BB    19
 AF      AA     A     AF      BA    1A
 AF      AB     B     AF      BB    1B
 AE      AE     C     AE      BE    1C
 AE      AF     D     AE      BF    1D
 AF      AE     E     AF      BE    1E
 AF      AF     F     AF      BF    1F

                      BA      AA    20
                      BA      AB    21
                      BB      AA    22

                      FF      FE    FE
                              (VOL#254)

  We can now decode the four groups of bytes as: vol# 254 (3), track# 0
(4), sector# 0 (5), and checksum $FE (6). The first three are
self-explanatory, and the last is used to detect any errors which may
creep in after many hours of disk use. Following these is a sequence of
bytes (7) used to mark the end of the address field. A total of three
bytes (DE AA EB) are written to the disk, but only the first two are
checked when the field is read. This pair of bytes is known variously as
"closing bytes", "trailers", or the "epilog". Finally, there is another
series of gapbytes (8) which separates the address field from the
following data field.

  The data field has a similar structure:

----FF FF FF D5 AA AD ----342 BYTES OF DATA----(CKSUM) DE AA EB FF FF
FF----
           / \      / \                   /    \     / \   /       \
______(1)_/   \_(2)/   \_____(3)_________/      \(4)/   (5)        
\__(6)__


where the gapbytes (1) are same group that ended the address field. The
data marker bytes (2) are also called by all the names mentioned for the
address marker, and are interpreted by DOS as "here comes the data..."
the big stretch of 342 bytes (3) is a very complex way of storing 256
bytes on a disk, following some compromises made with the original laws
of disk recording. Without going into exactly why, each "byte" can
represent only 6 bits of an original byte, which means that each byte
has two bits left over. Packing these together at 6 bits each requires
another 256/3 or 86 diskbytes, for a total of 256+86=342 "bytes", which
no longer represent a nibble or half a byte, but 3/4 of a byte (make up
your own name for it, there's no real agreement what it should be
called).

  Following the data is a single checksum byte (4), which will give zero
when exclusive-ored with all the other bytes from the data, and then the
same active closing bytes that were used in the address field (5).
Finally, more gapbytes (6) pad the space between this data field and the
address field which comes next.

  This sequence is repeated 15 more times to make a complete track, and
there is usually a large "gap" of up to 128 FF's separating the last and
the first sectors on the track. One final item of interest is that the
sectors do not normally follow each other in numerical sequence of
0,1,2...etc. The actual sequence (called "skewing" or interleaving) is
chosen for speed of reading and writing, and can vary on some DOS's
which are otherwise strictly identical in format to DOS 3.3.

  This would be a good point, if you're not already very comfortable
with the sequences described above, to get out a utility which will
perform a "nibble read" of a disk track (inspector, nibbles away,
locksmith, etc.), and read in a standard DOS track. Scan through the
bytes until you come to the magical D5 AA 96 sequence, then compare all
the bytes which follow it to the description given above. Try a few
tracks and decode the start of several sectors until you become familiar
with the appearance of them. You'll save yourself a lot of time and
effort by becoming familiar with the appearance of normal DOS sectors
and tracks.

  Knowing that all these things are required to make a disk compatible
with DOS 3.3 (and make it copy with COPYA), you can easily see how to
make a protected or modified DOS: simply change almost any one of the
important bytes in either or both fields, and make the appropriate
changes to the read and write routines in DOS. In order to appreciate
what this means, let's spend a minute or two on the structure of DOS.
and decode the start of several sectors until you become familiar

  Just as was gaul, DOS is divided into three main parts. The first one,
called the command interpreter, has been described in considerable
detail by Bert Kersey in the now-classic "DOS BOSS" program and the
short series he authored for Softalk Magazine. While DOS command changes
may figure in a number of protection schemes, they are usually not the
primary system, and will be described with a few examples where
appropriate. The second third, known as the "file manager", is not
commonly altered as a protection scheme. Cogent descriptions of this
part of DOS are rare, but some hints about its function, liberally
paraphrased and rewritten from B.A.D. Were given in the "Type Attack"
file.

  The crux of most DOS alteration schemes is the last third of DOS, the
RWTS routines. These exist in everyone's 48K Apple between $B700 and
$BFFF, and are the only subroutines which read from or write to the disk
under anything resembling a normal DOS. After a command (keyboard or
program) has been processed by the command interpreter, and the right
part of the right file has been selected by the file manager, the RWTS
routines are called on to do the crucial job of exchanging information
between the Apple's memory and the diskette.

  Space prevents us from listing all the routines, but those of
particular interest are:


 ADDRESS  NAME          FUNCTION
 -------  ----    ---------------------
B700-B749  --     DO 2ND STAGE BOOT LOAD, RUN HELLO PROG.

B793-B7B4 RWPAGES READ OR WRITE A GROUP OF PAGES

B7B5-B7C1 CALLRWTS DISABLE INTERRUPT AND CALL RWTS

B7E8-B7F8 IOBLOCK RWTS PARMLIST-SEE B.A.D.

B800-B829 PRENIB  CONVERT BYTES TO NIBBLES FOR WRITING

B82A-B8C1 WRITE   WRITE SECTOR TO DISK

B8C2-B8DB POSTNIB CONVERT NIBBLES TO BYTES AFTER READING

B8DC-B943 READ    READ SECTOR FROM DISK

B944-B99F RDADR   READ AN ADDRESS FIELD

B9A0-BA28 SEEKABS POSITION READ HEAD TO THE DESIRED TRACK

BA29-BA68 NIBL    WRITE TRANSLATE TABLE

BA69-BA95 (EMPTY) =>WATCH THIS SPACE<=

BA96-BAFF  --     READ TRANSLATE TABLE

BB00-BBFF NBUF1   BUFFER (PRIM) USED TO STASH THE NIBBLES

BC00-BC55 NBUF2   SEC. BUFFER FOR NIBLS

BC56-BCC3 WRADR   WRITE ADDRESS FIELD (ONLY DURING INIT)

BCDF-BCFF (EMPTY) =>BE SUSPICIOUS<=

BD00-BDEC RWTS    MAIN READ/WRITE ORGN

BDED-BE03 RDRIGHT GOOD READ, CK TRACK #

BE10-BE25 RTTRK   RIGHT TRK, CK VOL#

BE26-BE45 CRCTVOL RIGHT VOL#, CK SECT#

BEAF-BFB7 DSKFORM INITIALIZE DISK

BFD8-BFC7 SECMAP  SECTOR INTERLEAVE MAP

BFC8-BFFF PATCHES CORRECTIONS FOR SMALL DOS BUGS =>BEWARE<=

=======================================

  As before, you are strongly urged to get as familiar as you can with
these routines, using DOSSOURCE and B.A.D. As your primary references.

  Returning to the subject of detecting and circumventing modified
DOS's, you have a choice. You can either look for changes by inspecting
a track, or you can search through the above RWTS routines for something
that isn't normal. Neither approach will work 100% of the time, so it's
best to become proficient at both. The table below lists most of the
crucial locations in RWTS that are commonly changed for the purpose of
protection.

        NORMAL
ADDRESS VALUE    USE
------- ------ ------------------------
 B853     D5   DATA ADDR MARKER 1-WRITE
 B858     AA   DATA ADDR MARKER 2-WRITE
 B85D     AD   DATA ADDR MARKER 3-WRITE

 B89E     DE   EPILOG BYTE 1
 B8A3     AA   EPILOG BYTE 2
 B8A8     EB   EPILOG BYTE 3-NOT READ
 B8AC     FF   EPILOG BYTE 4-NOT READ

 B8E7     D5   DATA ADDR MARKER 1-READ
 B8F1     AA     "   "     "    2   "
 B8FC     AD     "   "     "    3   "

B92A-C D9 00 BA LOCATION FOR CHECKSUM COMPARE

 B935     DE   EPILOG BYTE 1-READ
 B93F     AA   EPILOG BYTE 2-READ

 B942     38   SET CARRY FOR I/O ERROR

 B955     D5   ADDR DATA MARKER 1-READ
 B95F     AA     "    "     "   2  "
 B96A     96     "    "     "   3  "

 B991     DE   ADDR EPILOG BYTE 1
 B99B     AA   ADDR EPILOG BYTE 2

BA29-68   *    WRITE TRANSLATE TABLE

BA96-FF   *    READ TRANSLATE TABLE

 BC5F     FF   SYNC BYTE VALUE

 BC7A     D5   ADDR MARKER WRITE-1
 BC7F     AA   ADDR MARKER WRITE-2
 BC84     96   ADDR MARKER WRITE-3

 BCAE     DE   ADDR EPILOG BYTE 1-WRITE
 BCB3     AA     "     "     "  2   "
 BCB8     EB     "     "     "  3   "

BFB8-C7   *    SECTOR INTERLEAVING TABLE

 * see DOSSOURCE listing for correct contents.

  Any of the locations above can be modified, either permanently (which
means that you can probably find the changes in the DOS image on tracks
0-2), or temporarily. The temporary DOS changes are much tougher to find
than the permanent ones, since the changes may be erased after they have
been used. A good example of this was 'Mask of the Sun' and 'The
Serpent's Star', where the main disk is protected (among other
techniques) by using FF's for all the epilog bytes, but the save game is
written out and read in using the normal DE AA's. A pair of subroutines
was called to swap the bytes in and out as required. Much more devious
was the protection scheme used by TSR on 'Computer Dungeon' and 'Theseus
and the Minotaur', where epilog bytes were computed according to which
track was being read.

  There are many other examples of DOS modifications used to keep us at
bay, including some secondary protection techniques, but we'll look at
those after we describe the basic approaches to unprotecting these disks
in part 5 of the basics of kracking. In the meantime, study the format,
become familiar with the standard tricks, and remember:


"The night shall be filled with music,

     and cares that infest the day,

 shall fold their tents like the arabs,

     and as silently, steal away."


            -Henry Wadsworth Longfellow

This file was brought to you by Christer Ericson. (christer@cs.umu.se)