-------------Animal Kingdom------------
A 4am crack                  2014-07-22
---------------------------------------

"Animal Kingdom" is a 1985 educational
game distributed by Unicorn Software.

The original program comes on one
double-sided disk and uses both sides.
Booting side A looks and sounds like a
normal DOS 3.3 boot, complete with the
drive seeking to track 2, then 1, then
0, then swinging to the middle of the
disk to read the catalog track. It even
displays a BASIC prompt during boot, as
if it's loading a HELLO program. It
displays a graphical title screen, then
asks you to flip the disk to continue.

Booting side B directly just crashes,
so, uh, don't do that, I guess.

However, the disk is uncopyable by any
automated method. COPYA fails miserably
and immediately. EDD 4 bit copy gives
no read errors, but the copy it creates
only gets as far as loading DOS and
displaying the BASIC prompt before
filling the screen with garbage and
rebooting.

Turning to my trusty Copy ][+ sector
editor, I press "P" to get to the
Sector Editor Patcher, and select "DOS
3.3 PATCHED". This option ignores
checksum bytes and epilogue sequences
-- as long as the address and data
prologue are standard ("D5 AA 96" and
"D5 AA AD", respectively), this will
allow me to read each sector. And lo
and behold, it works! I can read the
data from every sector on every track.
Track $11 does appear to contain a disk
catalog, which strongly suggests this
program is file-based.

Based on my limited experience cracking
other disks, I would guess that this
disk has

- Standard prologue bytes before the
  address and data fields [otherwise
  Copy ][+ sector editor would give
  read errors, even with the "DOS 3.3
  PATCHED" option]

- Non-standard epilogue bytes after the
  address and data fields [otherwise
  COPYA would work]

- Some secondary protection [otherwise
  the bit copy created with EDD 4 would
  work]

Given the (relatively) weak structural
protection, I used to turn to the DOS
3.3 master disk, patch the RWTS to
ignore checksums and epilogue bytes
(changing $B942 from "SEC" to "CLC"),
and run COPYA. Then, one fine day, and
completely by accident, I came across
an original disk with a bad sector. I
suppose this shouldn't surprise me.
These floppies are decades old by now;
it's amazing any of them work at all.

The point is, I shouldn't be using
tools that ignore potentially serious
read errors. There are other tools,
like Super Demuffin, that can convert a
disk like this (with non-standard
epilogue bytes) into a standard format.
It requires figuring out what the
actual epilogue bytes are, but it has
the advantage of surfacing a read error
if the original disk actually has a
read error.

So... no more COPYA+B942:18 patch. From
now on, it's Super Demuffin or Advanced
Demuffin to convert disks to a standard
format. Just by looking at the first
few sectors, it appears that this disk
uses a DOS 3.3-derived RWTS, which
means that my AUTOTRACE program should
be able to extract the RWTS from the
original disk.

[S6,D1=original disk, side A]
[S5,D1=my work disk]

]PR#5
...
CAPTURING BOOT0
...reboots slot 6...
...reboots slot 5...
SAVING BOOT0

For those of you just tuning in, my
work disk uses a custom program that I
affectionately call "AUTOTRACE" to
automate the process of boot tracing as
far as possible. For some disks (like
this one, apparently), it just captures
track 0, sector 0 (saved in a file
called "BOOT0") and stops. For other
disks that load in the same way that an
unprotected DOS 3.3 disk loads, it
captures the next stage of the boot
process as well (in a file called
"BOOT1"). BOOT1 contains sectors 0-9 on
track 0, which are loaded into memory
at $B600..$BFFF. This generally
contains the RWTS routines which the
program uses to read the rest of the
disk.

If the RWTS is fairly normal as well
(and my AUTOTRACE program just spot-
checks a few memory locations to guess
at its "normalcy"), AUTOTRACE extracts
the RWTS routines (generally loaded
from track 0, sectors 2-9 into $B800..
$BFFF) and saves *that* into a third
file called "RWTS". There's a good
chance I'll be able to load that "RWTS"
file into a tool called Advanced
Demuffin (written in 1983 by The Stack)
to convert the disk into a standard
disk readable by unprotected DOS 3.3
disks or any other third-party tools.

If anything looks fishy or non-
standard, AUTOTRACE just stops, and I
have to check the files it saved so far
to determine why. In this case, it
stopped after capturing T00,S00. So I
need to look at that sector and figure
out why.

]CALL -151

*800<2800.28FFM

*801L
...

Everything here looks pretty normal
(i.e. just like an unprotected DOS 3.3
disk), until it goes to jump to the
boot1 code. Usually that happens with
an indirect JMP ($08FD), which, in a
normal boot0, will end up continuing
execution at $B700 which is stored in
track 0, sector 1. But in this case, I
see:

084A-   4C C0 08    JMP   $08C0

*8C0L

08C0-   8E E9 B7    STX   $B7E9
08C3-   6C FD 08    JMP   ($08FD)

