--------------Microzine 23------------- A 4am crack 2014-09-30 -------------------. updated 2015-09-06 |___________________ "Microzine" was an educational disk- based magazine published by Scholastic between 1983 and 1992. Issue no. 23 features "Escape from ANTcatraz" and "Monitor Mystery: The Case of the Foul Play." COPYA copies both sides, but the copy does not work. It loads DOS, displays a prompt, runs a boot program, then reboots. Attempts to break (Ctrl-C, Ctrl-Reset) with the program in memory also reboot. In my experience, computers do not spontaneously reboot unless someone tells them to. According to Copy ][+, the boot program on this disk is a binary file called "TOC.1" that is loaded at $9000. ("CHANGE BOOT PROGRAM" will show the current boot program, even if you don't want to change it. "CATALOG DISK" -> "W/ FILE LENGTHS" will show the start address of each file.) [S6,D1=non-working copy] [S5,D1=DOS 3.3 master disk] ]PR#5 ... ]BLOAD TOC.1,S6,D1 ]CALL -151 *9000L ; get address of RWTS parameter table 9000- 20 E3 03 JSR $03E3 9003- 85 FB STA $FB 9005- 84 FA STY $FA ; hmm 9007- A9 C5 LDA #$C5 9009- 48 PHA ; set up RWTS parameters 900A- A9 00 LDA #$00 900C- 85 FC STA $FC 900E- A2 03 LDX #$03 9010- BC 49 90 LDY $9049,X 9013- 91 FA STA ($FA),Y 9015- CA DEX 9016- 10 F8 BPL $9010 9018- 8A TXA ; hmm 9019- 48 PHA At this point, we've pushed two bytes on the stack -- $C5 and $FF. In other words, an RTS right now would pop those values off the stack, add 1, and "return" to... $C600. Which reboots. There is absolutely no reason for legitimate code to do this. 901A- 20 3C 90 JSR $903C *903CL ; call the RWTS (most likely just to ; move the drive head to the proper ; position for an impending nibble ; check) 903C- 20 E3 03 JSR $03E3 903F- 20 D9 03 JSR $03D9 9042- A9 00 LDA #$00 9044- 85 48 STA $48 ; if that fails, off to The Badlands 9046- B0 5D BCS $90A5 9048- 60 RTS Caller was $901A, so resuming at $901D: *901DL ; get the slot number (x16) from the ; RWTS parameter table and put it in X 901D- A0 01 LDY #$01 901F- B1 FA LDA ($FA),Y 9021- AA TAX ; don't know what this does yet 9022- 20 58 90 JSR $9058 *9058L ; turning on the drive motor manually ; is always suspicious 9058- BD 89 C0 LDA $C089,X 905B- A9 56 LDA #$56 905D- 85 FD STA $FD 905F- A9 08 LDA #$08 9061- C6 FC DEC $FC 9063- D0 04 BNE $9069 9065- C6 FD DEC $FD ; if this counter hits zero, jump to ; The Badlands 9067- F0 3C BEQ $90A5 ; look for a nibble 9069- BC 8C C0 LDY $C08C,X 906C- 10 FB BPL $9069 906E- C0 FB CPY #$FB 9070- D0 ED BNE $905F 9072- F0 00 BEQ $9074 ; kill a few cycles (not pointless, ; because the disk spins independently ; of the CPU, so all of these low-level ; disk reads are highly time-sensitive) 9074- EA NOP 9075- EA NOP ; read data latch (note: no BPL loop ; here, we're just reading it once) 9076- BC 8C C0 LDY $C08C,X ; do a compare to set or clear the ; carry bit (among other things, but ; it's the carry bit we care about) 9079- C0 08 CPY #$08 ; rotate the carry into the low bit of ; the accumulator 907B- 2A ROL ; if we just rolled a "1" bit out of ; the high bit of the accumulator, take ; this branch 907C- B0 0B BCS $9089 ; next nibble needs to be $FF 907E- BC 8C C0 LDY $C08C,X 9081- 10 FB BPL $907E ; ...otherwise we start over 9083- C0 FF CPY #$FF 9085- D0 D8 BNE $905F ; loop back to get next nibble 9087- F0 EB BEQ $9074 ; execution continues here (from $907C) ; get another nibble 9089- BC 8C C0 LDY $C08C,X 908C- 10 FB BPL $9089 ; stash it in zero page 908E- 84 FC STY $FC ; if the accumulator is anything but ; %00001010, start over 9090- C9 0A CMP #$0A 9092- D0 CB BNE $905F I got lost several times trying to follow this routine. I think the easiest way to explain it is to show the difference between the original disk and my non-working copy. Here is the original disk, as seen by the Copy II+ nibble editor. Nibbles with extra "0" bits (timing bits) after them are displayed in inverse on an original machine, marked here with a "+" after the nibble. --v-- COPY ][ PLUS BIT COPY PROGRAM 8.4 (C) 1982-9 CENTRAL POINT SOFTWARE, INC. --------------------------------------- TRACK: START: 1B1E LENGTH: 17C1 1C70: 9F EB E5 FC D7 D7 D7 EE VIEW 1C78: FA E6 E6 FF FE F2 ED FD 1C80: FF EF ED BA BB DD AF E6 1C88: B7 A7 CB B7 DE AA EB FF 1C90: FF FF FF FB+FF FF+FF FF+ 1C98: FD FF+FF+FF+FF+FF+FF+FF+ 1CA0: FF+FF+D5 AA 96 AA AB AA 1CA8: AA AA AB AA AA DE AA EB+ 1CB0: FF+FF+FF+FF+FF+FF D5 AA --------------------------------------- A TO ANALYZE DATA ESC TO QUIT ? FOR HELP SCREEN / CHANGE PARMS Q FOR NEXT TRACK SPACE TO RE-READ --^-- It's easy to understand why a simple sector copy failed. The sequence that this code is looking for starts at offset $1C93, which is between the end of one sector and the beginning of the next. (The data epilogue is at $1C8C; the next address prologue is at $1CA2.) Sector copiers discard everything between those delimiters and rebuild the track with a default pattern of sync bytes. That pattern doesn't include an $FB nibble, so the nibble check fails. But the EDD bit copy also failed. Here is the original disk's pattern at offset $1C93: - $FB + timing bit - $FF - $FF + timing bit - $FF - $FF + timing bit And here is what the same part of the track looks like on my failed EDD copy: --v-- COPY ][ PLUS BIT COPY PROGRAM 8.4 (C) 1982-9 CENTRAL POINT SOFTWARE, INC. --------------------------------------- TRACK: START: 1B1E LENGTH: 17C1 1C70: 9F EB E5 FC D7 D7 D7 EE VIEW 1C78: FA E6 E6 FF FE F2 ED FD 1C80: FF EF ED BA BB DD AF E6 1C88: B7 A7 CB B7 DE AA EB FF 1C90: FF FF FF FB+FF FF FF+FF+ 1C98: FD FF+FF+FF+FF+FF+FF+FF+ 1CA0: FF+FF+D5 AA 96 AA AB AA 1CA8: AA AA AB AA AA DE AA EB+ 1CB0: FF+FF+FF+FF+FF+FF D5 AA --------------------------------------- A TO ANALYZE DATA ESC TO QUIT ? FOR HELP SCREEN / CHANGE PARMS Q FOR NEXT TRACK SPACE TO RE-READ --^-- A subtle difference! The sequence at offset $1C93 now looks like this: - $FB + timing bit - $FF - $FF - $FF + timing bit - $FF + timing bit This code is looking for $FF bytes with an alternating pattern of timing bit, no timing bit, timing bit, no timing bit. It doesn't find that on the bit copy, so it knows it's not running on an original disk. Continuing the code listing... ; get a nibble 9094- BD 8C C0 LDA $C08C,X 9097- 10 FB BPL $9094 ; more bit twiddling 9099- 38 SEC 909A- 2A ROL ; AND it with the previously stashed ; nibble 909B- 25 FC AND $FC 909D- 49 FF EOR #$FF ; branch to failure path 909F- D0 04 BNE $90A5 ; success path falls through to here -- ; turn off the drive motor and ; (eventually) return to the caller 90A1- DD 88 C0 CMP $C088,X 90A4- 60 RTS ; failure path (a.k.a. "The Badlands", ; from which there is no return) 90A5- A8 TAY 90A6- DD 88 C0 CMP $C088,X ; manually pop the return address of ; the immediate caller (which leaves ; the manually pushed $C5FF address on ; the top of the stack to "return" to) 90A9- 68 PLA 90AA- 68 PLA ; destroy all trace of this program in ; memory 90AB- 99 00 90 STA $9000,Y 90AE- C8 INY 90AF- C0 8B CPY #$8B 90B1- D0 F8 BNE $90AB ; "return" to $C5FF+1, i.e. reboot 90B3- 60 RTS That explains the behavior I saw on my non-working copy. Meanwhile, the success path returns to the real caller and continues execution at $9025: ; pop the bogus return value ($C5FF) ; off the stack 9025- 68 PLA 9026- 68 PLA ; Route a series of bytes through the ; DOS output vector at ($36). This is ; how binary files "execute" DOS 3.3 ; commands, like PRINT CHR$(4)"..." in ; Applesoft BASIC. This is totally ; legitimate code, cleverly disguised ; as an infinite loop. 9027- A0 00 LDY #$00 9029- 84 FE STY $FE 902B- B9 4D 90 LDA $904D,Y 902E- 09 80 ORA #$80 9030- 20 39 90 JSR $9039 9033- A4 FE LDY $FE 9035- C8 INY 9036- 4C 29 90 JMP $9029 9039- 6C 36 00 JMP ($0036) Let's see what it's printing. *904D.9057 904D- 04 52 55 9050- 4E 48 45 4C 4C 4F 0D 00 *FC58G N 400<904D.9057M DRUN HELLOM@ Aha! It's not an infinite loop after all. Well, it is, technically, but it won't actually run forever. It's not easy to show in plain text, but the initial "D" and the final "M@" are in inverse. So that string starts with Ctrl-D and ends with Ctrl-M and a null byte. Since DOS is already loaded, printing this through the DOS vector will execute that command, as if you typed it from a prompt yourself. Since that program never returns to the caller, it will break out of the seemingly "infinite" loop. Since there are no side effects to the copy protection routine, I can change this file to simply skip over it and go straight to running the real startup program. Using my trusty Disk Fixer sector editor, I press "D" to enter directory mode, select "TOC.1", and I find this code on T0A,S0E. T0A,S0E,$04 change "20 E3 03" to "4C 27 90" Quod erat liberandum. ~ Changelog 2015-09-06 - Vastly improved explanation of the actual protection routine. Thanks to qkumba for pointing out that my original explanation was inaccurate. 2014-09-30 - initial release --------------------------------------- A 4am crack No. 152 ------------------EOF------------------