Difference between revisions of "WAD files"

From WiiBrew
Jump to navigation Jump to search
(Remove the stub template.)
 
(49 intermediate revisions by 25 users not shown)
Line 1: Line 1:
== WAD Format ==
+
:''This article is about Wii software packaging. For the data files used by Doom, see [[WiiDoom]].''
 +
==General info==
 +
The WAD file-format is a package that contains title information for the Wii, such as System Menus, IOS versions, and channels.
 +
===Piracy===
 +
Unfortunately, WAD files are often used to distribute pirated channels (both Virtual Console and WiiWare), due to the fact that they are also used by Nintendo and therefore easy to rip from the Wii and, for some WAD files, Nintendo's servers, and easy to create installers for. Wiibrew does not in any way endorse piracy, and as such these uses of WAD files should not be discussed.
  
The data within a WAD file has the following format.
+
If you wish to discuss legitimate WAD files, please ensure you make clear which file you are talking about and what you will use it for, to prevent people jumping to conclusions about your intentions.
  
'''<span style="color: red;">This page is horribly out of date. Expect an update when the dust of recent events settles.</span>'''
+
== System Menu ==
 +
WAD files are often installed in the Wii System Menu to appear as channels, making launching easier. If a WiiBrew app isn't installed as a channel, it can usually only be launched from the Homebrew Channel itself. WAD file creation seems to be an intricate process and tools are difficult to locate, and most are based on the .NET framework. Associated with WAD file generation are forwarders, which when loaded simply load another arbitrary application. A common technique is to use a somewhat generalized WAD that can be easily customized to then forward to another WiiBrew application stored on the SD card.
  
=== Header ===
+
Wii System Channel WAD files exist for WiiMC, ftpii, and numerous others.
  