OK, that's harmless (as far as copy
protection goes). This boot0 code is
close enough to normal that I should
be able to run my AUTOTRACE1 script
to patch the boot0 code and interrupt
the boot before it jumps to boot1.

*BRUN AUTOTRACE1
...reboots slot 6...
...reboots slot 5...
SAVING BOOT1
SAVING RWTS

Excellent! I have the RWTS and can load
it into Advanced Demuffin.

Advanced Demuffin will only load RWTS
files from a drive in slot 6, which is
annoying since mine is in slot 5. Note
to self: patch that someday. In the
meantime, I'm swapping floppy disks
like some kind of 20th century peasant.

[S6,D1=my work disk]

]PR#6
]BRUN ADVANCED DEMUFFIN 1.1

--> LOAD NEW RWTS MODULE
    At $B8, load "RWTS"
    from drive 1

[S6,D1=original disk, side A]
[S6,D2=blank disk]

--> FORMAT TARGET DISK

...grind grind grind...

--> CONVERT DISK

This disk is 16 sectors, and the
default options (copy the entire disk,
all tracks, all sectors) don't need to
be changed.

ADVANCED DEMUFFIN 1.1  - COPYRIGHT 1983
WRITTEN BY THE STACK -CORRUPT COMPUTING
=======PRESS ANY KEY TO CONTINUE=======
TRK:...................................
+.5:
    0123456789ABCDEF0123456789ABCDEF012
SC0:...................................
SC1:...................................
SC2:...................................
SC3:...................................
SC4:...................................
SC5:...................................
SC6:...................................
SC7:...................................
SC8:...................................
SC9:...................................
SCA:...................................
SCB:...................................
SCC:...................................
SCD:...................................
SCE:...................................
SCF:...................................
=======================================
16 SC $00,$00 TO $22,$0F BY $01 TO DRV2

The disk's own RWTS gave no read errors
on any track. This is the power and the
genius of Advanced Demuffin. Every disk
must be able to read itself. So, let it
read itself, then capture the data and
write it out in a standard format.

(I do the same with side B.)

There are two problems with this copy:

1. Depending on how the original disk
   was written, this copy may or may
   not be able to read itself. I may
   need to patch the disk's RWTS to
   deal with the fact that the disk is
   now in a standard format.

2. Even if it can read itself, it won't
   run. The copies I tried to make --
   even the bit copies -- just rebooted
   endlessly, which means there is some
   code being executed during boot to
   check if the disk is original.
   (Hint: it's not.)

Just by booting side A of my copy, I
can rule out problem #1. The disk seems
to read itself just fine. It makes it
exactly as far as my failed bit copy --
far enough to figure out that it's not
an original disk, fill the screen with
garbage, and reboot.

But wait...

[S6,D1=my work disk]
[S6,D2=non-working copy of side A]

]PR#6
...
]CATALOG,S6,D2

C1983 DSR^C#254
320 FREE

 A 002 JELLO
 B 065 AK
 B 005 B.LOOKUP TABLE
 B 003 A.DESCRIPT
 B 004 B.DESCRIPT
 B 002 C.DESCRIPT
 B 019 INTRO SCREEN.C
 B 005 A.A
 B 004 A.B
 B 005 A.C
 B 006 A.D
 B 005 A.E
 B 004 A.F
 B 009 A.BACK
 B 034 JUNKO
 B 004 FLIP.C

"JELLO"? Really?

]RUN JELLO

Yes, really! The game boots and runs,
even from drive 2.

At this point, I can probably recreate
a working copy by initializing another
blank disk with DOS 3.3 and copying
these files over with a file copier.
What about the nibble check? Don't
even care.

OK, OK, I care a little. Let's do a
little boot tracing, just for fun.(*)

(*)not guaranteed, actual fun may vary

[S6,D1=my work disk]

]PR#6
...
]BLOAD BOOT1,A$2600
]CALL -151

*FE89G FE93G     ; disconnect DOS

*B600<2600.2FFFM ; move RWTS into place

*B700L

B700-   20 00 BB    JSR   $BB00

I've learned from previous cracks (and
from actually reading "Beneath Apple
DOS" instead of, you know, just staring
at it on my bookshelf) that, in a
standard DOS-3.3-derived RWTS, the area
from $BB00 to $BC55 is overwritten
during every disk read. (It's used as
scratch space during denibblization,
which is totally a real word that I
just made up.)

So why is there executable code there?
Let's find out.

BB00-   A0 00       LDY   #$00
BB02-   B9 00 BB    LDA   $BB00,Y
BB05-   99 00 02    STA   $0200,Y
BB08-   88          DEY
BB09-   D0 F7       BNE   $2B02
BB0B-   60          RTS

Well that's definitely suspicious.
Relocating yourself into the input
buffer at $0200? Seriously, who does
that?

