My earliest memory defeating copy protection went like this: typical for games of my system in those days, programs were loaded from tape, and often consisted of a small stub program in BASIC to do loading/protection, followed by raw assembly loaded directly into memory .. if you tried to break out of the game and return to the BASIC interpreter, the stub loader would trap the break and issue a "NEW" command, 'wiping' the program from memory.<p>Well, someone figured out that all the NEW command did was set a single byte to #400, which was the top of usable memory or something, and then the interpreter would see .. nothing. So we wrote an "OLD" command that simply replaced that value with maximum memory avialable - and voila, program loaded again! I'll never forget the joy of typing in that 10-line OLD command, loading up a protected game, breaking into BASIC, seeing that the game had been 'wiped', then typing 'OLD' to get it all back again .. so I could save it to tape again. That moment sent me off on a wonderful journey that is still not over, 30 years later .. I think copy protection is responsible for motivating more software development by hackers over the decades than, perhaps, any other aspect ..
Wow, that brought back some memories. I used a darkStar SYSTEMS Snapshot board on my II+ to copy the contents of a program running in RAM to disk so I could then use assembler to edit out the copy protection. While my original Snapshot board is long lost, I still have the IIe version. I believe this would qualify as a hacking unicorn:<p><a href="http://defaultstore.com/copycat.png" rel="nofollow">http://defaultstore.com/copycat.png</a>
The later protections were very interesting also.<p>The Apple II disk drives featured head movement that was operated by programmed I/O. For increments of a stepper motor were required to go from one track to another. This made it possible to write data in quarter track increments, giving rise to one copy protection scheme.<p>A conventional track-by-track disk copy program would not correctly copy data written in a spiral pattern using quarter track increments.<p>There were also schemes whereby tracks were written at a different speed. The logic-state-sequencer state machine for shifting bits from the head would still read the data correctly, but the program could tell a copy made at a conventional speed from the genuine article, due to the different size and content of the gap.<p>Programs that did this sort of thing would tend to have to be cracked by removing all the checks, and replacing their disk loading routines with conventional ones that read ordinary tracks that are copyable with any disk copying utility.
Not mentioned was the A2FS1 Flight Simulator Game, I still remember hacking it to make a tape copy.<p>1st stage loader was easy, but when I started the game from the tape copy it just printed:<p>"Stolen aircraft!"
"Stolen aircraft!"
etc.<p>Much later and after some Jolt Colas I got it running on the copy :-)