Cracking BurgerTime, a 1982 game on a floppy disk | Hacker News Reader

Cracking BurgerTime, a 1982 game on a floppy disk

ia801505.us.archive.org

151 pointspavel_lishin57 comments

Interesting exploration and impressive persistence. This approach definitely provides more detailed information about how the process worked. This seems like the only approach that would have worked back in 1982.

Reading the description of the archive.org project at https://archive.org/details/apple_ii_library_4am&tab=about makes it clear that this effort intentionally deconstructs and documents the original copy protection.

Other than as an exploration of copy protection, though, I can't help but wonder if the simplest approach to preserve and run the same software today would involve an appropriate emulator, more accurate floppy drive emulation, and the unmodified original disk image. The crazy amount of self-decryption and obfuscated code wouldn't matter as long as it found what it expected on the disk; the modifications just let it run on real hardware using a copied disk.

Apart from allowing the use of the original unmodified disk, emulation would also avoid the possibility of missing more subtle copy protection schemes. This particular disk made things easier by just stopping the game at the start. Some of the worse copy protection mechanisms developed later would detect a copied game, leave it somewhat playable, but make it either exceptionally difficult or intentionally broken near the end. Sometimes they would include a more obvious copy protection scheme to defeat that prevented playing the game at all, so that a prospective cracker would think themselves successful once the game starts. See http://media.earthboundcentral.com/2011/05/earthbounds-copy-... for an example.

Some copy protection systems relied on using subtle timing errors to create disks that would read as "corrupt" by standard system software. Replicating this behavior in an emulator would be a major undertaking as well as being hard to reproduce in an image format.

This.

I was never very advanced at cracking, but I do remember back on the C64 I encountered a number of games that had corrupt/unreadable sectors on the disk. Many copy programs would halt when they encountered these errors meaning you couldn't copy the disk. I had one program (no idea what it was called anymore) that would skip the errors and write everything else. To beat the copy protection, I would open the sector with the read error on the original disk, swap out for my mostly complete copy, and then write the disk error to that sector. I always thought it was kind of weird that I could write an unreadable error, but it seemed to work most of the time.

I think the ultimate problem with emulation is the disk image: how do you image a disk with these subtle timing errors? The default behavior of the software operating the drive isn't aware of half tracks; every vendor uses different tricks so you don't know which 'timing errors' to activate; etc.

Go look into Kryoflux:

http://www.kryoflux.com/?page=kf_features

It's a USB floppy controller which allows you to image the raw magnetic state of the disk (subject to head step and width). It allows you to record the disk and then try to figure out what the format is. It's good enough to allow you to read CLV disks, such as Mac floppies, from an image taken from a CAV drive, such as a PC one. I don't know whether it supports half tracks --- probably --- but it will certainly support all the weird timing error tricks.

It's not what I would call user friendly but once you've figured it out the results are magical. I was able to image an ancient BBC Micro floppy disk once and then spend ages figuring out how to parse the sector layout and encoding density working with just the image. Not only does this avoid having to keep working with the fragile disk, but it's way faster!

The problem is a lot of the age machines (Apple II in particular) had a lot of direct control over the disk hardware. So they could move the head in "half track" increments (reading from positions that potentially interfere with standard disk positions) and it is uncertain what on the physical disk is the intended image without somewhat knowing how the drive head is scheduled to move. Obviously something more sophisticated than a drive of the time could image the whole floppy (and one could simulate a drive over that)- but using a drive of the time isn't enough to make usable images in all cases. I think the software that tried to do so were called "nibblers" or "nibble editors", but it has been a long time.

This is actually not a problem today, see e.g. the ipf image format and hardware such as KryoFlux:

http://info-coach.fr/atari/documents/_mydoc/IPF-Documentatio... http://www.archiveteam.org/index.php?title=Rescuing_Floppy_D...

