Reverse Engineering the CIC

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

Post Reply
Zack S
Posts: 55
Joined: Mon Jan 02, 2006 12:45 am
Location: Orlando, FL

Reverse Engineering the CIC

Post by Zack S »

I wanted to try and RE the CIC, but have found little info on it. I know some guys were trying to get the source code using an electron microscope. I'd rather not go this route because it would be no different than getting the source from the patent like tengen did. Has any one ever tried to data log the communications between the key and lock? Maybe we could lower the clock speed to make it easier to log. This is just speculation on how I think it could work. I'm thinking that the Lock sends a number to the Key, then they both use this as the seed for some alogarithim or random number generator. After so many clock cycles the key sends it's results to the lock. The lock then compares it with what it calculated and responds accordingly. Does this sound feasible? Or am I way off track. Not having a CIC replacement is one of our biggest barriers in developing new games, so we need to crack this thing. Any suggestion would be greatly appreciated.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

My understanding is that the two CIC chips run identical programs and continually communicate some portion of their state between each other. If these communications differ, the NES goes into reset mode. I heard that someone once tried to log these communications, but even after hundreds of megabytes of data there was no repetition.

The electron microscope route to uncover the source code would not ultimately be to merely copy the source code, but to reverse-engineer it and write new code (for something more modern like a PIC microcontroller) that gives the same result as the original CIC code.

It's funny that modern encryption schemes like CSS and the like have been broken, but this ancient copy protection chip is still a mystery. :)
augnober
Posts: 23
Joined: Sun Jan 08, 2006 12:22 pm

Post by augnober »

Something to look into.. Has patent protection expired on this? It must have been more than 20 years since the patents were filed. Not knowing much about these things, I would expect the patent protection to last for about 15 years. If the protection has expired, then perhaps it wouldn't be necessary to be selective in your methods.
Zack S
Posts: 55
Joined: Mon Jan 02, 2006 12:45 am
Location: Orlando, FL

Post by Zack S »

I'm not against the SEM I just want to take a different approach.

Perhaps whoever tried datalogging it either wasn't thorough or maybe this thing needs a different approach. What if we just take a small sample and then try to find alogarithms that will produce the same output. It probably wouldn't take much to narrow down one that is the same. Assuming it is a 4bit MPU and we know for sure it's clock is 4Mhz. It can only perform so many operations. It probably transfers 1 or more nibbles at a time. For each nibble added the possibilites increase but it also reduces the amount of operations it can perform on it. When you take into account the 1hz square wave it outputs for reset. That only leaves 1s to apply an alogarithm. Not to mention the MPU probably takes multiple clock cycles per instruction. Any ideas on making a 2bit data logger?
User avatar
Quietust
Posts: 1918
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Post by Quietust »

Such a data logger has already been made by kevtris, and the data stream is extremely sparse - short bursts of '1' (each 3 clocks long) followed by huge spans of '0' (ranging from 76 to well over ten thousand).

Note that the CIC is clocked at 4MHz, but the clock is effectively divided by 4, resulting in two 1MHz data streams.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

If you write your own original program that performs the same function, then you are not violating the copyright, but you may be violating the patent. The patent has expired (filing + 20), but the copyright has not.

The biggest obstacle to CIC RE right now is the unknown 1. instruction set architecture and 2. layout of addresses in the internal ROM.
bunnyboy
Posts: 449
Joined: Thu Oct 27, 2005 1:44 pm
Location: CA
Contact:

Post by bunnyboy »

I dont think looking at the data stream is the solution, mainly because I have tried and failed =] Atari/Tengen also tried and failed. They eventually decapped the chip. I am waiting for ~6 more lockout chip versions to be decapped from neviksti, the same guy that did the other one on cherryroms. I am hoping the roms from all of them can be compared to get more architecture info. So far none of the permutations/inversions of the rom data match any Sharp instruction sets I have found.

