RapidLok1 Notes v1.0
(C) 2007-2011 BanGuiBob .o ooooo o888 ooooooooo. `888' 888 Welcome to this RapidLok1 notes. `888 `Y88. 888 888 RapidLok is a copy protection for 888 .d88' 888 888 diskette games on the Commodore C64 888ooo88P' 888 888 back in the 1980s and early 1990s. 888`88b. 888 o o888o There exist several versions of 888 `88b. o888ooooood8 RapidLok, counted from v1 to v7. o888o o888o You will find here a list of known RapidLok1 protected software titles and how to get the protected G64 images working in WinVice emulator. Keep in mind that "True drive emulation" must be enabled in WinVice when dealing with RapidLok protected G64 files. The included patches remove the whole RapidLok1 protection: the RapidLok track header integrity checks (i.e. sync lengths), track alignment, the track 36 handler, the key checks, and the track 36 key sector integrity check. There is only one exception: the off-byte check is still active -- the "12th header byte" must be the same for two successive $52 sector headers on track 18 and the value must be #$7B. Please refer to the RapidLok2 notes for details on remastering. The RapidLok6 handbook has information on how to create NIB/G64 images of original disks and structural information about tracks 1-35. PART 1: RapidLok1 patches PART 2: Software titles with RapidLok1 PART 3: Special notes on RapidLokPART 1: RapidLok1 patches
We start here with a short cut in the $0416 routine that directly calls the $0508 file transfer management ($042A-JSR). This bypasses the initial track 19 RL1 track header integrity check, the track alignment for tracks 20-29, the track 36 handler, the key checks for tracks 29-34, and the track 36 key sector integrity check. See following code snippets for the patch: --- ORIGINAL CODE #1 --------------------------- 0416: A9 03 LDA #$03 0418: 85 CA STA $CA ; [$CA]:=3, hi buffer pointer for file transfer 041A: 0A ASL A 041B: 85 BF STA $BF ; [$BF]:=6, index for storage of #7Bs 041D: A5 D6 LDA $D6 ; [$D6] set by "M-W", encrypted index into track selection record (not bit6) 041F: 49 55 EOR #$55 ; $55=0101.0101b 0421: 29 BF AND #$BF ; $BF=1011.1111b, mask out bit6 (selector bit for integrity checks & Track 36) 0423: 85 C2 STA $C2 ; [$C2]:= ([$D6] xor $55) and $BF, index into track selection record 0425: A9 0A LDA #$0A ; $0A=0000.1010b 0427: 8D 00 18 STA $1800 ; CLK=DATA=1/lo 042A: 20 88 04 JSR $0488 ; Integrity checks, read Track 36 Key Sector, run file transfer management ------------------------------------------------ --- PATCHED CODE #1 ---------------------------- 042A: 20 08 05 JSR $0508 ; Run file transfer management ------------------------------------------------ The $042A/$048E code is obviously located in the $04xx buffer which got read into memory by the $0300-B routine: Job #1, Track 18 Sector 9. This is a problem as the $0300-B routine uses the 3rd and 4th bytes from the final GCR sequence of the sector (sector parity) for decrypting [$039C-$07FF] ($0320-LDA, $0327-LDA). We have to make sure the original sector parity remains the same. We bypass the $0488 routine with the above patch, hence we can turn the $048E-BCS into a $048E-BIT correcting the sector parity with its argument: --- ORIGINAL CODE #2 --------------------------- 0488: 20 A6 06 JSR $06A6 ; Move head to Track 19 (from Track 18), set Bit rate. 048B: 20 48 04 JSR $0448 ; Check RL track header integrity, set/use [$C5]:=$32, CF:=1 if something wrong. 048E: B0 F6 BCS $0486 ; branch if error. Avoid this branch!!! ------------------------------------------------ --- PATCHED CODE #2 ---------------------------- 048E: 24 E3 BIT $E3 ; fix sector checksum / final GCR sequence ------------------------------------------------ The calculation is as follows. The 4 bytes we change ($042B/$042C/$048E/$048F) have the following "parity" (the decrypted bytes are used for this here): original: $88 xor $04 xor $B0 xor $F6 = $CA patched: $08 xor $05 xor $24 xor $.. = $29 Hence $29 xor $CA = $E3 is to be used for correcting the sector parity. Note on bypassing code: I could not find any dependencies on values of variables that were initialized or used by the bypassed code. As all RapidLok routines are encrypted on disk we have to encrypt all our patches before we apply them to the G64 images. The $0300-B routine decrypts the RapidLok code routines [$039C-$07FF]. Setting a memory breakpoint into the decryption loop (e.g.w 8:042A) reveals the original encrypted bytes,
the bytes they get decrypted (xor'ed) with, and the decrypted plain code
bytes:
--- ORIGINAL DECRYPTION ---------------------
042A = |0E D4 BD| xor |2E 5C B9| = |20 88 04|
048E = |9E AA| xor |2E 5C| = |B0 F6|
---------------------------------------------
--- MANIPULATED DECRYPTION ------------------
042A = |0E 54 BC| xor |2E 5C B9| = |20 08 05|
048E = |0A BF| xor |2E 5C| = |24 E3|
---------------------------------------------
The $042A/$048E code is obviously located in the $04xx buffer which got
read into memory by the $0300-B routine: Job #1, Track 18 Sector 9.
Applying the patches to the G64 images
I always use the Maverick v5.04 GCR Editor (in WinVice) to "edit" the G64
images. Please refer to the RL6 handbook for instructions. Never save
your modifications to disk/G64 from within the GCR Editor!
Use "UltraEdit" in hex-mode instead to apply the changes directly to the
G64 images (GCR code). The following Figure #1 shows the original Track
18 Sector 9 of a RapidLok1 G64 image, Figure #2 shows the modifications.
Figure #1: Original Track 18 Sector 9 of a RapidLok1 G64 image (disk side 1, NTSC).
Figure #2: Patched Track 18 Sector 9 ($042A/$048E patches).
The patches here allow the removal of all $7B extra sectors and all $55 empty sectors from RapidLok protected disks (including their preceding sync marks). Only the $52 DOS reference header on each RapidLok formatted track, the RapidLok $75 sector headers, $6B data sectors and the DOS format sectors ($52 headers and $55 data sectors) are required anymore. All sync marks can be set to standard 5 bytes length.