---------------Pitstop II-------------- A 4am crack 2014-08-13 --------------------------------------- "Pitstop II" is a 1984 racing game developed by Synergistic Software and distributed by Epyx. The title screen credits three people by name: Ivan Manley, R. Clardy, and D. Stinnett. [The copy protection is identical to several other titles I've seen before, including - "Gertrude's Secrets, "Bumble Games," "Juggles' Rainbow, "Moptown Parade," "Reader Rabbit," and "Wizard of Words" by The Learning Company - "Xevious" by Mindscape - "The Notable Phantom" by DesignWare - "Animal Kingdom" and "Race Car 'Rithmetic" by Unicorn Software Which is an interesting discovery in and of itself. Anyway, this write-up is quite similar to those, with a few updates and corrections.] Booting the disk looks and sounds like a normal DOS 3.3 boot, complete with the drive seeking to track 2, then 1, then 0, then swinging to the middle of the disk to read the catalog track. It even displays a BASIC prompt during boot, as if it's loading a HELLO program. However, the disk is uncopyable by any automated method. COPYA fails miserably and immediately. EDD 4 bit copy gives no read errors, but the copy it creates only gets as far as loading DOS and displaying the BASIC prompt before filling the screen with garbage and rebooting. In my experience, disks do not spontaneously reboot unless someone tells them to. Turning to my trusty Copy ][+ sector editor, I press "P" to get to the Sector Editor Patcher, and select "DOS 3.3 PATCHED". This option ignores checksum bytes and epilogue sequences -- as long as the address and data prologue are standard ("D5 AA 96" and "D5 AA AD", respectively), this will allow me to read each sector. And lo and behold, it works! I can read the data from every sector on every track. Track $11 does appear to contain a disk catalog, which strongly suggests this program is file-based. Based on my limited experience cracking other disks, I would guess that this disk has - Standard prologue bytes before the address and data fields [otherwise Copy ][+ sector editor would give read errors, even with the "DOS 3.3 PATCHED" option] - Non-standard epilogue bytes after the address and data fields [otherwise COPYA would work] - Some secondary protection [otherwise the bit copy created with EDD 4 would work] Given the (relatively) weak structural protection, I used to turn to the DOS 3.3 master disk, patch the RWTS to ignore checksums and epilogue bytes (changing $B942 from "SEC" to "CLC"), and run COPYA. Then, one fine day, and completely by accident, I came across an original disk with a bad sector. I suppose this shouldn't surprise me. These floppies are decades old by now; it's amazing any of them work at all. The point is, I shouldn't be using tools that ignore potentially serious read errors. There are other tools, like Super Demuffin, that can convert a disk like this (with non-standard epilogue bytes) into a standard format. It requires figuring out what the actual epilogue bytes are, but it has the advantage of surfacing a read error if the original disk actually has a read error. So... no more COPYA+B942:18 patch. From now on, it's Super Demuffin or Advanced Demuffin to convert disks to a standard format. Just by looking at the first few sectors, it appears that this disk uses a DOS 3.3-derived RWTS, which means that my AUTOTRACE program should be able to extract the RWTS from the original disk. [S6,D1=original disk] [S5,D1=my work disk] ]PR#5 ... CAPTURING BOOT0 ...reboots slot 6... ...reboots slot 5... SAVING BOOT0 For those of you just tuning in, my work disk uses a custom program that I affectionately call "AUTOTRACE" to automate the process of boot tracing as far as possible. For some disks (like this one, apparently), it just captures track 0, sector 0 (saved in a file called "BOOT0") and stops. For other disks that load in the same way that an unprotected DOS 3.3 disk loads, it captures the next stage of the boot process as well (in a file called "BOOT1"). BOOT1 contains sectors 0-9 on track 0, which are loaded into memory at $B600..$BFFF. This generally contains the RWTS routines which the program uses to read the rest of the disk. If the RWTS is fairly normal as well (and my AUTOTRACE program just spot- checks a few memory locations to guess at its "normalcy"), AUTOTRACE extracts the RWTS routines (generally loaded from track 0, sectors 2-9 into $B800.. $BFFF) and saves *that* into a third file called "RWTS". There's a good chance I'll be able to load that "RWTS" file into a tool called Advanced Demuffin (written in 1983 by The Stack) to convert the disk into a standard disk readable by unprotected DOS 3.3 disks or any other third-party tools. If anything looks fishy or non- standard, AUTOTRACE just stops, and I have to check the files it saved so far to determine why. In this case, it stopped after capturing T00,S00. So I need to look at that sector and figure out why. ]CALL -151 *800<2800.28FFM *801L ... Everything here looks pretty normal (i.e. just like an unprotected DOS 3.3 disk), until it goes to jump to the boot1 code. Usually that happens with an indirect JMP ($08FD), which, in a normal boot0, will end up continuing execution at $B700 which is stored in track 0, sector 1. But in this case, I see: 084A- 4C C0 08 JMP $08C0 *8C0L 08C0- 8E E9 B7 STX $B7E9 08C3- 6C FD 08 JMP ($08FD) OK, that's harmless (as far as copy protection goes). This boot0 code is close enough to normal that I should be able to run my AUTOTRACE1 script to patch the boot0 code and interrupt the boot before it jumps to boot1. *BRUN AUTOTRACE1 ...reboots slot 6... ...reboots slot 5... SAVING BOOT1 SAVING RWTS Excellent! I have the RWTS and can load it into Advanced Demuffin. Advanced Demuffin will only load RWTS files from a drive in slot 6, which is annoying since mine is in slot 5. Note to self: patch that someday. In the meantime, I'm swapping floppy disks like some kind of 20th century peasant. [S6,D1=my work disk] ]PR#6 ]BRUN ADVANCED DEMUFFIN 1.1 --> LOAD NEW RWTS MODULE At $B8, load "RWTS" from drive 1 [S6,D1=original disk] [S6,D2=blank disk] --> FORMAT TARGET DISK ...grind grind grind... --> CONVERT DISK This disk is 16 sectors, and the default options (copy the entire disk, all tracks, all sectors) don't need to be changed. ADVANCED DEMUFFIN 1.1 - COPYRIGHT 1983 WRITTEN BY THE STACK -CORRUPT COMPUTING =======PRESS ANY KEY TO CONTINUE======= TRK:................................... +.5: 0123456789ABCDEF0123456789ABCDEF012 SC0:................................... SC1:................................... SC2:................................... SC3:................................... SC4:................................... SC5:................................... SC6:................................... SC7:................................... SC8:................................... SC9:................................... SCA:................................... SCB:................................... SCC:................................... SCD:................................... SCE:................................... SCF:................................... ======================================= 16 SC $00,$00 TO $22,$0F BY $01 TO DRV2 The disk's own RWTS gave no read errors on any track. This is the power and the genius of Advanced Demuffin. Every disk must be able to read itself. So, let it read itself, then capture the data and write it out in a standard format. There are two problems with this copy: 1. Depending on how the original disk was written, this copy may or may not be able to read itself. I may need to patch the disk's RWTS to deal with the fact that the disk is now in a standard format. 2. Even if it can read itself, it won't run. The copies I tried to make -- even the bit copies -- just rebooted endlessly, which means there is some code being executed during boot to check if the disk is original. (Hint: it's not.) Just by booting my copy, I can rule out problem #1. The disk seems to read itself just fine. It makes it exactly as far as my failed bit copy -- far enough to figure out that it's not an original disk, fill the screen with garbage, and reboot. But wait... [S6,D1=my work disk] [S6,D2=non-working copy] ]PR#6 ... ]CATALOG,S6,D2 C1983 DSR^C#254 493 FREE B 003 BOOT OK, this disk has a "catalog," but it's obviously just a stub for a disk-based loader. (I attempted "BRUN BOOT" and it crashed.) It's either tightly bound to the custom DOS on the disk, or it doesn't like the 64K DOS on my work disk, or maybe it's not even used. Let's back up. ]PR#5 ; reboot work disk ... ]BLOAD BOOT1,A$2600 ]CALL -151 *FE89G FE93G ; disconnect DOS *B600<2600.2FFFM ; move RWTS into place *B700L B700- 20 00 BB JSR $BB00 I've learned from previous cracks (and from actually reading "Beneath Apple DOS" instead of, you know, just staring at it on my bookshelf) that, in a standard DOS-3.3-derived RWTS, the area from $BB00 to $BC55 is overwritten during every disk read. (It's used as scratch space during denibblization, which is totally a real word that I just made up.) So why is there executable code there? Let's find out. *BB00L BB00- A0 00 LDY #$00 BB02- B9 00 BB LDA $BB00,Y BB05- 99 00 02 STA $0200,Y BB08- 88 DEY BB09- D0 F7 BNE $2B02 BB0B- 60 RTS Well that's definitely suspicious. Relocating yourself into the input buffer at $0200? Seriously, who does that? I'm guessing that the first instruction after this is the entry point, so after relocation, that would be $020C. *20C