Hacking Wii backup Manager for Windows

  • Thread starter Thread starter fig2k4
  • Start date Start date
  • Views Views 4,933,316
  • Replies Replies 2,996
  • Likes Likes 20
Nevermind, I'm an idiot.
blush.gif
 
Hi Wiimm,

Yes you are correct about the size it is close but trimmed iso's are still smallest. I am not sure about the Fake Signing thing. I no that trimmed iso's that I have made with WiiScrubber play fine. Can you enlighten me about the fake signing? Maybe WiiScrubber does fake signing when trimming? Anyway here are some numbers for Mario Kart starting with a full iso...

Mario Kart - 4,589,824

Partition 0 - Update
Partition 1 - Data
Partition 2 - Installer

WiiScrubber 1.4 - Save Option = ISO, Scrub Type = 0xFF, Keep Headers = Yes

The Trim function has removed the Update and Installer partitions.

Mario Kart Trimmed - 2,706,560


WiiBackupManager 0.3.8 Build 61 - Keep game partition only, Enable full scrubbing mode

All Transfers removes the Update and Installer partitions.

Mario Kart iso - 4,589,824
Mario Kart ciso - 2,912,288
Mario Kart wbfs - 2,711,552


As you can see the trimmed is the smallest. I know it is only a 5MB difference but this is not the point. I wish archived games on my computer to be as small as possible and in iso format. That would be a trimmed iso. I also wish to play the trimmed ios's with my Loader. Why convert to wbfs when iso's play fine. I am only suggesting that WBM add a trim function when creating iso's. This makes sense since you can already remove the unneeded partitions. I also suggest that transfers to FAT32 drives allow iso's. If the iso's are trimmed they will be smaller than the FAT32 file limit so why not. With the exception of dual layer games of course. I just would like to use one program WBM to manage my games...
 
MrGreg said:
I also suggest that transfers to FAT32 drives allow iso's. If the iso's are trimmed they will be smaller than the FAT32 file limit so why not. With the exception of dual layer games of course.
Wrong
Single Layer DVDs hold up to 4.7GB data - to much for the ~4GiB limit of FAT32.
Games > 4GiB I have:

Arc Rise Fantasia
Bakugan Battle Brawlers
Dance Dance Revolution - Hottest Party 3
Dead Space Extraction
Diabolik - The Original Sin
Fragile Dreams
Guitar Hero 4 - World Tour
Guitar Hero 5
Guitar Hero 6 - Warriors of Rock
Guitar Hero - Band Hero
Guitar Hero - Metallica
James Bond_ Golden Eye
Little King's Story
Metroid - Other M
Metroid Prime 3 - Corruption
Metroid Prime Trilogy
Okami
Sakura Wars - So Long My Love
Super Smash Bros. Brawl
Tales of Symphonia - Dawn of a New World
The House of the Dead - Overkill
 
If you change the data within a partition, new checksums must be calculated. And this means that the original signing becomes invalid. Because we haven't the private key it's only possible to fake sign the new image. I think, WiiScrubber does it like "wit" automatically. Such games only run on IOS with trucha bug or on cIOS.

It's your decision but I don't understand why storing a game as trimmed ISO and not as generally supported WBFS file, which is only 0.18% larger? And if really needed, a WBFS can be converted back to the original (but perhaps scrubbed) ISO.

btw: The smallest for archiving is WIA, not RAR/ZIP.
 
If begging about size, why not comparing to an iso on ntfs using ntfs logic, they appear as 4.7gb but in properties you have true size of the scrubbed iso without fakesigning, trimming and so on
currently i have >3tb on a 2tb hdd this way
 
Thanks to all for your info on this subject...

PsyBlade
QUOTE said:
Wrong
Single Layer DVDs hold up to 4.7GB data - to much for the ~4GiB limit of FAT32.

Yes this would be correct. There are certainly games that would exceed the FAT32 limit even if trimmed.


ChaosEnergy
QUOTEIf begging about size, why not comparing to an iso on ntfs using ntfs logic, they appear as 4.7gb but in properties you have true size of the scrubbed iso without fakesigning, trimming and so on
currently i have >3tb on a 2tb hdd this way

I did not realize this and I do archive my games on NTFS. This is great. I find that Wiiscrubber does not achieve this when I do a scrub only. WBM does achieve this but I am confused about one thing. It seems that I achieve the same size on disk whether I remove unneeded partitions or not. Here are my results for size on disk for Mario Kart...

Original - 4,699,979,776
Keep all partitions/Enable full scrubbing - 2,980,446,208
Keep game partition only/Enable full scrubbing - 2,980,446,208


Wiimm
Thanks for your explanation of signing. I had a look at the signing of Partition.bin within the DATA partition of a WiiScrubber trimmed image. I used WiiScrubbers/WiiPartitionBinChanger to examine the sigs. It appears that the signature of the TMD is lost. It is all zero's which can not be good. However WBM retains the TMD sig which is good. I think for me ChaosEnergy's suggestion is the best for archiving my games. However I am not sure whether to keep all partitions or just keep the data partition. Strange that the size on disc is identical. What would be your suggestion?

In summary I think I will use WBM with full scrubbing and maybe Keep game partition only to create a new iso on NTFS. This will give me a significant reduction in size as far as NTFS is concerned and retain the sigs. Then I will use WBM to transfer to WBFS on my Wii hard drive. This will ensure that I will never hit the FAT32 limit since my Wii hard drive is FAT32. What does everyone think?
 
Wiimm,

