💾 Archived View for mirrors.apple2.org.za › active › 4am › images › games › action › Xevious%20(4am%… captured on 2024-08-18 at 17:45:21.
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
----------------Xevious----------------
A 4am crack 2014-06-14
---------------------------------------
"Xevious" is a 1982 Namco arcade game
programmed by Dan Hewitt and
distributed by Mindscape, Inc.
Booting the original disk sounds like a
normal DOS 3.3, complete with track
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.
However, the disk is uncopyable by any
automated method. COPYA fails miserably
and immediately. EDD 4 bit copy shows
no read errors, but the copy does not
boot. It loads DOS and displays a BASIC
prompt, then fills the screen with
garbage and reboots.
Turning to my trusty Copy ][+ sector
editor, I press "P" to enter the Sector
Editor Patcher, then select "DOS 3.3
PATCHED" (which ignores address field
checksums and epilogue bytes). Behold!
All tracks and sectors are readable.
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.
Based on my initial inspection with a
sector editor, this disk loads DOS and
runs a HELLO program. So it shouldn't
be difficult to capture the RWTS and
load it into Advanced Demuffin.
[S6,D1=original disk]
[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
CAPTURING BOOT1
...reboots slot 6...
...reboots slot 5...
SAVING BOOT1
SAVING RWTS
Excellent! I have the RWTS and can load
it into Advanced Demuffin.
[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]
[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
Now I have a copy of the disk in a
standard format that can be read by any
tools. That is, I can copy this copy
with COPYA or Locksmith Fast Disk
Backup, without patching the DOS 3.3
RWTS beforehand. I can sector edit the
disk without messing with the Sector
Editor Patcher. &c.
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 the copy, I can rule
out problem #1. The disk seems to read
itself just fine. It makes it exactly
as far as the failed bit copy -- far
enough to figure out that it's not an
original disk, fill the screen with
gibberish, and reboot.
Let's back up.
[S6,D1=demuffin'd copy]
[S5,D1=my work disk]
]PR#5
]BLOAD BOOT1,A$2600
]CALL -151
*B600<2600.2EFFM
*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. 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 disk head to where the
; nibble check should be
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 the 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 to $80
T00,S0B,$4F: change $02 to $A1
Success! The game boots and runs with
no complaint. There doesn't appear to
be any further protection once DOS is
loaded.
Quod erat liberandum.
---------------------------------------
A 4am crack No. 76
------------------EOF------------------