From WikiTemp, the GBAtemp wiki

NKit supports GameCube and Wii disc images. They are named .iso, but are Nintendo's own formats. This documentation will describe known layouts and focus on key items that NKit uses or information that is not well documented elsewhere. Read the Glossary for terminology.

Disc Information

Here we will take a look at the parts of the Disc NKit is interested in. Wii will be the main focus as it's the most technical with more complexity. The GameCube disc is covered in the Partition Data section of this page as the contained data is basically a GameCube image.

Note: Offset Addresses and lengths are denoted with the 0x prefix to indicate hexadecimal. 

Knowledge for the overall layouts was gained from code, Dolphin contributors and the docs below. This document will refer to them as Wii Docs and GameCube Docs.

Wii Docs: 
GameCube Docs: 

Since the above documents were written the full catalogue of games has been released. Scans have been performed. This document will aim to point out confirmed facts where possible.

Disc Layout

The table below shows a Wii disc with an extra channel partition. A typical Wii disc is items 1 to 7 only. Each partition has a header and a data section. 0x-------- denotes that the offset follows the previous item.

Item No. Offset Length ID Name Wii Docs
1 0x0 0x50000 Game ID Disc Header
2 0x50000 0x20000 Update [Header]
3 0x70000 RELS Update [Data]
4 0x-------- Gap
5 0xF800000 0x20000 Data [Header]
6 0xF820000 [Game ID] Data [Data]
7 0x-------- Gap Junk
8 0x-------- Channel [Header]
9 0x-------- _INS Channel [Data]
10 0x-------- Gap Junk

There are variants of this arrangement:-

  • Channel then Data partitions (reverse order)
  • Multiple channels (Virtual Console) + gap junk (items 8 to 10 would be repeated as 11+)
  • One series of games has a _WIN partition that contains the bulk of the data. It would be in place of the Channel in this above example

The above table is an example the offsets of the various items specified in the partition table. The partition table is located in the disc header and should be used when parsing discs.

Redump image scans show that unless they have been modified, official releases never deviate from the update partition being at 0x50000 and the first channel or data partition is at 0xF800000. There are a couple of service discs that have invalid update partitions. In this case they have an entry in the partition table, have a valid partition header and the partition data is encrypted with valid hashes. The data is just incrementing 32 bit values starting at 0x00000000.

Disc Header

The main items of interest in the disc header are:

Item No. Offset Length Name
1 0x0 0x4 ID
2 0x4 0x2 Maker Code
3 0x5 0x1 Disc No
4 0x6 0x1 Disc Version
5 0x20 0x40 Title
6 0x40000 0x120 ? Partition Info -
7 0x4E000 0x20

The NKit Format adds it's own items to the header in an area that is always empty – 0x200.

Partition Header

Most of the info in the partition header are ignored by NKit. The following are used:

Item No. Offset Length Name
1 0x2b4 0x4 H3 Table Offset
2 0x2b8 0x4 Partition Data Offset
3 0x2bc 0x4 Partition Size
4 H3 Table (pointed to by 0x2b4)

The Partition Size is the size of the data partition including the hash sectors. The NKit format writes it as the size without the hashes and preserves the original size in the partition data at 0x210 (data address after dehashing).

Partition Data

The partition data is encrypted and split into blocks containing hash data. This section will cover the encryption, hashing then file system.


The encryption covers the partition data only. NKit does not do anything special with it. The NKit format removes the encryption, when restoring, the encryption is reapplied. When recovering an image it encrypts any repaired data groups the standard way. Scrubbing wipes the encryption with a value – usually 00 or FF. NKit can preserve scrubbing when converting.

Data (Hashes, Groups, Blocks and Sectors)

This requires a high level overview of how the partition data is set out for clarity.

  • The partition data is split in to 2MiB groups
  • Each group is 64 32KiB blocks
  • Each block is 32 1KiB sectors
  • The first sector is the hash sector – H0, H1, H2 tables (Wii Docs)
  • Sectors 2 to 32 are data
  • Offsets for files and junk generation offsets ignore the hash sectors (group 2 data start offset would be 0x7c00 = 31KiB)
  • A group can be less than 2 MiB and is always split on a block boundary (32KiB)

The hash tables are linked, they hash the data and each other. This is described in the Wii Docs. NKit obeys those rules.

Hashes are checked and removed when converting to NKit, hashes that don't conform are preserved so they can be restored accurately. This includes hashes that not complete due to part group scrubbing are also preserved. Redump images have 100% recreatable hashes.

NKit removes all hashes from the data partition. Non recreatable hashes found in scrubbed, hacked and corrupt images are stored at the end of the NKit partition data.

GameCube Disc / Wii Raw Partition Data

The Wii Raw Partition Data (no encryption or hashes) is almost exactly the same as a GameCube disc. Offsets used in the data need to be multiplied by 4 for Wii whereas GameCube don't. There are other minor differences for example bi2.bin not being in a Wii Partition etc, but they are not important for this document.

A raw data partition contains the following items

Boot.bin (Data Header)
Item No. Offset Length Name
1 0x0 0x4 ID
2 0x4 0x2 Maker Code
3 0x5 0x1 Disc No
4 0x6 0x1 Disc Version
5 0x20 0x40 Title
6 0x420 0x4 Main.dol location
7 0x424 0x4 Fst.bin location
8 0x428 0x4 Fst.bin size
9 0x42C 0x4 Max Fst.bin size

It's worth noting that the Max Fst.bin size is the same as the Fst.bin size in most cases. It can be different for 2 disc games though where the other disc has a larger fst.bin. Fst.bin size is always the size of the fst.bin on the same disc.


A GameCube file containing region info, this is not populated on the Wii. It's listed here for completeness


Extracted from GameCube images to form the Recover Files.

Located at 0x2440

The length of this file is calculated by adding the value 32 to the 4 byte values stored at 0x14 and 0x18 of the appldr.bin. 32 bytes being the length of the appldr header.


Not used by NKit. GameCube Recovery will scrub after this file before the fst.bin when attempting to brute force a dat CRC match.

Located at the position pointed to by 0x420 in the boot.bin

The length is calculated by looping 18 dol sections and lengths. Section offsets are based at 0x0, section lengths are based at 0x90. Where the section offset value is not 0x0, add the corresponding section length to it. Store the largest value over the 18 items. This is effectively finding the last dol offset and adding the length. This is the only reliable method proven to work on all images as it caters for the one image has the second value being the largest. Normally it's the last populated.


Located at the position pointed to by 0x424 in the boot.bin

The length is located at the position pointed to by 0x428 in the boot.bin

The Fst.bin contains all the information about the GameCube disc / Wii Partition Data files positions and sizes.

NKit modifies this file when compacting or restoring images for Wii and GameCube.

Wii: Only hacks and customs have modified file positions that are not recoverable due to the file content being modified. NKit recovery does not support moved files as there have been 0 images found that require it. Wii Recovery works at group and block level and only looks at the file system to recover gaps (junk and trailing nulls).

GameCube: There are many GameCube scrubber / compacter apps that move files. NKit can recover these using the correct recovery files.


This is documented under DiscFileSystem