Type 9090 and Press Enter

It's 1988. You're twelve years old. Your friend has a copy of King's Quest IV on three 5.25" floppies, hand-labeled in ballpoint. You copy them with DISKCOPY. You boot disk one. And then:

You don't have the manual. You never had the manual. The disks came from a kid in math class who got them from his cousin in Michigan. The game is right there, loaded, waiting. And it won't let you past the first screen.

This was Sierra's bet: that the physical manual was harder to copy than the floppy disk. They were right, mostly. Photocopiers existed, but a thirteen-year-old didn't have casual access to one. And some of Sierra's manuals were printed with black text on dark red paper, or with answers hidden behind transparent red overlays — specifically designed to defeat photocopying.

But Sierra didn't account for DEBUG.EXE.

Sierra used two fundamentally different copy protection schemes, corresponding to their two game engines.

Here's the beautiful irony: the tool that cracked Sierra's protection shipped with every copy of DOS. Microsoft included DEBUG.EXE as a system utility — a bare-metal hex editor, disassembler, and debugger rolled into one. It was meant for programmers. It became the skeleton key of a generation.

DEBUG loaded any file into memory at address CS:0100 and let you poke around. You could dump hex, disassemble machine code into assembly mnemonics, search for byte patterns, edit individual bytes, and write the modified file back to disk. It was terse, unforgiving, and incredibly powerful.

The instructions circulated on BBSes as plain text files — usually a few lines, typed out by someone who'd figured it out and wanted the world to know. For the AGI-era games, the crack targeted SIERRA.COM directly:

That was it. Two edits. Four bytes changed. Copy protection dead.

The REN to .XXX was a necessary trick — DEBUG treated .COM and .EXE files specially during loading. Renaming to a neutral extension ensured it was loaded as raw bytes at CS:0100 with no interpretation.

The byte 0x90 is the x86 opcode for NOP — "No Operation." The CPU reads it, does absolutely nothing, and advances to the next instruction. It's the machine code equivalent of a blank line. And it's the single most important byte in the history of software cracking.

Here's what the protection logic looked like in assembly, before and after the patch:

The JZ (Jump if Zero) instruction is two bytes: the opcode (74) and a relative offset. Replace both bytes with 90 90 and the conditional branch becomes two NOPs. Execution falls through to the normal game startup regardless of whether the protection check passed or failed.

This is why the BBS instructions always said "type 9090" — you needed two NOPs to cover the two-byte jump instruction. One wouldn't do it; you'd leave a stray offset byte that the CPU would try to execute as an opcode, crashing the game.

The BBS text file told you where to type 9090. But how did the person who wrote that file figure it out in the first place? There were four main techniques, ranging from brute force to elegant.

Once someone cracked a game, the knowledge propagated through layers. The cracker wrote a text file — usually ten lines of DEBUG commands with maybe a one-line note: "works on KQ4 v1.0, SQ3" — and uploaded it to their local BBS. From there, sysops traded it to other boards. Within weeks, every warez BBS in North America had it.

The major crack groups of the PC era ran this pipeline at industrial scale:

Each release came with an NFO file — elaborate ASCII art with the group's logo, the game title, cracking credits, and a list of BBS numbers. Some groups attached cracktros: animated intro screens with scrolling text and chiptune music that played before the game launched. The cracktro was the signature, the calling card, the proof of craft. They were showing off.

The NOP trick was devastating against the AGI games because their protection was architecturally clean. One loader file. One CALL to the protection routine. One conditional jump. NOP the jump, game runs.

The SCI engine games were a different animal. Sierra learned. The copy protection was no longer a single gate in the loader — it was woven into the game scripts themselves. King's Quest IV had 79 possible challenge questions. The verification used a character-sum hash: convert to uppercase, sum the ASCII values. The hash was collision-prone (both "voice" and "licks" hash to 374), but the protection wasn't in one patchable location. It was scattered across script resources.

For SCI games, the scene adapted. Instead of binary patches, they distributed softdocs — plain text files containing every answer from the manual, every code wheel combination, every symbol chart. The copy protection still ran, but now you had the answers.

Some elegant workarounds emerged: swapping script.700 for script.701 to skip the protection dialog entirely. King's Quest IV v1.0 even had a backdoor — typing "bobalu" bypassed the check completely. Sierra quietly removed it in later versions.

Here's what never makes it into the histories: for a lot of us, cracking the game was the game.

You didn't crack Sierra games because you were a criminal. You cracked them because you were thirteen, you had a 286, and someone told you there was a way. The BBS text file was a treasure map. DEBUG.EXE was a portal into the machine beneath the machine. You were looking at raw hex — the actual bytes the CPU would execute — and you could change them.

Most of us who typed 9090 into DEBUG didn't fully understand what we were doing. We followed the instructions. But some of us got curious. We started reading the hex dumps. We learned what JZ and JNZ meant. We figured out what a conditional branch was before we knew the term. We were learning assembly language, reverse engineering, and computer architecture — and we thought we were just pirating King's Quest.

The copy protection existed to stop us. Instead, it taught us how computers actually worked.

Sierra games that fell to the DEBUG crack, and their protection schemes:

The 0x90 NOP patch didn't die with Sierra. The same technique — find the conditional jump, replace it with NOPs — was used to crack every generation of PC software for the next two decades. Windows shareware. CD-ROM checks. Serial number validation. Online activation. The tools got fancier (SoftICE replaced DEBUG, IDA Pro replaced hand disassembly, OllyDbg gave you a GUI), but the core insight never changed: somewhere in the binary, there's a conditional branch that decides whether you're allowed to run the software. Find it. Kill it. 90 90.

The crack groups that started on Sierra games — Razor 1911, Fairlight, The Humble Guys — went on to crack Doom, Quake, Half-Life, and everything that followed. The BBS network evolved into the internet. The NFO files became websites. The cracktros became the demoscene. But the technique? The technique was eternal.

Two bytes. That's all it ever took.