"Under MAME license" is unfortunately a showstopper for FOSS. Particularly unfortunate because MAME itself has started the process of moving away from that license and towards a FOSS license (see https://github.com/mamedev/mame/blob/master/README.md#licens...).

Do you know if the authors of that code would consider releasing it under a FOSS-compatible license (e.g. MIT, LGPL, or GPL, depending on preferences about copyleft)? Failing that, do you know if a FOSS library exists to read and write the IPF image format?

Neat. I knew a superior drive could copy everything, I didn't know this had become common.

I wrote some 6502 protection code for Atari game cartridges. The problem was that a cartridge could be copied (trivially), then loaded into RAM at the same address, then run. There were many disks running around with cracks of cartridges that you could just load and run. The goal of the protection code was to detect whether the code was running in RAM or ROM, usually by hiding writes that would cause crashes or be detected by the game logic.

Once I had about two weeks to spare on a protection system; it used a couple levels of decryption and some delaying tactics so that the title would crash minutes after starting.

A prolific Atari pirate lived in my apartment complex. After the cartridge shipped, I asked him about it. "Oh, that was a hard one. It took me and my friends three days to crack."

Time and numbers are not on the side of DRM. (I'm also unconvinced that Atari lost much money to copying).

Cart protection on 6502 was tough to hide. I personally never reversed one, but a friend and I did a couple for the 6809. That thing was tough! Lots of options, addressing modes, etc... Took weeks, and it was on cassette.

I've often wondered about your last bit there.

The way it was in my little home town is a lot of people copied stuff. But, they barely could afford the computers too. Those who did have the bucks bought most of the stuff that ended up copied. You might be right, at least early on.

Later in the 80's, disk copying was massive. The C64 scene seemed to have buyers, but nearly everyone was on copied media in the Atari scene. Fewer machines, more copies, and it seemed like easier copies too... Some schemes were bad sector ones, and frankly, one could just count the beeps, open the door, wait for the error and continue. Not everyone checked the nature of the error, it seems.

I'm both impressed and terrified that most of this article makes sense to me, even thirty years later.

It feels like writing the protection must have taken longer than developing the game itself.

If you're curious, here is the actual game:

https://www.youtube.com/watch?v=5wEWftbwSm4

Hard to imagine they went to that amount of trouble to protect it, but those were different days.

This was written just a couple days ago, it's just in the formatting of files written 30 years ago. The writing and explanation style is definitely a lot more modern and detailed.

> The writing and explanation style is definitely a lot more modern and detailed.

Especially since many of the original crackers usually did not want to share all of the details, only just enough to aggrandize themselves without supporting others.

This is spot on, that's exactly how I remember the scene back then.

"Beneath Apple DOS" (and later ProDOS) were the cracker bibles back then. It's pretty much the only official documentation you could buy that described how the floppy drives work at the lowest levels. There was no internet and BBS were reserved for the most wealthy hackers. Basically, you were on your own to figure things out.

With the knowledge from this book, you could theoretically crack anything, but as the article shows, you also need to have total mastery of the 6502 and of the Apple ][ ROM layouts too.

> you also need to have total mastery of the 6502 and of the Apple ][ ROM layouts too.

Those were not rare skills.

Two things here:

We were not anywhere near as connected as we are today. So yes, there were a fair number of people able to do this kind of thing, but they were well distributed and not always motivated to do it.

In my little town, a few of us reached that level. Together. All we had was the usual books, and a massive amount of time. After cracking one or two, we moved on to doing other things. It was about getting some of those skills, then putting them to use. It's my perception that the hardcore types were, in fact, pretty rare because of this.

Remember: the C64 and the Apple II were sold in very large numbers as was the BBC Micro and the Acorn Atom. 6502 Assembly language was the only way to get those computers to do much of anything at appreciable speed. Almost all those programmers went through the same path: first the Basic that came with the system, then frustration and enlightenment as they discovered the layer underneath the Basic interpreter that gave them both better control of the system and much higher execution speeds. The number of people capable of programming the 6502 at a very high level must have numbered in the 10's of thousands. And quite a large number of those were just as good at piecing things together again from binary data as they were producing that stuff in the first place. The reason for that is that the correspondence between assembly and machine code is 1:1, in other words the output of a dis-assembler looks very closely like the input to an assembler for the same processor.

In my little circle of programming friends at the time all of us would have been able to do this (and more), and were definitely weren't gods by programming standards, merely average and with too much time on our hands. Persistence is a good substitute for talent if you have a lot of time.

In my small town, there were maybe 5 people, and one or two of those were at this level. I was somewhere in there, but not at the peak for sure.

Many did explore assembly language, but there is still a difference between, say writing an assembly language program, and digging deep into the guts of the disk system.

You are right about binary data. But, I must say access to information wasn't the same either. Many of us worked from what we could find in the magazines found in the grocery store. I used to take really long bus trips to the university library to photocopy useful bits.

The books we all know well, "Inside the Apple..." and "Inside DOS" were out there, but not everywhere. Our group didn't have them for quite some time.

Access to better tools was an issue on many machines too. The Apple and BBC Micro came with some assembly language support. Other machines, C64, Atari, didn't. And stuff wasn't cheap. People who came from those two machines were a little different than those coming from the C64 or Atari, for example.

One of the first things I learned to do was write a disassembler in BASIC, then an assembler. My first home machine was an Atari. Awesome capabilities, but not anywhere near the learning machine the Apple 2 was. I missed the monitor and mini-assembler big. A friend had a 6809 computer, and we both were mentored by someone who was fairly advanced, showing us things. Took a while to get ML tools. So a ton of stuff got done from the BASIC.

This is small town perspective. I think we aren't in disagreement as much as differences in perspective are in play. If you didn't live somewhere with a notable population, information often came from the school of hard knocks.

One other thing... those assembly skills varied. I still struggle with larger programs in assembly, though I'm good at hacking something, or doing little helper routines. The people showing real mastery often had tools, or were able to put bigger projects together. They ended up doing those bigger projects.

In any case, awesome times.

One thing I do find notable is those skills did have an impact. I'm on a project right now that requires some bootstrapping, and or low level development. At one point, a system monitor was discussed. A lot of people today are just used to pretty awesome tools. You use your PC to target whatever it is and go.

Not a thing wrong with that.

But, say you want to do it on chip, or piece together a big project, test, or do other things. A monitor can be used to run things from RAM, move stuff around, and of course, if you've got an assembler, you assemble to RAM, stash it somewhere, ideally storage, get all the pieces done, link 'em, or page / bank 'em, jump tables, etc... and eventually write it all out as a larger project.

Those kinds of things are foreign to many today. And that's fine because of where computing is. But you can tell who was there early and who was not, just by how they may attempt things, or the tools they use, or create.

For the curious, "Beneath Apple DOS" is available online at:

http://fd.fabiensanglard.net/prince_of_persia/Beneath%20Appl...

Thanks for pointing out! I was also assuming it was an article from 1982 at first. I was already wondering about terms like "bare metal" and "automated tools" in the first paragraph. Not sure if they'd have been used in '82.

Would be interesting to analyze further possible differences in the language if the article would have been written in 1982.

The term "bare metal" goes way back and wouldn't have been out of place in 1982 (IBM was Big Iron, after all). I don't think "automated tools" was in use, certainly not in everyday use, although I think we would have understood it. Maybe. That's a pretty fascinating question, really.

Was around at the time and "bare metal" was not a commonly used term.

Me neither.

It was called machine language, or assembly language. References to the hardware were common in pretty much all language contexts. Since very little didn't involve the hardware directly, "bare metal" didn't even have the context yet.

Perhaps it would in some academic circles, but not for the general population of microcomputer users.

Well, so was I, of course, but since I failed to take careful dated terminological field notes, I can't really say much more than feeling that I would have understood it at the time. But frankly I don't know. It just doesn't seem as freighted with modernity as the concept of "automation" in this context.

Seems kind of like maybe something Gibson would have used, but yeah, that's probably later than 1982. Now my interest is really starting to get piqued.

Oh, wow... now my mind is blown for real.

May I ask how you know that?

Does this mean that the person actually cracked this game recently just to post such a write up?

see https://archive.org/details/apple_ii_library_4am A collection of historical software for Apple II computers from the 1980s and early 1990s. Each item was originally copy protected (i.e. the original floppy disk could not be copied to another floppy disk), but the copy protection has been removed and documented. Most items also include a "work disk" comprising the intermediate files created during the deprotection.

To send feedback, ask questions, or get notified of new releases, follow @a2_4am on Twitter.

Fascinating.

Do you know how they do it? I mean, in order to crack these games, they need to have the original physical floppy, don't they? Or do they have a digital version of the protected floppy with all its weird sectoring and data on it?.

Well you'd have to start with an original floppy or cassette, wouldn't you? Some still enjoy cracking on the real hardware, but most make a low level floppy or tape image and work from that.

I've only cracked relatively simple stuff, but working in an emulator is a LOT easier than working on real hardware. In an emulator you can freeze the system and inspect both the computer and the disk drive, set breakpoints, modify memory, and so on, and it's totally undetectable to the protection code.

> 2015-12-31

;)

Precisely. A lot of the stuff he's cracked has never had a usable rip done even 30 years after people started moving on to bigger and better, and he's still finding new stuff that has never been dumped before and needs copy protection removed.

Right after he put out the crack, I was working on a (hard-drive friendly) port to ProDOS based on it.

> It feels like writing the protection must have taken longer than developing the game itself.

Protection schemes tended to be reused for the whole panoply of games they produced.

Burger Time was a pretty big hit for the time. Not Pac Man level of success, but, I played it in the arcade and was excited to get it on my C64 (pirated, of course). It was ported to every major platform, and had sequels and imitators. So, not surprising they'd go to some lengths to prevent piracy, since anti-piracy tricks were very common at the time.

As I understand it, there were a variety of somewhat known tricks that were sort of pre-made (or at least were sort of design patterns that existed), and they'd vary the disk timings, track skip patterns, and combine various tricks for new major releases, so the copy cartridges and software would have to do a new release periodically to cover the new methods (and sometimes automated methods just didn't work, as it seems is the case here). So, while it seems like an incredible amount of work, it was likely merely repackaging existing work.

