An excerpt from a cracker's handbook:
(Note: This page aims at providing information on cracking just for knowledge sake and all text on this page is pure information and does not have any methodical description on how exactly to go about the whole cracking process)

*Start excerpt*

You might be wondering what type of programming skills you need to become a cracker. Knowing a higher level language such as Basic, Pascal, or C++ will help you somewhat in that you will have an understanding of what's involved in the process of writing a program and how certain aspects of a program function. If you don't have any programming skills at all, you have a long road ahead of you. But even if you can program in a high level language, in order to crack you have to know assembly...

It really doesn't matter what language a program was written in order to crack it, because all programs do the same thing. And that is issue commands to the microprocessor. And all programs when broken down to their simplest form are nothing more than a collection of 80XXX instructions and program specific data. This is the level of assembly language. In assembly you have total control of the system. This is also the level that the debugger operates at.

You don't have to become a master at assembly to crack a program, but it helps. You do need to learn some rudimentary principles, and you absolutely have to become familiar with the registers of the cpu and how the 8088 instruction set uses them. There is no way around this.

How proficient you are at assembly will determine how good of a cracker you become. You can get by on learning a few basic instructions, how to use a debugger, and one or two simple techniques. This will allow you to remove a few shareware nag screens, and maybe you'll luck out and remove the copy
protection from a game or two, but that's it.

As soon as a programmer throws some anti-debugging code into a program or starts re-vectoring interrupts, you'll be whining for someone to post a crack for this or that... And you can forget about ever learning to crack windows programs.

It's much much easier to learn to crack in DOS than windows. DOS is the easiest environment to debug in. This guide will focus on DOS programs as cracking windows apps is a little bit overwhelming unless you are already an experienced cracker. And if you are, your wasting your time by reading this. This manual is geared towards the raw beginner who has no clue as to where to start and needs a little hand holding in order to get going.

There are several good beginners manuals out there, but most of them assume a person has at least some experience in cracking or knows how to use the different tools of the cracker, and the raw beginner usually becomes frustrated with them very quickly because they don't understand the concepts
contained in them.

Now in case your not familiar with the debugger and disk editor and what their different roles in cracking are, I'll give a brief explanation of each. As these are the crackers most used tools.

The debugger is what you will use to actually crack the program. When you load a program you wish to crack into the debugger, it will load the program and stop at the first instruction to be executed within the code segment. Or, you can also optionally break into an already running program and it will halt the program at the instruction you broke into it at and await further input from you. At this point, you are in control of the program.

You can then dynamically interact with the program and run it one line of code at a time, and see exactly what the program is doing in real time as each line of code is executed. You will also be able to re-assemble instructions (in memory only), edit the contents of memory locations, manipulate the cpu's registers, and see the effects your modifications have on the program as it's running. This is also where all your system crashes will occur... There is a lot of trial and error involved in cracking.

As stated above, the debugger will only modify the program while it's up and running in memory. In order to make permanent changes, you need to load the program file to be patched into the disk editor and permanently write the changes you've made to disk.

So, with this in mind, you need a few essential tools... As you get better, you'll have to write programs that will implement your patches if you decide to distribute them. The patches themselves don't have to be written in assembly.

*End excerpt*