CIC-NUS
The CIC-NUS (usually called "CIC") is a protection chip that is present on all N64 cartridges and implements the required security measures to allow the game to boot on an unmodified console.
Once the cartridge is inserted into the slot, the CIC is electrically connected to the PIF-NUS, the peripheral and protection chip within the N64 itself, via two lines (roughly, clock and data), and communicates with it. The PIF is in charge of securing the boot sequence and is able to halt the CPU if the protection fails, preventing the game from booting. Since the PIF can be regarded as the "master" of the communication between the CIC and itself, the whole boot sequence is documented in the PIF-NUS page in the wiki. Please refer to it for more details about how the secure boot works.
The 64DD (which plugs to the bottom of the console) comes with its own CIC. The N64DD games on the magnetic disk support do not have a CIC themselves, so the secure boot is completed by the 64DD firmware, which then loads the games from the disk and boot it.
Variants
There are different models of CIC, which normally differentiates themselves for small details in the firmware and different "secret keys" used to secure the boot. As explained in the PIF-NUS page, each variant of the CIC comes in pair with a different boot software (called IPL3), which is part of the secure boot, and is embedded in the cartridge itself (in a special area of the ROM: offset 0x40 - 0x1000). A mismatch of IPL3 with CIC would be detected by the previous secure boot stage (IPL2) which is hardwired in the console itself because of a failed checksum.
The following table lists all known CIC variants, with some overview of the main differences between them. Notice that the security keys are instead listed in the PIF-NUS page, in the section related to the secure boot.
| Variant | Used in | Game Entrypoint[1] | Comment |
|---|---|---|---|
| 6102 / 7101 | Most titles (~ 88% of commercial games) | u32@0x08 |
|
| 5101 | Aleck 64 titles | u32@0x08 - 0x100000 | |
| 6101 | Starfox 64 | u32@0x08 |
|
| 7102 | Lylat wars | 0x80000480 |
|
| 6103 / 7103 | Banjo-Kazooie, Diddy Kong Racing, ... | u32@0x08 - 0x100000 |
|
| 6105 / 7105 | Banjo-Tooie, Perfect Dark, Zelda OOT, Zelda MM, ... | u32@0x08 |
|
| 6106 / 7106 | F-ZeroX, Yoshi's Story, ... | u32@0x08 - 0x200000 |
|
| 5167 | 64DD ROM conversion | u32@0x08 if u16@0x16 != 0
u32@0x101c if u16@0x16 == 0 |
|
| 8303 | 64DD IPL Retail (J) | u32@0x08 |
|
| 8401 | 64DD IPL Dev (J) | ||
| 8501 ? | 64DD IPL Retail (U) |
[1] IPL3 is in charge for loading the game into RDRAM and jumping to its entrypoint. Normally, for instance in the case of the IPL3 code for the vastly popular CIC 6102, the entrypoint is stored in the ROM header at a fixed offset and is thus readily available. Some IPL3s somehow "mangle" the entrypoint, possibly in an effort to obfuscate it. This table reports where the entrypoint is.
UltraCIC
The name "UltraCIC" normally refers to a physical chip that can acts as a CIC clone. There have been a few projects sharing this name, based on several different MCUs. Normally, the project can be found on GitHub as open source, complete with the full source code. These clones are normally found in "reproduction cartridges" (aka physical cartridges that can be bough and programmed to eg. distribute physical copies of a homebrew game) to allow the cartridge to boot correctly on a real N64.
UltraCICs are normally "universal", that is, they can act as any CIC variant. To switch variant, it is necessary to either flash a modified firmware, or send a custom command typically through a different bus available to the MCU (eg: SIPO).
Programmable flashcarts such as Everdrive 64 or 64drive also features some sort of "UltraCIC" to allow games to boot. Sometimes the CIC emulation functionality is provided by the main FPGA, while in other cases it is a real separate chip.
These are a few links to explore:
- https://github.com/jago85/UltraCIC_C
- https://github.com/perkinsb1024/UltraCIC-II
- https://github.com/ManCloud/UltraCIC-III
Pinout
| N64 Function | SM5 Function | Number | Number | SM5 Function | N64 Function | |
|---|---|---|---|---|---|---|
| VDD | VDD | Pin 1 | Pin 16 | VDD | VDD | |
| P5:0 | Pin 2 | Pin 15 | P2:0 | DIO (to PIF) | ||
| P5:1 | Pin 3 | Pin 14 | P2:1 | DCLK (to PIF) | ||
| P5:2 | Pin 4 | Pin 13 | P2:2 | GND | ||
| P5:3 | Pin 5 | Pin 12 | P2:3 | |||
| GND | TS:0 | Pin 6 | Pin 11 | CLK | CLK | |
| GND | TS:1 | Pin 7 | Pin 10 | TIO | ||
| GND | GND | Pin 8 | Pin 9 | Reset | !RESET |
Description of operation
This section tries to detail how a CIC works. The differences between CICs themselves are actually minimal and mostly related to data (region, security keys) rather than code (functionality).
The CIC is powered by a Sharp SM5 core, running a custom firmware that is burnt within the chip and cannot be modified. Most of the CIC firmwares have been dumped via a trick explained below in the section "Hacking the CIC", and the firmwares have been analyzed. This link https://github.com/jago85/UltraCIC_C/blob/master/cic_c.c contains a C implementation very faithful to the original firmware that can be regarded as a pseudo-code reference of the workings of CIC. Everything described in this section can be cross-referenced to that C source code.
Physical connection with PIF
Each CIC is connected to PIF via two lines: Pin 14 (aka DCLK) and pin 15 (aka DIO). In this simple serial protocol, the PIF acts as the master, and the CIC as the slave. Whenever the PIF firmware is ready to send or receive data, it will pulse the DCLK line and then either move the DCLK line (in case PIF is wiring), or read the line status as moved by CIC (in case of reading). The protocol makes it clear beforehand whether a write or a read should happen. Any time the CIC needs to either read a data from the PIF or write a data for it, it spins waiting to see the front on the DCLK line.
Boot sequence
1. ID
The CIC writes 1 nibble (4 bits) to the PIF called "ID". The bits are as follow (in order of transmission, so what we call here "bit 0" would actually be "bit 3" in a reconstructed 4 bit register).
- Bit 0: "type". This is 0 for normal CICs, and 1 if the CIC is part of a 64DD unit.
- Bit 1: "region". This is 0 for NTSC CICs, and 1 for PAL CICs. This value is hardcoded in the firmware, which makes the CIC region-locked.
- Bit 2: always 0
- Bit 3: always 1
2. Seeds
The CIC writes 6 nibbles which contains one of the boot secrets: the checksum seeds. These are 2 seeds of 1 byte each one, called IPL2 seed and IPL3 seed (please refer to the PIF-NUS page for a description of how these seeds are then used by PIF). In all known PIF variants, the two seeds happen to be exactly the same byte, even though the protocol would allow for them to differ. A table in the PIF-NUS page lists the seeds for all known CIC variants. In addition these 2 bytes, a third byte is transmitted first, which is a fixed value (0xB5).
For instance, the transmitted sequence for a CIC 6102 which uses 0x3F as seed is B5 3F 3F.
Before putting the data on the wire, the 3 bytes are scrambled via a very light obfuscation algorithm to avoid to directly leak the secrets on the wire. The algorithm is very simple: starting from the second byte, each byte is added to the previous one, and the result is further incremented by 1; the first byte is not changed.
For instance, the sequence B5 3F 3Fis scrambled as follows:
- The second byte
3Fis added to the first byteB5, producingF4, which is further incremented becomingF5. - The third byte
3Fis added to the scrambled second byteF5, producing34, which is further incremented before35.
The resulting scrambled sequence is then B5 F5 35, which is transmitted as 6 nibbles on the wire.
3. Random entropy
The CIC now waits for the Data CLK line to go low. While the pin stays high, the CIC keeps incrementing an internal memory location.
On the other side of the line, the PIF is now executing a part of the boot process in sync with the CPU, and at some point it is also using a hardware time-based random number generator (it's waiting for a capacitor to charge in a RC connected to one of its pin). Once this is done, the PIF puts the DCLK line low. The amount of time it takes to get this is subject to some entropy (mostly because of the time-based RNG), and thus the CIC will increment the memory location a number of times that changes across boots, which in turns produces something akin to a random number.
4. Checksum
The CIC writes 16 nibbles which contain the other boot secret: the IPL2 checksum. This is a 6 byte checksum that is used by the PIF to verify that the IPL3 found in the cartridge is the correct one for this CIC. The exact process (that also involves the CPU at its IPL2 stage) is detailed in the PIF-NUS page.
As a prefix to the 6 byte (12 nibble) checksum, 2 bytes (4 nibbles) are prefixed. These bytes come from the random number generated in the previous step and are thus different at each boot.
The resulting 16 nibbles (4: random prefix + 12: checksum) are then scrambled using the same algorithm detailed in the section above related to seeds. As an example, if the random prefix is 3F DF and the checksum is A5 36 C0 F1 D8 59 (which is the actual CIC 6102 checksum secret), the final sequence transmitted is 3F DF A5 36 C0 F1 D8 59which is scrambled and put on the wire as 3F 57 29 3E 54 7C F5 90.
After the checksum has been transmitted, the boot sequence is finished, and the CIC enters its main operation loop.
Main loop
During the main loop, the CIC waits until the PIF transmits a 2-bit command. After a command is received, the CIC executes the command, which might involve receiving additional bits from PIF and/or transmitting bits to it. After this a command is processed, the CIC starts wiring for the next command.
The main loop never exits. Notice that the CIC is not affected by the soft reset (presses of the RESET physical button on the console), as those are handled by PIF resetting the CPU, but do not directly affect the CIC; the boot sequence in fact is not repeated.
The follow paragraphs detail the 4 different commands that can be sent by PIF.
1. Command "Compare" (bits: 00)
2. Command "Die" (bits: 01)
When the CIC receives this command, it enters an infinite loop in which it does nothing, thus stopping any communication with PIF, until powered off.
3. Command "Challenge" (bits: 10)
This command is fully implemented only on CIC 6105 / 7105. All other CICs contain a dummy version of this command that does almost nothing (see below).
When the CIC receives this command, it begins a challenge / response security protocol: the protocol receives some bytes from the PIF (actually, coming from the CPU via the PIF), runs a "secret" security algorithm that also uses some tables in ROM, and sends back some other bytes. The CPU can check whether the answer is what it was expected and if so, it can confirm that the CIC 6105 is legit. This was based on the fact that counterfeiting the security protocol was deemed to be hard (and in fact, it required some time to be reverse engineered even before the CIC firmwares were dumped).
After receiving this command, the CI first writes 2 nibbles with the fixed value 0x0A 0x0A. These represent a timeout for the PIF (interpreted as 0x0A0A = 2570 iterations of a wait loop, so it was probably hand-tuned and tested): they given an indication of how much time the PIF will have to wait before being able to read the response. Remember that PIF is the master of the communication, so it has no way to "wait for the CIC to be ready to send data": when the PIF pulses the clock line, it expects the CIC to be ready to immediately send the data. So for this algorithm, the designers decided to let the CIC send the expected duration to PIF, probably to be able to change the algorithm in newer CIC versions without having to change the PIF as well.
After sending the timeout, the CIC receives 30 nibbles (15 bytes) which is the challenge string. The challenge string is transformed through a security algorithm that we will not try to cover here as it is pretty convoluted, but can be studied in one of its C implementations.
Then, the CIC sends a 0 bit to PIF (used such as a "start" bit), followed by the 30 transformed nibbles. After this, it goes back to the main loop.
It is important to notice that most CIC variants (all excluding 6105 and 7105) do not implement the full algorithm. Instead, the challenge string is simply bit-inverted and sent back to PIF. In fact, no known software relies on this dummy challenge algorithm.
4. Command "Reset" (bits: 10)
Hacking the CIC
This section describes a way that can be used to hack the CIC, that is take control of it up to the point of dumping its internal ROM. The actions described below have been done successfully as part of a University project. Some of the details are missing whether it was to avoid encouraging piracy, simply not required for the core of the paper or lost in the language translation (authors live in Germany) is unknown.
The main entry point is to use the "test mode", a feature of the SM5 core that is available on known CIC variants.
To Enable Test Mode(s)
Pulling TS:0 and/or TS:1 high before power on will place the SM5 controller in one of 3 test modes. (Which test modes and which pin states are unknown) It's also unclear if you can change between test modes while the unit is powered on.
The fourth state is standard usage with TS:0 and TS:1 tied to ground.
It's unknown how slowly you can clock the CIC.
In Test Mode
Which mode is still unclear but the following functionality is available.
Arbitrary Code Execution
Instructions can be set 1 nibble at a time on Port 5 pins, most instructions are 1 byte long so they must be entered 1 nibble at a time then toggle the clock line.
Halt Instruction
The Halt instruction is encoded as 0x77 which is nice because it doesn't matter which nibble you send first. This instruction also has a nice benefit of causing a clear external change, the TIO line defaults to the Clock signal but after the Halt instruction it stops outputting a clock signal.
Stop Instruction
The Stop instruction is encoded as 0x76 which will assist in determining if the high or low nibble should be input first. This instruction also stops the TIO clock upon execution, so we have a clear external indication of success.
Output Data
Port 2 of the CIC can be used to output either the AREG register or the Program Counter (PC), it's unclear at this time if the difference is achieved with different test modes or by modifying internal configuration registers.
NOTE: On power up Port 2 is configured for Input, an internal configuration register must be modified to make it output.
Load Constant into Accumulator LDX
The LDX instuction can be used to populate the AREG with a known value that can be checked on Port 2
Dumping the CIC code
This process is very confusing so it may take some experimentation to work out the exact steps and details, the original document tries to explain but it feels like some details are missing.
Jump Instructions are 2 bytes, the first nibble is the instruction and the following 12 bits are the destination address.
Being in test mode seems to have a side effect on this instruction, inputting only the Jump instruction followed by a zero nibble, the second byte is loaded from the ROM, which is an instruction but is treated as data. The Jump instruction is then executed and the PC can be viewed on Port 2, as well
References
https://sites.google.com/site/consoleprotocols/home/techinfo/lowlevel/pif12
https://code.google.com/archive/p/mupen64plus/wikis/SoftResetNotes.wiki