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.

3 Answers 3


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.

  • 4
    "I modified the Kickstart disk to copy all the base memory into my 2MB RAM expansion on reset," that's great! because for instance Herdnon protection decrypted itself and then remained decrypted, so it may be a way to get decrypted parts of the code Commented Dec 31, 2022 at 9:47
  • 1
    I only ever cracked one thing, Jet Set Willy I think, indeed using a disassembler (which was not copy protected fortunately :-p). I succeeded in short circuiting the copy protection code by adding a jump to the main code.
    – chthon
    Commented Dec 31, 2022 at 13:35
  • 1
    that's for the easy ones. The more complex ones require disassembly + running the code in a debugger. I remember cracking Subwar 2050 (AGA) just using the disassembly too, by checking the test for RETURN key ($0D) in the code. But that's the only one. Commented Dec 31, 2022 at 16:29
  • 5
    If you’re offering really primitive tools and your brain as separate categories then you’re well ahead of me on this topic.
    – Tommy
    Commented Dec 31, 2022 at 18:26

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.

  • 1
    ret should be rts ;) Commented Jan 4, 2023 at 11:30
  • 1
    You're right, sometimes I confuse the 68000 instruction set with the 8086 instruction set. In 68000 : rts ; in 8086 ret Did both amiga and pc patching. On PC I used Numega's SoftICE with a standalone debugger like IDA (Pro) --- Main post editted accordingly. Thx for pointing out !
    – HermDP
    Commented Jan 4, 2023 at 16:08

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.

  • yes, you could usually bruteforce the keys (for rob northen encrypted exes), but when the code is encrypted and self-decrypts (and self-reencrypts when done) it's still difficult to get a decrypted version without tools/a good monitor. Some tools used a IST (instruction size table) to fake execution and decrypt. In the end, you almost need an emulator for those cases Commented Dec 31, 2022 at 18:06
  • 1
    Also, this was in the era of the "Crypto Wars", when many governments (including the U.S.) still treated "good" cryptography as a military secret (even if the methods were actually published in official standards) and restricted its export. While you could certainly implement decent encryption algorithms like DES on the Amiga if you knew how, most game devs probably wouldn't want their software to be categorized as a munition. Commented Jan 1, 2023 at 1:55
  • 1
    good encryption is useless if you provide the key to run your software. Commented Jan 1, 2023 at 9:06
  • @Jean-FrançoisFabre The key wasn't directly provided, but in this case, it was a poor choice of an encryption algorithm (xor-ing with a constant key instead of a hash function). My point is: Some encryptions could be cracked because people just didn't pay enough attention to their choice of algorithm.
    – PMF
    Commented Jan 1, 2023 at 12:51
  • 6
    This comment is double-encrypted in ROT-13 for extra security. Commented Jan 1, 2023 at 17:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .