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 | 0x80000480 |
|
| 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 | Data I/O (to PIF) | ||
| P5:1 | Pin 3 | Pin 14 | P2:1 | Data CLK (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 |
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