CIC-NUS: Difference between revisions

m
Fix 6101 and 7102 information.
(Created page with "==== CIC ==== '''Disclaimer: All of the CIC 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.''' alt=CIC decap pins labeled|thumb|'''CIC decap pins labeled''' {| class="wikitable" |+CIC/IPL variants !Variant !...")
 
m (Fix 6101 and 7102 information.)
 
(11 intermediate revisions by 2 users not shown)
Line 1:
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.
==== CIC ====
 
'''Disclaimer: All of the CIC 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.'''
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.
[[File:CIC decap pinslabeled.png|alt=CIC decap pins labeled|thumb|'''CIC decap pins labeled''']]
 
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.
{| class="wikitable"
|+CIC/IPLIPL3 variants
!Variant
!Used in
!RealGame Entrypoint[1]
!Comment
|-
|6102 / 7101
|Most titles (~ 88% of commercial games)
|u32@0x08
|
* Identical IPL between NTSC (6102) and PAL (7101)
|-
|5101
Line 16 ⟶ 29:
|6101
|Starfox 64
|u32@0x08
|0x80000480
|
* Similar to 6102 with minor code differences.
* Entrypoint is hard-coded to 0x80000480 whatever the ROM header says.
|-
|7102
Line 24 ⟶ 37:
|0x80000480
|
* IdenticalEntrypoint to 6102 except that it hardcode entrypointhardcoded to 0x80000480; whateverotherwise theidentical ROMto header says6102.
|-
|6102 / 7101
|Most titles
|u32@0x08
|
* Identical IPL between NTSC (6102) and PAL (7101)
|-
|6103 / 7103
Line 39 ⟶ 46:
|-
|6105 / 7105
|Banjo-Tooie, Perfect Dark, Zelda OOT, Zelda MM, ...
|u32@0x08
|
* Identical IPL between NTSC (6105) and PAL (7105)
* More complex protection scheme which involves the RSP at boot, plus a special challenge/response security protocol that is invoked by the CPU during gameplay.
|-
|6106 / 7106
Line 50 ⟶ 57:
|
* Identical IPL between NTSC (6106) and PAL (7106)
* HasThe IPL3_part2second part of IPL3 is ciphered
* No junk byte at the end
* (It should have been called 6104, but "4" is the "unlucky" number, so it was renamed to 6106.)
|-
|5167
Line 59 ⟶ 66:
u32@0x101c if u16@0x16 == 0
|
* This is an "imaginary" CIC that does not exist in physical shape. It was used as part of the home-brew effort to convert 64DD games from the disk format to the cartridge format, to facilitate playing pirated versions on emulators and flashcarts.
|-
|8303
Line 76 ⟶ 84:
|
|}
[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 ==
[[File:CIC decap pinslabeled.png|alt=CIC decap pins labeled|thumb|'''CIC decap pins labeled''']]
{| class="wikitable"
|+CIC Pinout (16 Pin DIP Package)
Line 100 ⟶ 127:
|Pin 15
|P2:0
|DIO (to PIF)
|D_OUT
|-
|
Line 108 ⟶ 135:
|Pin 14
|P2:1
|DCLK (to PIF)
|D_IN
|-
|
Line 150 ⟶ 177:
|!RESET
|}
 
The test modes of the CIC are available on most (all?) retail cartridges.
== 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 ====
[[File:ID nibble.png|thumb|ID nibble with value 0101 (yellow = DCLK, cyan = DIO)]]
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).
[[File:Seed.png|thumb|Scrambled seed (yellow = DCLK, cyan = DIO)]]
For instance, the transmitted sequence for a CIC 6102 which uses 0x3F as seed is <code>B5 3F 3F</code>.
 
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 <code>B5 3F 3F</code>is scrambled as follows:
 
* The second byte <code>3F</code> is added to the first byte <code>B5</code>, producing <code>F4</code>, which is further incremented becoming <code>F5</code>.
* The third byte <code>3F</code> is added to the scrambled second byte <code>F5</code>, producing <code>34</code>, which is further incremented before <code>35</code>.
 
The resulting scrambled sequence is then <code>B5 F5 35</code>, 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 ====
[[File:Checksum.png|thumb|A checksum transmitted to PIF (yellow: DCLK, cyan: DIO)]]
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|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 <code>3F DF</code> and the checksum is <code>A5 36 C0 F1 D8 59</code> (which is the actual CIC 6102 checksum secret), the final sequence transmitted is <code>3F DF A5 36 C0 F1 D8 59</code>which is scrambled and put on the wire as <code>3F 57 29 3E 54 7C F5 90</code>.
 
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 <code>0x0A 0x0A</code>. These represent a timeout for the PIF (interpreted as <code>0x0A0A</code> = 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 [https://github.com/jago85/UltraCIC_C/blob/3450b4403a1df190b9abb2dbe071ce07a546179b/cic_c.c#L292-L322 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) =====
Line 185 ⟶ 293:
 
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
 
==== PIF ====
[[File:PIF decap pins labeled.png|alt=PIF Decapped with Pins numbered|thumb|PIF Decapped with Pins numbered]]
The PIF handles a lot of very core functions in the console. While the PIF chip is clearly a custom part, it appears to be heavily based on the SM5K (4/5/6) series. The instruction set and features match closely.
{| class="wikitable"
|+PIF Pinout (28 Pin SOP Package)
!
!N64 Function
!SM5 Function
!Pin
!
!Pin
!SM5 Fuction
!N64 Function
!Direction
|-
|
|PIF Clock
|
|Pin 1
|
|Pin 28
|VDD
|VDD
|Power
|-
|
|RC Cold
|
|Pin 2
|
|Pin 27
|
|Reset Button
|Input
|-
|
|CIC D Out
|
|Pin 3
|
|Pin 26
|
|N/C (No Connect)
|
|-
|
|RC Rand
|
|Pin 4
|
|Pin 25
|
|INT 2 VR4300 CPU
|Output
|-
|
|CIC D In
|
|Pin 5
|
|Pin 24
|
|EEPROM Data
|I/O
|-
|
|/Cold
|
|Pin 6
|
|Pin 23
|
|EEPROM Data
|I/O
|-
|
|NMI VR4300 CPU
|
|Pin 7
|
|Pin 22
|
|Player 4 Controller
|I/O
|-
|
|Power Good
|
|Pin 8
|
|Pin 21
|
|Player 4 Enable
|Output
|-
|
|PIF CLK Input from RSP
|
|Pin 9
|
|Pin 20
|
|Player 3 Controller
|I/O
|-
|Input
|Test 0
|??
|Pin 10
|
|Pin 19
|
|Player 3 Enable
|Output
|-
|
|PIF ADR from RSP
|
|Pin 11
|
|Pin 18
|
|Player 2 Controller
|I/O
|-
|Input
|Test 1
|??
|Pin 12
|
|Pin 17
|
|Player 2 Enable
|Output
|-
|
|PIF DATA from RSP
|
|Pin 13
|
|Pin 16
|
|Player 1 Controller
|I/O
|-
|Power
|GND
|GND
|Pin 14
|
|Pin 15
|
|Player 1 Enable
|Output
|}
 
=== References ===
1

edit