If you want to look at the stream there is some important starting information. First is the bit rate is not as described on the patent info. This will be shown in the picts below. Second is there are only 16 unique streams, selected by the cic chip in the nes at the beginning. Each stream is apparently non repeating and constant, so record/playback is not an option. The data stream is very sparse with long and VERY long pauses between pulses.

Here is what I have learned so far, gathered from a usa nes-cpu-11 + logic analyzer. I connected directly to the cic in the nes, so dout is to cart and din is from cart. Ignore clock in all pictures except for the close up of the pulse. The first transaction syncs the chips using resetout line from nes->cart. Then the nes selects 1 of 16 streams, shown in the first 4 pulses. The length and pause between those pulses is shown close up. The clock does not seem to match the patents. After that the bits transferred are always the same, and resetnes goes high when the cart is authenticated ~1300uS later. When there is no cart, some bits are missing and resetnes stays low and starts the 1hz sequence. Now comes the sparse part. There is nothing for ~2.5mS, then a second transaction. All 16 possible second transactions are shown. I was hoping it was send 16 bits, wait 2.5mS, send 16 bits, etc but that doesnt line up later. The data transfers just keep going and are similarly sparse. Disconnecting either din or dout at any time causes it to go into reset so both chips are still looking for input from the other.

If I ever get some more free time I can capture more sequences, and also look at the protocol of the other country lockouts. I am guessing the other country ones just switch around what number each stream is.
User avatar
teaguecl
Posts: 211
Joined: Thu Oct 21, 2004 4:02 pm
Location: San Diego

Post by teaguecl »

tepples wrote:The biggest obstacle to CIC RE right now is the unknown 1. instruction set architecture and 2. layout of addresses in the internal ROM.
I agree, and I think the unknown ISA is the biggest of the problems. Using Nevitski's pictures I have transcoded the binary for the code. However, this is useless without knowing the instruction set. I haven't gone so far as to try to map it to the Sharp chips, but it looks like bunnyboy has done so. If there are any crypto experts out there that could take the info we have and turn it into a number crunching excercise that would be great. I'm sure we can round up enough cpu cycles to solve it, the problem is framing the question so that this approach can be tried.
Zack S
Posts: 55
Joined: Mon Jan 02, 2006 12:45 am
Location: Orlando, FL

Post by Zack S »

Thanks for all the info above. It should save me considerable time. I'm glad to see that I'm not the only one bothered by this unsolved mystery.

I pulled a couple CIC's off some carts and stuck them in a bread board. I don't have a logic probe so I'm just going to use the parallel port on my computer. I did some experiments and found that they still function @ 100Khz clock speed.

Do you think that the Lock selecting one of the 16 streams is the seed for the key to use as a number generator? If so than maybe analyzing all the streams together would make cracking the code easier.

I read the cherryrom forum about extracting the rom. Did anyone ever consider trying to make the ISA from scratch? Perhaps write a program to emulate a cpu that can easily swap out instruction sets. Then just let it cycle through all the different ones untill it outputs something that resembles the data streams. Could someone give me the link to the binary of the rom?
bunnyboy
Posts: 449
Joined: Thu Oct 27, 2005 1:44 pm
Location: CA
Contact:

Post by bunnyboy »

I put all my text files in a new directory at www.nesmuseum.com/10nes It has been a few weeks since I looked at all this so I'm not sure I remember what all of them are so use carefully....

D411_rom.txt - snes lockout rom dump, directly from rom array. snes has same chip, different rom

nescicrom.txt - nes lockout rom dump, directly from rom array. Bits and bytes are interleaved, figuring out how it is actually arranged is part of the problem.

nescicromuninterleaved.txt - uninterleaved data in the way I believe it is arranged. Split into top half (I think data) and bottom half (I think code).

romhex-le-inv.txt - uninterleaved, written in hex, little endian bits (i think). inv probably refers to whether the black in the rom pictures are a 0 or a 1.

romhexsn-le-inv.txt - not sure what the sn means compared to other hex file, could be rotating the bits 90 degrees...

