Hacking Wii backup Manager for Windows

[FoGBaV]

Yes ... please ... WBFS file format support ... this would be great ...

And ... an HTML-Report-Export of ALL Games ... games on HDD1 ... Games on HDD2 ... etc ...

i'm loosing my orientation on all the HDDs ...8)

 

[fig2k4]

Thanks for your replies. I'll address the comments and suggestions tomorrow, I need some sleep.

I've just posted version 0.1.5 with FAT32 and WBFS file support. I have tested it a lot and it seems to be working fine. I've converted from WBFS to CISO to WBFS files and loads of different combinations. I checked the .wbfs files byte for byte against the output from wbfs_file using Hxd hex editor's file compare function and the files were identical.

As you probably know, hermes IOS 222 rev 4 is needed to use the FAT32 drives in Configurable..

A side note: Be careful when formatting drives if you're not sure what you're doing. Chances are, you've got other stuff on your FAT32 drive that you'll lose if you format. Just don't blame me

 

[OtakuGamerZ]

I've just posted version 0.1.5 with FAT32 and WBFS file support. I have tested it a lot and it seems to be working fine.

Thanks!!!!

 

[redia]

I checked the .wbfs files byte for byte against the output from wbfs_file using Hxd hex editor's file compare function and the files were identical.

I checked a couple of files.
and I confirm that too.
edit 3 please disregard this confirmation. I only checked the last chunk for each dump... should have checked all

am I missing something or there is no isociso direct conversion ?

thanks for the hard work.
Cheers,
R

edit :
I noticed you are not creating the info file.. not a big deal as we are accessing the file through your manager, but I just thought I would point it out.


edit 2 :
I am testing more files.. and there are some differences.
if you need details let me know. I will try to find what exactly.

 

[oggzee]

I've just posted version 0.1.5 with FAT32 and WBFS file support. I have tested it a lot and it seems to be working fine. I've converted from WBFS to CISO to WBFS files and loads of different combinations. I checked the .wbfs files byte for byte against the output from wbfs_file using Hxd hex editor's file compare function and the files were identical.

Nice job!
Although I am getting some differences.
I have tried it with wii sports and the n_hd_sec doesn't match, are you calling wbfs_trim(), it should take care of that.

This is hexdump from wbfs_file:
00000000 57 42 46 53 00 13 f0 00 09 15 00 00 01 00 00 00 |WBFS............|

This is hexdump from your manager:
00000000 57 42 46 53 01 18 24 00 09 15 00 00 01 00 00 00 |WBFS..$.........|

Now, if the n_hd_sec doesn't match the file size, cfg loader will refuse to load it, with an error:
hd num sector doesn't match

Also, running wbfs_file on that created file reports this:
wbfs_file.exe i:/wbfs/RSPP01.wbfs ls
hd num sector doesn't match

File size is: 668991488, that is 1306624 sectors, in hex: 0013F000 which you can see in the first hexdump.
The value in your header is: 01182400 which is 18359296 sectors, giving 9399959552 file size, which is of course the full dual layer size that the program begins with.

Also another little difference, but this is not important, it seems you use 0xFF to fill the unused padding (same as wiiscrubber does) while libwbfs uses 0x00, so the resulting .wbfs file differ in this too in the last padding block.

I hope i haven't missed something...

 

[redia]

I've just posted version 0.1.5 with FAT32 and WBFS file support. I have tested it a lot and it seems to be working fine. I've converted from WBFS to CISO to WBFS files and loads of different combinations. I checked the .wbfs files byte for byte against the output from wbfs_file using Hxd hex editor's file compare function and the files were identical.

Nice job!
Although I am getting some differences.
I have tried it with wii sports and the n_hd_sec doesn't match, are you calling wbfs_trim(), it should take care of that.

This is hexdump from wbfs_file:
00000000 57 42 46 53 00 13 f0 00 09 15 00 00 01 00 00 00 |WBFS............|

