About copy protections.
There's nothing wrong with discussing cracking, reverse engineering or programming techniques AFAIK 
In fact, it's not even illegal to crack or reverse engineer a software product. The illegality is in distributing this cracked version.
Xelasoft's fastcopy was also able to clone disk-tracks containing errors (that's the 'security' of the disk.. the soft checks for bad-tracks)
I know this, but what about those more advanced protections (like in FireHawk or in Sunrice games) The idea behind was, that there was another sector with same number on the other side of the track so, that read error was not generated. For example, if you take FireHawk disk and read sector 9 you eiher get FIREHAWK text or a copyrigt message. I think, that fastcopy could not copy these, but Amiga's X-COPY could, am I wrong?
ARC was cracked by Dynamic Duo, IIRC.
The dongle contained the music replayer, which CAS released earlier on disk for a promo.. So Erik (Dynamic Duo) was clever enough to rip that replayer and insert it into the original. or atleast he told me
Nice to know. It sounds like very nice protection. Cas was definately a MSX genious.
~NYYRIKKI
In my MSX time, I made some copy protections for the games Teachers Terror and Bet Your Life. These were never advanced and any person that was clever enough to detect until which track the disk was formated, could make a copy using Xela-Soft's Fast Copy.
Hey, HEGEGA also needed to duplicate simply!
Furtermore, for Teachers Terror the error check routine was very simple. It used the BASIC error hook to detect that BDOS made an error by reading a sector in the unformatted area of the disk. If no error was detected, the loader stalled (loop: jp loop).
It was coded the evening before Tilburg 1993 and it took us quite some time to realize that the BASIC error hook switches the BASIC ROM back at #4000. And we needed RAM there .
We almost took the decision to release the game without copy protection... 
For the game Bet Your Life, we used the same trick but now used PHY_IO (#0144) and checked the carry flag. To give crackers a hard time, the loader code that did the check was encoded via a self writted Huffman coder. The only weakness was that somewhere in the code, there was a call to the decoded code. In fact, this was done deliberately, because I had always kept in mind that maybe someday an unprotected version was necessary. Because the game files were written in sectors at fixed locations, changing a file was a hell of a job. So when the MCCM CD-Roms needed diskimages without protection, I used a simple disassembler and removed the call instruction (check the disk image at this site) 
Another thing about copy protection... It didn't matter how much time you spend on creating an interesting scheme... If the Amiga couldn't copy it, there was always some Spanish cracker that could provide an unprotected version 
"Perfect" (there is no one) copy protection is very hard to make.
One basic thing is, that your code is very hard to crack, if cracker can't find it. Put the code somewhere, where people are not looking. Hide it between graphic routines or something like that. Also if you call a known addresses calculate the address on the fly like adding two numbers together, push the address and make RET. Also when you want to hang a computer, don't do JR $ or DI & HALT type of code. That is very easy to locate. You can do that as well by calculating.
You can anyway run, but you can't hide, if someone can hook your protection check... If you use #0144 it is easy to crack via hook in #FFA7. Best way is to switch manually disk ROM on and use #4010. You may still get it hooked via #FFCF but for example other emulators than NLMSX do not execute this hook AFAIK and the details you get differs between different MSX disk ROMs. In worst case cracker may hook even BIOS slot switch routines. You may anyway write a routine that checks the known hooks before you execute DISK I/O. Then again, someone may fake a whole disk ROM. In general... using standard DISK I/O makes your protection vulnerable, but there is no way to get around it without loosing compatibility.
Even if you have scrambled the code and you use decoder to make your code safe, you are safe just untill you get hooked. One way to try to get away is to generate DISK I/O routine on the fly and destroy the generator code before you execute disk check. To make this usefull, you still need to have some randomness on the generator. (For example low byte of execute address) This makes it even harder.
When it comes to the decoder, you should make it so, that it can not be used without running the crypted code. Otherway people just copy your code and execute it from another address. Ok, this may sound impossible, but actually you can see this kind of code in the FDDEMU, that I wrote in 1998. If you try to rip the decoder and open the code with it, the result will be just mess. To get the code open, you need to write the decoder again using a different method.
The idea behind was, that the decoder first confirmed the location in the memory, where it was loaded. Then it set the stack pointer far after the end of the decode routine and then decoded the data using it self as a key. To make it impossible to call this routine outside I made it so, that it pushed the decoded data to the stack in a loop untill stack pointer reached the decoder routine and broke the loop inside. This means, that the data was originally coded to file actually backwards.
If this sounds like science fiction, then go and decode the FDDEMU
Actually I wrote this routine because FDDEMU was able to handle normal as well as these weird kind of copy protections like used in FireHawk and I didn't want anybody to see, how to get around these "problems". The version that really used this feature actually newer came out as I could not get it working with all the games (If I remember right Enigma gave me some problems) and examine of the disk and ripping it to HD actually took about 45min / disk using standard disk I/O. 
The support for this is anyway still coded inside and can be activated by placeing certain kind of DSK_name.ERR file to the same directory as the DSK file.
~NYYRIKKI
I'll reveal a nice story about copyprotection: Bozo's Big Adventure had besides a very effective copy-protection also the name of the buyer encrypted on the disk. Besides the creators (Cain, which is 50% me) only the Sunrise distributors of that time (1991) knew about this. Every single disk that was sold was patched with this encryption just before we put the game in the buyers' hands or in the enveloppe to be sent. The copyprotection was amazingly good aswell, there are only a few copy programs that can copy it. And then you still have your name encrypted on the disk. We collected a lot of pirated copies and decrypted them. Turned out a lot of our "friends" back then, didn't seem to think it would be a problem to copy their disk for a friend. I'll ask Bard for the decrypt disk, I wonder who's name is in the version we host
We never used copy protections because they did not stop anyone to copy the software anyway. Also copy protections made it impossible to put the software on harddisk.
We simply asked the buyer to give us his/hers name and address and we give that address a code. This code was put on the disk twice and we put random data on the disk so you couldn't find the code by comparing two original disks. More or less the same system as used at Bart's example above.
One of the 2 codes was acually checked and so if the cracked would find that protection he would never find the second version of this code. This way would could always be able to find out who copied the software.
But what if we did find out who copied the software? We were not able to sew them or something. You made to little money to actually do something against this and talking to those people did not change anything, nor were you compesated for your loss.
Some people made more effort in creating a copy protection than they put into the software itself