CIC-NUS: Difference between revisions
m
Fix 6101 and 7102 information.
No edit summary |
m (Fix 6101 and 7102 information.) |
||
| (8 intermediate revisions by one other user not shown) | |||
Line 5:
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.
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/IPL3 variants
Line 29:
|6101
|Starfox 64
|u32@0x08
|
* Similar to 6102 with minor code differences.
|-
|7102
Line 37:
|0x80000480
|
*
|-
|6103 / 7103
Line 100:
[[File:CIC decap pinslabeled.png|alt=CIC decap pins labeled|thumb|'''CIC decap pins labeled''']]
{| class="wikitable"
Line 126 ⟶ 127:
|Pin 15
|P2:0
|DIO (to PIF)
|-
|
Line 134 ⟶ 135:
|Pin 14
|P2:1
|DCLK (to PIF)
|-
|
Line 176 ⟶ 177:
|!RESET
|}
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.
| |||