According to the different copiers/patchers for this that existed are at least 7 different versions (plus variants) of this protection. There are multiple protection schemes all going on at once. Since this protection relies on exact sync lengths and contains bad GCR in the gaps, the disks seem to deteriorate quickly over the years. Many of my originals will not load any more, and the ones that do are erratic.
1) First, all tracks start with a sync mark about 320 bits long. Then, sector 0 has a sync about 480 bits long before it's header. If it isn't around this length, that track or sector won't load and you get a crash, so drive speed is an issue with this protection. All other syncs seem to be the standard 40 bits. It is very difficult to read/detect and write exact sync lengths due to drive speed differences and limitations of the 1541 hardware, but we should be able to get close enough to pass this part, which we can.
2) Each gap has bad GCR ($00) instead of the inert bytes we normally see. It has been found that these are not checked..
3) There is a key encoded on track 36. The key consists of a long sync, a series of encoded bytes, then some bad GCR. This track can be (carefully) reimaged.
4) If the key is properly loaded and decrypted from track 36, it corresponds to a table of 35 values that are the number of $7B bytes (this varies) expected to be in a special "sector" on each track.
4) It just has "time-bomb hooks" or add-ons that execute checksums, key checks, and track alignment at random times in the game to prevent patching.
Banguibob has completely documented this protection and solved all remaining mysteries.
Check it out here!
Rapidlok remains one of the few remaining protections we can't get to run without partially cracking them, unfortunately. This may change in the future, though. Whoever wrote this protection, please stand up and tell us the history, because you win. :)
All versions load a key from track 36. This boots in VICE sometimes (bitshift) and on the real thing almost always if mastered properly. The key check when loaded checks a hidden "sector" on each track and counts the number of key bytes found. You get the black screen if this fails. I can patch this part out easily and it's what the software-based Rapidlok copiers all did back in the 80's. VICE cannot "autoload" these disks, they must be loaded manually. If you remaster these disks, your drive must run at 300rpm nearly exactly, and even then they are a little flaky.
I have different mastering runs of the same games with different versions of the protections, sometimes from the same region, so keep sending them if you have them. You can convert to G64 and run them through the tools to check what RL version they are and remove the keys. (I used the old Utilities Unlimited tool, email me if you need it)
v1-v4 : Patch out keycheck and they work fine. There doesn't seem to be a sync check except for Conflict in Vietnam, which checks sync between track 34/35.
v5-v6 : Patch out key check and they "usually" load in VICE. These disks will intermittently fail the add-on protection checks, depending on the title. Reset and reload and it usually runs fine- I attribute this to the VICE drive emulation not really being at "virtual 300rpm". A few do not pass ever and I suspect they might be bad dumps or just are variants that aren't patchable by normal tools.
v7? : Patch out key check and they won't boot - need to crack further for other self-checksums.
