------------Gulp and Frenzy------------ A 4am crack 2016-03-01 --------------------------------------- Name: Gulp and Frenzy Genre: educational Year: 1982 Authors: William H. Kraus Publisher: Milliken Publishing Company Media: single-sided 5.25-inch floppy OS: Diversi-DOS (T02,S02 has the string "C1982 DSR" in reverse) Previous cracks: none Similar cracks: #292 The Writing Workshop #139 Tangrams Puzzler ~ Chapter 0 In Which Various Automated Tools Fail In Interesting Ways COPYA immediate read error Locksmith Fast Disk Backup can't read any track EDD 4 bit copy (no sync, no count) no read errors, but copy boots DOS then puts a "." in the top-left corner of the screen and reboots Copy ][+ nibble editor modified address and data epilogue bytes ("DF AA EB") on every track Disk Fixer ["O" -> "Input/Output Control"] set Address Epilogue to "DF AA EB" set Data Epilogue to "DF AA EB" Success! All tracks readable! ...except T02,S05 ...identical error on all disks, so probably intentional T00 -> looks like a DOS 3.3 RWTS T11 -> DOS 3.3 disk catalog T01,S09 -> startup program is "BOOT" Why didn't COPYA work? modified epilogue bytes (every track) Why didn't Locksmith FDB work? modified epilogue bytes (every track) Why didn't my EDD copy work? probably a nibble check during boot Next steps: 1. capture RWTS with AUTOTRACE 2. convert disk to standard format with Advanced Demuffin 3. find nibble check and bypass it ~ Chapter 1 In Which We Attempt To Use The Original Disk As A Weapon Against Itself [S6,D1=original disk] [S6,D2=blank disk] [S5,D1=my work disk] ]PR#5 CAPTURING BOOT0 ...reboots slot 6... ...reboots slot 5... SAVING BOOT0 CAPTURING BOOT1 ...reboots slot 6... ...reboots slot 5... SAVING BOOT1 SAVING RWTS ]BRUN ADVANCED DEMUFFIN 1.5 ["5" to switch to slot 5] ["R" to load a new RWTS module] --> At $B8, load "RWTS" from drive 1 ["6" to switch to slot 6] ["C" to convert disk] --v-- ADVANCED DEMUFFIN 1.5 (C) 1983, 2014 ORIGINAL BY THE STACK UPDATES BY 4AM =======PRESS ANY KEY TO CONTINUE======= TRK:..R................................ +.5: 0123456789ABCDEF0123456789ABCDEF012 SC0:................................... SC1:................................... SC2:................................... SC3:................................... SC4:................................... SC5:..R................................ SC6:................................... SC7:................................... SC8:................................... SC9:................................... SCA:................................... SCB:................................... SCC:................................... SCD:................................... SCE:................................... SCF:................................... ======================================= 16SC $00,$00-$22,$0F BY1.0 S6,D1->S6,D2 --^-- The disk's own RWTS gave one read error on track $02, but the rest of the disk copied without a hitch. The original disk gives no indication of a bad sector, so either this sector is unused (and I got lucky) or this is part of the copy protection. Let's see if I can launch the program from my work disk. ]PR#5 ... ]CATALOG,S6,D2 C1983 DSR^C#254 169 FREE ERROR #8 I/O ERR Wait, what? ~ Chapter 2 Hide Your Disk Catalog With This One Weird Trick! Crackers Hate It! The demuffin'd copy ought to have a catalog (I saw it on the original disk with Disk Fixer), but now it has suspiciously vanished. Turning again to my trusty Disk Fixer sector editor, I see the problem. Track $11 does have a catalog, but the pointer to the first directory sector has been intentionally corrupted. --v-- -------------- DISK EDIT -------------- TRACK $11/SECTOR $00/VOLUME $FE/BYTE$00 --------------------------------------- $00: 00 F1 0F 03 00 00 FE 00 @qOC@@~@ ^^ hey now, what's this? $08: 00 00 00 00 00 00 00 00 @@@@@@@@ $10: 00 00 00 00 00 00 00 00 @@@@@@@@ $18: 00 00 00 00 00 00 00 00 @@@@@@@@ $20: 00 00 00 00 00 00 00 7A @@@@@@@: $28: 00 00 00 00 00 00 00 00 @@@@@@@@ $30: 04 FF 00 00 23 10 00 01 D.@@#P@A $38: 00 00 00 00 00 00 00 00 @@@@@@@@ $40: 00 00 00 00 FF FF 00 00 @@@@..@@ $48: 0F FF 00 00 00 00 00 00 O.@@@@@@ $50: 00 00 00 00 00 00 00 00 @@@@@@@@ $58: 00 00 00 00 00 00 00 00 @@@@@@@@ $60: 00 00 00 00 00 00 00 00 @@@@@@@@ $68: 00 00 00 00 00 00 00 00 @@@@@@@@ $70: 00 00 00 00 00 00 00 00 @@@@@@@@ $78: 00 00 00 00 00 00 00 00 @@@@@@@@ --------------------------------------- BUFFER 0/SLOT 6/DRIVE 1/MASK OFF/NORMAL --------------------------------------- COMMAND : _ --^-- Third-party utilities can not catalog this disk or work with any of its files (every DOS file function routes through this pointer), but the original disk obviously has no problem. But how does the original disk know? I scoured "Beneath Apple DOS" until I found the answer on page 8-28: --v-- B011-B036 Read a directory sector ; (If CARRY flag is zero on entry, read first directory sector. If CARRY is one, read next) ; Memorize entry code. ; Set buffer pointers (B045). ; First or next? ; If first, get track/sector of directory sector from VTOC at offset +1,+2. ; Otherwise, get track/sector from directory sector at offset +1,+2. If track is zero, exit with error code (end of directory). ; Call RWTS to read sector. ; Exit with normal return code. --^-- So, to read the first sector of file names and other metadata, this routine is supposed to look at the VTOC sector buffer (read from T11,S00 and stored at $B3BB..$B4BA). The VTOC says "hey, the first sector of files and stuff is in TF1,S0F" so DOS goes and tries to read track $F1, sector $0F, which obviously won't work. But the DOS on this disk made one small modification to that routine. (This is stored on T01,S0F.) B011- 08 PHP B012- 20 45 B0 JSR $B045 B015- 28 PLP B016- B0 08 BCS $B020 B018- AC BD B3 LDY $B3BD ------ B01B- A2 11 LDX #$11 << hey B01D- EA NOP << now ------ B01E- D0 0A BNE $B02A B020- AE BC B4 LDX $B4BC B023- D0 02 BNE $B027 B025- 38 SEC B026- 60 RTS B027- AC BD B4 LDY $B4BD B02A- 8E 97 B3 STX $B397 B02D- 8C 98 B3 STY $B398 B030- A9 01 LDA #$01 B032- 20 52 B0 JSR $B052 B035- 18 CLC B036- 60 RTS Instead of getting the track number from the VTOC, it hard-codes track $11. Now that I've identified the problem, the fix is straightforward. If I change the VTOC header (T11,S00) to point to the actual first directory sector (T11,S0F), DOS 3.3 or any other copy utility should be able to read the entire catalog. This disk doesn't care either way, since it never looks at it. T11,S00,$01 change "F1" to "11" Now I should be able to catalog it from my work disk. ]PR#5 ... ]CATALOG,S6,D2 C1983 DSR^C#254 028 FREE *A 019 BOOT *A 021 MGR *B 024 G *B 005 O.GULP *B 028 T.GULPDATA T 065 STDTA *A 031 GULP T 002 GULP.SB *B 022 A.MATHFUN *B 019 A.GULP!! *B 021 A.MNGR A 024 MANAGER.BAS *B 033 FRENZY STUFF *A 043 FRENZY.BAS *B 002 SOUND *B 011 A.MLKN *B 005 COL.TABLE *B 019 A.FRENZY T 002 FRENZY.SB *A 029 F1 *A 002 INITSB *B 002 B.MUSIC *B 033 PIC.MLKN *B 006 FR.G ]RUN BOOT ...works... [S6,D1=copy] ]PR#6 ...grinds... My copy just grinds on boot, which tells me that the RWTS is looking for specific (non-standard) epilogue bytes and failing to find them. So I need to patch the RWTS to standardize the epilogue bytes. This happens so often that I made a tool for it. ]PR#5 ... ]BRUN PDP T00,S03,$91 change DF to DE T00,S03,$35 change DF to DE T00,S06,$AE change DF to DE T00,S02,$9E change DF to DE ]PR#6 --v-- ATTENTION! THE DISK DRIVE YOU ARE USING IS OPERATING AT AN UNSAFE SPEED. OPERATION OF THIS PROGRAM ON THIS DRIVE MAY DESTROY THE PROGRAM. PLEASE HAVE YOUR DRIVE SPEED CHECKED, OR USE ANOTHER DISK DRIVE. --^-- I am not making this up. ~ Chapter 3 In Which We Walk The Fine Line Between Bullshit and Misdirection I should note at this point that my copy is actually a disk image being managed by a CFFA3000 card. I sector- copied the disk image back to a physical floppy and booted it, and it displayed the behavior I was expecting (load DOS, print ".", then reboot -- just like my failed bit copy). Then I copied the disk image to a modern PC and ran it in two different emulators; each time, it gave me the message about the drive operating at an unsafe speed. I'm about to give up on this DOS and just blow it away and replace it with a fresh copy of DOS 3.3. I've already confirmed that the program itself loads when I boot from my work disk. But now I want to know whether this DOS is really checking the drive speed, or if that's just bullshit and misdirection. So here we go. ]PR#5 ... ]BLOAD BOOT0 ]CALL -151 *801L . . nothing unusual . *BLOAD BOOT1 *FE89G FE93G ; disconnect DOS *B600<2600.2FFFM ; move RWTS into place *B700L . . nothing unusual, until . B747- 4C 03 9B JMP $9B03 This usually jumps to $9D84, the DOS cold start vector. I don't know what's at $9B03 yet, but I can find out. *C500G ; because I overwrote DOS ... ]CALL -151 *9600