Breaking copy protection on a 1983 game for Apple 2 | Hacker News Reader

Breaking copy protection on a 1983 game for Apple 2

ia804502.us.archive.org

146 pointscolinprince33 comments

When I was a teenager I used to enjoy playing computer games. However the copy protection was really annoying as you couldn't back up the expensive game disks and floppy disks weren't exactly reliable then. So I taught myself how to crack copy protection.

I did some 6502 (BBC Micro) games but mostly 68000 (Atari ST). The process was quite similar to the article but I never cracked anything that complicated! Nor did I keep detailed records - I was far to worried about them being evidence to be used against me.

My best crack was working out that I didn't need to figure out how to read the key to decrypt the game from the secret uncopyable protected sector on the disk (I think it had a deliberate CRC error in it so the standard disk firmware wouldn't read it). I disassembled the crypto routine and saw that it just did a simple XOR of the key block over and over again. I then used a frequency analysis on the encrypted game binary to recover the secret key and decrypt the game!

I came to enjoy cracking the copy protection much more than playing the game as it was like having an intellectual battle with the developer. In fact after that playing games lost its appeal and I moved on to creating new things on the computer instead.

I never distributed my cracks though - I was far too frightened of getting caught!

I was a C64 cracker and added intros (with ripped Rob Hubbard tunes and border sprite scrollers).

Much of the disk protection was laughable, Ocean games been an example.

They had a routine that would return 1 in the A register so the crack was to load the accumulator with 1, do a nop to fill the gap and continue

I could crack their games in about a minute with a disk sector editor I wrote that would disassemble the game on disk by reading the sectors for the game.

The hardest crack I did was EA’s Skate or Die. It had self modifying code in the copy protection which took quite a while to unwind loops.

I also cracked Ghosts and Goblins, or maybe it was Ghosts and Ghouls, on the Amiga. The chumps who made the disk left the source code to the boot loader on the disk as a deleted file. I undeleted it and “fixed” the boot loader.

Oddly, I worked in copy protection many years later.

That is funny!

One lame scheme I ran into was a basic try to load deliberately bad sector check.

If bad, run game.

If good, fail.

But, they did not check for any specific error! Any error would do to start the game, which was ULTIMA 2.

Because of that, anyone could copy the game disk and cause a disk read error to happen at the right time to play the game.

The easiest thing to do was open the drive door, wait a bit, then close it to see the game load normally.

It sounds similar to the Ocean protection which did a disk check.

It was, essentially a:

bool IsGenuineDisk() { return DiskHasSecretStuff(); }

Lol, yeah.

That was my first "crack." I happened to run the game on an Atari computer, which makes sounds during disk I/O. I could hear the sectors, hear the fail, retry, then remaining sectors load.

So, count em up, open the door, listen for fail, close, go!

Didn't even need a single hex value to accomplish.

After that, I got into it on an Apple. Reading this brings back memories. That particular machine is a lot of fun, and it is fun because almost everything is software. Totally open.

4am has cracked loads of apple ii games, and after doing several hundred manually, automated it as a set of python scripts, https://github.com/a2-4am/passport an article with interview here, https://paleotronic.com/2018/06/15/confessions-of-a-disk-cra...

These lab notebooks of the cracking process are shared for titles that could not automatically be cracked.

These are the only public records of reverse engineering these titles, though many did this in the 80’s the techniques and findings were never shared beyond the cracks themselves, and 4am is so practiced and proficient I think he definitely wins the title of the best apple ii cracker in history!

A set of Python scripts... more like a set of 6502 assembler routines integrated into a disk imaging app with a highly cursed build process!

4am is ridiculously prolific. The sheer number of bizarre disk-copy protection schemes applied on these old computers has always been fascinating to me. A lot of creativity went into both inventing and reversing these things.

I think you're correct, a lot of the earliest cracks are essentially undocumented.

But in later times there was a good community of cracking software for PCs, and those notes continue to live on despite the unfortunate death of the curator/collector, +fravia.

Here's a decent mirror, for example:

https://www.darkridge.com/~jpr5/mirror/fravia.org/academy.ht...

At one point I used wget --mirror to download the whole site, and that was back in the early 90s.

I actually cracked an Apple game in about 1990. It was incredibly easy. The Mac IIci had a debug button. Press it, and it would halt the CPU and throw you into a debugger mode. The key for cracking was that it had a disassembler, which would convert the binary back into assembly code (including any comments if they were left in).

The game Tristan did not remove the comments from its code, so after disassembly, I could see the name of subroutines. One line was something similar to "GOSUB hexaddress" with the comment "doProtec". I naturally assumed this was a subroutine that would run the copy protection code. In those days it was one of those pop up windows that asked a question from a random page in the manual.

