Re: Possibly the most copy protected Apple program I've seen

[Dick Sisco <dsisco@mchsi.com>]

On Tue, 28 Sep 2004 15:00:54 -0400, "Jayson Smith"
<nospamratguyspambegone@nospamplease.bellsouth.ihatespam.net> wrote:

>Hi,
>Just thought I'd share my experiences with a very heavily copy protected
>software and see if anybody has any thoughts as to what's really going on
>under the hood.  Unless there's interest, I'll not name the actual program,
>especially since I have successfully cracked it but for an unrecoverable
>disk error on my only copy of the program.  I'll just say that it is a
>program designed to be used with the Echo speech synthesizer card.
>The weird thing about this program is that normal DOS 3.3 can't read the
>disk.  But, the custom DOS on the disk *can* read normal DOS 3.3 disks.

This may not be as weird as you think.  The address and data epilogues
on a normal disk are DE AA EB.  (The third one, EB, is ignored on
read).  

One way to protect a disk is to format the disk with the  second
epilogue byte changed from AA to say DE.  DOS is then changed to look
for a DE instead of an AA.  The disk and read and write itself, but it
cannot be copied by an unmodified DOS.

But take the same disk and modify DOS to _ignore_ the second epilogue
byte.  It still can't be copied by an unmodified DOS, but the DOS on
the modified disk can read and write to either itself or a normal
disk.

>This is actually important for one part of the program in question.
>Now, for some clever tricks this custom DOS has up its sleeve.  First of
>all, hitting a reset causes about a half second delay (maybe it's erasing
>something in memory?) then a reboot.  That's probably pretty normal.  

3F2-3F4  is the Reset vector (I think--if I recall, it's an address
and a validity byte--but I could be wrong about that).  0's in that
location will  cause a reset to reboot.  But programmers often pointed
this vector to code that first blasted memory, then rebooted.  This
was often done even when the disk was not copy protected, just to keep
people from reading the code.

>But
>what's stranger is that when the program exits, or even if there's an error
>loading the program, and you're left sitting at the Applesoft prompt, any
>command typed, or even just a blank line, will net the same result.  A
>slight delay, then a reboot!  So you can't load/list/save/etc.

My (15 year old) notes say: "If location 214 ($D6) is greater than
127, any line typed at the ] prompt will cause the program to run."  

Combined with other techniques, this could be used to reboot the disk.

>The way I cracked this is quite interesting.  I had a normal DOS disk set up
>to run FID at startup.  Now remember that this custom DOS can read and write
>normal DOS disks as well.  So I booted up the custom DOS, then just as the
>head was traveling to track seventeen so DOS could read the catalog track, I
>yank open the drive door, pull out the disk then quickly, while the head is
>recalibrating after not being able to read from an open drive, put in the
>normal FID disk and close the door!  Voila!  Now Fid's running and I can
>just copy the files to a standard DOS disk.

If the only change to the disk was the second epilogue byte, you could
have simply booted a normal DOS disk, gone to the monitor and typed
B99C: EA EA and run FID.  Of course, there may have been other
techniques in use on the disk too.

A quieter way to do what you did is to use an old Integer BASIC Card.
Boot with the Integer Basic Card "Off".  Switch the Integer BASIC Card
to ON.  Hit reset.  Without the "Autostart ROM" you drop right into
the monitor where you can fix the Reset Vector.

>Upon further examination, I found that the actual Applesoft programs also
>have a few tricks up their sleeves.  First of all, as each program starts it
>messes up the reset vector so reset causes a reboot.  Also, should any
>program terminate in error, it clears itself from memory, so a 'list' gets
>you nothing!
>Jayson
>
>