This FAQ will hopefully answer any questions that have arisen while using SWiiT. Reading it from start to end can provide a good insight in to the available capabilities.
GENERAL
Wii backup images can be stored in a variety of ways. The original backup will be uncompressible. To enable it to be compressible it can be scrubbed and/or converted to another format such as wbfs. Tools are available to do all manner of things. SWiiT’s goal is to allow the restoration of such modifications back to the original disc image.
Please read the readme.txt. SWiiT is really a showcase for the SuperWiiDiscLibrary.dll which was started as programmatic way to enable .Net developers to add disc repairing to their apps. It’s a start - not a fully complete library by any means. The various apps show a few different things that can be achieved so far. The restoration ability is working and as complete as it can be.
It has been confirmed to work on Linux, however, the Configs must be edited to swap any slashes in paths from Windows ( \ ) to Linux ( / ). Hopefully Mac should work also.
Ideally you need a Wii dat file from redump.org and a nonredump dat file containing information about the known valid images. These are important to verify the original checksum information that is to be restored to.
Using the SuperWiiAuditTool (swat.exe) a backup set of full iso images can be audited and all required information will be preserved to allow it to be restored back to its original state. Update, Channel and VC partitions will be extracted and the nonredump dat will be populated with the filename and checksum information.
The iso images can then be scrubbed and shunk to wbfs for example. Then using SuperWiiUltimateUnscrubber (swuu.exe) the shrunk files can be restored back to the original state.
When using swat.exe to audit images and extract update partitions, partitions are saved in two locations Partitions and NewPartitions. If a partition has a known crc (as set in the dll.config) it will save it to Partitions. If it not known it will save it to NewPartitions. NewPartitions is not used when restoring images, they need to be moved to Partitions once you’re satisfied it’s good and not from a bad image.
SuperWiiUltimateUnscrubber (swuu.exe) will read an image file and attempt to insert any missing partitions and unscrub the partitions - testing that each group of blocks hash to match the H3 table. The H3 table’s purpose is to allow the Wii to determine if data has not been modified. It is only tested as data is read from the disc. Unscrubbing involves filling the missing areas with the original junk data. Every group of blocks must match the H3 table.
The process is:-
· Read and crc the image header (header1).
· Copy the header1 to header2 in memory for modifying
· Copy and crc the Update partition + filler. If missing write as all filler.
· Copy and crc all other partitions with junk filler data.
· Copy header2 to header3 in memory and apply the data partition header to it (ID and title etc)
· Read all the Update Partition crcs
· Brute force combine all three header’s crcs with all Update and all written non Update partition crcs.
· Compare every combination against every dat item crc
· Replace the header and Update partition if the header and Update crc match a dat crc and they’re not the ones from the source image.
· Optionally verify the destination image so confirm everything is accurate.
· Save the image to the mask used in the dll.config
· Images that have H3 errors (See the Image Failures section).
· RVT-R images have not been tested and will most likely fail.
· Scrambled images (.wii) are not support. Unscramble them first.
· Images with missing partitions that do not exist in the partitions folder.
· Region swapped images
· Fake (Trucha) signed images
· Hacked Images
COMMAND
LINE
Swuu has the same command line as all the other SWiiT apps. It’s basically a list of space separated files and masks.Paths can be relative or absolute. The apps will scan all inputs for files and collate them in to a unique set. They are processed for multipart files (rars, split etc) then sorted and processed.
Examples (all standard command line)
·
Relative path: swuu
test\*.*
· Absolute path: swuu c:\test\*.*
· Path with spaces: swuu "test path\*.*"
· Specific file: swuu "backup image.iso"
· All rar files: swuu *.r??
· All wbfs files: swuu *.wbf?
· All files in a folder: swuu path
· All files in a folder: swuu path\*.*
The above examples (and more) can be placed on the same command line space separated. For Example: swuu c:\test\*.* "test path\*.*" "backup image.iso" ..\*.* *.wbf?
Yes this is set in the app’s config. E.g. swuu.exe.config – set SearchSubfolders to false (off) or true (on).
Yes, they must be selected in the command line like *.wbf*. They are currently not supported within archives.
<appname> "<path to files>\*.iso" "<path to files>\*.wbf?"
CONFIGURATION
By default the dll.config is set up to save files relative to the current working directory (cwd). When swuu is called from the command line, the cwd is the path the command line is executed from. When files are dropped on to swuu, windows sets the cwd to the dropped file’s location.
In the dll.config: Use %exe, %pth and %src to explicitly force a specific path.
They are placeholders for paths to be used in the dll.config. They ensure the same paths are used without having to use absolute paths all over the config.
· %pth – substituted for the value in the Path configuration item.
· %exe – substituted for the path of the exe being used.
· %src – substituted for the path of the source file being processed.
Setting the Path configuration item in the dll.config allows %pth to be used as a placeholder in other paths. If Path is relative it may behave unpredictably depending on the current working directory (cwd).
If left blank it will default the the cwd. If not absolute it will be relative to the cwd. %exe can also be used in this path.
The configuration required by the core dll has been centralised. The apps can modify the settings object in code if they need to (the provided apps do not currently do this). Having it this way simplifies configuration.
Ensure the temp path and the destination are on the same drive as the rename can cause it to copy the full image from one drive to another.
ARCHIVE
SUPPORT
The SuperWiiDiscLibrary.dll is implemented to ensure an image (iso/wbfs etc) is read in a forward only manner. It does not seek forwards and backwards through the image. This has its complications internally, but allows the image to be read from an archive as a continuous stream. SharpCompress supports streaming files from the archive so SWiiT just processes the data as it receives it.
Archiving is provided by a third party managed (all .Net) library called SharpCompress. It’s by far the most capable open source compression library available, but has some short falls. Please request enhancements and report bugs here: https://github.com/adamhathcock/sharpcompress
· During testing there has been 1 multipart rar archive that extracted nulls and not the data. This out of hundreds of tests. SharpCompress does not support multipart zips
· .001, 002… files are regarded as 1 file split into sections. SWiiT will attempt to seamlessly stitch this together. Rars etc stored as this format will need renaming to .rar, .r00, r01… if they are to be handled properly.
· When passing split archives to any SWiiT app please pass all parts or use a mask *.* etc.
IMAGE
FAILURES
If FailMatchDelete is false in the dll.config the unverified output is not deleted when processed. If an image is restored and fails to match the redump and nonredump dats it will be left unscrubbed but may not contain all the partitions the original disc had. It should be valid however with all the data from the source. Any H3 error messages means likely to be corrupt and invalid.
An H3 error is where an area of data inside a partition does not hash to match its entry in a hash table used to confirm integrity. Scrubbing invalidates all these hashes, but it’s okay because the Wii should never read them. When unscrubbing an iso all H3 checks must be valid. When they fail it’s likely that the image is corrupt or data has been scrubbed that is required. Do not keep these images.
LOG
MESSAGES
The Partitions folder is scanned when an image is to be
processed. If there are duplicate channels or VC partitions with differing crcs this message is displayed along with the start of the
duplicate filename e,g, IDID_01_N_... The first found is used. Remove
the duplicates for future processing.
The crc calculation found no matches so this image will not have its header replaced.
The crc calculation found that the existing header was correct.
The crc calculation found no matches so this image will not have its update partition replaced.
The crc calculation found that the existing update partition was correct.
All channels were removed from the partition table and re-added using the known partitions. This is done when an image has been truncated to remove some, but not all channels that existed after the data partition (very rare).
The crc calculation found that a Known Partition crc (found in the dll.config) would repair the image, but the associated file was not in the Parititions folder. The required filename ends with _01234567 (the required crc)
Same as above, but output when processing the image rather than the summary.
Extra partitions were listed in the as Known Channels (found in the dll.config) but missing from the Partitions folder. The files should be named filename e,g, IDID_01_N_... The first item is the disc Id, second is the order and N can be K for Korean.
The image has not restored successfully. It is corrupt. See the Image Failures section of this FAQ.
The Disc ID was changed. This mainly happens because the Data partition header had the correct ID and Title.
The Disc Title was changed. This happens because the Data partition header had the correct ID and Title.
A summary message to indicate the Update partition was updated.
The image being processed has had its Data partition moved in to the Update filler area to save space. It has been corrected.
A summary message to indicate any channels that were added to the image.
At the time of writing this only happens if the Update
partition files have incorrect crcs in their filename
or the channels are incorrect. It could always be a bug of some sort of course.
Wii Backup Manager moves one of the VC partitions in to the first partition table from the second. This message is output when this issue has been corrected.
POST-PROCESSING
Post processing is the ability to run another app or batch file/script after processing. It’s currently only supported by swuu.exe. It can be configured in swuu.exe.config.
There are 3 configuration items:-
1. PostProcessCommandEnabled – true is on, false is off.
2. PostProcessCommand – path and name of the app or batch file/script.
3. PostProcessCommandParams – Space separated params.
The PostProcessCommandParams take placeholders to allow for flexible command line support. See the config for details.
This can be used to convert images, log, create wbfs and/or compress too.
When executing scripts the current working directory is set to the path of the script.
It is advised to use batch files for Windows. Use %res to pass the result of the restore and evaluate it. See PostProcessing\ToWbfs.bat