How were Amiga games cracked circa 1987?

Question

I remember getting my Action Replay MKIII cartridge on my A500 in 1992, and from there I could remove protections (manual/code & physical) of a lot of games.

The MKI & MKII existed before 1991 but not before 1989. Also CPUs with a vector base register and/or a MMU (2 devices that help a lot when debugging) weren't available on the Amiga. Maybe with some early software monitor?

So how were earlier games which had intricate disk-based copy protection (like King's Quest I & II, which had Herdnon copy protection) cracked? (they were using multiple self-decrypting code and monitored/used the trace vector long before Rob Northen copylock, so without a VBR you couldn't follow it, and trap breakpoints were also impossible to set)

With modern tools like WinUAE emulator, we have everything at our disposal: save states, unlimited memory watchpoints & breakpoints, "stealth" capability (not being able to influence debugged program timings or behaviour in any way) which helps tremendously (not to mention that protections can be emulated by some raw floppy formats like IPF, SCP, ...), and even with those tools sometimes the task is time consuming and non-trivial.

But at the time, with really primitive tools, how was it done?

I'm looking for accurate software and/or hardware names.

Answer 1

But at the time, with really primitive tools, how was it done?

I can only speak for myself, but I suspect it was the same for most - we just used those really primitive tools - and our brains.

All that was needed was a disk sector editor, a disassembler and possibly an assembler. You used the disk editor to read the bootblock, disassembled the code in it and figured out how it loaded the next part. To get that code you poked the bootblock so it loaded the code but didn't jump into it. Then you modified that code to just decrypt and give control back, continuing until you had all the assets in unencrypted form. If a custom track format was present you modified the loader to read the data into a safe area of memory where you could save it to a file for writing back to disk in a standard format.

In the early days (1987) I had nothing except the Amiga Hardware and ROM kernel manuals, Amiga BASIC and the MetaComCo assembler. With that I could write any other tools I needed. However public domain tools soon started to appear, such as DiskX by Steve Tibbett, and DIS - a freeware 68k disassembler by Greg Lee which was distributed on Fred Fish disks 128 and 160.

In 1989 or 1990 (not sure of the exact date because all my Amiga gear was stolen in 1991) I purchased a book by Abacus called Amiga Machine Language, which included an assembler/debugger IDE called AssemPro. Another package that I believe was popular with coders in Europe was ASM-One, which spawned several 'enhanced' versions and is still being developed today.

I also had the advantage of owning an Amiga 1000, which had 256k of 'Writable Control Store' memory that the system 'ROM' was loaded into from the Kickstart disk on power up. I modified the Kickstart disk to copy all the base memory into my 2MB RAM expansion on reset, making a snapshot of what was in memory when a game was running. I had already used a similar technique many times on my Amstrad CPC664, gaining a lot of experience at cracking games when transferring them from tape to disk.

Once you have the ability to see what is on disk and can modify it, the only other 'tool' you really need is what's between your ears. You don't have to be a genius either, just logical and persistent.

Answer 2

Same method as used on the early PC's (those with 10-20mb boat anchor hard discs), those things even hadn't a gui.

• Completely manual disk debugging. Reading in boot record, then following code with the kernel and hardware manuals at a side. Then patching functions with NOP's or RTS's.
• Running the program in a debugger, using debugger breakpoints
• Sometimes using hardware debugging breakpoints. (in some cases ejecting the disk at the right moment while loading gave a hardware breakpoint)
• Live patching of memory addresses was also commonly done in Amiga era. (the first loaders)
• Work together as a group, dialing in on underground BBS's (pre-internet era, multiple brains have sometimes more ideas then one) (or on fidonet, or uucp, or using the in that era famous penet.fi anon remailer, or gopher or on usenet)
• Some memory expansion cards preserved memory state after reboot, in memory dumps could be done this way
• If I remember correctly some memory cards had a hardware switch to map the main memory different (on the expansion card)
• On the Amiga line some processor interrupt lines where available on peripheral connectors, it gave the possibility to set hardware breakpoint (or at least slow down the code)
• Sometimes programs/games where deliberately leaked without copyprotection from the original coders as kind of marketing system. (the more the name of a game/program went around, the cooler/better it was)

The real challenge came when self-modifying code and self-encrypting code came out, then an easy nop or rts to patch some code didn't work anymore.

(Those games/programs who needed a 'decrunching' in mem. Sometimes the video mem or blitting possibilities of the Agnus chip was/were used as temporary 'decrunching' mem. One of those custom Amiga chips had direct mem access. One could notice it easily on some demo-disks in that time which were made on coding contests at gatherings. When one noticed some temporary noise/garbage on the screen, one was sure that technique had been used) D-Mob & Digital Concert music discs & some budbrain demo discs used that technique for example.

Not specifically Amiga related, but afterwards the Fravia site was a huge gem on disassembly, reversing, and patching techniques.

Answer 3

I'd like to point out that in those times, even though it could seem complicated, encryption algorithms often were nowhere near what they are today. While most of the theory behind good encryption was known, actual implementations still were significantly behind, for several reasons. One of them was that few people saw the necessity for good encryption, and another one was that the CPUs weren't able to apply complex decryption in reasonable time.

I remember a case ca. 1996, when we hacked a password-protected application just because it was using a simple xor-encryption with a constant key for the stored passwords. So with the password file open in the hex-editor, we could recreate every user's password by just performing some xor calculations with pen and paper. The administrator was very confused as we were able to guess every password he used, whatever it was.