A GOSUB and an address was two bytes of code, if I remember correctly. I used the Mac built in Hex editor to edit the binary for Tristan, found the GOSUB line with the correct hex address as its argument and replaced it with two NOOP commands, which were one byte each. I saved the binary file and played the game. And it worked! I could now play Tristan without having to answer the stupid questions from the manual every time.

Now we get to(*) trace the boot process one sector, one page, one instruction at a time.

(*) If you replace the words "need to" with the words "get to," life becomes amazing.

Prajnaparamita

Back in the hacking days for apple ii you would reprogram the eprom on the Apple II Firmware Card and could pretty much stop the CPU and at any address and hack away. With no internet people hosted BBS sites with slow ass modems to share all these hacks, quite the community over time. Long distance was expensive but that didn't everyone from hacking the phone cards and pretty much dialing for free. What's funny is all this continued on even when the first Mac was introduced, so more cracking to do. I had people buying and sending me program to crack, then share with the community. Cool to see someone document their efforts.

I had a Wildcard or maybe Wildcard 2. It would snapshot memory and could save it to a disk along with a bootstrap routine (as I recall) to make the disk bootable.

http://mirrors.apple2.org.za/Apple%20II%20Documentation%20Pr...

Demo:

https://www.youtube.com/watch?v=GKDiDtk-62o

My friend had one too. And it did as you said, basically dumped memory to disk and made it bootable. It had a wire with a red button that came out of the case.

We used it for a couple games when one of us had a bought copy and one of the various copy programs didn’t work (I had a disk full of them being young and not having enough knowledge to crack on my own. )

Worked well for arcade games. Didn’t work well for games that loaded more stuff from disk..

What's the statute of limitations for admitting to something like that? Asking for a friend

Go find my old apple ii and mac and I'll confess.)

In-browser emulator allowing you to play said game:

https://archive.org/details/SpareChange4amCrack/

The copy protection for Burgertime on the Apple ][ was especially labrynthine.

"I'm beginning to suspect that this disk is nothing more than an infinite series of decryption routines with a game bolted on as an afterthought."

https://ia800209.us.archive.org/8/items/BurgerTime4amCrack/B...

Doing this with a Beagle Bros book in hand in early 80s is how I learned 6502 and made enough spare copies of games to survive the central African climate.

Didn't intend to 'crack', just needed copies to play till they degraded while the original stayed in dry sealed storage.

Today I wonder -- who didn't learn assembly back then by reverse engineering games?

I love how the text is formatted to fit on the screen of an Apple II that doesn't have an 80-column card :)

Yes! That dev log would read perfectly.

And it would be a popular download on the BBS and early internet gateways.

Didn't grow up with Apple 2, sadly! So I have to ask. The text in the OP is hard-wrapped to 40 characters. So did Apple 2 support 40 character width screen?

I think 25 lines of it. The memory layout was not linear but garbled as far as I remember this Woz hack was to do the DRAM refresh as a side effect.

24 lines, for a total of 960 bytes occupying $400 to $7FF. The missing 64 bytes were called "screen holes", peppered throughout that memory range, and were used as scratchpad locations for peripherals. One of those peripherals is the disk drive controller card, and the position of the current track is stored in one of those holes. So if you try to clearing the screen the easy way, by zeroing $400 to $7FF, the disk drive forgets what track it's on and it needs to recalibrate, resulting in an awful noise as the read-write head bangs on a stopper.

I remember modifying that routine into banging the head at different frequencies. You could get into musical note range and turn it into a little organ.

Good point. I forgot about these scratchpad locations. One of my first assembly programs was a reverse scroll functions. Depending on the paddle controller it shifted also one char left/right. Two char spaced apart on each line served boundaries for a street and the car was two stationary char in the middle (depending on the paddle controller pointing left, ahead or right). Due to lack of assembler the whole was hand coded. Due to limited access to the computer it was all written out on paper first.

Yes, Apple 2 supported only 40 characters natively. You could add an "80 column card" to expand this to 80. This card became standard on the Apple 2e and 2c. Think it was in slot 3 by default. (Feels strange not to write "Apple ][" and "Apple //c" as they were written then!)

Yes, by default the screen width is 40 characters.

Many had an "80 column card" and later versions included it. However, TV screens of the time could not readably display 80 character wide screens.

This is a limitation of the NTSC composite signal. Eighty columns of text will never be readable through a composite connection, no matter how good the monitor is.

Well, that is true for a color signal.

Monochrome monitors take composite and can deliver 600 lines or so,

Also, no lower case. ¹

Does anyone have inside stories to share on more modern software cracking in Scene/P2P?

Nice article! Loved the Atari port of this game.

Reply on news.ycombinator.com