UNABLE TO LOAD GAMEDON'T LOOK NOW, BUT I THINK WE JUST FOUND THE COPY PROTECTION.
26FAL
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 ???OH JOY, MORE OBFUSCATED CODE. THE "BNE" AT $0701 UNCONDITIONALLY BRANCHES INTO THE MIDDLE OF THE NEXT INSTRUCTION, WHICH CONFUSES THE MONITOR'S BUILT-IN DISASSEMBLER.
2703:EA
26FAL26FA- 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),YOOPS, THERE'S ANOTHER ONE. $0706 IS A BRANCH TO $070B, WHICH IS SHOWN IN THE MIDDLE OF AN INSTRUCTION AGAIN.
270A:EA
I'LL SPARE YOU THE GORY DETAILS, BUT THERE ARE A FEW MORE OF THESE. JUST A FEW. 16. THERE ARE 16 MORE.
2713:EA
271B:EA
2722:EA
272A:EA
2731:EA
2739:EA
2740:EA
274A:EA
2751:EA
2754:EA
275E:EA
2766:EA
276E:EA
2776:EA
277D:EA
2786:EA
It goes on like this for like, days:
]PR#6
...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 SectorsLet'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.
<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>
Ah, I thought DOS meant DOS, not DOS.
This was my life as a teenager :-)
My teenage years looked like this, to some degree. Nice to see the crack so well-documented.
Was it common for the copy protection to be so complex? I figured they wouldn't try nearly this hard!
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.
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.
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.)
Because that wasn't going to work:
See the epilogue; he has to fix that check anyway.
"It's a challenge", I guess.
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.
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.
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.
Yeah, since it used GCR too and didn't track the index hole, all the same things apply as the 1541.
http://www.bigmessowires.com/2015/08/27/apple-ii-copy-protection/
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.
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.
https://archive.org/details/MrDo4amCrack
Ah, he talks about this in his Mr. Do crack:
Previously
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.
Wouldn't a 4x radial density scan of the track data be the way to accomplish this, though?
Previously.
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.
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.
Well, those people are kind of thin on the ground... also as I recall, it was full of spiders, wasn't it?
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.
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.
http://goughlui.com/2013/04/21/project-kryoflux-part-4-the-hidden-secrets/
http://goughlui.com/2013/04/21/project-kryoflux-part-3-recovery-in-practise/
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.
The 40 character wide presentation is a nice touch.
I'm so glad we live in the future. The people of 2015 clearly didn't have many entertainment options.
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.
It's a far less open-ended mission than many.
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.
>
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 varyFun was in fact had.
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.
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.
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.
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.