[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Possibly the most copy protected Apple program I've seen
- Subject: Re: Possibly the most copy protected Apple program I've seen
- From: "Jplcsch" <jplcsch@wanadoo.fr>
- Date: Tue, 28 Sep 2004 22:06:20 +0200
- Newsgroups: comp.sys.apple2
- Organization: les newsgroups par Wanadoo
- References: <Gwi6d.60001$as2.56812@bignews3.bellsouth.net> <xaj6d.15491$54.236377@typhoon.sonic.net>
- Reply-to: "Jplcsch" <jplcsch@wanadoo.fr>
- Xref: g2news1.google.com comp.sys.apple2:4597
"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.
If it's an RDOS from SSI
remove the line with a call of the file QWERTY
that's all
If it's RDF85 or a recent (hmmm 20 years old of course) it's a track arcing
.. look inside the drive the whiite wheel