{| style="border-collapse: collapse; padding: 0.2em 0.2em 0.2em 0.2em;"
+
Forwarders are somewhat easier to locate, a common one being the Narolez-NForwarder, for which source exists and is easily modifiable. One WAD generation system that still appears to be active is the CRAP system that appears to be .NET based. The Wadder system also seemed to be .NET based but it appears abandoned. Although these tools are often associated with piracy, there are clearly legitimate uses for them as well.
|- style="background-color: #ddd;"
+
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #cdc;" | '''Start'''
+
The WAD files themselves contain either still images or a collection of images to be animated, as well as sound data. In addition there is a .DOL file for the program to be run when launched.
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ccd;" | '''End'''
+
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ccc;" | '''Length'''
+
== WAD format ==
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dcc;" | '''Description'''
+
 
|- style="background-color: #ddd;"
+
=== Installable WADs ===
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x000
+
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x003
+
Common format used for WAD files distributed in update partitions from Wii discs. Thanks to Segher for his [http://git.infradead.org/users/segher/wii.git?a=blob_plain;f=zeventig.c;hb=HEAD source].
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 4
+
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Header size = 0x0020
+
{| class="wikitable"
|- style="background-color: #ddd;"
+
|-
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x004
+
! '''Start'''
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x007
+
! '''End'''
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 4
+
! '''Length'''
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Header type (0x49730000 or 0x69620000)
+
! '''Description'''
|- style="background-color: #ddd;"
+
|-
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x008
+
| 0x00
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x00B
+
| 0x03
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 4
+
| 0x04
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | [[Certificate chain]] size.
+
| Header size. Always set to 0x20.
|- style="background-color: #ddd;"
+
|-
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x00C
+
| 0x04
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x00F
+
| 0x05
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 4
+
| 0x02
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Reserved = 0
+
| WAD Type. 'ib' is used for [[boot2]] WADs, 'Is' for everything else.
|- style="background-color: #ddd;"
+
|-
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x010
+
| 0x06
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x013
+
| 0x07
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 4
+
| 0x02
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | [[Ticket]] size
+
| WAD Version. Always set to zero.
|- style="background-color: #ddd;"
+
|-
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x014
+
| 0x08
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x017
+
| 0x0B
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 4
+
| 0x04
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | [[Tmd file structure]] size
+
| [[Certificate chain]] size.
|- style="background-color: #ddd;"
+
|-
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x018
+
| 0x0C
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x01B
+
| 0x0F
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 4
+
| 0x04
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | APP size
+
| Reserved. Always set to zero.
|- style="background-color: #ddd;"
+
|-
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x01C
+
| 0x10
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x01F
+
| 0x13
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 4
+
| 0x04
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Trailer size
+
| [[Ticket]] size.
 +
|-
 +
| 0x14
 +
| 0x17
 +
| 0x04
 +
| [[Title metadata|TMD]] size.
 +
|-
 +
| 0x18
 +
| 0x1B
 +
| 0x04
 +
| Encrypted content data size.
 +
|-
 +
| 0x1C
 +
| 0x1F
 +
| 0x04
 +
| Footer size.
 +
|-
 +
| 0x20
 +
| 0x3F
 +
| 0x20
 +
| Alignment to 0x40 bytes (padding).
 
|}
 
|}
  
The files are stored in the WAD in the same order that in the header. After each block (header, files), the file is aligned to 0x40 bytes.
+
Sections are stored in installable WAD files in the same order from their headers (certificate chain, ticket, TMD, content data). Each section is aligned to a 0x40-byte boundary.
  
=== Chain of Certificates ===
+
The encrypted content data section is composed of content files, which are stored following the same order from the TMD content records. These are encrypted using the decrypted titlekey from the [[Ticket]] and the content index as the IV (first two bytes, followed by 14 zeroes). The SHA-1 checksum of the decrypted content must match the hash from its corresponding TMD content record. Each content is individually aligned to a 0x40-byte boundary.
  
{| style="border-collapse: collapse; padding: 0.2em 0.2em 0.2em 0.2em;"
+
The footer is an optional, unencrypted timestamp / buildstamp. It's usually the first decrypted 0x40 bytes from the first content file.
|- style="background-color: #ddd;"
+
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #cdc;" | '''Start'''
+
In a hex editor, the beginning of any installable WAD will be <code>00 00 00 20 49 73 00 00</code>. This can be useful to extract an embedded installable WAD from an ELF binary.
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ccd;" | '''End'''
+
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ccc;" | '''Length'''
+
=== Backup WADs ===
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dcc;" | '''Description'''
+
 
|- style="background-color: #ddd;"
+
Format used by [[content.bin]] files to store content data from a channel copied or transferred to the SD card, which get saved to <code>/private/wii/title/<low_tid_ascii>/content.bin</code>.
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x040
+
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x043
+
Also used by downloadable content data stored in the SD card, which gets saved to <code>/private/wii/data/<low_tid_ascii>/<index>.bin</code> - in this context, <code><index></code> represents a specific content index value from a TMD content record, expressed as a 3-digit number in base 10 notation (e.g. <code>000.bin</code>).
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 4
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | signature type (0x00010001 RSA2048, 0x00010000 RSA4096)
 
|- style="background-color: #ddd;"
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x044
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x143+d
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 256 for RSA2048 (d=0x000), 512 for RSA4096 (d=0x100)
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | signature
 
|- style="background-color: #ddd;"
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x144+d
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x17F+d
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 60
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | zero filled
 
|- style="background-color: #ddd;"
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x180+d
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x1BF+d
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 64
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | issuer
 
|- style="background-color: #ddd;"
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x1C0+d
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x1C3+d
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 4
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | ? subject type (0x00000000, 0x00000001)
 
|- style="background-color: #ddd;"
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x1C4+d
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x203+d
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 64
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | subject
 
|- style="background-color: #ddd;"
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x204+d
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x307+d
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 260
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | ? public key
 
|- style="background-color: #ddd;"
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x308+d
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x30B+d
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 4
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | ?? unknown (0x00010001)
 
|- style="background-color: #ddd;"
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x30C+d
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x33F+d
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 52
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | zero filled
 
|- style="background-color: #ddd;"
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | ...
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | ...
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | ...
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | ...
 
|}
 
  
=== Key and IV ===
+
[[Savegame Files|Savegames]] use the same exact header, albeit with different fields filled and with an entirely different structure for the rest of the file.
  
{| style="border-collapse: collapse; padding: 0.2em 0.2em 0.2em 0.2em;"
+
{| class="wikitable"
|- style="background-color: #ddd;"
+
|-
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #cdc;" | '''Start'''
+
! '''Start'''
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ccd;" | '''End'''
+
! '''End'''
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ccc;" | '''Length'''
+
! '''Length'''
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dcc;" | '''Description'''
+
! '''Description'''
|- style="background-color: #ddd;"
+
|-
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x0bff
+
| 0x00
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x0c0e
+
| 0x03
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 0x0010
+
| 0x04
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Encrypted title key (decrypt using the master key)
+
| Header size. Always set to 0x70.
|- style="background-color: #ddd;"
+
|-
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x0c1c
+
| 0x04
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x0c23
+
| 0x05
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 0x0008
+
| 0x02
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | First 8 bytes of IV for title key decryption (last 8 bytes are zero)
+
| WAD Type. Always set to 'Bk'.
 +
|-
 +
| 0x06
 +
| 0x07
 +
| 0x02
 +
| WAD Version. Always set to 0x01.
 +
|-
 +
| 0x08
 +
| 0x0B
 +
| 0x04
 +
| Console ID.
 +
|-
 +
| 0x0C
 +
| 0x0F
 +
| 0x04
 +
| Savegame file count. Always set to zero (only used in savegames).
 +
|-
 +
| 0x10
 +
| 0x13
 +
| 0x04
 +
| Savegame file data size. Always set to zero (only used in savegames).
 +
|-
 +
| 0x14
 +
| 0x17
 +
| 0x04
 +
| [[Title metadata|TMD]] size.
 +
|-
 +
| 0x18
 +
| 0x1B
 +
| 0x04
 +
| Encrypted content data size.
 +
|-
 +
| 0x1C
 +
| 0x1F
 +
| 0x04
 +
| Backup area size (total size from the start of this header to the end of the encrypted content data).
 +
|-
 +
| 0x20
 +
| 0x5F
 +
| 0x40
 +
| Included contents bitfield.
 +
|-
 +
| 0x60
 +
| 0x67
 +
| 0x08
 +
| Title ID. Set to zero in backup WADs from content.bin files, set to parent title ID in DLCs (not the DLC title ID) and set to game title ID in savegames.
 +
|-
 +
| 0x68
 +
| 0x6D
 +
| 0x06
 +
| MAC address. Always set to zero (only used in savegames).
 +
|-
 +
| 0x6E
 +
| 0x6F
 +
| 0x02
 +
| Reserved. Always set to zero.
 +
|-
 +
| 0x70
 +
| 0x7F
 +
| 0x10
 +
| Alignment to 0x40 bytes (padding).
 
|}
 
|}
  
To obtain the title key, simply decrypt it using the master key and the given IV (last eight bytes zero, first eight bytes supplied).
+
Sections are stored in backup WAD files in the same order from their headers (TMD, content data). Each section is aligned to a 0x40-byte boundary.
  
Note: this is probably part of the TMD/ticket/whatever. I'm throwing the offsets here for now, since this is arguably the most important part for extraction purposes.
+
The included contents bitfield serves to determine which contents from the TMD are part of the backup WAD. Up to 512 different contents (bits) can be toggled, separated in groups of 8 contents (byte), where the LSB represents the first content from the group and the MSB represents the last content. Shared contents are usually not included. For example, the bitfield for a backup WAD that holds a TMD with 10 content records, where indexes 4 and 8 are both shared contents, would be <code>EF 02</code> (<code>11101111 00000010</code>), followed by 62 zeroes.
  
=== File Table ===
+
The encrypted content data section is composed of content files, which are stored following the same order from the TMD content records. These are encrypted using the console-specific PRNG key and the content index as the IV (first two bytes, followed by 14 zeroes). The SHA-1 checksum of the decrypted content must match the hash from its corresponding TMD content record. Each content is individually aligned to a 0x40-byte boundary.
  
WAD files contain a number of "files" in them. The number of files can be obtained from the halfword (2 bytes) at 0xede. The table itself starts at 0xee4, and it is composed of a number of file entries:
+
In a hex editor, the beginning of any backup WAD will be <code>00 00 00 70 42 6B 00 01</code>. This can be useful to extract an embedded backup WAD from a bigger file (such as [[content.bin]] files).
  
{| style="border-collapse: collapse; padding: 0.2em 0.2em 0.2em 0.2em;"
+
Please note that, unlike <code>content.bin</code> files from channels, each <code><index>.bin</code> file from transferred DLCs only holds a single encrypted content. This also means that a single bit from the entire included contents bitfield is enabled.
|- style="background-color: #ddd;"
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #cdc;" | '''Start'''
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ccd;" | '''End'''
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ccc;" | '''Length'''
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dcc;" | '''Description'''
 
|- style="background-color: #ddd;"
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x00
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x03
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 0x04
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | File number / ID
 
|- style="background-color: #ddd;"
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x04
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x05
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 0x02
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | First 2 bytes of IV to decrypt contents (last 14 bytes are zero)
 
|- style="background-color: #ddd;"
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x06
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x07
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 0x02
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Flags ?
 
|- style="background-color: #ddd;"
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x08
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x0B
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 0x04
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | Padding (zero)
 
|- style="background-color: #ddd;"
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x0C
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x0F
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 0x04
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | File size
 
|- style="background-color: #ddd;"
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ded;" | 0x10
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #dde;" | 0x24
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #ddd;" | 0x14
 
| style="border: 1px solid #ccc; padding: 0.2em; background-color: #edd;" | SHA-1 sum of decrypted file
 
|}
 
  
The files are located after the file table, with their starts aligned to a 64 byte boundary. To read a file, skip bytes until the next 64 byte boundary (unless already at one), read the ''File size'' bytes rounded to the next 16 bytes (the AES block size), decrypt using AES (using the title key and the IV in the file table entry plus 14 zero bytes), and take filesize bytes from the result to create the output file. The SHA-1 sum of this should match the one in the file table.
+
[[Category:Software]]
 +
[[Category:File formats]]

Latest revision as of 04:53, 30 June 2020

This article is about Wii software packaging. For the data files used by Doom, see WiiDoom.

General info

The WAD file-format is a package that contains title information for the Wii, such as System Menus, IOS versions, and channels.

Piracy

Unfortunately, WAD files are often used to distribute pirated channels (both Virtual Console and WiiWare), due to the fact that they are also used by Nintendo and therefore easy to rip from the Wii and, for some WAD files, Nintendo's servers, and easy to create installers for. Wiibrew does not in any way endorse piracy, and as such these uses of WAD files should not be discussed.

If you wish to discuss legitimate WAD files, please ensure you make clear which file you are talking about and what you will use it for, to prevent people jumping to conclusions about your intentions.

System Menu

WAD files are often installed in the Wii System Menu to appear as channels, making launching easier. If a WiiBrew app isn't installed as a channel, it can usually only be launched from the Homebrew Channel itself. WAD file creation seems to be an intricate process and tools are difficult to locate, and most are based on the .NET framework. Associated with WAD file generation are forwarders, which when loaded simply load another arbitrary application. A common technique is to use a somewhat generalized WAD that can be easily customized to then forward to another WiiBrew application stored on the SD card.

Wii System Channel WAD files exist for WiiMC, ftpii, and numerous others.

Forwarders are somewhat easier to locate, a common one being the Narolez-NForwarder, for which source exists and is easily modifiable. One WAD generation system that still appears to be active is the CRAP system that appears to be .NET based. The Wadder system also seemed to be .NET based but it appears abandoned. Although these tools are often associated with piracy, there are clearly legitimate uses for them as well.

The WAD files themselves contain either still images or a collection of images to be animated, as well as sound data. In addition there is a .DOL file for the program to be run when launched.

WAD format

Installable WADs

Common format used for WAD files distributed in update partitions from Wii discs. Thanks to Segher for his source.

Start End Length Description
0x00 0x03 0x04 Header size. Always set to 0x20.
0x04 0x05 0x02 WAD Type. 'ib' is used for boot2 WADs, 'Is' for everything else.
0x06 0x07 0x02 WAD Version. Always set to zero.
0x08 0x0B 0x04 Certificate chain size.
0x0C 0x0F 0x04 Reserved. Always set to zero.
0x10 0x13 0x04 Ticket size.
0x14 0x17 0x04 TMD size.
0x18 0x1B 0x04 Encrypted content data size.
0x1C 0x1F 0x04 Footer size.
0x20 0x3F 0x20 Alignment to 0x40 bytes (padding).

Sections are stored in installable WAD files in the same order from their headers (certificate chain, ticket, TMD, content data). Each section is aligned to a 0x40-byte boundary.

The encrypted content data section is composed of content files, which are stored following the same order from the TMD content records. These are encrypted using the decrypted titlekey from the Ticket and the content index as the IV (first two bytes, followed by 14 zeroes). The SHA-1 checksum of the decrypted content must match the hash from its corresponding TMD content record. Each content is individually aligned to a 0x40-byte boundary.

The footer is an optional, unencrypted timestamp / buildstamp. It's usually the first decrypted 0x40 bytes from the first content file.

In a hex editor, the beginning of any installable WAD will be 00 00 00 20 49 73 00 00. This can be useful to extract an embedded installable WAD from an ELF binary.

Backup WADs

Format used by content.bin files to store content data from a channel copied or transferred to the SD card, which get saved to /private/wii/title/<low_tid_ascii>/content.bin.

Also used by downloadable content data stored in the SD card, which gets saved to /private/wii/data/<low_tid_ascii>/<index>.bin - in this context, <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).

