----------------Xevious---------------- A 4am crack 2014-06-14 --------------------------------------- "Xevious" is a 1982 Namco arcade game programmed by Dan Hewitt and distributed by Mindscape, Inc. Booting the original disk sounds like a normal DOS 3.3, complete with track 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 shows no read errors, but the copy does not boot. It loads DOS and displays a BASIC prompt, then fills the screen with garbage and reboots. 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. Based on my initial inspection with a sector editor, this disk loads DOS and runs a HELLO program. So it shouldn't be difficult to capture the RWTS and load it into Advanced Demuffin. [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 CAPTURING BOOT1 ...reboots slot 6... ...reboots slot 5... SAVING BOOT1 SAVING RWTS Excellent! I have the RWTS and can load it into Advanced Demuffin. [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 Now I have a copy of the disk in a standard format that can be read by any tools. That is, I can copy this copy with COPYA or Locksmith Fast Disk Backup, without patching the DOS 3.3 RWTS beforehand. I can sector edit the disk without messing with the Sector Editor Patcher. &c. 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, fill the screen with gibberish, and reboot. Let's back up. [S6,D1=demuffin'd copy] [S5,D1=my work disk] ]PR#5 ]BLOAD BOOT1,A$2600 ]CALL -151 *B600<2600.2EFFM *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. So why is there executable code there? Let's find out. 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. ; this subroutine seeks to track $11 ; and sets the reset vector to ; something unfriendly 020C- 20 CF 02 JSR $02CF 020F- A9 0A LDA #$0A 0211- 85 2A STA $2A ; initialize disk motor ; (highly suspicious) 0213- AE E9 B7 LDX $B7E9 0216- BD 89 C0 LDA $C089,X 0219- BD 8E C0 LDA $C08E,X ; set some counters 021C- A9 C7 LDA #$C7 021E- 85 48 STA $48 0220- A9 02 LDA #$02 0222- 85 49 STA $49 0224- A9 80 LDA #$80 0226- 85 29 STA $29 0228- C6 29 DEC $29 ; reboots (bad) 022A- F0 67 BEQ $0293 ; position disk head to where the ; nibble check should be 022C- 20 44 B9 JSR $B944 022F- B0 62 BCS $0293 0231- A5 2D LDA $2D 0233- C9 0D CMP #$0D 0235- D0 F1 BNE $0228 0237- A0 00 LDY #$00 0239- BD 8C C0 LDA $C08C,X 023C- 10 FB BPL $0239 023E- 88 DEY ; reboots (bad) 023F- F0 52 BEQ $0293 ; Search for a specific sequence of ; nibbles in the "dead zone" between ; the address field and data field. ; This area is normally not important, ; so COPYA didn't copy it precisely ; because normal disks don't care. ; (Actually, it's even more evil than ; that, because the original disk is ; written with timing bits in specific ; non-standard places between the ; nibbles in the dead zone. This code ; not only requires the right nibbles ; in the right order, it reads them ; just slightly faster than normal. So ; the timing bits need to be in the ; right places too, or the disk will ; get out of sync and read the wrong ; nibble values. This will trip up even ; the best bit copiers. And you can ; forget about making a disk image for ; emulators -- those don't store timing ; bits at all.) 0241- C9 D5 CMP #$D5 0243- D0 F4 BNE $0239 0245- A0 00 LDY #$00 0247- BD 8C C0 LDA $C08C,X 024A- 10 FB BPL $0247 024C- 88 DEY ; reboots (bad) 024D- F0 44 BEQ $0293 024F- C9 E7 CMP #$E7 0251- D0 F4 BNE $0247 0253- BD 8C C0 LDA $C08C,X 0256- 10 FB BPL $0253 0258- C9 E7 CMP #$E7 ; reboots (bad) 025A- D0 37 BNE $0293 025C- BD 8C C0 LDA $C08C,X 025F- 10 FB BPL $025C 0261- C9 E7 CMP #$E7 ; reboots (bad) 0263- D0 2E BNE $0293 0265- BD 8D C0 LDA $C08D,X 0268- A0 10 LDY #$10 026A- 24 06 BIT $06 026C- BD 8C C0 LDA $C08C,X 026F- 10 FB BPL $026C 0271- 88 DEY ; reboots (bad) 0272- F0 1F BEQ $0293 0274- C9 EE CMP #$EE 0276- D0 F4 BNE $026C ; check for nibble sequence stored ; in reverse order at $2C7 0278- A0 07 LDY #$07 027A- BD 8C C0 LDA $C08C,X 027D- 10 FB BPL $027A 027F- D1 48 CMP ($48),Y 0281- D0 10 BNE $0293 0283- 88 DEY 0284- 10 F4 BPL $027A ; if we made it this far, the nibble ; check passed 0286- A9 80 LDA #$80 0288- 8D 4E 9E STA $9E4E 028B- A9 A1 LDA #$A1 028D- 8D 4F 9E STA $9E4F 0290- 4C 4D 9E JMP $9E4D That last section at $0286..$0290 is interesting. After the nibble check passes, it replaces two bytes at $9E4E and $9E4F, then immediately jumps to $9E4D. That implies that this nibble check is called via an unconditional jump, not a JSR. With the Copy ][+ sector editor, I searched the disk for "4C 0C 02" and found one reference on track 00, sector 0B, byte $4D. I wonder if I can just change those two bytes to bypass the nibble check altogether and turn this into a working copy: T00,S0B,$4E: change $0C to $80 T00,S0B,$4F: change $02 to $A1 Success! The game boots and runs with no complaint. There doesn't appear to be any further protection once DOS is loaded. Quod erat liberandum. --------------------------------------- A 4am crack No. 76 ------------------EOF------------------