Nintendo's weird and wonderful CIC lockout chip
hackmii.com
hackmii.com
Typical game cartridge contained multiple games (i.e., for example, Mario, Contra and Ninja Turtles could be on the same cartridge) and was quite inexpensive. I didn't realize for years that in US one game would cost 10 times more than 10 games one cartridge for Dendy. Ah, golden days of piracy.
Naturally, this wasn't a popular move. Many things were tried to force Nintendo into making their console open, from the legislative (anti-trust suits) to the technical (in early NES revisions, a high-voltage spike to the CIC chip at startup would disable it until the console was reset... Nintendo stopped that soon enough). Eventually Atari, embittered that Nintendo had succeeded where they had failed, decided to devote their engineering resources to reverse-engineering the CIC chip. After many months of work, they finally presented their own equivalent to the CIC, which they called the Rabbit, and used it in a few games including a version of Tetris.
Nintendo was highly skeptical that Atari could have decoded their CIC chip, and sued them[1]. It came out that despite their best efforts, Atari had failed to reverse-engineer the CIC, and quietly requested a copy of the CIC program from the Copyright office, messed it around a bit and called it Rabbit. Things did Not Go Well for Atari after that. [2]
Fast forward to 2006, where the NES homebrew community (who so far had been making their NESs homebrew compatible by simply snipping the RESET pin off the CIC chip) decided that since the CIC patents had expired, and since so much reverse-engineering hardware was available to hobbyists, they should have a crack at the Greatest Unsolved Mystery of NES Programming, and began to poke around. If you've got a few hours, I recommend reading the forum thread[3] as an excellent example of clever, creative, knowledgeable people working on an interesting problem.
For the less patient, even twenty years later, the CIC still resisted the best efforts of dedicated researchers... until one of them decided to abandon the CIC, and start poking at a Rabbit chip instead. After poring over a decapped Rabbit and trying to decipher its workings, somebody noticed a few circuit traces with no obvious purpose snaking across the silicon. It turns out the Atari engineers must have wanted to save others the stress and heartache they'd suffered through themselves: when Rabbit is hooked up like CIC, it behaves identically - but if a voltage is applied to a seemingly unused pin, another pin suddenly begins broadcasting the internal state of the chip after every stage of the algorithm. Once they had that bitstream, it was simple to figure out the instructions Rabbit was executing, and from there to put together the entire CIC algorithm.
These days, CIC is a Solved Problem as the original post shows... but it's impressive how long it lasted, considering how short-lived some content protection systems are these days. The only other system I know that's been remarkably long-lived is the original Playstation's - it's well understood by now, but there's still no way for ordinary consumers to burn a disc that will play on an unmodified PS1.
[1] http://digital-law-online.info/cases/24PQ2D1015.htm
[2] For more information on the early history of Nintendo up to the late SNES era, see the excellent book "Game Over" by David Sheff: http://www.amazon.com/dp/0679736220/
i'm not super-proud of it, but i got started in programming by breaking the copy protection of dos games. i ran the game on my color monitor and borland's turbo debugger on the monochrome one, and single-stepped my way through the code until i had figured it out. then i'd use the norton utilities to find a particular code string in the executable on disk, and patch it with my NOP'ed out version. twenty years later and i still have the byte patterns of many 8086 machine language instructions memorized.
this would have just been harmless fun, except i posted my cracks on the BBSes of the day. well, i was young.
http://www.jonandkarrie.com/images/prints_028-2.jpg
I know why you might want to post the fruits of your labors to BBS's. When I tried to boast of my accomplishments to friends of the day, I couldn't get them past "you can have two monitors on the same computer and they both go!?"
i could always tell the difference between the companies that rolled their own weak-ass protection schemes in-house, and the ones who ponied up for the good stuff, like softguard.
the simplest game i ever broke, before i even owned turbo debugger, was the dos version of rampage. all i had to do was NOP out three calls to INT 10h, the bios direct disk interrupt, and it wasn't able to 'see' the corrupted sectors on its copy-protected floppy anymore.
in the mildly difficult range was this flight simulator i cracked for a friend. i found the protection function that i wanted to NOP out and wrote down the sequence of bytes that needed to be changed. but when i searched the executable with norton, those bytes weren't found! further exploration revealed that the programmers had applied some weak XOR-style "encryption" to the copy protection routine i was trying to get rid of. i had to write a little utility in C to break that one.
i tried to break several of the sierra games, like king's quest. but they were using their own in-house interpreter, so trying to crack it with an 8086 assembler was approaching the problem at the wrong level of abstraction. i couldn't do it.
i never did manage to get any of the softguard games, either. they were doing really wicked things like using the INT 1 and INT 3 interrupt vectors as scratch space. they knew perfectly well that people like me needed those interrupts to be intact for our debuggers to work. i tried redirecting the first 100 calls to a different area of memory, but they were really fiendishly thorough. i gave up.
bet you've got some good stories, too. hint hint.
I spent a huge amount of time on my Amiga tweaking disk copy algos to foil those rotten floppies that had tiny holes physically burned or punched into the medium. After you got the damn thing to copy, then you had to hunt through the executable to find out what behavior the program expected from the disk drive when it encountered the hole and put in a jump to skip this.
I remember my 13 year old self exclaiming "they use the drive error as the key?! That's just diabolical!"
[Edit] You already answered that. I had a 1200 bps modem for that rig around the same time and would sit around on BBS'es for hours.
Those were good times. Damn I feel old.
Apologies to johnyzee, there is an A500 around there somewhere, but Nate's right. Look at the round 488 connectors in the middle. Thats a 64-c alright. I was trying for the life of me to figure out why my a500 would have been down there on that cart looking so disused.
That sounds like a JTAG ( http://en.wikipedia.org/wiki/Joint_Test_Action_Group ) scan for test purposes. Basic idea is that registers on logic block boundaries are turned into a shift register that pumps out the internal state.