***************************************
* *
* 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)