Quote - The reverse is not decrypting, is to follow the algorithm in the reverse direction..

This is not always easily done.

For example, if the algorithm for checking a serial number S is to compute some hash d of S and use d to decrypt some other block of data E to a known block M, generating a serial is going to be a rather difficult problem if you don't know d.  In particular, attempting to solve the equation  Ed º M (mod n) for d where E, M, and n are known (and n is extremely large) is an extremely difficult problem.

The trick is that the serial has to hash to a certain integer d - but the program doesn't actually have that number, so no amount of reverse engineering is going to reveal it.  The resulting hash is known to be correct only when it correctly solves a particular equation.

This can be taken one step further, and once the has is verified to be correct, it is then used to decrypt a block of code needed for the installation to continue; this way, disassembling the program and finding the code that checks the serial number and changing it to bypass this check won't work because you will be missing an essential piece of code.

Of course, nothing is ever perfect.  It literally is a game of cat and mouse, with the software developers having to constantly develop new and novel ways of protecting their software from piracy, and the crackers are constantly finding ways of defeating new protection schemes.