This is hexdump from your manager:
00000000 57 42 46 53 01 18 24 00 09 15 00 00 01 00 00 00 |WBFS..$.........|

Now, if the n_hd_sec doesn't match the file size, cfg loader will refuse to load it, with an error:
hd num sector doesn't match

Also, running wbfs_file on that created file reports this:
wbfs_file.exe i:/wbfs/RSPP01.wbfs ls
hd num sector doesn't match

File size is: 668991488, that is 1306624 sectors, in hex: 0013F000 which you can see in the first hexdump.
The value in your header is: 01182400 which is 18359296 sectors, giving 9399959552 file size, which is of course the full dual layer size that the program begins with.

Also another little difference, but this is not important, it seems you use 0xFF to fill the unused padding (same as wiiscrubber does) while libwbfs uses 0x00, so the resulting .wbfs file differ in this too in the last padding block.

I hope i haven't missed something...

ok I guess I don't need to give any more details.. lol.. thanks oggzee.
if I am not mistaken we don't really care about the FF padding.. or does it make a difference ?

R

 

[oggzee]

ok I guess I don't need to give any more details.. lol.. thanks oggzee.
if I am not mistaken we don't really care about the FF padding.. or does it make a difference ?
R

Yes, as i said, it's not important, it's never used.

 

[fig2k4]

Hi, I think i know where the problem is. Haven't debugged it yet, but it looks like the header isn't rewritten after the trim(). The FF are empty blocks and the num sectors are still at the full size. I'll try to find why it happens.

Edit: I've fixed the num sectors problem. I commented out the code in the trim() function, duh. And the info text file was deleted straight after it was created, silly last minute copy n paste error. I'll test some more to make sure the header is getting written correctly when the file is split.

 

[redia]

Hi, I think i know where the problem is. Haven't debugged it yet, but it looks like the header isn't rewritten after the trim(). The FF are empty blocks and the num sectors are still at the full size. I'll try to find why it happens.

Edit: I've fixed the num sectors problem. I commented out the code in the trim() function, duh. And the info text file was deleted straight after it was created, silly last minute copy n paste error. I'll test some more to make sure the header is getting written correctly when the file is split.

fig2k4,

great news.

sorry I do not mean to pressure you, but do you have any idea if you plan to implement the titles.txt ? (notice I am not asking "when"

)
about isociso.. did I miss it, or it is not implemented ?
and once again I am offering you to translate the software for you if you need

Cheers,
R

 

[Wiimm]

Also another little difference, but this is not important, it seems you use 0xFF to fill the unused padding (same as wiiscrubber does) while libwbfs uses 0x00, so the resulting .wbfs file differ in this too in the last padding block.

Filling with 0x00 is the better solution because some file systems support sparse files: If whole disc blocks contains only zero bytes there is no need to allocate disc space for that block. Most modern unix files systems supports sparse files.

 

[fig2k4]

As I suspected, it was the block allocation table that had the FFs. It was a bug in the code I converted from.

The trim() function had this..
// make all block full
memset(p->freeblks,0,p->n_wbfs_sec/8);

When it should've been...

memset(p->freeblks,0,ALIGN_LBA(p->n_wbfs_sec/8));

and in Delphi..

ZeroMemory(FreeBlocks, AlignLBA(NumWBFSSectors div 8));

So I was only filling up to the size of the table with zeros, not to the end of the block, causing the free blocks (FF) to remain.

 

[oggzee]

Most modern unix files systems supports sparse files.
Including NTFS.

QUOTE(fig2k4 @ Nov 5 2009, 01:53 PM) As I suspected, it was the block allocation table that had the FFs. It was a bug in the code I converted from.
....
So I was only filling up to the size of the table with zeros, not to the end of the block, causing the free blocks (FF) to remain.

Ah I haven't checked the offset of the 00 vs FF difference carefully, I just assumed it was a block of padding data.
Anyway, glad to hear you solved that, I take it you fixed the num_hd_sec too...

 

