About Disk Protection
There are basically two different forms of copy protection that you could create: the disk based and manual based copy protection schemes.
With disk based schemes, software often reads from specific sectors
on a disk to determine the disk's validity. When you perform a disk format,
the disk is formatted with specific sector sizes. Once the sector size
changes, DOS cannot recognize it, thinking that it is a bad sector. Since
this looks like a bad sector, a simple DISKCOPY will not work in copying
such disks. Interrupt 13h (the assembly mnemonic
is INT 13) was commonly used to handle such copy protections. It is now
very rare to encounter the once famed INT 13h copy protection method nowadays
since it was quite easy to defeat. Any professional commercial software
(including yours) will often use their own custom based disk I/O routines.
This involves intimate access to I/O ports using IN and OUT instructions.
It is probable that the I/O functions might be called from a "CALL" instruction.
Another disk based scheme used to denote legality of software is used
during the installation process of the software. With certain programs,
when you install it, it copies the files into the hard drive. But it also
sets a specific sector in the hard drive so that the program can recognize
it. This disk-based copy protection is almost completely out of the software
industry.
However, a more difficult copy protection scheme has arisen that may sometimes prove to be even more difficult to crack. These schemes are commonly known as the doc checks in which the user must have a copy of the manual to bypass the protection. With programs compiled as true assembly (you can call them "normal" programs), these protections are not too bad to trace through. With programs that run scripts, this can he a real chore however. It is like running a program within a program.
As if these copy protection schemes weren't enough, software companies have also added trace inhibition schemes to their code. This means that it is much time consuming for someone to try and trace through your code. On the other hand if someone knows how these things work, it should not be too much of a problem for him. Run-time compression / decompression and encryption / decryption of files also make changes to the program difficult. In this case, the loader sure comes in handy. Also, when the data within the file changes due to overlays, loaders are also good to use.