I'm guessing that the first instruction
after this is the entry point, so after
relocation, that would be $020C.

; this subroutine seeks to track $11
; and sets the reset vector to
; something unfriendly
020C-   20 CF 02    JSR   $02CF
020F-   A9 0A       LDA   #$0A
0211-   85 2A       STA   $2A

; initialize disk motor
; (highly suspicious)
0213-   AE E9 B7    LDX   $B7E9
0216-   BD 89 C0    LDA   $C089,X
0219-   BD 8E C0    LDA   $C08E,X

; set some counters
021C-   A9 C7       LDA   #$C7
021E-   85 48       STA   $48
0220-   A9 02       LDA   #$02
0222-   85 49       STA   $49
0224-   A9 80       LDA   #$80
0226-   85 29       STA   $29
0228-   C6 29       DEC   $29

; reboots (bad)
022A-   F0 67       BEQ   $0293

; position the drive head to where the
; nibble check needs it
022C-   20 44 B9    JSR   $B944
022F-   B0 62       BCS   $0293
0231-   A5 2D       LDA   $2D
0233-   C9 0D       CMP   #$0D
0235-   D0 F1       BNE   $0228
0237-   A0 00       LDY   #$00
0239-   BD 8C C0    LDA   $C08C,X
023C-   10 FB       BPL   $0239
023E-   88          DEY

; reboots (bad)
023F-   F0 52       BEQ   $0293

; Search for a specific sequence of
; nibbles in the "dead zone" between
; the address field and data field.
; This area is normally not important,
; so COPYA didn't copy it precisely
; because normal disks don't care.
; (Actually, it's even more evil than
; that, because the original disk is
; written with timing bits in specific
; non-standard places between the
; nibbles in the dead zone. This code
; not only requires the right nibbles
; in the right order, it reads them
; just slightly faster than normal. So
; the timing bits need to be in the
; right places too, or the disk will
; get out of sync and read the wrong
; nibble values. This will trip up even
; the best bit copiers. And you can
; forget about making a disk image for
; emulators -- those don't store timing
; bits at all.)
0241-   C9 D5       CMP   #$D5
0243-   D0 F4       BNE   $0239
0245-   A0 00       LDY   #$00
0247-   BD 8C C0    LDA   $C08C,X
024A-   10 FB       BPL   $0247
024C-   88          DEY

; reboots (bad)
024D-   F0 44       BEQ   $0293
024F-   C9 E7       CMP   #$E7
0251-   D0 F4       BNE   $0247
0253-   BD 8C C0    LDA   $C08C,X
0256-   10 FB       BPL   $0253
0258-   C9 E7       CMP   #$E7

; reboots (bad)
025A-   D0 37       BNE   $0293
025C-   BD 8C C0    LDA   $C08C,X
025F-   10 FB       BPL   $025C
0261-   C9 E7       CMP   #$E7

; reboots (bad)
0263-   D0 2E       BNE   $0293
0265-   BD 8D C0    LDA   $C08D,X
0268-   A0 10       LDY   #$10
026A-   24 06       BIT   $06
026C-   BD 8C C0    LDA   $C08C,X
026F-   10 FB       BPL   $026C
0271-   88          DEY

; reboots (bad)
0272-   F0 1F       BEQ   $0293
0274-   C9 EE       CMP   #$EE
0276-   D0 F4       BNE   $026C

; check for nibble sequence stored
; in reverse order at $2C7
0278-   A0 07       LDY   #$07
027A-   BD 8C C0    LDA   $C08C,X
027D-   10 FB       BPL   $027A
027F-   D1 48       CMP   ($48),Y
0281-   D0 10       BNE   $0293
0283-   88          DEY
0284-   10 F4       BPL   $027A

; if we made it this far, the nibble
; check passed
0286-   A9 80       LDA   #$80
0288-   8D 4E 9E    STA   $9E4E
028B-   A9 A1       LDA   #$A1
028D-   8D 4F 9E    STA   $9E4F
0290-   4C 4D 9E    JMP   $9E4D

That last section at $0286..$0290 is
interesting. After the nibble check
passes, it replaces two bytes at $9E4E
and $9E4F, then immediately jumps to
$9E4D. That implies that this nibble
check is called via an unconditional
jump, not a JSR. With my trusty Copy
][+ sector editor, I searched the disk
for "4C 0C 02" and found one reference
on track 00, sector 0B, byte $4D. I
wonder if I can just change those two
bytes to bypass the nibble check
altogether and turn this into a working
copy:

T00,S0B,$4E change "0C 02" to "80 A1"

Success! The game boots and runs with
no complaint. Flipping to side B and
continuing brings up the main menu, and
all options work. (Press the space bar
to switch between options. Arrow keys
do not work.) Anyway, there doesn't
appear to be any further protection.

Quod erat liberandum.

---------------------------------------
A 4am crack                      No. 94
------------------EOF------------------