I think the actual arcade game was before my time, but i seem to recall playing it, or one of those clones, on DOS at some point.

Edit: or maybe my brain is in dire need of a fsck. Checking some screenshots on mobygames makes me wonder if it was the NES version on emulator.

The good ol' days.... I still remember waiting for the latest version of copywrite or copyiipc which would crack the latest batch of games. It was an arms race but the game developers weren't winning it. I think at some point they resorted to using the documentation that came with the games, but we would all just get photocopies of the docs, so that didn't work either. It must have really sucked to be a game developer back in the 80s, probably 99% of the games were pirated.

So then they made the documentation with colors that were hard to impossible to copy.

Yup, I have some gloss-black-on-matte-black examples of this somewhere.

That was tense!!! Seems that Pac Man had better ghosts than the baddies in this game, still felt I had to watch it to the end.

From what I remember there was no discussion of how to actually do copy protection in magazine articles, as in the early magazines that published reams of assembly or hex that you could type in, yet, concurrent with this era there were plenty of copy protection schemes, as evidenced. So it was not as if you could easily use a few well known tools and techniques to obfuscate code. People were very much on their own but the games companies would have been able to put resources into protection and learn how others do it. This know how must have travelled word of mouth between publishers and developers as copy protection was vital for revenue in an era when everything was instantly copied and shared as a matter of course. What else were games for?!?

