Some notes on Buck Rogers:
First off, sectors on tracks are normally delimited by "sync fields" of nibbles that allow the disk controller code to get in phase with the nibbles, no matter where it starts. (It can't tell where it is within a track when it seeks to it.)
1/
First off, sectors on tracks are normally delimited by "sync fields" of nibbles that allow the disk controller code to get in phase with the nibbles, no matter where it starts. (It can't tell where it is within a track when it seeks to it.)
1/
"Sync" nibbles are usually eight "1" bits (0xFF) followed two "0" bits. Because reasons (read "Beneath Apple DOS"), this allows 6502 disk reading code to get back in sync quickly if it happened to start reading data in the middle of a byte, which happens most of the time.
Furthermore, the Disk ][ has a hardware limitation that limits the stable representation of data on disk: it can only reliably read two "0" bits in a row. This is why sector data can't just be stored as-is on disk; there has to be an intermediate format (6-and-2 encoded nibbles).
Some disks use this 2-zeroes-in-a-row limitation to their advantage by putting a large number of zeroes in a row and checking that multiple reads of that region produce different values. The nondeterminism isn't replicated by bit copiers, so it works well as a runtime protection.
"Buck Rogers: Planet of Zoom" takes this hardware limitation to an extreme by building it into every since sync field before every single sector on every single track. Instead of "1111111100" (0xFF + two zeroes), it uses "1111100000".
That's right. FIVE zeroes in a row.
That's right. FIVE zeroes in a row.
Every "0" bit after the first two in a row has about a 50% chance of spontaneously becoming a "1" bit, so this sequence eventually synchronizes just by random chance. It takes a long time though—lots of missed sectors that are only read the second or third or fourth around.
The reason this is copy protection is that bit copiers can't replicate the five "0" bits in a row, because that's not what they read. They write out whatever mix of 0s and 1s they read. Stastically, some sectors will get invalid sync fields and never be read properly on the copy.
I have examined hundreds of copy protection schemes on thousands of disks. "Buck Rogers: Planet of Zoom" is uniquely insane.
So... virtually impossible to bit copy. But copy protection != crack protection. How difficult is this to crack, for someone who knows how to trace the Apple ][ boot process?
Oh sweet summer child, strap in, because this is where it gets weird.
Oh sweet summer child, strap in, because this is where it gets weird.
T00,S00 LOOKS like a normal DOS 3.3 boot at first glance, but $0800 is actually #$10 so it loads all 16 sectors from track 0 before it even gets to $0801, and by then the standard condition ($27=#$09) is false so it falls through to the JMP ($08FD) 
$08FD is a weird value (#$0D) and is incremented twice and ends up at #$0F, so when we JMP ($08FD), execution continues at $0F00.
At $0F00 is a decryption loop that LOOKS like it's just trashing the language card at $D000, but ACTUALLY wraps around and trashes zero page, the stack, the input buffer, the text page, and finally trashes the boot code at $0800..$0F00, which includes this decryption loop itself.
So the JMP ($0F70) is a complete red herring. Execution never reaches that far because the loop itself trashes the loop.
So where does execution go instead? When it "decrypts" $0F16, it changes the opcode into a branch instruction which matches, and execution continues at $0E99.
So where does execution go instead? When it "decrypts" $0F16, it changes the opcode into a branch instruction which matches, and execution continues at $0E99.
$0E99, of course, has just been decrypted.
By the way, the $74 opcode at $0F16 (that is changed to a branch) is an undocumented opcode. On a 65c02, it's STZ zero-page,X. But on a 6502, it functions as a 2-byte NOP. The built-in dissasembler in the Apple ][ monitor treats it as a 1-byte NOP and corrupts the listing.
I mention this because the next phase of the code—at $0E99, which jumps to ($0ED0), which points to $0E0D—has not one but three of these $74 opcodes, just to make it that much more difficult for the determined cracker who made it this far.
/fin
/fin
