Hacking Wii backup Manager for Windows

[Elfish]

i donno if it has been answered yet. where are the md5 hashes stored?
of what does it calculate the md5 hash? game partition only?
could you make an online db so we can verify our wbfs files against it?

 

[fig2k4]

http://gbatemp.net/index.php?showtopic=188...t&p=2431371

The hash is quite different depending on your installation. ie. What partitions you keep, the WBFS block size (depends on the drive size), whether the source ISO or whatever was scrubbed etc. So an online database wouldn't really work.

 

[Elfish]

http://gbatemp.net/index.php?showtopic=188...t&p=2431371

The hash is quite different depending on your installation. ie. What partitions you keep, the WBFS block size (depends on the drive size), whether the source ISO or whatever was scrubbed etc. So an online database wouldn't really work.

thanks. ye an online database would be useless then

.
will storing the md5 hash inside the wbfs file break support with other tools?
tbh i'd rather like to see the wbfs file untouched and create a wbfsfilename.md5 file or w/e it could be named.
anyway it's a nice feature

 

[Wiiwu]

Instead of a single hash, it would be better if you can give us a hash for each partition that is copied, it will allow us to easily compare hash.

 

[oggzee]

Instead of a single hash, it would be better if you can give us a hash for each partition that is copied, it will allow us to easily compare hash.

This might actually be doable in a repeatable and consistent way if the granularity is set to the wii sector size (32k) instead of the wbfs sector/block size (2mb+). However it is quite a bit of work not sure how much time fig2k4 or anyone else has to spend on that

And patching would of course break the hash...

 

[fig2k4]

Instead of working at the WBFS level, maybe I should concentrate on WBFS files, since WBFS drives will probably be obsolete soon anyway. On a FAT32 drive, I could create a text file that contains whatever hashes are needed. This text file could exist without interfering with anything, since it would be ignored by anything that doesn't support it.

Also, if I hash only the used Wii disc sectors, it would be possible to have an online database too. But it was suggested that the disc usage calculations in libWBFS are flawed, so that's why I calculated the hash for the WBFS sectors, instead of the Wii disc sectors.

 

[retKHAAAN]

I wouldn't plan on WBFS being "obsolete". New softmodders may use FAT32 and many vets have switched over, however, there is still a very large amount of users who are sticking with WBFS.

 

[oggzee]

Instead of working at the WBFS level, maybe I should concentrate on WBFS files, since WBFS drives will probably be obsolete soon anyway. On a FAT32 drive, I could create a text file that contains whatever hashes are needed. This text file could exist without interfering with anything, since it would be ignored by anything that doesn't support it.
Hmm for that, the existing md5sum utility can be used saving you some effort, it can do both create and check the md5 sums, so you could just include it in the distribution and run it as an external tool.
http://www.pc-tools.net/win32/md5sums/
Also the format it creates can be used also on linux / macosx machines...

QUOTE(fig2k4 @ Dec 11 2009, 03:06 PM) Also, if I hash only the used Wii disc sectors, it would be possible to have an online database too. But it was suggested that the disc usage calculations in libWBFS are flawed, so that's why I calculated the hash for the WBFS sectors, instead of the Wii disc sectors.

That might be a problem yes, but it might also work just fine

If disc usage calculations in libwbfs are flawed, this might point them out and they could be fixed. Maybe wiimm would be willing to assist, he has quite a bit of libwbfs experience and might be able to tell what is libwbfs missing in regards to disc usage.
However all of this is quite a bit of work

 

[pepxl]

@fig2k4

still getting the termanation on failed transfers on several games now but i used the Simple WBFS File Manager 2.05 from the CFG thread and that seems to convert the games fine, also i dont no if the .txt files have been changed but when a games been converted with your app it makes a ".file" instead of a ".txt" in the 6ID - Game Name folder

 

[fig2k4]

I can safely say the .file isn't mine..

I'm starting to think the read error is caused by my direct drive to drive code. More specifically, transferring larger WBFS blocks to smaller WBFS blocks.

How did the WBFS to ISO go with the files that fail?

 

[pepxl]

I can safely say the .file isn't mine..

done a recheck and it was the other app thats produces those..... not your

How did the WBFS to ISO go with the files that fail?

i havnt had time but ill do one quick one now while i have a spare min

 

[fig2k4]

I decided to have a look at the wbfs_file source to see what I was missing. It turns out that I skipped over 1 vital function in libWBFS that would've saved me a lot of hassle, wbfs_disc_read(). Because I didn't really know the code when I was converting it, it looked like it was similar to read_wii_disc_sector()

If I noticed that, direct drive to drive would've been implemented from the start too.

Once I change to using this, all the silly errors should be gone. It probably is something in my own drive to drive code that's causing them.

 

[giantpune]

wbfs_disc_read().. lmao. that even sounds important. we better use it.

 

[fig2k4]

It took about 2 minutes to convert the function there. It took a lot longer to write write my own code that does something similar.

 

[alejandroues]

also you could add a function to rehash a .wbfs and another one to hash the files 1 by 1 (not only the missing ones)?

thats because if you cancel in the middle of hashing a file, the calculated hash is incorrect, and you cannot calculate the md5 hash again (or at least i coulnt find the option to do it)

thanks in advance

ps sorry for my bad english

 

[fig2k4]

OK, so that new function is working fine.. I can now use the WBFS disc just like an ISO.

About the MD5 Hash.. It should be possible now to calculate the hash for the used Wii sectors instead of WBFS sectors. This means that the hash would be valid, whether you're verifying an ISO, CISO, WBFS or WBFS file. The sector size wouldn't be a factor either, since you're checking each used Wii disc sector.

To make this possible, my AddDisc() can use the same technique as WiiFlow here, copying 1 Wii sector at a time to WBFS and calculating the hash using each Wii sector.

I'll need to test it, but I think that's about all that's needed. Like I mentioned, the hash should be the same regardless of the file format and WBFS sector size, but still dependent on what partitions are used.

@alejandroues
I think that function will be needed anyway, if this goes to plan..

 

[dun4cheap]

Fig, first once again, thanks for putting this app together. It simply is a 1 tool does all. I know you have been working on a lot of mission critical fixes which is important to the project. If you find yourself board somewhere in between those fixes and have a chance can you add the function to unselect duplicate games already on the ciso folder?

Thanks

 

[pepxl]

@fig2k4

sorry for the late reply

to sum up on the termanated transfers the ISO's all tranfered without a hiccup so im stumped as to why they fail as WBFS to .wbfs, but you might of solved the issue now lool

 

[fig2k4]

@dun4cheap
That shouldn't be too difficult. So, basically check for already existing ISO, CISO etc. when exporting and pop up a message with the option to de-select them? Or would you prefer an option in the select menu?

Edit:
@pepxl
I think I might just have solved it.

I'll send a test out when I've ironed out a few things.

 

[dun4cheap]

Fig, while it would be nice to have it in the select option, this way you could have it select only the games in the ciso directory then the user can decide what he would like to do with the list afterwards.

Thanks again.