Anyway I think that even though there was not a lot of published material on obfuscation there must have been those that were well connected enough to know a library of techniques for copy protection. These guys would have found work with games publishers, their work being integral to publication. This was by then just capitalism and the resultant specialisms in the marketplace.

Back in the day, investing at least as much effort in the copy-protection as in the game it protected was not unheard of.

Programmers expected to get paid for their hard work.

Fantastic article as to how cracking was done back in the day. Plus, I've gotta give style points for it being formatted as 40 column, even if it isn't in all upper case, like files from back in the day would be. Though I was surprised he didn't check to see what that solitary bad sector was near the beginning of his explorations, because that was a pretty common way of keeping raw disk copy software from duplicating programs. All in all fascinating article.

3 days ago, not back in the day.

Hehe, lots of dusty neurons firing while reading this. Wonder how many old school hackers cut their teeth on cracking games.

  > In Which I'd Like To Add You
  > To My Professional Network Of
  > Linked Catalog Sectors

Priceless...

How much wall clock time went into this?

  > 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.

I would guess that to the guy who did the copy protection it was his master work in decryption routines, funded by the sad necessity of putting a game written by some talentless hacks into it as the ultimate payload.

I love reading the deconstruction.

Those apple copy protection schemes. Pirated software always had a "cracked by" load screen.

