----------------Sneakers---------------
A 4am crack                  2014-02-27
---------------------------------------

Booting from the original disk displays
an animated alien while loading, which
is the cutest damn thing I have ever
seen. It's likely that you've never
seen it, since every cracked version of
Sneakers in the 1980s was a file-based
crack that eliminated the boot sequence
altogether. From the first moment I saw
it, I knew that the goal of this crack
would be to preserve or recreate the
original boot animation as closely as
possible.

Boot tracing is a lot easier when you
have two disk controller cards, or
something like the CFFA 3000 card that
lets you set up virtual floppy
drives. That way, I can keep a "work
disk" in slot 5 and the original
Sneakers disk in slot 6, and boot each
as needed without swapping
floppies. (Seriously, it's the 21st
century. It's fun to have a hobby, but
I draw the line at swapping floppies.)

For the work disk, I used to use a
blank ProntoDOS disk with the
large-files patch (POKE 43364,255), but
I've since discovered the wonderful
DiversiDOS with the 64K DOS patch. It
has the large-files patch built in, and
it loads DOS into the language card on
boot so you can load data far above the
normal $9600 limit. And it has so many
other useful features and shortcuts:
"C" to display a disk catalog, BSAVE
that remembers the address and length
from the last BLOAD, and a TLIST
command for viewing text files.

OK, so let's get started.

]PR#5 (boots my work disk)
*8600<C600.C6FFM
*86F8:AD E8 C0 4C 59 FF
*BSAVE TRACE0,A$8600,L$100
*8600G (loads Sneakers T0S0 and halts)
*2000<0800.08FFM
]PR#5 (boots my work disk again)
]BSAVE SNEAKERS T0S0,A$2000,L$100

So what do we have? Lots of interesting
stuff, none of it the slightest bit
standard.

$0801..$080C: display hi-res page 1
(uninitialized)

$080D..$0851: load RWTS into
$0400..$07FF using a non-standard
prologue and a 4-4 nibble encoding
scheme

$0852..$0866: zero out all of main
memory from $0900 to $BFFF

$0867..$0870: a loop that uses
progressive EORs to calculate a
checksum of the T0S0 code
($0800..$08FF), then transfers the
checksum value to the stack

0867-   8A          TXA
0868-   E8          INX
0869-   F0 06       BEQ   $0871
086B-   5D 00 08    EOR   $0800,X
086E-   4C 68 08    JMP   $0868
0871-   AA          TAX
0872-   9A          TXS

$0873..$087A: another loop that uses
progressive EORs to calculate a
checksum of zero page ($00..$FF). The
checksum value is held in the
A-register, but to what end? The result
is unpredictable because most of zero
page is never initialized. Weird.

0873-   A2 00       LDX   #$00
0875-   8A          TXA
0876-   55 00       EOR   $00,X
0878-   E8          INX
0879-   D0 FB       BNE   $0876

$087B..$087F: restore the X-register to
slot number x 16, then jump to the next
phase of the boot at $0400.

As we'll see later, I need that first
checksum value that was transferred to
the stack at $0871; I can't fake it or
skip over it. But I can't modify T0S0
on disk, because the checksum value
depends on all the bytes in that
sector. However, I can create a boot
tracer that captures the checksum
without modifying the boot sector on
disk *or* in memory.

1. Load T0S0
2. Copy $0800..$08FF to $0900..$09FF
3. Neutralize the loop at $0952 that
   zeroes out of all main memory
4. Fix any absolute JMP addresses from
   $08XX to $09XX (there's just one, at
   $096E)
5. Modify the final JMP at $097D to
   call back to my own routine so I can
   transfer the checksum value back
   from the stack, store it somewhere,
   and exit to the monitor
6. JMP to $0901 (not $0801)

The first checksum value is $20.

Now I need to let the boot progress a
little further so that T0S0 actually
loads the RWTS, but interrupt the boot
before it jumps to the RWTS. This is
TRACE1 on my work disk.

