Difference between revisions of "Wii Points"

From WiiBrew
Jump to navigation Jump to search
Line 68: Line 68:
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Part A: Encrypted header
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Part A: Encrypted header
 
|- style="background-color: #ddd;"
 
|- style="background-color: #ddd;"
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | variable, padded to 64-byte boundary.
+
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | variable, padded to 64-byte boundary
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Part B: Encrypted game info
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Part B: Encrypted game info
 
|- style="background-color: #ddd;"
 
|- style="background-color: #ddd;"
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 0x70, padded to 64-byte boundary.
+
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 0x70, padded to 64-byte boundary
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Part C: Cleartext "Bk" header
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Part C: Cleartext "Bk" header
 
|- style="background-color: #ddd;"
 
|- style="background-color: #ddd;"
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 0x1E4 + num_contents*0x24, padded to 64-byte boundary.
+
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 0x1E4 + num_contents*0x24, padded to 64-byte boundary
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Part D: Cleartext TMD block, including content_records for the following files.
+
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Part D: Cleartext TMD block, including content_records for the following files
 
|- style="background-color: #ddd;"
 
|- style="background-color: #ddd;"
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | num_contents*variable, padded to 64-byte boundary.
+
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | num_contents*variable, padded to 64-byte boundary
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Part E: Encrypted data contents.
+
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Part E: Encrypted data contents
 
|- style="background-color: #ddd;"
 
|- style="background-color: #ddd;"
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 0x340
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 0x340
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Part F: Cleartext certificates.
+
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Part F: Cleartext certificates
 
|}
 
|}
  
Line 101: Line 101:
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x00B
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x00B
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 4
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 4
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Size of part B.
+
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Size of part B
 
|- style="background-color: #ddd;"
 
|- style="background-color: #ddd;"
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x00C
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x00C
Line 146: Line 146:
 
|}
 
|}
  
===Part D: TMD block===
+
===Part D: Cleartext TMD block===
 
This part is not encrypted. It is well described on the [[Tmd_file_structure|TMD file format]] page. Some things to note:
 
This part is not encrypted. It is well described on the [[Tmd_file_structure|TMD file format]] page. Some things to note:
 
* Only the tmd struct is included here, not the certificates.  
 
* Only the tmd struct is included here, not the certificates.  
Line 154: Line 154:
 
* If type is 0x80 0x01, then the content is included in part E, and the size of the content is given by the size field.
 
* If type is 0x80 0x01, then the content is included in part E, and the size of the content is given by the size field.
 
* Otherwise, type will be 0x00 0x01, and the content is (presumably) shared between VCs and stored elsewere on the Wii.
 
* Otherwise, type will be 0x00 0x01, and the content is (presumably) shared between VCs and stored elsewere on the Wii.
 +
 +
===Part E: Encrypted data contents===
 +
This part is encrypted. The encryption key is currently unknown. It might be unique to the Wii which saved the VC.
 +
It consists of several separate "files", one for each of the contents with the 0x80 type flag in the TMD content_record, padded to 64-byte boundary.
 +
 +
===Part F: Cleartext certificates===
 +
This part is not enrypted. The exact details of this field is not yet analyzed, but it is likely related to the chain of certificates as described on the [[Tmd_file_structure|TMD file format]] page.
  
 
[[Category:Software]]
 
[[Category:Software]]

Revision as of 12:29, 26 January 2008

Information

The virtual console (VC) is a platform to play retro games on your Nintendo Wii. For more information about the VC visit the VC page of wikipedia.

A little warning, as of this point not much is known so most of the text here will be speculation.

Internal game names

The folders in which the Virtual Console files (content.bin) are saved have systematic, four-character names. The first character tells us what system the ROM belongs to.

F : NES
J : SNES
M : Genesis/Mega Drive
N : N64
P : TurboGrafx-16/PC Engine
R : Wii

The second and third char is the game identifier. For non-Wii games, it is incremented from AA to AZ, then A0 to A9, BA to BZ and so on; for Wii games, it is often an abbreviation of the game name (e.g. "SP" for Wii Sports, "ZD" for Zelda).

The last character is the regioncode.

E : USA
J : Japan
P : Europe (and other PAL regions)

Let's take F-Zero as an example. The folder for F-Zero (USA) is named JACE. The 'J' tells us it's a SNES game, followed by 'AC' which tells us this is probably the third game released for the SNES and the 'E' tells us it's a USA release.

