CIC-NUS: Difference between revisions
m
Fix 6101 and 7102 information.
No edit summary |
m (Fix 6101 and 7102 information.) |
||
| (3 intermediate revisions by one other user not shown) | |||
Line 29:
|6101
|Starfox 64
|u32@0x08
|
* Similar to 6102 with minor code differences.
|-
|7102
Line 37:
|0x80000480
|
*
|-
|6103 / 7103
Line 127:
|Pin 15
|P2:0
|
|-
|
Line 135:
|Pin 14
|P2:1
|
|-
|
Line 184:
=== '''Physical connection with PIF''' ===
Each CIC is connected to PIF via two lines: Pin 14 (aka
=== Boot sequence ===
==== 1. ID ====
[[File:ID nibble.png|thumb|ID nibble with value 0101 (yellow =
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).
Line 199:
==== 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 =
For instance, the transmitted sequence for a CIC 6102 which uses 0x3F as seed is <code>B5 3F 3F</code>.
Line 217:
==== 4. Checksum ====
[[File:Checksum.png|thumb|A checksum transmitted to PIF (yellow:
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.
Line 236:
==== 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
==== 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).
==== 4. Command "Reset" (bits: 10) ====▼
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) ====
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.
| |||