; neutralize memory zapping loop
86F8-   A9 01       LDA   #$01
86FA-   8D 5C 08    STA   $085C
; jump to my callback instead of $0400
86FD-   A9 0A       LDA   #$0A
86FF-   8D 7E 08    STA   $087E
8702-   A9 87       LDA   #$87
8704-   8D 7F 08    STA   $087F
; let Sneakers boot
8707-   4C 01 08    JMP   $0801
; callback: save RWTS in safe location
870A-   A2 04       LDX   #$04
870C-   A0 00       LDY   #$00
870E-   B9 00 04    LDA   $0400,Y
8711-   99 00 20    STA   $2000,Y
8714-   C8          INY
8715-   D0 F7       BNE   $870E
8717-   EE 10 87    INC   $8710
871A-   EE 13 87    INC   $8713
871D-   CA          DEX
871E-   D0 EE       BNE   $870E
; turn off disk motor and exit
8720-   AD E8 C0    LDA   $C0E8
8723-   4C 59 FF    JMP   $FF59

This allows me to soft-reboot to my
work disk and save the RWTS, which is
now duplicated at $2000..$23FF.

Now let's examine the next phase of the
boot, starting at $0400.

$0400..$040D: a third loop using
progressive EORs to calculate a
checksum of zero page ($00..$FF),
starting with the ending value (in the
A-register) of the second checksum
loop.

0400-   A0 00       LDY   #$00
0402-   59 00 00    EOR   $0000,Y
0405-   C8          INY
0406-   D0 FA       BNE   $0402
0408-   A8          TAY
0409-   F0 03       BEQ   $040E
040B-   4C A2 05    JMP   $05A2

Oh, I see. This determines whether the
zero page has been modified between the
end of T0S0 and the beginning of this
phase. It appears I can just skip over
this check without any ill effects.

$05A2 is The Badlands. You never want
to end up in The Badlands. Every
copy-protection scheme has a routine
where the developers have determined
that Something Is Amiss and therefore
Bad Things Must Happen. This routine
generally displays a cryptic error
message, wipes all of main memory, and
reboots. Sneakers plays a cute sound
first. Apparently, even in The
Badlands, cuteness is paramount.

On the bright side, once I find the
entry point to The Badlands, searching
for other references to that address
may uncover further copy protections
down the road.

$040E..$0451: various unfriendly
initialization routines. Sets the reset
vector at $03F2 to point to a routine
that wipes all of main memory and
reboots. Then wipes out the auxiliary
memory in the language card to
neutralize any memory-resident boot
tracers. Then sets the low level reset
vector at $FFFC. Then, just for good
measure, sets the input and output
vectors at $36 and $38.

$0452..$0471: a fourth(!) loop using
progressive EORs to calculate a
checksum of the entire RWTS
($0400..$07FF), starting with the
ending value of the first checksum loop
which has now made its way into zero
page $0B.

Having saved the RWTS to my work disk,
I'll BLOAD it at both $2000 and $2400,
then make the following changes to
manually calculate the RWTS checksum:

*2451:A2 20 A9 00
*2472:60
*400<2000.23FFM N 2451G

The checksum (stored in zero page $0B)
is $16.

$0472..$048E: loads the game from disk,
then jumps to $0500 for some final
nibble craziness. If I interrupt the
boot, manually set zero page $0B to
$16, patch the jump at $047E to exit to
the monitor instead of jumping to
$0500, and skip over all the unfriendly
initialization, I can let Sneakers load
itself in $0800..$97FF and save it to
my work disk.

Here's the boot tracer code (TRACE4 on
my work disk):

[$8600..$86F7 copied from $C600..$C6F7]
86F8-   A2 00       LDX   #$00
86FA-   BD 00 08    LDA   $0800,X
86FD-   9D 00 09    STA   $0900,X
8700-   E8          INX
8701-   D0 F7       BNE   $86FA
; don't wipe main memory
8703-   A9 EA       LDA   #$EA
8705-   8D 5D 09    STA   $095D
8708-   8D 5E 09    STA   $095E
870B-   A9 09       LDA   #$09
870D-   8D 70 09    STA   $0970
; jump back here to set up next phase
8710-   A9 1D       LDA   #$1D
8712-   8D 7E 09    STA   $097E
8715-   A9 87       LDA   #$87
8717-   8D 7F 09    STA   $097F
871A-   4C 01 09    JMP   $0901
; manually set initial checksum
871D-   A9 A9       LDA   #$A9
871F-   8D 6E 04    STA   $046E
8722-   A9 16       LDA   #$16
8724-   8D 6F 04    STA   $046F
; exit to monitor instead of JMP $0500
8727-   A9 59       LDA   #$59
8729-   8D 7F 04    STA   $047F
872C-   A9 FF       LDA   #$FF
872E-   8D 80 04    STA   $0480
; load the game
8731-   4C 52 04    JMP   $0452

