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

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

Actually, the unrecoverable disk error is an actual disk error.  The
program, in all its copy protected glory, can't read it, so it's a genuine
disk error.  That's too bad too, as it is in an Applesoft program.  While I
have used a DOS patch which keeps trying to read a bad sector until it gets
what it thinks is a good read, and this did get me a good read, it wasn't
quite good enough.  There are a few errors, at least one of which is
uncorrectable because the line number in a "gosub" command is missing and I
have no idea where it's supposed to gosub to.
Jayson.

"Don Bruder" <dakidd@sonic.net> wrote in message
news:xaj6d.15491$54.236377@typhoon.sonic.net...
> In article <Gwi6d.60001$as2.56812@bignews3.bellsouth.net>,
>  "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 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!
>
> Bet on some 6502 code that does copy-protection checking, and figure on
> a mangled RWTS.
>
> What you're describing sounds a lot like the old "RDOS" - I might be
> mis-remembering the name, though - It was used for a lot of "non-game"
> copy protections, and was fairly easily tweaked for each new title,
> making it relatively easy to come up with a "new" copy protection scheme
> for each program. What little I can remember about cracking stuff that
> used it is making me think that one portion of it was a custom RWTS,
> along with some oddball sector skewing, and mangled sector marks (which
> the RWTS was modified to deal with)
>
> Look for ampersand routines in the BASIC code. Chances are high that the
> protection involved is loaded at the tail end of the Applesoft code - In
> other words, it's VERY possible that they pulled some tricks with the
> various pointers that BASIC uses in order to tack binary data onto the
> end of the program code, eliminating the need for "BLOAD" or "POKE" work
> to get the machine language loaded.
>
> Your unrecoverable disk error is almost certainly due to a lack of
> something (Sorry, can't be more specific) that the modified DOS normally
> provides. Figure out what's happening when the error occurs, and
> backtrack to find what's getting called, and you may be able to rip the
> call out.
>
> --
> Don Bruder - dakidd@sonic.net - New Email policy in effect as of Feb. 21,
2004.
> Short form: I'm trashing EVERY E-mail that doesn't contain a password in
the
> subject unless it comes from a "whitelisted" (pre-approved by me) address.
> See <http://www.sonic.net/~dakidd/main/contact.html> for full details.