popcount-bot.txt - this is an attempt to see how often bytes appear to guess at instruction sets. bot means only the second half of the rom is counted. The large amount of FF or 00 without it being in a solid block is somewhat confusing.

popcount-le-inv-bot.txt - same as above, but little endian bits. doesnt change the FF or 00 problem.

I also tried to find repeating consecutive byte pairs but there was nothing significant. I think there are similarities between nes and snes rom but not in anything bigger than 2 bytes in a row. My brother wrote all the manipulation programs so I should be able to get them from him and make them available, but he is gone for a few more days. He also wrote a quick disasm app for some of the Sharp instruction sets I found but they didnt make sense in any bit arrangements.

One method that might be interesting is to look at the Tengen cic clone. It has the Motorola logo on it so hopefully it is a standard cpu core from them. I sent one to be decapped and hopefully rom dumped. Would be much easier to match to common core like 680x instead of guessing at the entire architecture. Anyone know of a good source of images of the 6800 core? I am actually surprised none of the Tengen info has been found or leaked out.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

Did anyone ever consider trying to make the ISA from scratch? Perhaps write a program to emulate a cpu that can easily swap out instruction sets. Then just let it cycle through all the different ones untill it outputs something that resembles the data streams.
Interesting idea, almost like the Superoptimizer from years ago, which tried every sequence of several instructions to find the shortest one to carry out the desired operation.

One problem is, there are probably many instruction sets that would carry out the beginning correctly, but fail at some point due to the code relying on features at different times (i.e. carry or something).
User avatar
teaguecl
Posts: 211
Joined: Thu Oct 21, 2004 4:02 pm
Location: San Diego

Post by teaguecl »

bunnyboy wrote: One method that might be interesting is to look at the Tengen cic clone. It has the Motorola logo on it so hopefully it is a standard cpu core from them. I sent one to be decapped and hopefully rom dumped. Would be much easier to match to common core like 680x instead of guessing at the entire architecture. Anyone know of a good source of images of the 6800 core? I am actually surprised none of the Tengen info has been found or leaked out.
I agree, this sounds like the most promising approach. This was discussed over at CherryRoms a long time ago though, I figured the effort had been given up. Glad to see it's still in process. When you get the SEM photo's back please let us know, I'm not too bad with reading them.
User avatar
Quietust
Posts: 1918
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Post by Quietust »

Zack S: I noticed you added some of this information to the old NESdev wiki - you really should be adding this sort of stuff to the new wiki (currently hosted at http://nesdevwiki.ath.cx/) so we don't have to add it to the list of stuff to copy over.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
Zack S
Posts: 55
Joined: Mon Jan 02, 2006 12:45 am
Location: Orlando, FL

Post by Zack S »

I didn't realize there was a new wiki. I'll move everything over to it. Also does anyone know excactly what pins 11 to 15 are? I remember Kevin saying something about them being used address up to 16 on the same bus. This would require a 4bit address bus. Perhaps one of the five is a /CE input and the rest are /A[0..3]. I would think since they all are active low they should all be interchangable.

I just got 4 more college classes today so I might not have time to get to data logging anytime soon. Eventually I will though. Even if I can't crack the code, figuring out as much about it's operation as possible should make the ROM extracting much easier. It could even give insight on how the internals of the chip might work.
sevast
Posts: 107
Joined: Mon Oct 31, 2005 1:01 am

Post by sevast »

So, can some of this be translated into newbie? There are only 16 codes. Looking at some of the pictures above, they seem to be the same total length. How many bits or bytes long are they? Are there 16 total, or are there 16 sends and 16 replies? Is that all there is in a cycle?

You don't have to, but and explantion of how to read green squiggily lines would be great! I'm assuming that each bump on the 16 picture is 3 ones in bianary? The scale seems to go from -700 to 700. Does this mean 1,400 bits?

Are both chips sending at the same time or does one start a sending pattern and the other one start a reply? Is the first half of one of the sixteen transmissions a send and the second half a reply or something?

So there's very long lengths of zeros. What's the highest comon denominator?
Post Reply