[oggzee]

The trim() function had this..
// make all block full
memset(p->freeblks,0,p->n_wbfs_sec/8);
When it should've been...
memset(p->freeblks,0,ALIGN_LBA(p->n_wbfs_sec/8));

This made me check if that could be a problem in the existing code, but it doesn't seem to be, because:
p->freeblks = wbfs_ioalloc(ALIGN_LBA(p->n_wbfs_sec/8));
wbfs_memset(p->freeblks,0xff,p->n_wbfs_sec/8);
And while it is true that the freeblk allocation is lba aligned, only p->n_wbfs_sec/8 is used.
The rest is already set to 0 because wbfs_ioalloc already does that (at least my variant does it)
So, the original
memset(p->freeblks,0,p->n_wbfs_sec/8);
Will work fine and changing it to
memset(p->freeblks,0,ALIGN_LBA(p->n_wbfs_sec/8));
Will be ok too.
In other words, the current wbfs_file does not have this problem.
I assume you changed this:
wbfs_memset(p->freeblks,0xff,p->n_wbfs_sec/8);
To:
SetMemory(FreeBlocks, 0xFF, AlignLBA(NumWBFSSectors div 8));
Or whatever the delphi syntax is...

 

[fig2k4]

I assume you changed this:
wbfs_memset(p->freeblks,0xff,p->n_wbfs_sec/8);
To:
SetMemory(FreeBlocks, 0xFF, AlignLBA(NumWBFSSectors div 8));
Or whatever the delphi syntax is...

That's basically what I did.

FillChar(FreeBlocks^, AlignLBA(NumWBFSSectors div 8), $FF);

If I didn't, the memory would be filled with junk anyway, not 0xFF. Since the extra part doesn't get used, the only time it matters is when it's trimmed so I think it'll be OK just to leave it like that. I could zero the memory, then set the correct size to 0xFF, but it's an extra step for nothing really eh?

I've posted version 0.1.6 with the fixes if anyone has time to test..

 

[oggzee]

That's basically what I did.

FillChar(FreeBlocks^, AlignLBA(NumWBFSSectors div 8), $FF);

If I didn't, the memory would be filled with junk anyway, not 0xFF. Since the extra part doesn't get used, the only time it matters is when it's trimmed so I think it'll be OK just to leave it like that. I could zero the memory, then set the correct size to 0xFF, but it's an extra step for nothing really eh?

I've posted version 0.1.6 with the fixes if anyone has time to test..

Yes, it's perfectly fine this way. I was just trying to clear why it works the way it is in wbfs_file, because I use:
#define wbfs_ioalloc(x) calloc(x,1)
To make sure there is never any junk in allocated memory.
(calloc will set the memory to 0, in case anyone wonders)

btw, in wbfs_file/libwfs_os.h i also commented this:

// some allocations are not cleared in libwbfs, so,
// we're using calloc to get always the same reproducible output
#define wbfs_malloc(x) calloc(x,1)
#define wbfs_ioalloc(x) calloc(x,1)

I was hoping it would be spotted, by whoever was modifying this

 

[oggzee]

I've posted version 0.1.6 with the fixes if anyone has time to test..

I have tested it with WiiPlay and it creates binary exact same files as wbfs_file.exe
I have tested it with 'all' and with 'game only' partition selection and in each case the produced files are exactly the same as with wbfs_file -a or -g.
I haven't tested it with any game that would require splits.

ps. I have added a link to your wbfs backup manager in my cfg loader first post and fat faq.

 

[fig2k4]

Nice. Thanks for testing.

 

[redia]

fig2k4,

just tested 0.1.6
the info file is there

the file are PERFECTLY identical..
I tested with two game below 2GB and two games over 2GB requiring split. all chunk are good.

R

 

[madtamski]

Brilliant, great work!

I was hoping something like this would come along

 

[FoGBaV]

Yeah ... thank you very much ... nice work !!