The final boot phase is at $0500, and
it's a doozy. I can't just skip it;
it's reading real code and data into
low memory that the game actually uses
later.

$0500..$0534 looks for a non-standard
prologue (D5 AA B5), reads a page of
data (using a 4-4 nibble encoding
scheme), EORs it with the magical
checksum value in zero page $0B, and
stores it in $0200..$02FF.

$0535..$055F reads some amount of data
(not sure how much, but it's
zero-terminated), EORs it with the
magical checksum value at zero page
$0B, and stores it in zero page.

$0560..$0588 reads two bytes from the
disk, EORs it with -- you guessed it--
the magical checksum value at zero page
$0B, and pushes it to the stack. Then
turns off the disk motor. Whew, we're
finally done reading stuff from disk.

$0589..$05A0 loops through every single
byte that was just read from disk
($0800..$97FF) with a progressive
EOR. If the final checksum is
unexpected (if even a single byte of
the game has been modified), it veers
off into The Badlands at $05A2.

And then... that's it. No JMP, just an
RTS at $05A1. Remember those bytes that
were read from disk and pushed to the
stack in $0560..$0588? That's the
starting address of the game. What is
it? I have no idea. Let's find out.

Building on TRACE4, I need one more
callback letting (some of) the routine
at $0500 run its course. To do this, I
need to move my boot tracer out of the
way because it's going to get
overwritten. This is TRACE5 on my work
disk.

[$8600..$8726 copied from TRACE4]
; set up callback after boot is over
8727-   A9 4C       LDA   #$4C
8729-   8D 89 05    STA   $0589
872C-   A9 44       LDA   #$44
872E-   8D 8A 05    STA   $058A
8731-   A9 BF       LDA   #$BF
8733-   8D 8B 05    STA   $058B
; move boot tracer to $BF00
8736-   A2 00       LDX   #$00
8738-   BD 00 87    LDA   $8700,X
873B-   9D 00 BF    STA   $BF00,X
873E-   E8          INX
873F-   D0 F7       BNE   $8738
; let Sneakers load itself
8741-   4C 52 04    JMP   $0452
; grab address from stack
8744-   68          PLA
8745-   8D FE BF    STA   $BFFE
8748-   68          PLA
8749-   8D FF BF    STA   $BFFF
; grab zero page
874C-   A2 00       LDX   #$00
874E-   BD 00 00    LDA   $0000,X
8751-   9D 00 20    STA   $2000,X
; grab $0200..$02FF
8754-   BD 00 02    LDA   $0200,X
8757-   9D 00 22    STA   $2200,X
875A-   E8          INX
875B-   D0 F1       BNE   $874E
; exit to monitor
875D-   4C 59 FF    JMP   $FF59

This allows me to reboot to my work
disk and save the zero page and
$0200..$02FF data that Sneakers
expects.

The game starts at $4000.

Now it's time to put all the pieces
together. Here's my proposed memory
map:

$0800..$97FF: original Sneakers code
$9800..$9BFF: original RWTS
$9C00..$9CFF: original zero page
$9D00..$9DFF: original page 2
$9E00..$9FFF: my initialization routine

$9E00 will just move a bunch of stuff
into the places that Sneakers expects.

$9800..$9BFF to $0400..$07FF
$9C00..$9CFF to $00..$FF
$9D00..$9DFF to $0200..$02FF

and JMP $4000.

Success! The game runs! And... failure.
The disk motor turns on when you lose a
life during the game. Then the game
animates the ship coming down (but
doesn't appear to be reading from the
disk, WTF?), then the game hangs when
the ship makes it to the bottom of the
screen.

