--------------Microzine 13------------- A 4am crack 2014-09-22 --------------------------------------- "Microzine" was an educational disk- based magazine published by Scholastic between 1983 and 1992. Issue no. 13 is a double-sided disk that features "The Frog and the Fables" and "The Secret of the Sphinx." [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 - "Pitstop II" by Epyx - "Microzine 12" by Scholastic Somebody been sellin' copy protection. Anyway, this write-up is quite similar to those, except that my AUTOTRACE program has gotten smarter over time, so more of the process is automated.] 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 boot program (like "HELLO"). 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 Disk Fixer sector editor, I press "O" to get to the Input/Output Control and set "CHECKSUM ENABLED" to "NO". This will ignore the checksum bytes and epilogue sequences. i.e. 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 disk 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. 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, side A] [S5,D1=my work disk] ]PR#5 ... CAPTURING BOOT0 ...reboots slot 6... ...reboots slot 5... SAVING BOOT0 /!\ BOOT0 JUMPS TO $08C0 CAPTURING BOOT1 ...reboots slot 6... ...reboots slot 5... SAVING BOOT1 SAVING RWTS /!\ NIBBLE CHECK AT $BB00 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, this 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 acalled "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"), there's a good chance I'll be able to use a tool called Advanced Demuffin (written in 1983 by The Stack) to convert the disk from whatever weird format it uses to store its sector data into a standard disk readable by unprotected DOS 3.3 disks or any other third-party tools. In this case, 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". If anything looks fishy or non- standard, AUTOTRACE just stops, and I have to check the files it saved so far to determine why. But in this case, it ran all the way through, automatically capturing BOOT0, BOOT1, and RWTS files. Now I can use Advanced Demuffin to convert the disk to a standard format. (It uses the disk's own RWTS to read the original, then a standard DOS 3.3- compatible RWTS to write out the data, sector by sector.) Along the way, AUTOTRACE gave me two different warnings, which is very exciting(*). I just added the warnings recently, and here I am already reaping the benefits. (*)not guaranteed, excitement may vary Let's see what the first one is about. /!\ BOOT0 JUMPS TO $08C0 ]BLOAD BOOT0,A$800 ]CALL -151 *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) I've seen this pattern before on other disks -- "Gertrude's Secrets" and "Xevious", just to name two. It usually means that some code at $B700 will be calling a subroutine that I don't particularly want it to call (like a nibble check). The second warning provides additional evidence of this: /!\ NIBBLE CHECK AT $BB00 I'll deal with that later. Right now I want to focus on converting this disk to a standard format. I have the RWTS and can load it into Advanced Demuffin. [S6,D1=original disk, side A] [S6,D2=blank disk] [S5,D1=my work disk] ]PR#5 ... ]BRUN ADVANCED DEMUFFIN 1.5 [press "5" to switch to slot 5] [press "R" to load a new RWTS module] --> At $B8, load "RWTS" from drive 1 [press "6" to switch to slot 6] [press "C" to 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 unless something goes horribly wrong. --v-- ADVANCED DEMUFFIN 1.5 (C) 1983, 2014 ORIGINAL BY THE STACK UPDATES BY 4AM =======PRESS ANY KEY TO CONTINUE======= TRK:................................... +.5: 0123456789ABCDEF0123456789ABCDEF012 SC0:................................... SC1:................................... SC2:................................... SC3:................................... SC4:................................... SC5:................................... 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 no read errors on any track. (I repeated the procedure on side B, also with no errors.) 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... ]PR#5 ... ]CATALOG,S6,D2 C1983 DSR^C#254 012 FREE A 004 MICROZINE SIDE 1 A 005 HELLO A 024 TABLE OF CONTENTS A 021 INTRO A 070 FABLES A 023 UTILITIES A 007 CREDITS A 006 LOAD PIC B 008 MZINE1.PAC B 008 MZINE2.PAC B 015 INTRO.SPC B 004 UTILITIES.SPC B 002 CLEAR.OBJ B 003 DRAWTC.OBJ B 004 INIT.OBJ B 002 PACK.OBJ B 012 LITTLE APEX B 002 MAP B 014 PICDRAWH B 003 TPINDEX B 008 ST.FABLES0 B 002 ST.TIME B 002 ARTIST.TXT B 003 BEAR.TXT B 002 BOOKCASE.TXT B 002 BUSH.TXT B 003 CARPENTER.TXT B 002 CHAIR.TXT B 002 CHEF.TXT B 003 CROW.TXT B 002 CURTAINS.TXT B 002 DOG.TXT B 003 DONKEY.TXT B 002 FLOWERS.TXT B 002 FROG.TXT B 002 HARE.TXT B 003 HEARTH.TXT B 002 JESTER.TXT B 002 KING.TXT B 002 LADY.TXT B 002 LAKE.TXT B 003 LORD.TXT B 002 PICTURE.TXT B 002 READER.TXT B 003 SCRIBE.TXT B 002 SHIELD.TXT B 002 SIGN.TXT B 002 STOOL.TXT B 002 STUMP.TXT B 003 SUN.TXT B 002 TABLE.TXT B 002 TREES.TXT B 002 YOU.TXT B 003 WIZARD.TXT T 021 CLUES T 006 MORALS T 002 MZ.PARAMETER FILE T 002 SIDE T 093 TWISTAPLOT FILE T 006 VERSION A 023 BACK PAGE B 007 TOON1.SPC B 007 TOON2.SPC B 006 TOON3.SPC B 006 TOON4.SPC ]RUN HELLO The disk boots and runs without complaint. This tells me that there isn't any coordination with or reliance on the custom DOS once the program loads. (Some programs manually check for specific non-standard values in the DOS area in memory. But I don't see any evidence of that here.) Let's back up and take a look at that nibble check. ]PR#5 ... ]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