Thanks for clearing this up. Wit says that Mario Kart trimmed by WiiScrubber is fake signed so I guess it is doing the correct thing when trimming. Do you think I will have any problems with trimmed ios's that are fake signed? It kinda makes me uneasy. Also what are your thoughts about removing the Update and Channel Partitions with either WiiScrubber of WBM? Thanks for all your help on this...
 
beware that for some idiotic reason the default for scrubbing isos is writing ones (or 0xff)
spares files require zeroes (0x00) to save space
 
Thanks PsyBlade,

QUOTE said:
beware that for some idiotic reason the default for scrubbing isos is writing ones (or 0xff)
spares files require zeroes (0x00) to save space

This is the case for WiiScrubber but WBM does uses zeros by default which is good. I find that ios's that have already been scrubbed by WiiScrubber can be re-scrubbed by WBM and the 0xFF's will be replaced with 0x00's. This will make sparsing work for these ios's.

I plan on using NTFS sparsing for my archive and FAT32/WBFS for my Wii Gaming hard drive. I still do not understand why a sparsed iso with the update partition removed yields the same size as the same iso with the update partition left in tact. Can you explain this?

I am still not sure what the implications of removing the update partition are. Since I use Priiloader and block disc updates, I think it is safe to remove because updates will never occur anyway. But what about Channel and Installer partitions? I guess removing Channel partitions is OK since I do not want game channels and I will only load via my usb loader app. However the Installer partition which seems to be rare could cause a problem. For instance Mario Kart has an Installer Partition. If I examine it I notice that it will try and install "WiiBitmapFonts.arc" and "RevoKartNR.wad". I am just not sure if the installer will even run if Priiloader is blocking updates. Does anyone have and answer to these questions about the non game partitions? Thanks all...
 
I think, WiiScrubber is the only one who fills the data with FF. All other tools use seek() to jump over data holes and the operating system will then automatically create sparse files.

I have never heard that scrubbing (removing update partition and ignoring non allocated blocks within partitions) makes a game unplayable.
 
Hi Wiimm/PsyBlade,

QUOTE said:
I have never heard that scrubbing (removing update partition and ignoring non allocated blocks within partitions) makes a game unplayable.
Thanks for the input. I have tested several games without the update/channel/installer partitions (i.e. Data partition only). They all work fine.

I have solved the mystery as to why a scrubbed iso with all partitions and the same iso with just the data partition have the same sparse file size on NTFS. I decided to run a second pass on the iso that was scrubbed/keep game partition only. Bingo the second pass iso has a smaller sparse file size. This is what I would expect to see since the update partition is removed. Here is how to reproduce this starting with a virgin iso. I used Wii Sports for my test...

1. Change settings on General Tab to "Keep game partition only"/"Enable full scrubbing mode".
2. Load the virgin iso via the Files/Add tab.
3. Transfer to iso on NTFS disk via the Transfer tab. (Use a Temp folder to transfer to).
4. Remove the virgin iso file from the list via the remove tab.
5. Load the "scrubbed/game only" created iso from Step 3 via the Files/Add tab.
6. Transfer to iso on NTFS disk via the Transfer tab. (Use another Temp folder not the one in step 3. Otherwise file size will not change.)

Sparse file sizes for Wii Sports
_________________________

virgin (All Partitions not scrubbed) - 4,699,979,776 bytes
1st pass (Scrubbed/game partition only) - 481,689,600 bytes
2nd pass (Scrubbed/game partition only) - 329,580,544 bytes

Obviously the 1st pass should produce an iso that reflects the sparse file size of the scrubbed game with the data partition only. So I guess this is a bug or over site. By the way the sparse size of the second pass is very close to the size of a WBFS file created with one pass using scrub/game partition only. The WBFS file size for Wii Sports is 337,641,472 bytes which is what I would expect.

Can you guys confirm my findings? If so then how do we report this to fig? Thanks guys for your patience with me...
 
Are you sure that you have used Wii Sports? My Wii Sports has about 630 MiB scrubbed size.

I think, all steps above can be done with:
Code:
wit copy path/to/source.isoÂÂ/path/to/dest.iso --psel data
Instead of dest.iso you can also say dest.wbfs.
 
Hi Guys,

Wiimm, the wit copy command definately does work and the sparse file size is correct. Not only that but it is very fast!. Is it possible with wit to have the output.ios be in the format discname.iso. In other words can wit extract the discname and use it in creation of the output file name?

OK I decided to test older versions of WBM to see if the sparse file size is correct when using scrub/keep game only. Sure enough the problem does not exist in version 0.3.5 beta 1. The problem starts with 0.3.6 beta 1 and continues in all releases up the current 0.3.8 build 61. This definately needs to be fixed but I am not sure if fig is reading these posts. I will try and send him an email and see what happens...
 
You can use %-escapes for destination names: http://wit.wiimm.de/info/iso-images.html#esc
For windows and not running cygwin scripts I recommend using -E$ to change the escape character from % to $.

Expample:
Code:
# using the internal disc name
wit copy source.iso $n.iso -E$

# using the disc name from the title db
wit copy source.iso $t.iso -E$
 
Hi Wiimm,

Thanks the escapes work like a charm. It seems that wit can do anything. The tools are very powerful and flexible. Very nice work indeed...
 
Do you know "move"?
Code:
wit move --recurse . %P/%X --test
The --test options prevents for real changing. It's a way to rename files with a new format or to reflect the new names of a changes title database. I use it sometimes to rename all my games.

Sorry fig2k4 for off topic wit support. I like your proggi too!
 

Site & Scene News

Popular threads in this forum