OK, so there's one more check
somewhere. Searching the code for
instances of "BD 89 C0" (LDA $C089,X)
-- commonly used to turn on the disk
motor -- brings up a routine at $4FE1
that turns it on and a sister routine
at $4FE7 that turns it back off. But
there are no JSRs or JMPs to either of
these routines... rats.

Ah, but there *is* a JSR $4FDE at
$6EFD. From looking at the surrounding
code, it appears that this disk check
was hacked in at the last minute. The
first instruction at $4FDE is
STX $85D8, which makes no sense and has
nothing to do with disk activity. But
it *does* make sense in the context of
the surrounding code near $6EFD, which
just loaded the X-register with a
value.

It's as if somebody said at the last
minute, "Hey, all that nasty stuff we
did with the RWTS, the custom disk
encoding, the nibble checks, the
self-modifying code, and the
progressive integrity checking JUST
ISN'T ENOUGH so could you please add a
disk check too?" And the weary
programmer rolled their eyes and said,
"Sure boss, I can monkey patch it."
Then they moved 3 bytes of real code to
a subroutine labeled
CAN_YOU_BELIEVE_THIS_SHIT_RIGHT_HERE
and went home early to get drunk in the
shower.

This still doesn't solve the hanging
problem, though. My guess is that it's
doing a nibble check of some sort at
the point where the disk read stopped
after the boot sequence. Searching the
code for instances of "BD 8C C0" (LDA
$C08C,X) brings up a routine that
appears to start at $94D3 that, lo and
behold, does an extremely basic check
for the existence of some non-standard
address prologue bytes. Since those no
longer exist, the code just hangs.

Once again, there are no references to
JSR $94D3 or JMP $94D3 or anything,
anywhere in the code. But look... at
$94D0, there is an odd instruction, STA
$1A28, which has nothing to do with
nibble checking. And sure enough, there
*is* a JSR $94D0, at $6FC9, and the
surrounding code before the JSR is
storing other values in $1A27 and
$1A29. This reinforces my theory that
this entire disk check was hacked in at
the last minute. Simply patching the
caller to do the STA instead of the JSR
is enough to get the code to stop
hanging. The nibble check subroutine
does not set any flags or modify any
memory to indicate success, so
bypassing it altogether is the simplest
solution.

Thus, the Smallest Patch That Could
Possibly Work:

*6FC9:8D 28 1A    ; originally 20 D0 94
*6EFD:8E D8 85    ; originally 20 DE 4F

Here's my proposed disk layout:

Track 0, sectors 0 and 3-B: a modified
ProntoDOS RWTS that loads the rest of
the game into memory and jumps to
$9E00.

Track 0, sectors 1-2: the original boot
animation code. This was stored in
$0600..$07FF in the original RWTS.

$0800 (T0S0) shows hi-res page 1, loads
ProntoDOS RWTS into $B700..$BFFF, and
moves the original animation code into
$0600..$07FF, then jumps to $B700.

$B700 (T0S3) loads everything else into
$0800..$9FFF, calling the original
animation code on each track change.

ProntoDOS works fastest when it is
reading tracks "backwards," i.e. read
logical sector 0F, then logical sector
0E, then logical sector 0D, and so on
down to logical sector 00. So, I've
stored the game data "backwards" on
each track. For example, track 1
contains the data from $0800..$17FF.
Track 1, sector 0F stores the data for
$0800..$08FF, sector 0E stores
$0900..$09FF, and so on until sector 00
which stores $1700..$17FF.

Track  Address
-------------------
01     $0800..$17FF
02     $1800..$27FF
03     $2800..$37FF
04     $3800..$47FF
05     $4800..$57FF
06     $5800..$67FF
07     $6800..$77FF
08     $7800..$87FF
09     $8800..$97FF
0A     $9800..$9FFF (partial track)

The final disk preserves the "look and
feel" of the original, from the display
of the uninitialized hi-res page at the
earliest possible moment, to the boot
animation synchronized with the disk
motor, to the unaltered game with
copyright messages intact. I have added
a standard DOS 3.3 VTOC on track $11
and stored these softdocs as a text
file, but the game itself never looks
at this catalog nor reads these docs.

---------------------------------------
A 4am crack                  2014-02-27
------------------EOF------------------