Funny thing is that when you change the folder name to something else like FAKE (for The legend of Zelda) the Nintendo Wii doesn't reconize the game channel anymore. So it somehow checks the games content.bin with the foldername. If you look in the content.bin you can also find the foldername in (what is probably) the meta data (which isn't encrypted). Using a Hexedit program you can view the content.bin file, and depending on the file, within 2000 lines you will find the file name (if viewing as a string).

Root-CA000 0000001-CP
CP00000004 04
0000000000 0000000000
0000000000 0000000000
0000000000 0000000000
FAKE 01

Encryption

The virtual console games are encrypted, presumably to prevent people exchanging VC games. The way it looks right now is as follows:

Your Wii contacts the content server and checks your Wii points. If you have enough Wii points it downloads a small tmd (Title Meta Data?) file which has some metadata about the virtual console title. After that the rest of the content gets downloaded. For VC games, this is 7 other files. Most of these files are then joined together to create the channel file, content.bin. The other files that aren't joined together are most likely shared between different VC games. For VC games, content files 00000002, 00000003, 00000004, and 00000006 are exactly the same size for every VC game, but only 00000002, 00000003, and 00000004 seems to be shared. The Wii takes the other 4 files and creates content.bin. Each of the 4 files is 0x2000-byte aligned in the file.

Again using a Hexedit to view the content.bin file, if you look at just a bit above the bottom of the file you will see a

Root-CA000 0000001-MS
MS00000002 02
0000000000 0000000000
0000000000 0000000000
0000000000 21eff4

and then a bit farther down

Root-CA000 0000001-MS
MS00000002 02-NG0221e
1eff4

where you see the 21eff4, 221e, and 1eff4 above are tags that identify what Wii the content.bin comes from and change accordingly to the Wii.

The content.bin file

When saved to a SD card, the VC game is saved in a file named "private/wii/title/XXXX/content.bin", where XXXX is the four-character name of the game, as described above.

The general layout of this file is as follows. Most of the data here is sketchy, at best.

Length Description
0x0640 Part A: Encrypted header
variable, padded to 64-byte boundary Part B: Encrypted game info
0x70, padded to 64-byte boundary Part C: Cleartext "Bk" header
0x1E4 + num_contents*0x24, padded to 64-byte boundary Part D: Cleartext TMD block, including content_records for the following files
num_contents*variable, padded to 64-byte boundary Part E: Encrypted data contents
0x340 Part F: Cleartext certificates

Part A: Encrypted header

The header is encrypted by the SD key and SD IV. When decrypted, it contains the following structure:

Start End Length Description
0x000 0x007 8 Title ID (which is 00 01 00 01 followed by the four-character code)
0x008 0x00B 4 Size of part B
0x00C 0x63F 0x634 As of yet un-analyzed data

Part B: Encrypted game info

This part is is also encrypted by the SD key and SD IV. The contents of this part has not yet been fully analyzed. It seems to contain information of what kind of system that is emulated, and probably the image to dislay on the channel selector for this VC game.

Part C: Cleartext "Bk" header

This part is not encrypted. It is similar to the Bk header found in savegames, but the contents only partially match. The header could also be exactly 0x80 long; the size of 0x70 is a guess based on the first field being a size parameter.

Start End Length Description
0x000 0x003 4 Size of this part (presumably; always 0x70)
0x004 0x007 4 Magic word, always 0x42 0x6B 0x00 0x01 (Bk..)
0x008 0x00B 4 NG-id
0x00C 0x06F 0x64 As of yet un-analyzed data, mostly zero.

Part D: Cleartext TMD block

This part is not encrypted. It is well described on the TMD file format page. Some things to note:

  • Only the tmd struct is included here, not the certificates.
  • As described on the TMD file format page, after the main struct (with a size of 0x1E4), there follows an array of content_record structs.
  • There is as many structs as the num_contents field in the tmd struct indicates. For VC, this seems to be always 7.
  • The type and size file of the content_record is of special interest, since they describe part E.
  • If type is 0x80 0x01, then the content is included in part E, and the size of the content is given by the size field.
  • Otherwise, type will be 0x00 0x01, and the content is (presumably) shared between VCs and stored elsewere on the Wii.

Part E: Encrypted data contents

This part is encrypted. The encryption key is currently unknown. It might be unique to the Wii which saved the VC. It consists of several separate "files", one for each of the contents with the 0x80 type flag in the TMD content_record, padded to 64-byte boundary.

Part F: Cleartext certificates

This part is not enrypted. The exact details of this field is not yet analyzed, but it is likely related to the chain of certificates as described on the TMD file format page.