242
edits
Changes
no edit summary
Line 2:
Line 2:
−On my database, they're all 0000 0000 0000 0000 0000 FF7F FF7F.
−Wild speculation: blacklist of already scanned celebrity (gold) Mii QRs?+Alternative interpretation: FFFF FFFF 0000 0000 0000 0000 0000 is the 1st item; FF7F FF7F 0000 [...] the 2nd, etc;+
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).
−An invalid node has value: ID = 0, MAC = 0, prev = 0x7FFF, next = 0x7FFF.
−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