Content.bin
Overview
Wii channels, savegames and downloadable content data (DLCs) from certain disc-based games can (almost everytime) be transferred from the internal NAND storage to a SD card inserted into the console.
Both channels and savegames are stored in /private/wii/title/<low_tid_ascii>/ as single content.bin and data.bin files, respectively, where <low_tid_ascii> is the ASCII representation of the lower 32 bits from the game-specific title ID.
DLCs are stored in /private/wii/data/<low_tid_ascii>/ as multiple <index>.bin, where <index> represents a specific content index value from a TMD content record, expressed as a 3-digit number in base 10 notation (e.g. 000.bin).
Renaming the directories where these files are stored will make the Wii not recognize them anymore, as expected.
This page covers the content.bin format used by transferred channels. Please refer to Savegame Files if you wish to know more about transferred savegames, and/or Backup WADs if you wish to know more about transferred DLCs.
File structure
Just like WAD files, each individual section from a content.bin file is aligned to a 0x40-byte boundary. This is evidenced by the fact that plaintext sections within these files (like the TMD) are artificially padded with trailing zeroes, in order to make the next section start at an aligned offset.
Each content.bin file starts with a header that can be decrypted successfully by every Wii console, since the icon, banner, title and description of the channel are all readable in the Wii SD card menu, even if the file was not originally generated by the console it's being used with.
A program to help parse and analyze the structure of content.bin files: parse-channel.c. Put it in the same directory as a compiled version of Segher's Wii.git tools, since it depends on them.
General layout
The general layout of content.bin files is as follows:
| Start | End | Length | Description |
|---|---|---|---|
| 0x000 | 0x63F | 0x640 | Encrypted info header. |
| 0x640 | 0x640 + (X - 1) | X | Encrypted icon.bin. |
| 0x640 + X | 0x640 + X + (Y - 1) | Y | Embedded backup WAD. |
| 0x640 + X + Y | 0x640 + X + Y + 0x03F | 0x040 | Backup WAD ECDSA signature. |
| 0x640 + X + Y + 0x40 | 0x640 + X + Y + 0x2FF | 0x300 | Plaintext certificate chain area. |
Encrypted info header
The info header is encrypted with the SD Key and SD IV using AES-128-CBC. When decrypted, it contains the following structure:
| Start | End | Length | Description |
|---|---|---|---|
| 0x000 | 0x007 | 0x008 | Title ID. |
| 0x008 | 0x00B | 0x004 | Decrypted icon.bin length (align up to 0x40 to get the encrypted icon.bin block size). |
| 0x00C | 0x01B | 0x010 | MD5 hash of this header, with this field set to the MD5 Blanker. |
| 0x01C | 0x02B | 0x010 | MD5 hash of the decrypted icon.bin block (without discarding the 0x40 alignment zero padding, if available). |
| 0x02C | 0x02F | 0x004 | Lower 32 bits from the title ID of another game/channel. Unknown purpose. Can be set to any title, even non-existant ones. |
| 0x030 | 0x037 | 0x008 | Reference Title ID #1. Unknown purpose. Can be set to any title, even non-existant ones. |
| 0x038 | 0x03F | 0x008 | Reference Title ID #2. Unknown purpose. Can be set to any title, even non-existant ones. |
| 0x040 | 0x63F | 0x600 | Copy of the IMET header from the channel's opening.bnr, with the MD5 hash at the end zeroed-out. |
Encrypted icon.bin
This is a copy of the /meta/icon.bin entry from the channel's opening.bnr U8 archive, zero padded for 0x40 alignment (if needed) and encrypted with AES-128-CBC using the SD Key and SD IV.
The decrypted icon.bin length field from the encrypted info header represents the unpadded icon.bin length after being decrypted.
Embedded backup WAD
This is a full backup WAD package with all normal/private contents from the transferred channel. Shared contents are never included, although the System Menu doesn't complain if they're available in the embedded backup WAD package.
Backup WAD ECDSA signature
This is an ECDSA signature calculated over the entire embedded backup WAD during the content.bin file creation, using SHA-1 as the cryptographic hash function and the random ECC private key from the AP certificate in the plaintext certificate chain area.
This signature can be verified using the ECC public key from that very same AP certificate. Unlike the ECDSA signatures from the certificates in the next section, this is a full, untrimmed, 0x40-byte long signature.
Plaintext certificate chain area
For more information about each certificate layout, please refer to this page.
| Start | End | Length | Description |
|---|---|---|---|
| 0x000 | 0x17F | 0x180 | Copy of the console-specific device certificate (also known as NG certificate), usually found at /sys/device.cert in the NAND FS.
|
| 0x180 | 0x2FF | 0x180 | Application-specific certificate (also known as AP certificate), dynamically generated during the content.bin file creation.
|
Both certificates hold a trimmed ECDSA signature and a trimmed 0x3C-byte long ECC public key. Both values must be padded with two leading \x00 before each coordinate in order to be able to use them as part of crypto functions.
The certificate name/identity from the AP certificate is always set to AP0000000100000002, because it's always generated by the System Menu.
The ECC public key from the AP certificate is nothing more than an ECC shared secret generated using the random ECC private key from this very same certificate.
Finally, the ECDSA signature from the AP certificate is issued by the NG certificate, using the console-specific ECC private key (stored inside the OTP).
Copying a content.bin file to the Wii
A content.bin file with a well-formed header will appear in the SD card section from the Data Management menu, displaying it's icon, name and description if clicked upon. If a savegame or channel is not already available in the Wii's internal NAND storage, the content.bin file can be unpacked and copied successfully.
Copying files from one Wii to the other
When copying a file that was created on another Wii, the process will fail with a corresponding message.
"Data was not copied."
Changing anything in a content.bin file (except for the encrypted header) will cause the copying to end with this message. This is because the 0x40-byte long ECDSA signature at the end of the backup WAD section serves to check the integrity of the whole embedded backup WAD.
Deleting or adding bytes at the end of the file will also yield this message. This is because of the certificate chain area located after the backup WAD ECDSA signature, and right before the EOF. The last certificate from this chain is signed by the one right that's before.
The White "?" Box
Every manipulation of the content.bin header will cause the channel or savegame to appear as a white box with a black question mark inside it in the Wii's SD card menu. The file can still be examined, but the name and description are filled with question marks as well.
Interestingly enough, the file will still get displayed even if all data beyond the encrypted header is deleted. At least a single byte needs to follow the isolated header, though, possibly to prevent the last byte of the header to be the EOF. The value of this byte of no importance. This feature is exploited by Bannerbomb to get the console to parse the encrypted header while not having to provide a backup WAD section.
File does not appear at all
The file will not appear when its directory is renamed. Combined with the last statement, this may mean that the Wii checks the headers first, then the name from the directory where the file is located.