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 In article , "Jayson Smith" 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 for full details. "Don Bruder" wrote in message news:xaj6d.15491$54.236377@typhoon.sonic.net... > In article , > "Jayson Smith" > 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 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 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" 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 > > > On Tue, 28 Sep 2004 15:00:54 -0400, "Jayson Smith" 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 > >