1982 Burgertime DRM was hard core.

In 2015, someone decided to crack a 1982 5½" floppy with an Apple][ port of Burgertime on it.




26FA-   BD 89 C0    LDA   $C089,X
26FD-   A9 56       LDA   #$56
26FF-   85 11       STA   $11
2701-   D0 01       BNE   $2704
2703-   D0 C6       BNE   $26CB
2705-   12          ???



26FA-   BD 89 C0    LDA   $C089,X
26FD-   A9 56       LDA   #$56
26FF-   85 11       STA   $11
2701-   D0 01       BNE   $2704
2703-   EA          NOP
2704-   C6 12       DEC   $12
2706-   F0 03       BEQ   $270B
2708-   D0 0A       BNE   $2714
270A-   D0 C6       BNE   $26D2
270C-   11 D0       ORA   ($D0),Y





It goes on like this for like, days:

...offers input selection, then hangs with the drive motor on...

That's actually a lot of progress. I can now calibrate my joystick before the game tells me to go f--- myself.


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

Let's go back to that "unreadable" sector on track $11, the one that looks exactly like a DOS 3.3 catalog sector, because it is a DOS 3.3 catalog sector. It's just not linked into the VTOC.

T11,S00 currently points to T11,S0F as the first catalog sector, but all of the "files" in that catalog sector are fake. What if I changed it to point to sector $07 instead?


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.

Previously, previously, previously, previously, previously, previously, previously, previously, previously, previously, previously, previously, previously, previously.

Tags: , , , ,

