Syncr0l0k
Description by LordCrass
(from C64 Preservation Project)
This awful little protection writes to the disk. It writes to t/s 19/02 and that must succeed or it tries over and over. Then it tries writing to t/s 20/02. This must fail or it tries over and over again. The protection seems to be based on physically damaged sectors that need to return errors when attempts are made to write to them. I tried erasing the sector header for 20/02 to see if it would fool the protection, but it doesn't work. The protection checks that some of the sector was written (first 6 bytes at the minimum must match). After it writes to track 20, it reads it back to verify it. The data it writes is a pseudo-random byte taken from the timer, so it's different each time you load the game. When it reads it back, at least 6 bytes must match what it thinks it wrote, but the whole sector cannot match. If it does: protection failed. Unless someone can think of a way to damage the sector in an image to the extent that a U2 write command will only partially work, this won't function in an emulator. And unless you can physically damage a real disk at the right spot, this won't work remastered either. On the other hand, it's an easy crack to remove the protection check entirely. There's only one little method used to hide it (check $179F in the main program for the self-modifying code that hides the protection check at $17A2).
Additional Information from Atari 8 Bit Preservation Forum
(Iljor):
I contacted the author, Yves Lempereur and I asked him about the protection: We used a drill :stuck_out_tongue: Basically, my idea was to cause a random defect on the disk by damaging/removing the magnetic material on the surface (a very thin layer) somehow. I then wrote a scanner that would format and scan the disk to discover which sector(s) were affected. At the end of the scan, it would write the game data on the disk, skipping over the affected area(s), then write the address of the center of the affected area in a specific spot on the disk (near the edge, away from the damage). At boot time, the loader would read the address and attempt to read/write in that area. If successful, the load would abort. If it failed, the load would continue and launch the game. I tried a few different ways of causing a spot damage on the disk, and settled on a small Dremel drill attached to a stand with an arm to lower the drill. The idea was to put the floppy “window” under the drill and carefully lower the drill to just remove the surface material, making a little damaged dot the size of the drill bit (which was very small). During production, I later discovered that the job had been handed to an intern who was doing serious damage to the disks. It didn’t prevent the copy protection from working, but I had concerns that the damage to the surface could itself damage the head of the drives used to load the game. We had … a talk. Yves
