Copy Protection In The 80s, Showcased By Classic Game Dungeon Master

Making a copy of a purchased game used to be as simple as copying a disk. As the game industry grew, so did fear of revenue loss which drove investment in countermeasures. These mainly consisted of preventing the easy duplication of magnetic diskettes, or having users jump through tiresome hoops like entering specific words from the printed manual. These measures rarely posed much of a challenge to the dedicated efforts of crackers, but the copy protection in the classic 80s game Dungeon Master for the Atari ST and Amiga was next-level. It implemented measures that went well beyond its contemporaries, and while it was eventually defeated, it took about a year to happen. In an era where games were cracked within days or even hours of release, that was remarkable.

Dungeon Master was a smash hit at the time, and while the details of its own brand of what we would now call DRM may not be new, this video presentation by [Modern Vintage Gamer] (YouTube link) does a wonderful job of stepping through everything it did, and begins with an informative tour of copy protection efforts of the era for context.

The video is embedded below, but if you’d like to skip directly to the details about Dungeon Master, that all starts just past eight minutes in. What we now call DRM clearly had roots that preceded the digital world of today; an absurd timeline in which even cat litterboxes can have DRM.

35 thoughts on “Copy Protection In The 80s, Showcased By Classic Game Dungeon Master

  1. From what I remember all DRM then were just byte manipulation based on disk controller behavior. Now days you have inline layer-encrypted or even byte-streamed virtual machines that take far longer to reverse.. The worse era was when everyone used the driver anti-debug options of protectors..

    1. On the contrary, encryption and virtual machines were common techniques in floppy disk protection. EA, for example, used a virtual machine that ran a proprietary language protecting their Apple II games. Multiple layers of encryption was typical. Follow a2_4am on twitter to learn more.

  2. In the end, the device is producing something that **we** have to consume, and as far as I’m concerned, I’ve no copy protection inside. I’m all analog, and so is the final monitor’s picture. In all cases, DRM are doomed.

  3. I remember the furore around Robocop 3 and the dongle which needed to go into the second joystik port.
    It pushed the price to an astronomical £35 for a computer game. Agast at the time.
    It was cracked mere hours after release on on the BBS’s.

    Many a pirated game for the Amiga had serious flaws. You had to wonder if some releases had been done this way on purpose by some of the groups.
    Supercars II had massive corruption on some levels. Monkey Island was uncompletable past the sword master.

    The good protection was like F1GP which required the entrie frikkin manual to be copied (till a crack came out) and Pirates! which if you answered the questions wrong you’d have a sucky game, but you needed the treasure map to play the game well anyway so just a disc wasn’t good enough.

    Of course all before everyone had digital cameras, never mind a scanner.

    1. i don’t understand this reference to the digital camera and the scanners, what was wrong with the film camera?
      i mean if i needed some map to be duplicated i simply take a picture of it with a film camera and send the exposed film to the lab where they can develop it and enlarge it to a photo paper in color of course :)

        1. ^^^^^

          Photocopies were only 5p per sheet at the library, but you were being VERY naughty
          Did learn about disassembling/reassembling things without trace thanks to F/A-18 Interceptor

    2. Yes, there have been several cases where the game developers intentionally circulated a sabotaged pirate copy. My favorite story was a sort of video game development RPG, where the pirated copy would have your company’s profits start to sink once you got past the cartridge era… due to people in-game pirating your software. Actually pay for the game, and you’d be able to go on since the in-game customers also would pay for your games.

      1. You are thinking of “Game Dev Tycoon” 2012 by Greenheart Games the irony is that most of the game is stolen wholesale from “Game Dev Story” 1997 by Kairosoft. I don’t mean similar I mean flat out copied, Greenheart have some brass balls to be complaining about USER piracy.

    3. Ah, F1GP. I cracked the PC version of that back in college.

      My first few efforts were ‘noticed’ by the game and you’d lose the ability to steer some minutes into playing.

      Eventually I defeated it by trapping the INT that got the time of day and always returning the same value. The game used this as a seed for its random number generator which was used for determining which word from the manual is was going to ask for. Thus it always asked for the same word. The splash screen for my ‘crack’ told you which word to enter.

      The same technique worked on most games that used this form of copy protection.

  4. I recall one game on the Spectrum (it might have been Manic Miner, or Jet Set Willy, but it was a long time ago) that required you to type in four colours from a given grid square in the manual. The idea was that, as colour photocopying didn’t really exist then, a photocopy of the instructions wouldn’t work.
    But they reckoned without the ingenuity of the copy makers, who simply wrote down r, g, etc for the colours on a matching grid and photocopied that.

    1. A related technique was to make the code sheets very low contrast to foil photocopiers. SimCity, for example, had a code sheet printed in brown-on-beige. Or the multi-part code wheels such as used by Bard’s Tale. Of course, we would transcribe the charts and take apart the code wheels. 😬

      1. Bard’s Tale for C64 (the first one, never got later version) didn’t come with code wheel. However the disk had specific design that made copying impossible. Later I found out it was an intentional bad sector that would always read random value every time. A copy would always read same value and would cause the game to refuse to load. Laser and the precision of burning bad sector wasn’t possible for us pirates back in the 80s. Fortunately cracker could find the bad sector check in the game code and cracked it to skip the check.

        1. I remember those “bad sector” schemes on the C64. It would cause your drive to reset, slamming the head against the stop up to 35 times, possibly causing it to get out of alignment. Gotta love DRM that can actually damage your hardware.

          1. Only certain bad sector errors caused the infamous head banging. If I remember correctly they were errors 21 and 27. Errors 23 and 29 were “silent” and only flashed the drive status light. I know error 23 was a checksum error.

            I cracked a Synapse Software game by sector editing the bootstrap LOAD’*’,8,1 loader so the track it checked for the bad sector was track 40. The 1541 returned an error so it thought it had a bad track and you could play the game.

  5. I remember a baseball game I had as a kid growing up, it came with a circular spinning disk, you had to spin to the right combos and then enter the value at the center to get into the game…. We just took it apart, and copied it on a copier also….

  6. I remember Battle Chess in the ’80’s – It’s DRM was archaic, but effective…It asked for a word, giving you the page and word number to look in the manual. Luckily it was only about 10 pages, and my copy had photocopies of the manual.

  7. The best copy protection I ever saw was from Borland. You really needed to have the reference manuals for their compiler software, and they sold the software, complete with printed and bound manuals, for less than the cost of photocopying the manual.

  8. Not just games. I was involved in a project that was done in by the copy protection applied to Lotus 123.

    Back when the AT floppy/hard disk controller was a big board full of circuitry, the company I worked for was hired to design an alternative. The point of the design was to take advantage of the fact that the SMC 9224 could do both floppies and hard disks; it wouldn’t need separate controllers for each.

    The first-pass design was a board with about half a dozen or so chips on it and it worked. Then we encountered Lotus 123.

    Among the fancy features supported by the 9224 was implied seeks; you’d set the chip up to read a sector and it would figure out which track the disk was on, move the heads, and start the read. It figured out which track the disk was on by reading the headers from the disk. The Lotus 123 copy protection scheme involved playing with those headers, including the field holding the track number. So the 9224 would read a header, see that the floppy was on track 255, and zip the head past track zero trying to find the correct track.

    So we *had* to have a 765 to deal with the copy protection of Lotus 123.

    Then somebody decided we also needed to emulate the WD1010-style hard disk controller used by IBM in order to be able to handle things like Unix. So we sprouted an 8051 to handle that command set.

    The second design was jsut as crammed full of stuff as the IBM controller.

    Then Western Digital came out with their cost-reduced controller that swept all the hard disk stuff on the IBM controller into a couple of chips, so *their* controller was now just a handful of chips.

    At that point, ti was all over.

    1. Ouch! That’s a pretty good case study for the perils of making things that interface with other things, especially when those “other” things are 1) not under your control, and 2) freely play dumb games with “standards”.

        1. The 1541 drive was the result of C= trying to make a cheap 5 1/4″ serial drive that was compatible with their 2040/4040 parallel drives. It was crammed into a too-small case which caused heat issues and the early ALPS mechanism drives were notoriously unreliable. I think I went through five before I got a Newtronics unit.

          Third-party drives came out early in the life of the C64 because of how slow the 1541 was and its unreliability. Unfortunately copy-protection for commercial games rendered them next-to-worthless unless you used cracked/ISEPICed versions.

  9. Software shouldn’t be protected by copyright. The story and illustrations in these games should.

    DRM countermeasures shouldn’t be a punishable (by government) offense.

    Other than that, DRM is fine.

  10. There was lots of clever protection systems for C64 games. One that particularly impressed me was Epyx Winter Games, which used its own data encoding. The directory track and one other used the usual GCR, but the rest used a mfm-like encoding. It was not as space-efficient than GCR, but it was simpler to decode and allowed the game levels to load incredibly fast (with a sector interleave of two).

  11. Many moons ago there was this fantastic game called Zak McKracken – I am sure some will remember. The copy protection scheme consisted of multiple pages filled with symbols, which were printed with black writing on dark brown. You could not make a photocopy of it. So my father (!) and I assigned a simple letter to each symbol and translated the whole thing. Yes, it took ages. Afterwards we would print it out on the fancy 9-needle printer and penciled in the symbols for reference. A lot of effort, yes, but we felt like renegades afterwards. 30 years later we still occasionally speak about it.

  12. I actually managed to break it (but I didn’t distribute it). First you needed to decompress the binary. Then patch the checks for the bad sector. Then patch TWO checks to see if the bad sector code was altered.
    More challenging than the game itself.

  13. back in those days my first real day job was working for a company that specialised in commercial floppy disk duplication.

    We would regularly get ‘protected’ master discs to copy.
    I used to think the crackers had it easy..find the protection and move the ‘check’
    It’s an entirely different thing to get asked to copy a copy protected disk, while ensuring the copy protection mechanism is intact in the copies.
    Typically we would be tasked with producing 100 duplicates, so they could be tested to ensure they all worked, before securing a larger order.
    Sometimes disks were serialised too, making each unique (think Little ComputerPeople, each LCperson was different)

    IBM PC discs were pretty straightforward, usually odd or faulty sector headers or checksums, or unusually sized sectors, often appearing as valid normal sized sectors, so the copying software would see it was all normal and would copy it happily..only for it to not actually work.
    And of course while there were tools like diskdoctor and similar which let you see the data on the disk, that was only half the story..The duplication systems allowed you to see the data, any clocking infomation and sync bits/bytes and the sector headers.

    Apple, victor/Sirius and commodore were a bit trickier as they all used variable speed drives or GCR (group code recording) or both. Duplication systems would sometimes struggle with these as they had to simulate the ‘variability’ of the speed of the drive by writing smaller or larger 1s and 0s
    Usually this resulted in a much slower ‘copy/verify’ process for these discs and to to start with, often these disks weren’t possible for us to copy easily (with automated systems)

    Double sided, double density IBM drives/discs 80track/2sides/15sectors per track(1.2mb) could be copied and verified in as little as 30 seconds.
    By writing to both sides of the disc simultaneously. (The heads were deliberately misaligned so you might be writing track 4 on the top surface while you wrote track 0 on the bottom, to avoid magnetic interference)

    Apple/victor and commodore discs could be much much slower, in some cases it was quicker to use built in tools to duplicate non copy protected discs. I remember one very long night, duplicating victor discs for a financial company using an entire room full of victor ‘luggable’ PCs, just using pip to copy them. Putting a disc in each drive closing the door and pressing the return key, working round the room and just getting back to the start as the first machine finished it’s copy.

    Things did get better, the tools to allow commodore apple and similar disc to be copied on the duplication systems gradually improved, I still had to work through the disk, checking for unusual constructs and then writing scripts in a proprietary language which described the format specification of the data written and sector headers etc. eventually we could copy these in the Duplication systems autoloaders, taking around 2 minutes per disk, quite slow considering they were usually single sided and with around 200kb (170k as standard)
    I remember driving to Microprose in tetbury, uk. With a bag of discs for their play testers. I sat there most of the day watching 2 guys play (I think) ‘’stealth fighter’’ working through all the missions and scenarios on the C64.

    From my memory, that c64 protection scheme used ‘unusual’ sector mapping, hiding small sectors inside regular sized sectors which had bad checksums. These were spread over the disc and also used odd sized bits (magnetic flux reversals) on the media.
    Regular 1541 drives didn’t Like these very much and would barf on the errors, copiers ‘could’ copy the bad checksums, but that wasn’t the only method, sometimes no data would be written or partial data might be written, which meant the drive reading the data back might get a different value each time (or a selection of values if only some bits were not written)
    These were known as ‘flaky’ bits/bytes
    This was harder to spot, checksums might vary. And simple copiers would just copy the value they read and that disk would then only read back a single value, the protection read the sector many times and expected to see several different values.

    Time marched on, AtariST was straightforward the format was more or less identical to the IBM formats for 3.5 inch floppies.
    The amiga however, was much more of a headache. [i remember a mahjong game being fiendishly tricky to copy)
    The disk format was an IBM like format… but the resulting output data was quite hard to read.
    The duplication systems could never make sense of it resulting in more manual messing around.
    This was because the amiga used one of its graphics chips to dump the data quickly to/from the disk controller, this resulted in all the odd bits (from the entire sector) being written first, then all the even bits. At the time this was bloody annoying, cos all the tools I had to look at the data on a pc or the duplication system itself, didn’t know about this and I spent a fair bit of time writing the bits out on paper to check what was going on. Going on to write a tool which took an amiga raw sector dump and viewing it after swapping the bits around and re-interleaving them.

    I left the company I little while later, but for about a year afterwards they asked me back every couple of months to build format specification for c64 and amiga game disks. After that I think theduplication systems caught up and had built in tools to cope with amiga disks more easily.

    Rich.

Leave a Reply to dave Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.