36 Responses:

  1. <comic book guy voice>pretty sure that's actually an Apple ][ game -- there was a "DOS 3.3" for the 2 series, and COPYA and all of the other tools mentioned are for the ][</comic book guy voice>

  2. This was my life as a teenager :-)

    • Mark Welch says:

      My teenage years looked like this, to some degree. Nice to see the crack so well-documented.

    • jwz says:

      Was it common for the copy protection to be so complex? I figured they wouldn't try nearly this hard!

      • Dan says:

        Yes. There were some schemes that used specialized hardware to write the disks during manufacturing, and could not be physically duplicated without similar special hardware. Other schemes used undocumented op codes, special disk formats, etc. Cracking Apple II copy protection was a favorite hobby of mine. My crowning achievement was "David's Midnight Magic", where I not only got it off of the highly customized, arc-written* disk, but also patched it to support keyboard input instead of a joystick. Good times. Of course, it took me until 1987 to do it (5 years after the game was released), but I did it for fun, not for distribution.

        You might also find interest in Fabien Sandlard's write-up of the disk protection on the original Prince of Persia disks (http://fabiensanglard.net/prince_of_persia/index.php): "From self-modifying code, in-house bootloader, clever floppy disc format to skewing lookup tables: Prince Of Persia features engineering treasures in every modules."

        *Arc writing meant that the disk would be written in "arcs", where a track would be, say, 1/4 of a normal track, then the head would step a half track, write another 1/4, step again, etc. That way it was very timing dependent, plus put data in places it normally wouldn't be (in the "half-track" zones), and made it much harder for disk copiers to successfully read the data correctly.

        • MattyJ says:

          The Commodore 64 had similar tricks up its tyvec disk sleeve, 'half-tracks' and long sectors and such. I was terrible at assembly back then and never successfully cracked anything. A good number of c64 games were memory-resident, so you could 'crack' them by loading them up to the menu screen, then dumping a memory snapshot. Then you got your warez.

          • moof says:

            The same thing was true of the Apple II; in the particular case of BurgerTime, I'm surprised that the 4am guy went through all the effort to crack it when it's just much easier to do a memory dump/restore. (Didn't crack it myself, but distinctly remember it being all of a 130 sector file.)

            • jwz says:

              Because that wasn't going to work:

              ; Scan all peripheral (slot) ROMs, test
              ; whether the first byte of the slot
              ; ROM changes over a short period of
              ; time, and if not, save it to an array
              ; at $BF73. (I'm assuming this is done
              ; again later, and if the values don't
              ; match, the game knows that it's not
              ; running on the same machine -- i.e.
              ; that someone used a memory capture
              ; card to save the game code to disk
              ; then reload it without going through
              ; this boot loader.)

            • Rich says:

              "It's a challenge", I guess.

          • Rena says:

            I remember reading about one game whose disks had some bits whose magnetic fields were somewhere between 0 and 1. When you read that sector, those bits were essentially random, different from one read to the next. I thought that was a pretty clever trick, though I wonder how many people had "lucky" drives that read it the same way every time and tripped the DRM.

            • jwz says:

              Yeah, that's the "half track" trick: you create the disk with a device that can lay down data mis-aligned with where the reading disk expects the physical tracks to be, so that a read will get you statistically "wrong" data. It was a pretty common technique.

              • Nate says:

                No, Rena is describing "weak bits". This is where you write a run of zeros, which causes the drive to lose sync and output a changing sequence for the same bit positions. When writing the data, the copy program would usually output whatever "random" sequence it read in a single pass, and the game would detect this by reading the target region twice. If it got the same data every time, it was a copy.

                On the Commodore 1541, this is because of a shift register that's clocked randomly when there aren't enough flux transitions to keep in sync with the bit timing. I don't know what the equivalent is on an Apple II, but it probably is based on the ROM state machine Woz used for clocking in bits since they had similar drive mechanics.

                Half tracks are based on just stepping the head once instead of twice (full track). You're right that the drive would likely clock in incorrect data in this case, but unless the side track was blank (i.e. a range of zeros = weak bits), it's not likely that the pattern would change every time the same range is read.

                Weak bits persisted in the CD and DVD standards, but there you had to come up with a varying pattern to intentionally force the spread-spectrum-style clocking to desync. A range of zeros wasn't enough because of how that was physically encoded.

                • Nate says:

                  Yeah, since it used GCR too and didn't track the index hole, all the same things apply as the 1541.


                  The major difference is that the 1541 has its own 6502, so it could load additional protection along the way without the host being aware of it or able to inspect its RAM directly.

                • Nate says:

                  This crack explains weak bits on the Apple II, however the author gets the electronics wrong for artistic license. There's no amplifier that's being adjusted dynamically, it's purely a matter of clock drift between two sources (the Apple II's 6502 and the much slower "clock" of the shift register on the drive controller). Since the speed of the motor wobbles slightly compared to a 1 Mhz sampling rate, the 1's clocked out will vary each rotation.


                • jwz says:

                  Ah, he talks about this in his Mr. Do crack:

                  The prologue ("D5 9B AB B2 9E BE")
                  looks important, but it's not. What's
                  important is what comes after it, and
                  what's being checksummed over and over:
                  a few sync bytes ($FF), then a long
                  sequence of zero bits. Because that is
                  what is actually on the original disk:

                  When we say a "zero bit," we really
                  mean "the lack of a magnetic state
                  change." If the Disk II doesn't see a
                  state change in a certain period of
                  time, it calls that a "0". If it does
                  see a change, it calls that a "1". But
                  the drive can only tolerate a lack of
                  state changes for so long -- about as
                  long as it takes for two bits to go by.

                  So what happens when a drive doesn't
                  see a state change after the equivalent
                  of two consecutive zero bits? The drive
                  thinks the disk is weak, and it starts
                  increasing the amplification to try to
                  compensate, looking for a valid signal.
                  But there is no signal. There is no
                  data. There is just a yawning abyss of
                  nothingness. Eventually, the drive gets
                  desperate and amplifies so much that it
                  starts returning random bits based on
                  ambient noise from the disk motor and
                  the magnetism of the Earth.


                  Returning random bits doesn't sound
                  very useful for a storage medium, but
                  it's exactly what the developer wanted,
                  and that's exactly what this code is
                  checking for. It's finding and reading
                  and checksumming the same sequence of
                  bits from the disk, over and over, and
                  checking that they differ.

                  Bit copiers will never duplicate the
                  long sequence of zero bits, because
                  that's not what they read. Whatever
                  randomness they get when they read the
                  original disk will essentially get
                  "frozen" onto the copy.

      • Jonathan says:

        This reminds me of the Amiga 'software preservation' community. Hacks like these make it really hard to preserve disk images for some games. The Amiga folks have built low-level disk reading hardware that stores not ones and zeroes for the data, but some kind of probability smear, as one measure to work around these.

        • jwz says:

          Wouldn't a 4x radial density scan of the track data be the way to accomplish this, though?


          • Nate says:

            Oh, that "previously" always makes me shudder. He ended up destroying one of the disk packs while "rescuing" it. It's great that he put in more work to recovering the data from the other pack, but a little more care could have been taken with the first one, such as consulting someone who had done this before.

            • Nate says:

              And yes, he was testing with a spare disk pack, but the process of "power it on repeatedly and see what burns out" is not recommended. He did destroy one of only a few remaining disk heads doing it this way.

            • jwz says:

              Well, those people are kind of thin on the ground... also as I recall, it was full of spiders, wasn't it?

              • Nate says:

                Old wasp nest, yeah.

                I appreciate the work he did. I just hope no one reads the paper and then replicates the gung ho approach on something irreplaceable. For example, he could have isolated some of the pieces (power supply, logic board, spindle, etc.) and made sure they powered up ok individually before flipping the switch on the whole thing and seeing what blows.

        • Nate says:

          You're probably talking about Kryoflux. It's not a "probability smear", it captures the timing between flux transitions without doing higher level decoding (GCR, MFM, etc.) This allows higher resolution images and capturing data which is non-conformant anyway, such as direct bit-encoded mastering marks that were never intended to be readable by the host system anyway.


          • Jonathan says:

            Sort-of, yeah. I wasn't thinking of Kryoflux specifically but I've been looking into that (and DiscFerret) because I have a pile of Amiga floppies to digitize (It's a back-burnered project, I think I have at least one not in the softpres archive, my list is here http://jmtd.net/log/amiga/). Thanks for explaining the technicals better, I didn't have a good handle on them.

  3. Phil says:

    The 40 character wide presentation is a nice touch.

  4. Paul N says:

    I'm so glad we live in the future. The people of 2015 clearly didn't have many entertainment options.

  5. phuzz says:

    I like the idea that this 4am person won't be happy until they have bypassed the copy protection on every single Apple II disk.

  6. Robert Thau says:

    I knew someone who was peripherally involved in cracking copy-protection like this, back in the day. At one point, I suggested to him that it was an awful lot of effort to go through to save $10. I was met with a look of utter contempt. No one was doing this to save money, I was told. They were doing it because breaking the copy protection was more fun than playing the game.

  7. James C. says:

    > Right out of the gate, I can tell this
    > is going to be fun(*). The branch at
    > $6404 jumps into the middle of the next
    > instruction, which confuses the monitor
    > disassembler.
    > (*) not guaranteed, actual fun may vary

    Fun was in fact had.

  8. Dear god. There is an entire collection of these. A large collection. We are looking at the life's work of the last great 6502 assembly hacker, right here.

    • Bill Paul says:

      Not only is there an entire collection, clicking on the splash screen image of the cracked game LOADS THE FUCKING GAME IN AN Apple ][ EMULATOR IN YOUR BROWSER SO YOU CAN PLAY IT.

  9. MattyJ says:

    Tangentially related for those of us who are middle-aged and like reading about old stuff, the blog The Digital Antiquarian is mandatory reading. I'm not at all affiliated with it, just a fan.

  10. Moofie says:

    Juiced.GS just did an interview with 4am that covers a lot more of his background and motivations. There is an overview of the issue with 4am in it here https://juiced.gs/2015/12/v20i4-now-shipping/ . Juiced.GS is a current Apple ][ magazine so they have a lot of interest in digital preservation and esoteric skills like 6502 assembly hacking.

  • Previously