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

[Don Bruder <dakidd@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.