| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Fri, Jul 22nd, 2011 @ 03:04 ( . ) |
Let's go back in time to 1988, 20 odd years before nibtools was created.. this protection is actually quite clever. Copies of the game will load and let you select a pilot and mission, but the protection doesn't kick in until you try to start the game on side 2. It just keeps looking for nonexistent gcr bytes which your lame copier missed. and it will keep searching until you insert your original or you power off the machine of course. Obviously the protection is designed to catch out amatures, but a determined cracker would quickly figure out a workaround. Let's assume you are just one of these amatures instead, All you want to do is share the game with your buddy down the road. OK, so your copy of side 2 doesn't work, time to dig out your original again. After playing the game for a while, You decide to quit the game and try out a different pilot or mission, so it asks you to insert side 1 again. You wait and wait and wait and continue waiting and waiting. You dig out your original again and insert side 1. Looks like the check has been activated for both sides of the disk now. Those who dare to ring up activision and describe these symptoms may be met with a response like this. "no pay, no play." (click) Heheh. |
 | Author: | Comos (registered user: 2 posts ) |
|---|---|---|
| Date: | Thu, May 24th, 2012 @ 17:06 ( . ) |
Well, I can confirm,that a copy will boot and run okay,but flipping to side 2 and try to run will fail. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Thu, May 24th, 2012 @ 21:46 ( . ) |
Yes, you really have to hand it to activision, it's a very clever and sneaky protection, it doesn't activate the check until side 2 is flipped. Once the check is switched on however, neither your copy of side 1 or side 2 will load unless it's an original or it's been dumped with nibtools of course. |
 | Author: | LordCrass (guest: search) |
|---|---|---|
| Date: | Fri, May 25th, 2012 @ 10:56 ( . ) |
I haven't checked this game, but I have the feeling this isn't some sneaky protection check. It's likely just an issue with the disk ID bytes in the sector headers and the way the loader doesn't bother to update the ID when you change disk. Portal (also by Activision) had this same issue. If Fighter Bomber uses KeyDOS, then this is the reason for sure. |
| Author: | LordCrass (guest: search) |
|---|---|---|
| Date: | Sat, May 26th, 2012 @ 00:24 ( . ) |
Confirmed. The original disk has two spaces for the disk ID in the directory on both sides. The sectors contain $30 $31 for the disk ID bytes. When asked to change disk, the loader keeps reading track 30 sector 4, and sends the disk ID bytes back to the computer, which only checks that the second byte is now a $32. When you convert this game to a d64, you no longer have sector headers. If this info is requested by a game, the emulator will supply it based on other data. In this case, it will always give you what was in the directory track for the disk ID bytes. When writing a d64 back to disk, it will write every sector with the ID taken from the directory. Mismatched sector IDs are easily copied by any software nibbler. Another way to bypass this is to change the ID in the directory to what the loader wants. Change side 1 to "01", and side 2 to "02". With Portal, this wasn't possible as the directory sectors on side 2 were used by game code instead of valid directory info. Changing the appropriate bytes would have corrupted the game. |