The most interesting thing to me were the hardware copy cards. Since most software fit in RAM, and the whole software would load at once, these cards let you push a button and make a bootable disk of whatever your computer was running.

When a disk failure meant trying to find another copy somewhere there was a legit fear of loosing your software.

central point software made some of these cards. A little info is available online. (Being before the internet took off, the names aren't search engine friendly.). Alaska Card Advert (why settle for copying the lower 48K.. Before they called it backup..)

https://s-media-cache-ak0.pinimg.com/736x/e2/70/cd/e270cdd90...

Bottom of this page has some interesting pictures and history of these card: http://retro.icequake.net/dob/

I was twelve or thirteen, had a ][e and with a copy of Beneath Apple DOS and the reference manual, and cracked a lot of software for the challenge. I wrote my own nibble copier but me and my friends pooled our money and bought Copy ][+ and Locksmith, which worked better.

My favorite, and easiest, trick was to use the 64k extended memory of the 80-column card to overlay the regular memory, copy the ROM and a few low pages into it, then jump to the boot routine. Then when the disk stopped spinning, I'd hit the reset button which left me with a copy of the system at that point. Sometimes I just had to dump the program from the memory, other times I would use it to disassemble how it loaded. I had a Applied Engineering RAMWorks card (Dad heavily used AppleWorks) and I recall there being tricks around that but can't remember (rigged a couple of buttons for page swapping, I think).

this one is also pretty crazy:

Super Mario World Credits Warp Explained

https://www.youtube.com/watch?v=vAHXK2wut_I

This glitch is far too interesting.

This is crazy! And I second too interesting...

I added some copy-protection to a Nintendo 64 game once. If the anti-piracy checks ever triggered, the game would do nothing at first - but after a few minutes, the frame-rate would ever-so-slowly start to get progressively worse and worse until it was unplayable. I'd like to think that I pissed at least a few people off.

If you're going to do that sort of piracy check, you have to be absolutely certain that it'll never trigger on a genuine copy. Red Alert 2 had a similar idea - about 60 seconds in to a game, all of your units will explode and the game ends - but it will sometimes trigger on legitimate copies of the game (usually due to mods, but I've had it happen on a clean install as well).

Nice work! Kind of hard to believe someone would go to all that trouble now, but fun is fun, right? I remember at least one game that was less fun to play than it was to remove the copy protection. Some of my old articles about removing Apple II copy protection are also posted on archive.com, like this one: http://archive.org/stream/computist-scan-14/issue14#page/n9/...

I remember cracking A2FS1 https://www.youtube.com/watch?v=sWIuTP_A6IQ This was before floppy disks, the game came on a cassette, but it had the same style of boot0/boot1 encryption. Starting the game from a copied cassette, it just printed "STOLEN AIRCRAFT! STOLEN AIRCRAFT!" all over the display.

Wow .. It looks like it would have been more fun to crack the encryption than actually play that game!

Very much so. I remember spending many months cracking game protection, not because I wanted the game, but because I wanted to pit my wits against the guy who wrote the protection. I learned more about disk controllers and hidden opcodes on the Z80 (TRS-80) doing that that any other way. I didn't always beat the guy, but always learned something.

Kudos to 4am, who has more patience than me. I'd probably have given up well before the third level of encryption.

For some titles, this was definitely the case. Nothing nefarious about it.

We weren't connected back then. People got bored, no new software, so... why not hack on the stuff we've got?

This reminds me tangentially of the Prince of Persia bootloader/disk format[0] used for the original Apple II release. Whenever I start to think I am clever or am feeling frustrated, I have a list of articles/code to read through to remind me I'm not; this is on there, and I'll be adding this to the list.

[0]: http://fabiensanglard.net/prince_of_persia/pop_boot.php

Reply on news.ycombinator.com