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

["Jayson Smith" <nospamratguyspambegone@nospamplease.bellsouth.ihatespam.net>]

Ok, maybe you aren't understanding.  I was able to crack the program, using
the method described in my first post, that of waiting until the custom DOS
was looking for the catalog track then quickly switching that disk for one
that ran FID.  I could then copy the files from the program disk.  The only
problem I have seems to be the result of a bad disk, clear and simple.
In all likelyhood the disk would not be imagable using ADT under a standard
DOS, but would be under its own DOS.  The trick is that with no access to
Applesoft, whatever you want to run has to be run, either directly or
indirectly, from the hello program on the standard disk.  Actually this
wasn't a problem for me as I've got a disk set up so that the hello program
loads the Textalker software for the Echo card, then runs a file called
autoexec if it exists.  That way I could just put whatever I wanted in the
autoexec then delete it when no longer needed, and never have to mess with
the hello program.
Jayson.

"Jplcsch" <jplcsch@wanadoo.fr> wrote in message
news:4159c021$0$21149$8fcfb975@news.wanadoo.fr...
> First : Could you send an image under .dsk format even if the disk don't
> work ?
>
> Second :
> It's possible that your original  disk'll be uncopiable (prolok protection
> for example) but it's impossible that the disk'll be uncrackable. Prolok
is
> the worst protection I know, it's an alteration of the magnetic area but
> it's crackable.
>
> |Third
> The others protection are a control between sectors. Look if you see some
> instrcutions like
> LDA C08C,X
> BMI xxx
> Or look for a nibble count.
>
>
>
>
> "Jayson Smith"
<nospamratguyspambegone@nospamplease.bellsouth.ihatespam.net>
> wrote in message news:Gwi6d.60001$as2.56812@bignews3.bellsouth.net...
> > 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 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.
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.
> > 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.
> > 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
> >
> >
> >
>
>