To add a bit of technical “meat” to this, but without falling foul of the mods I’ll explain how cracking used to work, back in the day ™. This is on the Amiga, which is no longer in production and neither are the games. Nothing given here is detailed enough to be much help either.
Amiga games used to load in a pretty standard way. There is a 512 byte sector at the start of the disk which is the boot block. This was read by the OS, checked for some [magic numbers](Magic number (programming) - Wikipedia, in this case DOS0.
If the magic was found and the boot block checksum was good, the OS would start to execute from an offset inside the bootblock. This was raw 68000 machine code.
On a normal disk this would generally hand back to the OS and let the boot run as normal, controlled by the OS. On a game it would initialise the hardware by disabling exec and Intuition (the window based gui) to free up RAM and CPU resource and then to make it tricky to monitor further it would start messing with traps and exceptions.
The way a debugger/monitor lets you see the machine state is by setting breakpoints in memory, letting the code run to the breakpoint and then starting the monitor to see what is going on. Breakpoints use a CPU function called traps, which are illegal instructions that cause the CPU to halt and jump to a memory address provided by a vector table. The monitor would insert addresses to its own routines in the vector table then write a trap instruction to the breakpoint address. So when a trap was reached it would jump to monitor code and start running, showing you RAM, CPU registers and disassembled program code, and letting you modify them.
Obviously the first thing the protection code would do is to disable the traps, often by putting routines of its own in the vector table - routines which were crucial to executing the game. When these traps were overwritten by the monitor the game would fail and crash. If you left the trap vectors as the game set them you couldn’t start your monitor! Other variants would disable traps, or setup nasty tricks such as double-faulting.
Bear in mind all of this is just inside the first 512 byte boot sector! Finally the boot code would load more disk blocks and start to execute them. These would contain the disk loader. As the operating system (exec & Intuition) had already been kicked out, it was necessary to write your own loader.
Whilst the trap tricks were still in place, the next gotcha would normally be timers. The Amiga had a pair of CIA chips which had time-of-day timers. These would count up but also had an alarm mode. The defensive programmer would set the timers to count down from 5 seconds, alarm, loop and repeat. But whilst the monitor is running the timers would still count down. When you exit the monitor and the game code recommenced execution, it would spot that the timers had hit zero without the game code noticing. It would figure that a monitor had been run and would either crash, or subtly alter the program execution - perhaps killing you after 30 seconds of gameplay. There were a number of ways to set the timers, some very cryptic indeed, so finding and patching these was tricky.
Often thrown into the mix was encrypted code. The 68000 had a feature called Trace Vector Decoding. This used traps to decode each instruction prior to execution, often re-encrypting it afterwards. The monitor traps would often interfere with this, especially if the trace vector used the CPU control bits. Sometimes the encrypted code was self-modifying so it would change the state of future encrypted code as it ran. This meant you couldn’t just save out the RAM and try to decrypt the code manually, as it would be junk until the running code modified itself during execution.
On top of this, the game code itself was probably “packed” on the disk. Using an often unique compression algorithm the data would be loaded from disk, unpacked and then executed under the trace vector decoder.
Even with all this to contend with, most games were cracked and distributed before or shortly after the commercial releases. This was almost solely the domain of the computer geek with no commercial aspect. Whilst we now have easy access to good cryptography, client-server authentication systems and tamper proof hardware devices, it’s still a race which is impossible to win. It’s always a matter of when, not if an app will be cracked.
tim
[sub] (Seriously, that’s things a box job. We joke about it.)[/sub]