---------The American Challenge-------- A 4am crack 2014-07-21 --------------------------------------- "The American Challenge" is a 1986 sailing simulation game programmed by Tom Snyder and distributed by Mindscape. COPYA fails miserably and immediately. EDD 4 bit copy gives no read errors, but the copy just reboots endlessly. In my experience, programs do not spontaneously reboot unless someone tells them to. Turning to my trusty Copy ][+ sector editor, I press "P" to enter the Sector Editor Patcher, then select "DOS 3.3 PATCHED" (which ignores address field checksums and epilogue bytes). Behold! All tracks and sectors are readable. 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. My AUTOTRACE program will only automate extraction of the RWTS from a DOS 3.3-shaped bootloader, so let's see if I can use Super Demuffin. Super Demuffin is a cracker's utility built on top of Locksmith Fast Disk Copy. It takes a disk that uses non- standard but uniform address and data prologue and epilogue bytes, and it converts it to a standard disk format. I've included a copy on my work disk. First, I'll need to find exactly what those epilogue bytes are. Turning to the Copy ][+ nibble editor: --v-- COPY ][ PLUS BIT COPY PROGRAM 8.4 (C) 1982-9 CENTRAL POINT SOFTWARE, INC. --------------------------------------- TRACK: 01 START: 262D LENGTH: 015F 2608: FF FF FF FF FF FF FF FF VIEW 2610: FF FF FF FF FF FF FF FF 2618: FF FF FF FF FF FF FF FF 2620: FF FF FF FF FF FF FF FF 2628: FF FF FF FF FF D5 AA 96 <-262D ^^^^^^^^ standard address prologue 2630: FF FE AA AB AA AA FF FF 2638: FF FF EB CF E7 F9 FE FF ^^^^^^^^ non-standard address epilogue 2640: FF FF FF FF D5 AA AD DA ^^^^^^^^ standard data prologue 2648: ED ED ED ED ED ED ED ED --------------------------------------- A TO ANALYZE DATA ESC TO QUIT ? FOR HELP SCREEN / CHANGE PARMS Q FOR NEXT TRACK SPACE TO RE-READ --^-- (Not shown in the above screenshot, but the data epilogue is also "FF FF EB".) Some quick inspection suggests that all tracks on the disk use the same non- standard address and data epilogue bytes. Now I can plug this information into Super Demuffin. When you first run Super Demuffin, it asks for the parameters of the original disk. In this case, the prologue bytes are the same, but the epilogues are "FF FF EB" instead of "DE AA EB". --v-- SUPER-DEMUFFIN AND FAST COPY Modified by: The Saltine/Coast to Coast Address prologue: D5 AA 96 Address epilogue: FF FF EB DISK ^^^^^ ORIGINAL *change from "DE AA" Data prologue: D5 AA AD Data epilogue: FF FF EB ^^^^^ *change from "DE AA" Ignore write errors while demuffining! D - Edit parameters - Advance to next parm - Exit edit mode R - Restore DOS 3.3 parameters O - Edit Original disk's parameters C - Edit Copy disk's parameters G - Begin demuffin process --^-- Pressing "G" switches to the Locksmith Fast Disk Copy UI. It assumes that both disks are in slot 6, and that drive 1 is the original and drive 2 is the copy. [S6,D1=original disk] [S6,D2=blank disk] --v-- LOCKSMITH 7.0 FAST DISK BACKUP R................................... W*********************************** HEX 00000000000000001111111111111111222 TRK 0123456789ABCDEF0123456789ABCDEF012 0................................... 1................................... 2................................... 3................................... 4................................... 5................................... 6................................... 7................................... 8................................... 9................................... A................................... B................................... C................................... D................................... 12 E................................... F................................... [ ] PRESS [RESET] TO EXIT --^-- 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 the copy, I can rule out problem #1. The disk seems to read itself just fine. It makes it exactly as far as the failed bit copy -- far enough to figure out that it's not an original disk and reboot. It's time for a little boot tracing. [S6,D1=original disk] [S5,D1=my work disk] ]PR#5 CAPTURING BOOT0 ...reboots slot 6... ...reboots slot 5... SAVING BOOT0 ]CALL -151 *800<2800.28FFM *801L ; put an "RTS" instruction at $0801 -- ; common for custom bootloaders that ; want to JSR to the disk controller ; ROM routine to read more sectors 0801- A9 60 LDA #$60 0803- 8D 01 08 STA $0801 ; munge reset vector 0806- 8D F4 03 STA $03F4 ; clear screen (the hard way, but OK) 0809- A2 00 LDX #$00 080B- A9 A0 LDA #$A0 080D- 9D 00 04 STA $0400,X 0810- 9D 00 05 STA $0500,X 0813- 9D 00 06 STA $0600,X 0816- 9D 00 07 STA $0700,X 0819- E8 INX 081A- D0 F1 BNE $080D 081C- 8E 78 04 STX $0478 081F- A2 40 LDX #$40 0821- 86 27 STX $27 0823- A9 00 LDA #$00 0825- A2 01 LDX #$01 0827- A0 0B LDY #$0B 0829- 20 2F 08 JSR $082F *82FL ; This is a multi-sector read routine ; that, as I suspected, re-uses the ; disk controller ROM routine at $C65C ; to read more sectors from track 0. ; Actually, it's even more than that; ; the routine at $08C0 (not shown here) ; can move the drive head forward, so ; this is a multi-track read routine. ; Accumulator holds the track, the X ; register holds the first sector, and ; the Y register holds the number of ; sectors to read. Since it's reusing ; the disk controller ROM, it uses ; zero page $27 to hold the address to ; store the data read from disk. 082F- 85 41 STA $41 0831- 86 FF STX $FF 0833- 84 FE STY $FE 0835- 20 70 08 JSR $0870 0838- A9 00 LDA #$00 083A- 85 26 STA $26 083C- A4 FF LDY $FF 083E- B9 60 08 LDA $0860,Y 0841- 85 3D STA $3D 0843- A2 60 LDX #$60 0845- 20 5C C6 JSR $C65C 0848- E6 FF INC $FF 084A- A5 FF LDA $FF 084C- C9 10 CMP #$10 084E- 90 0B BCC $085B 0850- A9 00 LDA #$00 0852- 85 FF STA $FF 0854- E6 41 INC $41 0856- A5 41 LDA $41 0858- 20 70 08 JSR $0870 085B- C6 FE DEC $FE 085D- D0 DD BNE $083C 085F- 60 RTS Backtracking... ; starting address is $4000 081F- A2 40 LDX #$40 0821- 86 27 STX $27 ; read from track 0 0823- A9 00 LDA #$00 ; start at sector 1 0825- A2 01 LDX #$01 ; read a total of $0B sectors 0827- A0 0B LDY #$0B 0829- 20 2F 08 JSR $082F ; don't know what this does yet 082C- 4C 00 4A JMP $4A00 OK, this is where I need to interrupt the boot process. We just read a whole bunch of stuff from disk, and now we're jumping to memory that was populated during that disk read. I want to know what's there. *9600