Content.bin file structure
|It has been suggested that this article or section be merged with [[::content.bin|content.bin]]. (Discuss)|
These are the details of the Content.bin file structure.
VC games and Wii channels, when saved to a SD card, will be stored in a file named "private/wii/title/XXXX/content.bin", where XXXX is the four-character name of the game/channel.
The general layout of this file is as follows. Most of the data here is sketchy, at best.
Part A: Encrypted header
The header is encrypted by the SD key and SD IV. When decrypted, it contains the following structure: (* means the field is discussed below)
Template:Table Template:Table/Header Template:Table/Row Template:Table/Row Template:Table/Row Template:Table/Row Template:Table/Row Template:Table/Row Template:Table/Row Template:Table/Row Template:Table/Row Template:Table/Row Template:Table/Row Template:Table/Row Template:Table/Row Template:Table/Row Template:Table/Row Template:Table/Row Template:Table/Row Template:Table/Row |}
This value looks almost like the four-letter code of a channel/game. I have found HADP on most files, but HAGP on Super Mario/NES and '\0UPD' (that is, the first byte is 00, then UPD) on two N64-games.
- Title-ID-reference_1 and Title-ID-reference_2
These two looks like two Title-ID:s. On most files I have analyzed they are: 00 01 00 08 HALP and 00 01 00 08 HAKP (this is from a PAL Wii). However, on Super Mario/NES I found 00 01 00 02 HAFP and 00 01 00 02 HAGA. A guess is that they might stipulate some kind of dependencies on system files.
If the guess about depencencies is correct, then this might be a padding field which is zero only if not more than two dependencies are needed.
- IMET data
The IMET data follows a quite strict format, with a few changes between files. I don't have any good idea what those changes represent. The only major difference is found i Metroid Prime 3 Preview, which have everyting zero except the "IMET" header. The values indicated below is for all other files I've studied, which was non-zero.
- Padding (normally zero)
For Metroid Prime 3 Preview, this field was not completely zero. The three bytes with positions 0x313, 0x367 and 0x3BB was 0x20 instead of 0. My guess is that this doesn't matter, but then again, it could have something to do with the weird IMET data of MP3preview.
Part B: Encrypted icon
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.
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.
- This part is probably the same for every Wii, but unique to each VC. It's probably encrypted with the title key, stored in a ticket somewhere. Bushing 03:42, 11 February 2008 (PST)
Part F: Cleartext certificates
This part is not encrypted. 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.
Part G: Making back-ups / copies of a channel / VC game
Disclaimer: This is only legal to do when you have the right to use the VC game / channel, in other words: when you have bought the VC game or channel, or when it is/was free. Also, you're only allowed to install the software at one Wii at a time, and only on a Wii you own. Of course you may create homebrew channels too, and copy them as many times as you like.
As said above, the Wii channels and VC games are encrypted by two AES/RSA keys. The first part (the header) is encrypted by a public key, which is the same on every Wii system. This explains why you can see what Wii channels/VC games are on a SD card on every Wii. The key used to encrypt the header is called the SD Key. The second part includes the software itself. It is encrypted with a key unique to each console. This explains why you can only copy software back to the Wii on which it was copied to the SD Card. The third part includes several checksums and certificates, for which I refer to the explanations above.
The only way to copy Wii channels / VC games for use on another Wii is decompiling them on the Wii itself or on the computer. If this has been done, you obtain a WAD file, which is in fact slightly reverse engineered version of the original file.
With the homebrew application WAD Packer it is then possible to convert the WAD file on the SD Card to a compiled version in your Wii NAND Memory. The installation can only be done on the Wii itself. When this is done, the WAD Installer gets your Wii unique key, and encrypts the WAD Package with this one. Once the installation is done, the new channel / VC game appears in the Wii menu, and you are able to use it as it was genuine. Further, it is then possible to copy the channels/games to an SD card, but again, when using this way, it can only be copied back to the Wii it was copied from.