Hacking wwt+wit: Wiimms WBFS+ISO Tools

[Wiimm]

Tendency:
"/cygdrive/c/" is equivalent to "C:\"

CGar
Try: wwt extract -a -P -d games +
The plus sign means: all images

dapps
The checksums (there are a lot of them) are stored in the images and there are no differences between ISO, WBFS, WDF, GCX, ...
here are some info links:
* http://wit.wiimm.de/wit/cmd-verify.html#intro
* http://wiiki.wii-homebrew.com/Wii-Image#Interner_Aufbau_eines_Images (german)
The command VERIFY simply compares the calculated checksums with the stored checksums.

An error in the free-blocks table may result ion an shared block, so one game may overwrite another one. And the checksum test find overwritten blocks, because the key for the decryption (needed before checksum calculation) is different.

 

[dapps]

Wiimm, can I assume that I won't have problems with shared blocks because each game is in their own WBFS file (my hard drive is formatted NTFS)?

And thanks for the link about Wii game image structures! Google translate worked surprisingly well. Now I understand why wwt and wit can simply run verify on the image itself without having to compare checksums against a remote file like CleanRip does.

 

[Wiimm]

Wiimm, can I assume that I won't have problems with shared blocks because each game is in their own WBFS file (my hard drive is formatted NTFS)?

Yes.

 

[Tendency]

Tendency:
"/cygdrive/c/" is equivalent to "C:\"

Thank you for responding. But umm, I already know that; and the workdir.d directory was not found in the equivalent "C:\" path. Is it possible that the tool created a directory that Windows cannot read/view?

 

[BullyWiiPlaza]

How do you replace a file in an ISO like when using Trucha Signer?

Building a new ISO from source files is way too slow.

 

[Wiimm]

. Is it possible that the tool created a directory that Windows cannot read/view?

I have never seen this. The script use only the usual Cygwin commands with relative pathes.

How do you replace a file in an ISO like when using Trucha Signer?

Building a new ISO from source files is way too slow.

But that's the only way with my tools.

 

[BullyWiiPlaza]

But that's the only way with my tools.

Thanks for replying! I need a command line solution to replace a file in a Wii ISO and it must be fast. Any other tool that can do this?

Since I'm editing a certain file which needs to be replaced in the ISO and sent to my harddrive there's no time to "waste". :/

 

[Wiimm]

I know only WiiScrubber, but it can only exchange files of same size.

At my linux server: Extracting and recreating a MKWii image (reduced size of about 1.4GB) < 2 minutes.
One optimization is to extract the image once and the for each new image:
* create a copy of the extracted image with hard links (about a second)
* change the files you want, but make sure that they are deleted before modifying (because of the hard links)
* create a new image

 

[BullyWiiPlaza]

One optimization is to extract the image once and the for each new image:
* create a copy of the extracted image with hard links (about a second)

Basically

wit copy "sourceFolder" "destinationFile" --overwrite --links

for optimization? I also removed some files which are never needed to speed things up.

 

[Wiimm]

about "* create a copy of the extracted image with hard links (about a second)"
linux: cp -rl "sourceFolder" "destinationFolder"

and for copying replacement files:
linux: cp --remove-destination source dest

 

[Tendency]

I have never seen this. The script use only the usual Cygwin commands with relative pathes.

Okay, then I guess I should just ask my nooby question: where is the workdir.d directory supposed to create itself? (Assuming I did not specify a destination folder beyond "workdir.d"). So it would look something like "wit extract C:\User\Downloads\MyISO.iso workdir.d". It did not appear in the same folder as the ISO, nor in any of the Wiimms folders for that matter.

 

[BullyWiiPlaza]

Okay, then I guess I should just ask my nooby question: where is the workdir.d directory supposed to create itself? (Assuming I did not specify a destination folder beyond "workdir.d"). So it would look something like "wit extract C:\User\Downloads\MyISO.iso workdir.d". It did not appear in the same folder as the ISO, nor in any of the Wiimms folders for that matter.

Try to do something like

wit extract "C:\User\Downloads\MyISO.iso" "C:\User\Downloads\Extracted"

 

[Tendency]

Try to do something like

wit extract "C:\User\Downloads\MyISO.iso" "C:\User\Downloads\Extracted"

Ahh, thank you. But I'm already aware of the fact that I should specify a path-destination for it to work properly. What I'm asking and trying to figure out, is where the "workdir.d" directory was created when I used the command in my last post. I know it's there, because I can dump the info. and also copy it; I just can't access it outside of the Wiimms interface (nor can I delete it, even through Wiimms commands, because there's no physical file source recognized). Hence, I wanted to know how the "wit extract...workdir.d" command was intended to work, as it seems I messed up somewhere along the line.

 

[Enverex]

Is it possible to have WIT resize the actual ISO partition? The files are 4.4GB by default and once scrubbed I assume they compress well, but the images themselves (for transferring between machines, etc) are still 4.4GB. Is there any way of having WIT resize the partition to what's actually needed rather than the full disc size?

"gc-shrink" scrubs then shrinks the ISO partition size for GameCube discs so I'm basically looking for the same here. Is that already possible and I've just missed the option?

 

[BullyWiiPlaza]

Is it possible to have WIT resize the actual ISO partition? The files are 4.4GB by default and once scrubbed I assume they compress well, but the images themselves (for transferring between machines, etc) are still 4.4GB. Is there any way of having WIT resize the partition to what's actually needed rather than the full disc size?

"gc-shrink" scrubs then shrinks the ISO partition size for GameCube discs so I'm basically looking for the same here. Is that already possible and I've just missed the option?

If you have a WBFS drive the ISOs are always compressed to what is actually needed. Wii Backup Manager can remove the update partition from ISOs: http://www.jesseweb.com/ent/gaming/shrinking-wii-disc-backups/ Also, you can use WinRAR to archive the ISO and save space.

 

[Enverex]

If you have a WBFS drive the ISOs are always compressed to what is actually needed. Wii Backup Manager can remove the update partition from ISOs: http://www.jesseweb.com/ent/gaming/shrinking-wii-disc-backups/ Also, you can use WinRAR to archive the ISO and save space.

I know I can compress them but that's not what I'm looking for. They're being read over a network drive so I'm trying to minimise the size of the files themselves and keep them in a seekable format (which RAR and such would not be).

 

[tmv_josue]

Use the wbfs file format:
http://wit.wiimm.de/info/iso-images.html#wbfs

wit copy "game".iso "x".wbfs -vv

 

[Enverex]

Yeah, that's what I've settled on along with the option only to copy the GAME partition. Shame there's no ISO shrinking option but this seems to work just as well.

 

[shuall]

Wiimm
When extracting gamecube isos, how do you determine file offsets (in align-files.txt)? Is that stored on the disc, or do you just find the largest multiple of 0x10 that the beginning aligns to?

 

[Wiimm]

Wiimm
When extracting gamecube isos, how do you determine file offsets (in align-files.txt)? Is that stored on the disc, or do you just find the largest multiple of 0x10 that the beginning aligns to?

For each file class, the minimal aligned value is calculated by looking the offset of all files.

Example: "0x80 = files/*.pak" means, that all *.pak files are aligned at 0x80 boundary, but not at 0x100.