Savegames use the same exact header, albeit with different fields filled and with an entirely different structure for the rest of the file.

Start End Length Description
0x00 0x03 0x04 Header size. Always set to 0x70.
0x04 0x05 0x02 WAD Type. Always set to 'Bk'.
0x06 0x07 0x02 WAD Version. Always set to 0x01.
0x08 0x0B 0x04 Console ID.
0x0C 0x0F 0x04 Savegame file count. Always set to zero (only used in savegames).
0x10 0x13 0x04 Savegame file data size. Always set to zero (only used in savegames).
0x14 0x17 0x04 TMD size.
0x18 0x1B 0x04 Encrypted content data size.
0x1C 0x1F 0x04 Backup area size (total size from the start of this header to the end of the encrypted content data).
0x20 0x5F 0x40 Included contents bitfield.
0x60 0x67 0x08 Title ID. Set to zero in backup WADs from content.bin files, set to parent title ID in DLCs (not the DLC title ID) and set to game title ID in savegames.
0x68 0x6D 0x06 MAC address. Always set to zero (only used in savegames).
0x6E 0x6F 0x02 Reserved. Always set to zero.
0x70 0x7F 0x10 Alignment to 0x40 bytes (padding).

Sections are stored in backup WAD files in the same order from their headers (TMD, content data). Each section is aligned to a 0x40-byte boundary.

The included contents bitfield serves to determine which contents from the TMD are part of the backup WAD. Up to 512 different contents (bits) can be toggled, separated in groups of 8 contents (byte), where the LSB represents the first content from the group and the MSB represents the last content. Shared contents are usually not included. For example, the bitfield for a backup WAD that holds a TMD with 10 content records, where indexes 4 and 8 are both shared contents, would be EF 02 (11101111 00000010), followed by 62 zeroes.

The encrypted content data section is composed of content files, which are stored following the same order from the TMD content records. These are encrypted using the console-specific PRNG key and the content index as the IV (first two bytes, followed by 14 zeroes). The SHA-1 checksum of the decrypted content must match the hash from its corresponding TMD content record. Each content is individually aligned to a 0x40-byte boundary.

In a hex editor, the beginning of any backup WAD will be 00 00 00 70 42 6B 00 01. This can be useful to extract an embedded backup WAD from a bigger file (such as content.bin files).

Please note that, unlike content.bin files from channels, each <index>.bin file from transferred DLCs only holds a single encrypted content. This also means that a single bit from the entire included contents bitfield is enabled.