--------------Krell's Logo-------------
A 4am crack                  2014-05-08
---------------------------------------

Krell's Logo is an implementation of
the Logo programming language. It was
derived from Apple Logo, programmed at
M.I.T. under the supervision of H.
Abelson. This version was developed by
Mark W. Friedland and distributed by
Krell Software.

COPYA barfs immediately on the original
disk. My trusty Copy ][+ sector editor
can read track 0, sectors 0-9, with the
"DOS 3.3 PATCHED" option. (Press "P" to
get to the Sector Editor Patcher, then
select "DOS 3.3 PATCHED" to ignore
address and data epilogue bytes and
checksums.) The rest of the disk is a
black box.

Time for boot tracing!

[S6D1=original disk]
[S5D1=my work disk]

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

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, this
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"), there's a good
chance I'll be able to use a tool
called Advanced Demuffin (written in
1983 by The Stack) to convert the disk
from whatever weird format it uses to
store its sector data into a standard
disk readable by unprotected DOS 3.3
disks or any other third-party tools.
In this case, 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".

If anything looks fishy or non-
standard, AUTOTRACE just stops, and I
have to check the files it saved so far
to determine why. But in this case, it
ran all the way through, automatically
capturing BOOT0, BOOT1, and RWTS files.
Now I can use Advanced Demuffin to
convert the disk to a standard format.
(It uses the disk's own RWTS to read
the original, then a standard DOS 3.3-
compatible RWTS to write out the data,
sector by sector.)

[S6,D1=my work disk]

]PR#6
]BRUN ADVANCED DEMUFFIN 1.1

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

[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 unless something goes
horribly wrong.

                 --v--

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

                 --^--

Well, the disk's own RWTS can't read
the boot1 code on track 0 (sectors
0-9), but that's OK. I captured that
separately (in the "BOOT1" file), and I
can replace it manually if I need to.
There is one read error on track $0D
(repeatable, I tried this twice) which
could be a glitch but is probably
intentional, on the assumption that
anything that makes a protected disk
harder to copy is intentional.

Rebooting my work disk, I can see the
disk catalog on the demuffin'd copy,
despite the read errors.

[S5D1=my work disk]
[S6D1=demuffin'd copy]

]PR#5
...
]CATALOG,S6,D1

C1983 DSR^C#254
300 FREE

 A 002 HELLO
 B 017 RUNTIME
 B 007 TURTLE
 B 037 BANNER.SHP
 B 128 LOGO A
 B 005 PROGRAM

That looks pretty normal. (The custom
catalog header is from my work disk,
not the disk I just converted.) Let's
see if it runs...

]RUN HELLO
...

Indeed, it displays the animated title
screen with a turtle pulling a Krell
logo across the screen, then goes
straight to the interactive Logo
editor, just like the original disk.
That means there probably isn't any
additional protection beyond the custom
disk encoding. (There might have been a
nibble check or some other nastiness
hiding in the original DOS, but the
program itself runs just fine from my
work disk, so I don't really care.)

Finally, I need to get my copy to read
itself. Since it's now in a standard
disk format, that's pretty easy: put a
standard DOS on it. Using Copy ][+'s
"Copy DOS" option, I copy tracks 0-2
from a freshly initialized Pronto-DOS
disk to the demuffin'd copy.

One more reboot reveals no surprises.
The disk boots up, auto-runs the HELLO
program, and launches Krell's Logo.

What about that read error on T0D,S00?
It turns out the disk doesn't use that
sector. In fact, Copy ][+'s "Track/
Sector Map" says it doesn't use that
entire track. Tracks 0-2 are used (of
course, to hold the RWTS and DOS), and
track $11 for the disk catalog, but the
actual files are all between tracks $16
and $22.

                 --v--

   TRACK           1               2
   0123456789ABCDEF0123456789ABCDEF012

S0 ***              *     FEEEEEEEEDDB
E1 ***              *     EEEEEEEEDDDB
C2 ***              *     EEEEEEEEDDDB
T3 ***              *     EEEEEEEEDDDB
O4 ***              *     EEEEEEEEDDDB
R5 ***              *     EEEEEEEEDDDB
 6 ***              *     EEEEEEEEDDCB
 7 ***              *     EEEEEEEEDDCB
 8 ***              *     EEEEEEEEDDCB
 9 ***              *     EEEEEEEEDDCB
 A ***              *     EEEEEEEEDDCB
 B ***              *     EEEEEEEEDDCB
 C ***              *    FEEEEEEEEDDCB
 D ***              *    FEEEEEEEEDDBB
 E ***              *    FEEEEEEEEDDBA
 F ***              *    FEEEEEEEEDDBA

                 --^--

Was it a glitch? Or a vestige of some
secondary copy protection that I
unknowingly bypassed when I replaced
the entire DOS? Possibly it was a
remnant of some other copy protection
routine from another disk by the same
company? We may never know.

Quod erat liberandum.

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