Mii: Difference between revisions

Wwylele (talk | contribs)
Mii Database: Confirmed another checksum according to MarioCart DLP child code
Wwylele (talk | contribs)
No edit summary
Line 2: Line 2:


See [[Mii Maker]] for the application chiefly designed to create, edit, delete, and trade Miis or convert them from and to a QR code.
See [[Mii Maker]] for the application chiefly designed to create, edit, delete, and trade Miis or convert them from and to a QR code.
The default endianness in this page is little-endian, unless explicitly specified.


==Mii Database==
==Mii Database==
Line 29: Line 31:
|-
|-
| 0x23FC
| 0x23FC
| 0x4
| 0x2
| Header 0xFFFFFFFF
| Linked list tail index. 0xFFFF if the list is empty
|-
| 0x23FE
| 0x2
| Linked list head index. 0xFFFF if the list is empty
|-
|-
| 0x2400
| 0x2400
| 0xA41E
| 0xA410 (3000 * 0xE)
| Array of objects? See chapter
| Linked list of objects? See chapter
|-
| 0xC810
| 0xE
| Padding?
|-
|-
| 0xC81E
| 0xC81E
Line 46: Line 56:
| 0xC824
| 0xC824
| 0x4
| 0x4
| Header? 0x39000000
| Mii count in this section. Maximum 100
|-
|-
| 0xC861
| 0xC828
| 0x2B
| 0x64 (100 * 0x1)
| Weird padding? 0x00
| Order index of Mii in this section?
|-
|-
| 0xC88C
| 0xC88C
| 0x1C20 (?)
| 0x1C20 (100 * 0x48)
| Array of Miis contributed from games, used for Mii Plaza "invitations" feature.<br/>The format isn't that of a full Mii.
| Array of Miis contributed from games, used for Mii Plaza "invitations" feature.<br/>The format isn't that of a full Mii. The "author" field is missing
|-
|-
| 0xE4AC
| 0xE4AC
Line 65: Line 75:
|-
|-
| 0xE4C0
| 0xE4C0
| 0x3D860
| 0x3D860 (3000 * 0x54)
| Empty (00)
| Another array of Miis. Seems related to the CFHE section. <br/>The Mii format in this section is modified. The "author" field is missing, A 4-byte timestamp (seconds since 2000) together with 8-byte zeros(?) is appended at the end.
|}
|}
When encrypted in QR codes, 4 additional bytes are added. Two null bytes and a CRC-16. It's the exact same CRC-16 as for the Wii blocks on the 0x5e first bytes. It seems that the CRC is ignored, the Mii Maker expecting the result of APT:Unwrap to detect integrity loss.
When encrypted in QR codes, 4 additional bytes are added. Two null bytes and a CRC-16. It's the exact same CRC-16 as for the Wii blocks on the 0x5e first bytes. It seems that the CRC is ignored, the Mii Maker expecting the result of APT:Unwrap to detect integrity loss.
Line 72: Line 82:
==CFHE object==
==CFHE object==


A 0xE-byte long item.
A 0xE-byte long linked list node. The format is 4-byte Mii ID (See Mii format) + 6-byte MAC + 2-byte previous node index (prev) + 2-byte next node index (next).
 
On my database, they're all 0000 0000 0000 0000 0000 FF7F FF7F.


Wild speculation: blacklist of already scanned celebrity (gold) Mii QRs?
An invalid node has value: ID = 0, MAC = 0, prev = 0x7FFF, next = 0x7FFF.


Alternative interpretation: FFFF FFFF 0000 0000 0000 0000 0000 is the 1st item;  FF7F FF7F 0000 [...] the 2nd, etc;
The highest bit of these fields has some special meaning and isn't part of the index value.


==Checksum==
==Checksum==
Line 129: Line 137:
| 0x0
| 0x0
| 0x4
| 0x4
| Mii ID (see chapter)
| Mii Header (see chapter)
|-
|-
| 0x4
| 0x4
Line 137: Line 145:
| 0xC
| 0xC
| 0x4
| 0x4
| Specialness and date of creation (big-endian 32bit unsigned integer):<br/>Bit 0..27: (bit[0..27] * 2) = date of creation (seconds since 01/01/2010 00:00:00)<br/>Bit 31: not set iff Mii is special
| Mii ID (big-endian 32bit unsigned integer):<br/>Bit 0..27: (bit[0..27] * 2) = date of creation (seconds since 01/01/2010 00:00:00)<br/>Bit 31: not set iff Mii is special
|-
|-
| 0x10
| 0x10
Line 208: Line 216:
|}
|}


==Mii ID==
==Mii Header==
* Byte 0: generally equals 3 (category?)
* Byte 0: generally equals 3 (category?)
* Byte 1: 0/1 = copying off/on
* Byte 1: 0/1 = copying off/on