The remainder of the partition is encoded as a gap. If the partition data ID is 4 null bytes then 0x440 bytes for the header is written followed by 4 bytes indicating the original partition length.Only read as many hashes are there are blocks Care must be taken to calculate the last group. The length can be calculated from the hash mask. Hashes that failed to verify are stored at the end of the NKit Format partition data.Bad Conversions often error too as not all possibilities are convertable If the fst.bin is invalid then the whole filesystem (post fst) is encoded as a gap.The filesystem is compacted with the NKit Format, by encoding the gaps between files.Add 1 byte if the number of groups isn't divisible by 8 The length of this mask is 1 byte for every 8 groups in the partition. Immediately after the fst.bin follows a bit mask of flags indicating preserved hashes that didn't verify correctly.The fst.bin will be modified to reflect new file offsets System items are copied as is up to the fst.bin.Hashes are verified and removed - if any hash sector fails in a group then all the group's hashes are cached and stored at the end of the partition.It's unconfirmed if a Dev Kit uses this value The real RVT-H format stores 0 for the length in the header. The original value is preserved in the partition data at 0x210. The new partition data length is calculated without the hashes, whereas the original includes them. The partition data is unencrypted and hashes have been removed. The length is the new size of the compacted partition data and is used to restore the partition. The NKit Format only modifies 1 4 byte value - the partition length (offset 0x2bc). The partition header length is always 0x20000.
The next partition (Data or Channel) is located at 0x58000 The original partition table is backed up at 0x50000. The removed partition will have been backed up in the 'Redump' recovery folder or in the 'NkitExtracted' recovery folder if it's not a known partition. In this case offset 0x218 in the disc header will hold CRC32 of the removed partition.
RUN GCZ GAMECUBE FILES ON USB LOADER FOR WII UPDATE
The update partition can be removed in order to save space. The partition tables are modified to point to new partition offsets. If the fst.bin is invalid then the whole filesystem (post fst.bin) is encoded as a gap. The filesystem and fst.bin are modified when converting to NKit. The disc header (Boot.bin) length is 0x440. This indicates to a Dev Kit and Dolphin that the encryption and hashes aren't present. NKit also modifies the Wii header to set the bytes at 0圆0 and 0圆1 to 0x1. Wii Update partition CRC32 if removed when converting NKit CRC - makes the NKit file CRC32 equal the source CRC at 0x208 (at 0x4 in GCZ)įorced Junk ID (When Disc ID differs - rare - GameCube only) NKit places its header at 0x200 in the Wii and GameCube disc headers.
Meaning any remaining data is as compressible as possible. Wii encryption and hashes are fully recreatable and removed. Non-uniform (NonJunk) data is preserved in 256 byte blocks with a 4 byte header.
NKit Format images contain the bare minimum of data. GCZ is Dolphin's own block seekable compression format
If hardware support is required then WBFS is currently the best available and recoverable to Redump where not hacked or corrupt. Hardware support for Wii was sacrificed for smaller image sizes. Both were designed with 1:1 preservation, size and playability in mind. There are 2 NKit output formats, raw (iso) and compressed (gcz). Some corrupt and bad images are supported too, although these can error due to invalid fst.bin modifications. It supports clean / Redump images as well as scrubbed and hacked images. The NKit Format is a non-lossy format for shrinking and restoring Wii and GameCube images. It's concise and intended to be used along side the code. This is the technical detail of the NKit Format.
0 kommentar(er)
