Well, it's complicated, but for the sake of not being a how to document (there are plenty of those out on the net already) and for the sake of brevity I will outline the basic concepts and steps which one would have to understand and follow in order to break the copy protection of most computer programs. Ok, here we go:

Firstly, one must understand how a particular program chooses to protect itself from piracy. There are many different schemes and most are dependent upon the type of delivery system used to get the software from the developer to the end user. For example, CD-ROM based programs often uses a cd check to determine if the user has the proper authorization (ie: has bought an original game CD) to run said program. Downloaded programs have a harder go at this because they never existed on a physical medium and therefore all checks must be done in memory. These programs often rely upon serial numbers and more recently companies have begun adopting Internet registration programs, which allow companies through hard encryption to identify single copies of their computer programs and verify that they are original and legitimate. During the analyzation process, a cracker may observe the various ways that the developers have enacted their copy protection, ie: what dialogue boxes are presented when copy protection begins, when the protection checks do begin, what consequences these checks have (time trials, etc). All of this information can become valuable later.

Ok, so, by this point, a cracker has an idea of what method of protection a program is using and how it enacts that protection. Well, here comes the tricky bit. A cracker will now enlist the aid of another program such as SoftIce and do what is called real time debugging. This process involves stopping all executions running through the processor and displaying the current state of the hardware (which is visualized by Assembly Language} as a frozen list of instructions. By stopping the processing at a certain point, the cracker can then do what is called stepwise debugging to step through the program one line of assembly at a time. To give the layman an idea of how much assembly a processor chews through, well, every operations that a processor handles is one assembly instruction, so, think of it as the clockspeed of your processor or some such number (an actual estimate would be difficult to calculate and I am not the most educated as to the subject). Now the cracker will isolate the part of the program which enables the copy protections and do the actual cracking. This is accomplished in many ways, but it often breaks down to something like this: the computer program expects one of two states, either the copy protection tests true or it tests false. If a cracker can track down where this test is evaluated, all other parts of the copy protection become negligible. Think about it like this, if you ask me whether I stole some apples from you, and I always say no, regardless of whether I did or not, and you always believe me, I will never get caught for stealing your apples (I swear, I was just feeding my starving family). Other solutions including reverse engineering the algorithm used to verify serial numbers so that a key generation program or keygen can be written and distributed.

For the hobbyist or personal cracker, the job was finished with the last step, the program's protection is bypassed and is running. He will, however, have to perform the same operation every time the program is run in order to continue to bypass the protection because the changes he made are entirely in memory and have no effect on the actual executable on the disk. So, the last part of the cracking process involves writing a small program to either patch the executable, patch the memory address(es) where the checks will be performed or to write a key generation program. These pursuits are often only undertaken by members of cracking groups such as Razor 1911 or Fairlight because unless one wants to share with one's friends these things are kind of a hassle to write.