WiiBrew

Changes

WAD files (view source)

Revision as of 15:09, 28 March 2025

3,331 bytes added ,  Friday at 15:09
Remove piracy section
Line 1: Line 1: −
:''This application is about Wii software packaging. For the data files used by Doom, see [[WiiDoom]].''
+
:''This article is about Wii software packaging. For the WAD 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.  
−
The WAD file-format is a file-format that contains information for the wii, such as System Menus, IOSs, 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 ==
 
== System Menu ==
Line 12: Line 7:  
Wii System Channel WAD files exist for WiiMC, ftpii, and numerous others.
 
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.
+
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. 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.
 
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''' ==
+
== WAD format ==
−
The data within a WAD file has the following format.
     −
Thanks to Segher for his [http://git.infradead.org/users/segher/wii.git?a=blob_plain;f=zeventig.c;hb=HEAD source].
+
=== Installable WADs ===
   −
=== Header ===
+
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].
    
{| class="wikitable"
 
{| class="wikitable"
Line 30: Line 24:  
! '''Description'''
 
! '''Description'''
 
|-
 
|-
−
| 0x000
+
| 0x00
−
| 0x003
+
| 0x03
−
| 4
+
| 0x04
−
| Header size = 0x0020
+
| Header size. Always set to 0x20.
 +
|-
 +
| 0x04
 +
| 0x05
 +
| 0x02
 +
| WAD Type. 'ib' (ImportBoot?) is used for [[boot2]] WADs, 'Is' for everything else.
 
|-
 
|-
−
| 0x004
+
| 0x06
−
| 0x007
+
| 0x07
−
| 4
+
| 0x02
−
| WAD Type ('Is\0\0' or 'ib\0\0' or 'Bk\0\0')
+
| WAD Version. Always set to zero.
 
|-
 
|-
−
| 0x008
+
| 0x08
−
| 0x00B
+
| 0x0B
−
| 4
+
| 0x04
 
| [[Certificate chain]] size.
 
| [[Certificate chain]] size.
 
|-
 
|-
−
| 0x00C
+
| 0x0C
−
| 0x00F
+
| 0x0F
−
| 4
+
| 0x04
−
| Reserved = 0
+
| Reserved. Always set to zero.
 +
|-
 +
| 0x10
 +
| 0x13
 +
| 0x04
 +
| [[Ticket]] size.
 
|-
 
|-
−
| 0x010
+
| 0x14
−
| 0x013
+
| 0x17
−
| 4
+
| 0x04
−
| [[Ticket]] size
+
| [[Title metadata|TMD]] size.
 
|-
 
|-
−
| 0x014
+
| 0x18
−
| 0x017
+
| 0x1B
−
| 4
+
| 0x04
−
| [[Tmd file structure|TMD]] size
+
| Encrypted content data size.
 
|-
 
|-
−
| 0x018
+
| 0x1C
−
| 0x01B
+
| 0x1F
−
| 4
+
| 0x04
−
| Data (APP) size
+
| Footer size.
 
|-
 
|-
−
| 0x01C
+
| 0x20
−
| 0x01F
+
| 0x3F
−
| 4
+
| 0x20
−
| Footer size
+
| Alignment to 0x40 bytes (padding).
 
|}
 
|}
   −
The sections are stored in the WAD in the same order that in the header. Each block (header, sections) 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.
 +
 
 +
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, and it is what gets installed into [[:/meta]] by older SDK versions.
 +
 
 +
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.
 +
 
 +
=== 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 <code>/private/wii/title/<low_tid_ascii>/content.bin</code>.
 +
 
 +
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>).
 +
 
 +
[[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.
 +
 
 +
{| class="wikitable"
 +
|-
 +
! '''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 (either [[Hardware/OTP|NG ID]] or null).
 +
|-
 +
| 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).
 +
|}
   −
The contents are stored in the WAD in the same order as in the TMD. Each file is aligned to 0x40 bytes.
+
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 contents (Data section) are encrypted using the title key (decrypt it from the [[ticket]]) and the content index (in the TMD, the 2 first bytes of the IV are the index, the last 14 bytes are zeroes) as IV. The SHA1 of the decrypted content must match the hash that is stored in the TMD.
+
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.
   −
In a hex editor, the beginning of any WAD will be 00 00 00 20 49 73. This can be useful to remove a WAD from an ELF file.
+
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.
   −
=== Footer ===
+
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).
−
The "footer" is an optional, unencrypted timestamp / buildstamp.
      +
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.
   −
{{stub}}
  −
[[Category:Software]]
   
[[Category:File formats]]
 
[[Category:File formats]]
Aep
8

edits

Retrieved from "https://wiibrew.org/wiki/Special:MobileDiff/92689...120843"