💾 Archived View for mirrors.apple2.org.za › active › 4am › images › games › misc › Racter%20(4am%20c… captured on 2024-08-18 at 17:54:43.
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
-----------------Racter----------------
A 4am crack 2014-12-07
---------------------------------------
"Racter" is a 1985 text-based insanity
simulation developed by INRAC Corp. and
distributed by Mindscape. No one can be
told what Racter is; you have to see it
for yourself.
[The copy protection is identical to
"Rambo First Blood Part II," also
distributed by Mindscape. This write-up
is therefore quite similar to that one,
with a few updates because I have more
automated tools now.]
The original disk appears to be built
on Apple Pascal. At least, the boot
process looks like Pascal. It fills the
screen with null bytes, then clears the
screen and shows a solid cursor, then
continues to load the program.
COPYA fails miserably and immediately.
EDD 4 bit copy gives no read errors,
but the copy just reboots endlessly.
In my experience, programs do not
spontaneously reboot unless someone
tells them to.
Turning to my trusty Disk Fixer sector
editor, I go to "Input/Output Control"
(press "O") and set CHECKSUM ENABLED =
NO. 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.
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. My AUTOTRACE program will only
automate extraction of the RWTS from a
DOS 3.3-shaped bootloader, so let's see
if I can use Super Demuffin.
Super Demuffin is a cracker's utility
built on top of Locksmith Fast Disk
Copy. It takes a disk that uses non-
standard but uniform address and data
prologue and epilogue bytes, and it
converts it to a standard disk format.
I've included a copy on my work disk.
First, I'll need to find exactly what
those epilogue bytes are. Turning to
the Copy ][+ nibble editor:
--v--
COPY ][ PLUS BIT COPY PROGRAM 8.4
(C) 1982-9 CENTRAL POINT SOFTWARE, INC.
---------------------------------------
TRACK: 01 START: 1F85 LENGTH: 015F
1F60: FF FF FF FF FF FF FF FF VIEW
1F68: FF FF FF FF FF FF FF FF
1F70: FF FF FF FF FF FF FF FF
1F78: FF FF FF FF FF FF FF FF
1F80: FF FF FF FF FF D5 AA 96 <-1F85
^^^^^^^^
standard address prologue
1F88: AA AB AA AE AA AA AA AF
1F90: FF FF EB FF E7 F9 FE FF
^^^^^^^^
non-standard address epilogue
1F98: FF FF FF FF D5 AA AD E6
^^^^^^^^
standard data prologue
1FA0: F2 B7 D6 B9 FC DF EE CE
---------------------------------------
A TO ANALYZE DATA ESC TO QUIT
? FOR HELP SCREEN / CHANGE PARMS
Q FOR NEXT TRACK SPACE TO RE-READ
--^--
(Not shown in the above screenshot, but
the data epilogue is also "FF FF EB".)
Some quick inspection suggests that all
tracks on the disk use the same non-
standard address and data epilogue
bytes. Now I can plug this information
into Super Demuffin.
When you first run Super Demuffin, it
asks for the parameters of the original
disk. In this case, the prologue bytes
are the same, but the epilogues are "FF
FF EB" instead of "DE AA EB".
--v--
SUPER-DEMUFFIN AND FAST COPY
Modified by: The Saltine/Coast to Coast
Address prologue: D5 AA 96
Address epilogue: FF FF EB DISK
^^^^^ ORIGINAL
*change from "DE AA"
Data prologue: D5 AA AD
Data epilogue: FF FF EB
^^^^^
*change from "DE AA"
Ignore write errors while demuffining!
D - Edit parameters
<SPACE> - Advance to next parm
<RETURN> - Exit edit mode
R - Restore DOS 3.3 parameters
O - Edit Original disk's parameters
C - Edit Copy disk's parameters
G - Begin demuffin process
--^--
Pressing "G" switches to the Locksmith
Fast Disk Copy UI. It assumes that both
disks are in slot 6, and that drive 1
is the original and drive 2 is the
copy.
[S6,D1=original disk]
[S6,D2=blank disk]
--v--
LOCKSMITH 7.0 FAST DISK BACKUP
R...................................
W***********************************
HEX 00000000000000001111111111111111222
TRK 0123456789ABCDEF0123456789ABCDEF012
0...................................
1...................................
2...................................
3...................................
4...................................
5...................................
6...................................
7...................................
8...................................
9...................................
A...................................
B...................................
C...................................
D...................................
12 E...................................
F...................................
[ ] PRESS [RESET] TO EXIT
--^--
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 and reboot.
It's time for a little boot tracing.
[S6,D1=original disk]
[S5,D1=my work disk]
]PR#5
CAPTURING BOOT0
...reboots slot 6...
...reboots slot 5...
SAVING BOOT0
]CALL -151